720 篇博文 含有标签「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 和数十种任务类型的数据显示了三种截然不同的失败模式：稳定平台期（收益趋于平缓）、峰值回归（收益先升后崩）和选择诱导崩溃（更换示例检索策略后收益蒸发）。理解自己处于哪种模式，会改变你构建提示的方式、何时放弃少样本方案，以及是否应该转向微调。

当某家供应商宣布停用一个广泛使用的模型版本时，工程论坛上涌现出了告别帖子、请愿书和由用户撰写的迁移指南——这些用户的日常工作流都围绕着某个特定模型的行为指纹而构建。这不是软件弃用通常的走向。当你从 UI 中删除一个按钮时，用户会感到恼火。当你删除一个他们已经依赖的 AI 功能时，他们会感到失落。

这种不对称揭示了一个重要事实：弃用一个 AI 驱动的功能，从根本上比弃用传统功能更难。LLM 的行为包络——其语气、延迟特征、格式化倾向、响应长度——与功能的实际输出同样关键。用户不仅依赖 AI 做什么，更依赖它如何做。如果你的下架计划把 AI 退役当成 API 端点退役来处理，你将为这种错配付出流失代价。

大多数需要结构化LLM输出的团队都遵循同一套方案：写一个提示词说"只返回有效的JSON"，解析响应，运行Pydantic验证，失败则附上错误信息重试。这种方式在大多数情况下能用，但在生产环境中恰恰会在最糟糕的时刻失效——高负载、边缘用例输入，以及指令遵循不如GPT-4可靠的低成本模型。

语法约束生成是一种根本不同的方法。它不是礼貌地请求模型然后事后检查，而是从数学上让结构无效的输出成为不可能。模型无法输出缺失的括号、不存在的枚举值或遗漏的必填字段——因为这些token在采样前就被过滤掉了。不是不太可能，而是不可能。

大多数团队跳过了这个方法，但不应该。

大多数招聘 LLM 岗位的工程团队进行的面试大同小异：两轮 LeetCode，一个系统设计问题，可能还有一个关于 Transformer 内部机制的小测验。他们考核的重点不对 —— 而且他们自己也知道。那些在这些筛选中表现优异的候选人往往难以交付实际可用的 AI 功能，而那些在二叉搜索上栽跟头的候选人却能从零开始构建一个评估套件，并在一个下午内调试好一个产生幻觉的流水线。

能预示在 LLM 工程领域取得成功的技能，与传统机器学习或软件面试所测试的内容几乎没有交集。尚未更新招聘流程的招聘经理正在产生大量的漏选（false negatives）—— 拒绝了本可以成功的工程师 —— 而误选者（false positives）则带着扎实的 LeetCode 分数步入公司，却对模型何时在自信地胡说八道毫无直觉。