为生产环境中的 LLM 构建幻觉检测流水线

你的 LLM 应用通过了每一项评估（eval）。演示看起来完美无缺。接着，一位用户询问了一个利基监管要求，模型自信地引用了一个根本不存在的法规。十二小时后，这份支持工单躺在了你的收件箱里，而那个虚假的答案早已被转发给了合规团队。这就是生产环境中的幻觉问题：并不是模型会犯错，而是它们犯错时表现出的流畅度和自信心，与它们回答正确时完全一样。

大多数团队将幻觉视为提示词（prompting）问题——增加更多上下文、调整温度（temperature）、告诉模型“仅使用提供的信息”。这些措施有所帮助，但并不能解决根本问题。事后验证（Post-hoc verification）——即在生成后检查主张，而不是寄希望于模型不产生幻觉——比任何仅限预防的策略都更便宜、更可靠，且能更好地与现有基础设施结合。

幻觉的三种类别

并非所有幻觉都是平等的，你的检测策略取决于你正在处理哪种类型。

捏造（Fabrication） 是最危险的类别。模型虚构了在任何来源中都没有根据的实体、引用、统计数据或事件。一个捏造的法律引用在语法上看起来是正确的——标准的报告格式、看似合理的卷号——但却指向了一个从未宣判的案例。研究估计，在已发表的文献中，由 AI 幻觉产生的引用目前已达数十万条。捏造需要存在性验证：检查引用的实体是否确实存在于权威来源中。

矛盾（Contradiction） 发生在模型的输出与其提供的上下文信息相冲突时。RAG 系统检索到的一份文档称季度营收为 42 亿美元，而模型的摘要却说是 48 亿美元。这是机械检测最容易实现的类别，因为你的上下文窗口中就有事实标准（ground truth）。自然语言推理（NLI）模型在这方面表现出色——它们可以分类一个主张是被源段落蕴含、中立还是矛盾。

过时的知识（Outdated knowledge） 是最微妙的失败模式。模型的参数化知识在训练时是正确的，但世界已经发生了变化。某家公司更换了 CEO，一项法规被修订，或者一个库弃用了一个函数。这类问题尤其具有误导性，因为模型以极高的自信陈述它所训练的事实，而任何提示词工程都无法解决训练数据的问题。检测需要具备新鲜感感知（freshness-aware）的检索：根据当前来源检查主张，而不是信任模型的内部知识。

每个类别都需要不同的检测机制。一个能捕获矛盾但忽略捏造的流水线会提供虚假的信心——你抓住了简单的问题，却漏掉了那些真正损害信任的问题。

生产环境检测流水线的解剖

最有效的幻觉检测架构遵循三阶段模式：分类、检测、解释。这种方法由 vLLM 的 HaluGate 等系统率先采用，通过避免对不需要的查询进行昂贵的检测，在延迟和精度之间取得了平衡。

阶段 1：哨兵分类（Sentinel classification）。 并非每个 LLM 响应都需要事实核查。创意写作、头脑风暴和寻求意见的查询可以不经检查直接通过。一个轻量级的二分类器——带有 LoRA 适配器的微调编码器模型——负责确定传入的查询是否属于事实寻求型。该分类器在 P50 下的运行时间约为 12 ms，并能过滤掉约 35% 的不需要验证的请求，从而将下游检测成本降低 70% 以上。

阶段 2：Token 级检测。 对于事实寻求型查询，Token 分类器会根据提供的上下文（工具输出、RAG 结果或其他参考来源）检查响应中的每个 Token。与其为整个响应生成一个“是否幻觉”的二进制标签，Token 级检测能准确识别哪些片段（span）缺乏支持。输入格式将上下文、问题和回答通过分隔符连接起来，分类器将每个回答 Token 标记为受支持或不受支持。连续的不受支持 Token 会合并为片段，以便生成人类可读的输出。

阶段 3：NLI 解释。 仅靠 Token 级检测会产生约 33% 的误报率，并漏掉约一半的实际幻觉。解释层对每个标记出的片段应用自然语言推理（NLI），将其分类为蕴含（entailed，可能是误报——将其过滤掉）、中立（neutral，无法核实的主张）或矛盾（contradicted，直接的事实错误）。这种三路分类映射到严重性评分，从而驱动下游决策：矛盾的响应会被拦截或标记，中立的主张会被记录以供审查，而蕴含的结果则被放行。

整个流水线的总延迟在 P50 下为 76 ms，在 P99 下为 162 ms——相对于典型 LLM 5 到 30 秒的生成时间来说微不足道。延迟随上下文长度线性增加：4K Token 约为 125 ms，16K Token 则上升至 365 ms。

Grounding：你的 Ground Truth 来源何处

一个检测流水线的好坏取决于其参考资料的质量。在生产环境中，Ground Truth 的三个实际来源是工具输出、RAG 检索结果和结构化数据。

