为什么幻觉率不是衡量生产级 LLM 系统的核心指标

你的 LLM 幻觉率是 3%。但你的用户仍然讨厌它。这并不矛盾 —— 而是衡量标准错误的症状。

幻觉率已成为 LLM 质量的默认头条指标，因为它很容易向利益相关者解释，且在基准测试（benchmark）中计算起来非常简单。但在生产环境中，它与用户真正关心的东西相关性很低：任务是否完成、结果是否值得信赖并足以据此行动、以及系统是否为他们节省了时间？

那些为了幻觉率而拼命优化的团队往往会发现自己陷入了死胡同。他们促使模型生成听起来很自信、看起来事实依据充分的输出，却悄无声息地在用户真正体验的维度上崩坏。在每周审查中，指标看起来很棒。但用户满意度得分却纹丝不动。

这正是古德哈特定律（Goodhart's Law）的体现：当一个指标变成目标时，它就不再是一个好的指标了。

幻觉率的结构性问题

幻觉率没有标准化的定义。根据你运行的基准测试、评分结构的构建方式、模型是否被允许弃权（abstain），以及到底什么才算作幻觉，同一模型的报告率可能从 5% 到 50% 不等。这使得跨系统比较几乎毫无意义，也无法为你提供真正需要修复什么的信号。

更深层的问题在于该指标未能捕捉到的内容。幻觉率只告诉了你一种失败模式 —— 编造 —— 却对以下方面只字未提：

• 模型是否理解了用户的实际目标
• 正确的信息最初是否被检索到了
• 响应即使在技术上准确，是否依然有用
• 失败是发生在事关重大的决策点，还是低风险的头脑风暴中

一个客服 AI 如果幻觉率为 8%（按大多数标准来看已经非常出色了），但这些幻觉集中在账单查询和退款资格回答上 —— 而这恰恰是用户期望权威准确性的地方 —— 仍然会导致灾难性的用户后果。与此同时，同一个模型在创意写作任务中自由地产生幻觉，可能根本没人在意或注意到。

幻觉率将这两种情况下的错误视为等同。但用户不这么认为。

RAG 陷阱

幻觉率与生产结果之间的不匹配在 RAG 系统中尤为明显。团队在精心挑选的基准上下文（检索成功的原始片段）上衡量幻觉率。他们针对这种情况进行优化。

在生产环境中，检索会悄无声息地失败。模型收到的文档不完整、片段过时，或者分块（chunks）包含正确的主题但包含错误的事实。然后，模型会生成忠实反映错误上下文的响应。忠实度（Faithfulness）很高。幻觉率看起来不错。但答案是错误的。

研究一致表明，在 40% 的生产案例中，即使是幻觉率极低的 RAG 系统仍会提供错误答案 —— 因为幻觉基准测试并不测试检索质量，它们假设检索问题已经解决了。当你孤立地衡量幻觉率时，你衡量的是最后一英里，却忽略了之前的五英里。

真正能揭示 RAG 失败的指标完全不同：上下文精确度（context precision，检索到的块中有多大比例是真正相关的）、上下文召回率（contextual recall，检索到的集合是否包含了正确答案所需的所有内容），以及对抗检索下的忠实度（faithfulness under adversarial retrieval，当上下文模棱两可或不完整时，模型是否能抵制生成看似合理但错误的答案）。

应该衡量什么

正确的指标框架始于这样一个问题：一次失败对你的用户和你的业务到底意味着什么代价？然后从那里反推。

任务完成率（Task completion rate）是 LLM 评估中最被低估的指标。它衡量智能体（agent）是否实现了既定目标 —— 预订已创建、邮件已发送、分析回答了实际问题。这需要基于执行的评估：不要只阅读模型的输出，要检查下游系统是否反映了预期状态。一个订票机器人说“我已经为你订好了航班”，但没有相应的预订记录，那么无论它的幻觉分数如何，其任务完成率都是 0%。

引用精确度（Citation precision）对于任何显示来源的系统都至关重要。跟踪引用的文档是否真的支持归属于它们的声明。这与幻觉率不同 —— 模型可以忠实地呈现文档，但却引用它来证明它并未提到的内容。用户如果点击进入来源并发现引用与声明不符，会立即失去信任并流失。

