567 篇博文 含有标签「llm」

一个法律团队的 AI 研究助手伪造了三个案例引用，并将它们混入了法庭文件中。这些引用看起来非常可信 —— 真实的法院、听起来很真实的案例名称、连贯的判决理由。在提交摘要之前，没有人发现它们。这一事件导致律所面临紧急听证会、公开道歉以及律师协会的调查。

那是 Sev-0 还是 Sev-2？答案取决于你使用的框架 —— 而传统的严重程度模型几乎每次都会给你错误的答案。

软件事故严重程度分类是为确定性系统构建的。服务要么有响应，要么没有。数据库查询要么成功，要么抛出错误。失败模式是二进制的，责任可以追溯到某个 commit，而修复方案则是回滚或补丁。AI 系统同时打破了这三个假设，如果组织将传统的严重程度框架应用于 LLM 故障，最终要么是对噪声感到恐慌，要么是将结构性故障视为偶然的异常。

你会花一个下午的时间来调整提示词（prompt）。你会移动一个句子的位置，把“classify”（分类）换成“categorize”（归类），添加一条关于边缘情况的注释，并针对笔记本中记录的少量示例进行抽查。到这一天结束时，提示词有了略微的改善——你觉得是这样。但你无法证明这一点。你没有一个可重复的基准。一周后，一位同事改动了几个词，整个系统就退化了。

这就是目前大多数团队提示词工程的现状。DSPy 是斯坦福大学给出的答案。与其手动编写指令文本，你只需声明你的 LLM 程序应该做什么，定义一个指标，然后让优化器为你编译实际的提示词。MIPRO——多提示词指令提案优化器（Multi-prompt Instruction PRoposal Optimizer）——是一种让这种方法能与人工编写的替代方案竞争（且通常优于人工编写方案）的算法。

凌晨 3 点的重试风暴通常以同样的方式开始：提供商的一次短暂抖动导致少数请求超过了速率限制，你的客户端库对此进行了重试，而这些重试落在了尚未恢复的端点上，导致更多请求失败；在 90 秒内，你的队列深度迅速飙升，而你的提供商仪表板显示你已经用满了 100% 的每分钟 Token 配额（TPM），由此产生的积压工作甚至可以用五位数的美元来衡量。事后分析会将其归结为“惊群效应（thundering herd）”。但诚实的回答是，你在一个容量多变的下游服务之上构建了一个固定吞吐量的重试策略，却忘记了排队论对此早有定论。

大多数知名的服务韧性模式是为那些吞吐量像一堵墙一样固定的下游服务设计的：例如带有连接池的数据库，或者具有已知并发限制的微服务。但 LLM 提供商并非如此。你的有效吞吐量是一个动态目标，受到你的服务层级、所选模型、Prompt 大小、响应大小、一天中的时间，以及同一提供商的其他用户是否正在微调前沿模型的影响。将它视为一根固定的管道，是我今年看到的多数 LLM 故障的根本原因。

一个团队发布了一项由 LLM 驱动的功能。它通过了安全过滤器，通过了准确性评估。但用户开始投诉。六个月后，一名研究人员运行了一项包含 300 万次对比的研究，发现该系统在输入完全相同的情况下，有 85% 的时间选择了与白人相关的名字，而选择与黑人相关的名字仅占 9%。

这不是安全问题。这是一个公平性问题，两者需要完全不同的工程应对方案。安全过滤器防范伤害。公平性检查衡量你的系统是否能为每个人产生同样优质的输出。一个模型可以满足你所有的内容策略，但仍可能诊断出黑人患者的死亡风险高于同样患病的白人患者，或者为女性生成的简历比男性更单薄。这些差异对于拦截脏话的护栏来说是不可见的。

大多数团队从未构建过第二种检查。这篇文章将探讨你为什么要构建它，以及具体如何去做。

当你的 API 成本飙升，有人建议“直接压缩上下文”时，这个方案听起来很简洁：输入更少的 token，支付更低的费用，获得同等的输出。LLMLingua 的基准测试显示，在数学推理上实现了 20 倍的压缩，而准确率仅下降了 1.5%。这听起来怎么会不好呢？

问题在于，这些基准测试衡量的是压缩后的上下文在干净、精心策划的测试集上的得分。它们没有衡量当你的智能体悄悄丢弃三轮对话前给出的约束、将代词解析到错误的实体，或者因为原始工具输出被总结掉而胡编乱造一个确切的文件路径时会发生什么。上下文压缩不仅仅是减少 token —— 它改变了模型实际看到的内容。而原始上下文与压缩版本之间的差距，正是你的系统注定会失败的地方。

大多数运行持续微调的团队都以同样的方式发现了污染问题：每周评估指标持续提升，团队欢欣鼓舞，然后某个用户反馈模型"变差了"。一旦深入排查，你才意识到你的评估基准已经悄悄地泄漏到训练数据中好几个月了。每一个看起来像能力提升的指标，其实不过是记忆。

数字比直觉更糟糕。LLaMA 2 的 MMLU 样本中有超过 16% 被污染——其中 11% 属于严重污染（超过 80% 的词元重叠）。GPT-2 在被污染的基准上比干净基准的得分高出 15 个百分点。这不是边缘案例。在持续微调循环中，污染是默认结果，除非你从架构层面明确加以防范。

你正在值班，凌晨三点，告警触发：过去一小时内 AI 聊天功能的用户满意度下降了 18%。你打开日志，却看到……什么都没有。每个请求都返回了 HTTP 200，延迟正常，没有任何报错。