工具输出作为 Ground Truth。 如果你的智能体（agent）调用了一个返回结构化数据的函数 —— 数据库查询、API 响应、计算结果 —— 那么该输出就是你置信度最高的参考。模型的响应应与这些工具结果保持一致。这是最简单的验证路径，因为工具输出通常是精确且机器可读的。在函数调用（function-calling）架构中，工具响应内容直接作为幻觉检测的上下文。

RAG 检索结果。 检索到的段落为知识密集型查询提供了 Grounding（依据），但它们引入了一个复杂问题：检索本身可能不足。研究表明，即使检索按相似度指标“成功”了，超过 50% 的复杂检索查询仍缺乏正确生成所需的充足上下文。你的检测流水线需要区分三种失败模式：模型在拥有正确上下文的情况下产生幻觉（生成失败）、检索到的上下文不包含答案（检索失败），或者模型正确地拒绝回答（这是上下文不足时的预期行为）。

结构化数据和知识库。 对于实体验证 —— 检查引用的个人、公司、法规或产品是否真实存在 —— 你需要对照权威来源进行查找。这不需要模型；数据库查询或 API 调用就足够了。挑战在于覆盖范围：你需要针对你的领域拥有正确的参考数据。

一个关键的设计原则是：永远不要根据模型自身的输出来验证其陈述。使用同一个 LLM 同时进行生成和验证会创建一个闭环，模型会在其中确认它自己的捏造。跨模型验证（使用不同的模型进行检查）有所帮助，但对照外部来源进行 Grounding 始终是首选。

在没有“人机回环”瓶颈的情况下衡量幻觉率

你无法修复你无法衡量的东西，如果每个陈述都需要人工审核，你就无法大规模衡量幻觉。六个自动化指标构成了一个实用的测量栈。

忠实度 (Faithfulness) 是主要指标。对于模型输出中的每一句话，检查它是否得到所提供上下文的支持。实现方式从基于 NLI 的蕴含评分到带有约束评分细则的 LLM-as-a-judge 不等。未经支持的陈述与总陈述的比率为你提供了每个响应的忠实度得分。汇总整个流量的数据以获得系统级的幻觉率。

片段级归因 (Span-level attribution) 超越了二元的忠实度，用于验证引用是否真正支持了其陈述。引用存在与否与事实准确性之间几乎没有相关性 —— 无论引用是否支持陈述，模型引用段落的频率几乎相同。你需要验证：(a) 引用的段落确实存在，(b) 它确实蕴含了其所附带的陈述。

一致性 (Consistency) 通过自我一致来捕获幻觉。对同一个查询采样多次生成，并衡量其一致性。不一致的答案表明模型是根据其先验知识而不是根据 Grounding 上下文生成的。该指标计算成本较高（需要多次生成），但能捕获单次生成指标会遗漏的一类幻觉。

上下文相关性、精确率和召回率 作为领先指标来衡量检索质量。追踪“已检索但未使用”的段落（浪费的上下文预算）以及“在上下文窗口中没有支持来源的陈述”（潜在的幻觉来源）。低上下文召回率直接预示着更高的幻觉率。

蕴含和矛盾得分 提供了针对每个陈述的严重程度分类。将这些接入告警系统：在高风险领域，发现矛盾级别的结果应触发立即升级，而中立（无法验证）的陈述可以记录并批量审核。

运营指标 —— 延迟、token 计数以及每个请求的工具调用次数 —— 与质量的相关性在你测量它们之前并不明显。消耗更多 token 或触发更多工具调用的响应往往具有更高的幻觉率，这可能是因为模型正在尝试更复杂的推理。这些指标可作为廉价的代理信号，用于确定哪些响应需要优先通过昂贵的验证。

将这些指标接入你的 CI/CD 流水线：在每次提示词（prompt）更改时运行评估，并在忠实度低于阈值时阻止合并。

语义熵：不确定性作为幻觉信号

最有前景的检测方法之一根本不分析输出，而是分析模型在生成过程中的不确定性。

语义熵 (Semantic entropy) 于 2024 年发表在《Nature》上，它计算的是生成句子含义的熵，而不是 token 本身的熵。当模型自信时，多个采样会用不同的词表达相同的含义（低语义熵）。当模型产生幻觉时，采样在语义上会发生分歧（高语义熵）。这可以检测出虚构（confabulations）—— 即随意的错误生成 —— 这是仅靠输出分析最难捕获的幻觉之一。

最初的实现有一个致命的限制：它需要 5–10 倍的正常推理计算量，因为你需要每个查询多次生成来估计熵。两项最新的进展使其具备了可部署性。

语义熵探针 (Semantic Entropy Probes, SEPs) 是在模型的隐藏状态（hidden states）上训练的线性探针，可以在不生成多个采样的情况下捕捉语义不确定性。它们在保持检测质量的同时，几乎消除了推理时的计算开销。这是最有希望看到大规模生产化应用的方法。