下游动作正确性（Downstream action correctness）是智能体系统最高信号的指标。当你的智能体生成 SQL 查询时，它返回的是语义正确的结果吗 —— 而不仅仅是语法有效的 SQL？当它起草电子邮件时，收件人的反应是否符合预期？这需要对结果（outcomes）而不仅仅是输出（outputs）进行检测，这虽然更难，但能发现真正让你付出代价的失败。

编辑率和绕过率（Edit rate and bypass rate）是来自用户的隐性质量信号。AI 生成内容的高编辑率意味着用户接受它只是为了避免从零开始，而不是因为内容本身出色。高绕过率（用户绕过 AI 功能手动操作）意味着该功能已经失去了他们的信任。这些信号收集成本极低，而且在反映真实情况方面比显式评分更真实。

多指标评估的必然性

单指标评估是大多数 AI 产品指标失效的根源。它很容易被操纵，且忽略了用户实际体验的多维性质。同时优化五个指标要比操纵一个指标难得多。

一个实际的生产评估框架至少应该追踪：

• 任务完成率：智能体是否完成了要求的任务？
• 引用精准度：来源引用是否准确？
• p95 延迟：系统是否足够快以至于可用？
• 编辑率 / 绕过率：用户是在接受输出，还是在设法绕过它？
• 单次成功结果的成本：该系统在规模化运营时是否具有经济可行性？

幻觉率可以保留在这个列表中——它并非毫无用处，只是不应作为首要指标。当它显著上升时，这是一个值得调查的信号。但如果孤立地对其进行优化，往往会产生那种在纸面上数据亮眼，但在实际应用中却令人失望的系统。

构建能反映正确信号的反馈闭环

最难的部分不是确定更好的指标，而是构建能够持续收集这些指标的监测机制。大多数团队在离线状态下对照基准测试进行评估，然后在生产反馈极少的情况下发布功能。等到他们发现离线指标无法预测生产结果时，功能已经上线，信任损失已经造成。

解决方法是在发布前闭合反馈回路。针对实时流量运行影子评估，将基准测试表现与真实查询进行对比。对系统进行埋点，以便在每个阶段（检索、上下文选择、生成、下游动作）都能发出追踪数据（spans），从而让你能够定位是哪个阶段导致了失败。构建针对抽样生产流量运行的持续评估流水线，而不仅仅是静态评估集。

当你发现离线指标与生产结果之间出现分歧时，这是系统中价值最高的信号。它会告诉你基准测试在哪些方面缺乏代表性。不要将其斥为噪声——更新你的评估方法论，以捕捉基准测试所缺失的内容。

构建可靠 AI 功能的团队，并不是那些幻觉率最低的团队。而是那些拥有最佳监测反馈闭环的团队——这些闭环足够贴近真实的用户体验，以至于当某些环节出错时，他们能在用户发现之前就察觉到。

校准问题

幻觉率在一个维度上确实有帮助：校准。一个校准良好的模型在正确时表现出自信，而在错误时表现出不确定。幻觉通常表现为“迷之自信的错误”——模型以陈述真理般的流畅度和确定性来陈述虚假内容。

测量预期校准误差（ECE）或跟踪置信度与准确度的相关性，可以让你洞察这一点，而不会将其与原始幻觉率混为一谈。一个说“我不确定，但我认为……”且结果被证明是正确的模型表现良好。一个说“答案绝对是……”却在编造事实的模型，即便其平均幻觉率看起来尚可，但在校准方面也是失败的。

校准在涉及重大利益的领域（如法律、医疗、金融）最为重要，因为自信的错误答案会造成最大的损害。如果你在这些垂直领域发布产品，校准应该是一个明确的指标，而不是一种含糊的期望。

在构建之前选择指标

决定要优化哪些指标的最佳时机，是在你编写第一个提示词（prompt）之前。定义行为契约：针对这类用户输入，成功的输出长什么样，以及你将如何验证它？什么样的失败预算是可接受的？什么是测试预言机（test oracle）——即你用来检查其是否通过的依据？

这会迫使你从一开始就思考用户结果，而不是在系统已经为其他目标优化之后再强行套用指标。它还能揭示一些情况，即所谓的“显而易见”的指标（如幻觉率）之所以被选中是因为它方便测量，而不是因为它才是正确的优化方向。

如果你在开始构建之前无法回答“任务成功是什么样的，以及我如何自动测量它”，那么你对该功能应该实现的目标还没有足够的清晰度。这个问题值得在设计阶段解决，而不是在产品上线并让用户感到沮丧之后再去处理。