702 篇博文 含有标签「llm」

我去年合作过的一个团队拥有一套包含 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 分数步入公司，却对模型何时在自信地胡说八道毫无直觉。

你发布的每一个 AI 功能，在成为产品决策之前，都首先是一个架构选择：这个模型调用是发生在用户的请求链路中，还是在用户无需等待的地方运行？这个选择通常由编写第一个原型的人做出，之后便不再被审视，并默默地决定了该功能在余下生命周期中的 p99 延迟。当事后分析（Post-mortem）询问为什么生产环境仪表盘在每周一上午 10 点变得无法使用时，答案几乎总是：某些本应属于冷路径（Cold-path）的东西被焊死在了热路径（Hot-path）中——而在 p50 时表现良好的模型，在流量扇出（Fan out）时，其 p99 的表现会变得极具灾难性。

热路径与冷路径的区别比 LLM 还要早。CQRS、流式架构、Lambda 架构——它们都在“必须立即响应”和“可以最终送达”之间划定了相同的界限。AI 工作负载的不同之处在于，走错方向的代价比以前高出了一个数量级。一个耗时 50 ms 的同步数据库查询变成 200 ms 是一次回归（Regression）。而一个在 p50 时耗时 1.2 秒的同步 LLM 调用在 p99 时变成 11 秒，则是你无意中做出的一项商业决策。

你的 LLM 供应商 SLA 涵盖了 HTTP 正常运行时间和首个 Token 到达时间。但它对于模型下个月是否仍会遵从你的格式化指令、是否会拒绝上周还能接受的请求、或者在你未测试的边缘条件下能否返回有效 JSON，只字未提。大多数工程团队是通过生产环境事故才发现这一点的——而非通过更新日志。

这就是隐性 API 契约问题。传统 API 承诺稳定、有据可查的行为；LLM 供应商只承诺一条连接。从请求发出到应用处理响应之间发生的一切，都由你自己负责。

当你给 Agent 一份 50 个工具的列表，让 LLM 自行决定调用哪个时，准确率大约在 94% 左右。还算合理，可以上线。但当这份列表增长到 200 个工具——这比任何人预期的都要快——准确率就会跌至 64%。到 417 个工具时，命中率只剩 20%。到 741 个工具时，更是跌落至 13.6%，与随机猜测在统计上没有区别。

解决方案是一种大多数团队跳过的模式：在工具分发之前运行意图分类层。不是取代 LLM，而是在它之前。分类器缩小工具命名空间，让 LLM 只看到与用户实际意图相关的工具。LLM 的推理能力保持完整，只是在一个经过筛选的相关子集上工作，而不是在一个不断膨胀的大海捞针中。

本文解释为什么团队会跳过这一步、跳过后代价几何，以及如何正确构建这个层——包括让其随时间持续优化的反馈循环。

一个安全模型在公开基准测试集上取得了 85.3% 的准确率。当研究人员用并非来自公开数据集的新型对抗性提示进行测试时，这个数字跌至 33.8%。该模型并未真正学会如何推理安全性，而是学会了识别评估数据分布。

这就是合成评估数据核心问题所在：当同一个模型家族既生成训练数据又生成测试用例时，通过评估意味着符合某个共同的统计先验，而非真正展示能力。这是一个看起来像质量保证的反馈循环，直到生产流量到来，数字对不上号才会暴露问题。

这种失败是结构性的，而非偶然的。修复它需要的不仅仅是增加更多合成样本。

Most RAG 的实现都以同样的方式失败：向量搜索检索到了看起来合理但并非用户真正需要的内容，LLM 用自信的辞令对其进行包装，最终用户得到一个大体正确但细节错误的答案。令人沮丧的是，这种失败模式是隐形的 —— 余弦相似度分数看起来很正常，检索到的片段也提到了正确的主题，但答案仍然是错的，因为问题需要跨关系进行推理，而不仅仅是语义上的接近。

向量嵌入 (Vector embeddings) 擅长一件事：找到听起来 像 你查询内容的文本。这是一种强大的能力，涵盖了极广的生产用例。但当问题取决于实体之间如何 连接（而非它们的描述有多匹配）时，这种方式就会出现可预见的失效。对于这类查询，知识图谱 —— 一种你可以通过 Cypher 或 SPARQL 遍历的属性图 —— 不仅仅是一种优化。它是一种从根本上不同的检索方式，解决的是另一类问题。

你的模型说“我非常有信心”，但 40% 的时间都是错的。这不叫幻觉——这是校准失败，而且在生产环境中，这是一个更难检测、衡量和修复的问题。

幻觉占据了所有媒体头条。但过度自信的错误答案往往更危险：模型以极高的表达置信度生成一个看似合理、流利的回答，而下游消费者完全收不到任何异常信号。幻觉检测器、RAG 依据性检查和事实核查流水线都有助于处理凭空捏造的内容。但对于模型知道事实却对其确定性存在系统性错误校准的情况，这些手段几乎无能为力。

大多数发布基于 LLM 功能的团队都将置信度视为事后才考虑的事情。这篇文章将探讨为什么校准会失败、如何衡量它，以及在生产环境中真正能改善这一指标的设计模式。