这就是 AI 事故的体验。传统值班的肌肉记忆——grep 堆栈跟踪、找到异常、部署修复——在这里完全失效。系统并没有崩溃，它做的正是它被设计来做的事。只是输出结果是错的。

当 OpenAI 在 2024 年 1 月停用 text-davinci-003 时，那些将该模型名称织入业务逻辑的团队花了数周时间才将其解耦。并不是因为更换模型在技术上有多难——毕竟只是一个字符串和一次 API 调用——而是因为该模型与一切都纠缠在一起：提示词构建、响应解析、错误处理、重试逻辑，所有这些都交织在一个特定的供应商会提供答案的假设中。对于中等规模的生产系统，这类迁移的工程成本估计在 5 万至 10 万美元之间，外加一个月或更长时间的工程注意力分散。

解决方案并不新奇。这是每个后端工程师都已经熟悉的模式：依赖注入。核心洞察是，你的业务逻辑应该依赖于语言模型的抽象，而不是来自 OpenAI 或 Anthropic 的具体客户端。在启动时注入具体的实现。代码的其余部分永远不需要知道接口背后是哪个供应商。

你的文档说 /summarize 端点会返回一个简明扼要的摘要。这没错。但它每次返回的摘要都不一样，有时会遗漏关键点，偶尔在你忘记在提示词（prompt）中指定格式时返回结构化的 JSON，并在你毫不知情的模型更新后发生无声的性能退化。而这些都没有出现在文档中。

传统的 API 文档记录的是契约：给定输入 X，预期输出 Y。而 AI 驱动的功能从根本上打破了这一模式。这里没有稳定的契约可供记录。同样的提示词、同样的模型、同样的参数 —— 却会产生不同的输出。然而，团队在发布这些功能时，使用的文档风格仍与编写数据库查询文档时如出一辙：一个函数签名、一个返回类型，或许还有一句关于错误代码的说明。

你的文档所描述的内容与功能的实际表现之间的鸿沟，正是开发者信任消亡的地方。

我去年合作过的一个团队拥有一套包含 847 个测试用例的评估套件，仪表盘一片绿色，发布节奏从外部看非常有纪律。然而，他们的旗舰摘要功能开始为大约二十分之一的客户支持线程生成言之凿凿的错误摘要。该能力的评估得分在连续六个月里一直保持在 94%。当我们对这套套件进行审计时，发现问题并不在于评估在撒谎。问题在于这些评估已经悄然腐化，测量了错误的东西，惩罚了正确的模型行为，并与它们正在评估的模型共享盲点。这套套件并不是像传统测试那样以一种响亮的方式崩溃，而是像温度计一样坏掉了——无论你把它放在哪里，它都显示室温。

测试异味（Test smells）在传统软件领域已经被研究了二十年。Van Deursen 的目录、xUnit 模式分类以及更近期的工作都记录了那些看起来正常的测试如何能积极地损害代码库——通过编码错误的规范、使重构变得昂贵、以及制造让真正的 bug 隐藏得更深的虚假信心。LLM 评估是一个非常新的领域，以至于同类的文献几乎不存在，但同样的动态已经发生在我交流过的每个 AI 团队中。不同之处在于，LLM 评估异味具有传统测试所不具备的机制：训练数据重叠、随机输出、评委模型反馈循环、能力漂移。你不能只是简单地移植旧的分类体系，你需要一个新的。

构建 LLM 应用的团队总会犯同一个错误：他们等待积累足够的标注数据之后，才肯投入评估基础设施建设。他们告诉自己需要 5000 个样本，或者 10000 个。评估系统始终停留在待办事项清单上，而"感觉不错"的主观判断代替了真正的指标度量。ZenML 对 1200 个生产部署的分析发现，即便是成熟的部署，非正式的直觉判断依然普遍存在——许多团队从未真正建立起系统性的评估机制。

数据量直觉是从经典机器学习时代借来的——在那个时代，更多的标注样本确实能稳定提升模型性能。但对于 LLM 评估，这个直觉基本上是错的。对稀疏基准测试的研究表明，20–40 个精心挑选的样本就能可靠地估算完整基准的排名，而 100 个样本产生的平均绝对误差低于 1%，与使用数千个样本相比相差无几。问题不在于数据量，而在于大多数团队跳过了使小规模评估集值得信赖的结构化流程。

本文介绍这个流程的实际操作方式：如何通过主动学习选取合适的样本，如何用弱监督大规模生成噪声标签，如何借助 LLM 评判者进行冷启动，以及如何判断你的小型评估集何时可以正式使用。

一个团队在路线优化任务上测试 Gemini 3 Flash，零样本准确率达 93%。他们开始添加示例，性能一路攀升——但在添加到八个示例时，准确率骤降至 30%。这不是噪声，而是少样本饱和曲线的猛烈反噬。这是大多数工程师只有在部署了一个四个示例时看起来正常、十二个示例时却出现问题的提示之后才会发现的故障模式。

"更多示例严格意味着更好"的直觉是错的。跨 12 个 LLM 和数十种任务类型的数据显示了三种截然不同的失败模式：稳定平台期（收益趋于平缓）、峰值回归（收益先升后崩）和选择诱导崩溃（更换示例检索策略后收益蒸发）。理解自己处于哪种模式，会改变你构建提示的方式、何时放弃少样本方案，以及是否应该转向微调。