自适应贝叶斯估计 (Adaptive Bayesian estimation) 根据观察到的不确定性动态调整采样需求。在低不确定性场景下，它会提前终止 —— 只需要减少约 50% 的采样即可达到相当的检测性能。对于高不确定性情况，它会在信息量最大的地方投入更多采样。

实际的权衡在于：语义熵方法需要访问模型内部（隐藏状态或 logits），除非提供商公开这些数据，否则对于闭源 API 提供商来说，这些方法是行不通的。对于自托管模型，它们越来越可行。对于基于 API 的部署，你只能使用 NLI 和一致性检查等输出分析方法。

设计决策层

只有检测而没有行动只是在记录日志。你的流水线需要一个决策层，将检测结果转化为系统行为。

基于严重程度的路由 (Severity-based routing) 将检测输出映射到具体行动。与依据上下文相矛盾（严重程度 4）的情况应当拦截响应，或者用免责声明替换被标记的片段。中立或不可验证的陈述（严重程度 2）应采取较温和的处理方式——例如响应头注解、UI 中的置信度指示器，或记录标记以供批量审核。逻辑蕴含的陈述 (Entailed claims，严重程度 0) 则直接通过。

响应头模式 (The header pattern) 是现有系统集成成本最低的方式。与其修改响应体，不如将检测元数据作为 HTTP 响应头附加：是否执行了事实核查、是否检测到幻觉、哪些片段被标记，以及最高严重程度评分。下游消费者——你的前端、日志流水线或安全层——可以各自独立决定如何根据这些元数据采取行动。

选择性弃答 (Selective abstention) 是一个被低估的模式，它能带来最大的准确性提升。当你的流水线检测到提供的上下文不足以回答查询时（例如上下文召回率低、检索不确定性高），正确的行为是拒绝回答，而不是生成一个猜测性的响应。研究表明，选择性弃答能将现实世界中的准确性提高 2 到 10 倍，因为移除低置信度的响应会提高你最终返回响应的准确性。

透明降级 (Transparent degradation) 对建立信任至关重要。当你的流水线遇到寻找事实的查询但没有依据上下文（无工具结果，无 RAG 段落）时，不要默默地让响应通过。要明确将其标记为未经验证。用户和下游系统随后可以根据自己的风险承受能力进行处理。静默通过是安全的对立面——它使缺失验证与验证成功变得无法区分。

运行流水线

构建检测流水线只是工作的一半。在生产环境中运行它会引入研究论文很少提及的工程约束。

延迟预算是不容商榷的。 对于同步服务，你的检测开销在 P99 情况下需要保持在 200ms 以下，以避免明显的延迟。通过在进程内运行检测模型（例如通过 Rust 的 Candle 框架）而不是作为独立的微服务，可以将冷启动时间从几秒缩短到 500ms 以下，并将每个模型的内存占用从 2-4GB 降至 1GB 以下。在规模化场景下，没有 Python GIL 限制的真正并行是一个显著优势。

上下文长度决定成本。 检测延迟随上下文长度线性增长。在 4K token 时你尚觉从容；到 16K token 时，你就接近了同步检测的上限。对于更长的上下文，请考虑异步验证：立即返回初始响应，并将检测结果作为后续发送，允许 UI 追溯性地对被标记的陈述进行标注。

监控你的监控器。 你的检测流水线自身也有失效模式——随着模型行为变化而漂移的误报率、在特定领域语言上退化的 NLI 模型、对新查询模式分类错误的哨兵分类器。在人工标注的留出集上跟踪检测的精确率和召回率，并在指标偏移时发出警报。一个产生过多误报的检测流水线，被挫败的工程师禁用的速度会比漏掉偶尔幻觉的流水线快得多。

闭环反馈。 每一个被标记的幻觉都是一个训练信号。按主题、查询模式和来源类型汇总被标记的片段，以识别系统性弱点。如果你的模型在日期方面持续产生幻觉，那就是一个有针对性的微调或提示词工程的机会。如果幻觉集中在特定的数据源周围，那么该数据源的检索质量就需要调查。检测流水线的长期价值不仅在于捕捉单个幻觉，还在于揭示让你能够预防它们的模式。

坦诚的权衡

没有任何检测流水线能完全消除幻觉。目前最先进的系统在生产环境中能减少约 35% 未检测到的幻觉——这很有意义，但远非完美。剩下的差距是技术本身固有的：模型产生幻觉是因为它们根据概率分布生成内容，而不是在查询事实数据库。

实际的问题不是“如何防止所有幻觉？”，而是“如何让系统的可靠性变得可衡量、可改进，并对其局限性保持坦诚？”一个将其 20% 的响应标记为潜在幻觉并让用户验证的系统，比一个以同样的置信度呈现每一项输出的系统更值得信赖。检测、衡量、严重程度路由和选择性弃答——这四种能力组合成一个流水线，使 LLM 的可靠性成为一个工程问题，而不是一种祈祷。