2024年1月21日

幻觉检测与缓解：Hallucination 评测与 RAG 忠实度

幻觉（Hallucination）指大模型生成看似合理但事实错误或与给定上下文矛盾的内容，幻觉检测与缓解的核心任务是识别并降低这种现象，特别在 RAG（检索增强生成）场景中通过忠实度（Faithfulness）指标衡量生成内容是否忠实于检索...

知识库大模型评测evaluation

幻觉检测与缓解：Hallucination 评测与 RAG 忠实度

先说结论

幻觉（Hallucination）指大模型生成看似合理但事实错误或与给定上下文矛盾的内容，幻觉检测与缓解的核心任务是识别并降低这种现象，特别在 RAG（检索增强生成）场景中通过忠实度（Faithfulness）指标衡量生成内容是否忠实于检索到的上下文。

先把核心脉络捋清楚

幻觉类型对比

幻觉类型 定义 示例 检测难度
内在幻觉（Intrinsic） 生成内容与输入/上下文矛盾 上下文说"2023年"，模型输出"2025年" 中等——可对比上下文检测
外在幻觉（Extrinsic） 生成内容无法从上下文验证，但可能事实正确或错误 上下文未提及某人的毕业院校，模型自行编造 高——需要外部知识验证
事实性幻觉 输出与真实世界事实不符 编造不存在的论文、法律条文 高——需要权威知识库
忠实度违反 RAG 场景中，输出与检索内容不一致 检索到的文档说 A，模型输出 B 中等——可对比检索内容

RAG 评测指标对比（RAGAS 框架）

指标 衡量内容 计算方式 范围
Faithfulness（忠实度） 回答是否忠实于检索上下文 被上下文支持的声明数 / 总声明数 [0, 1]
Answer Relevancy 回答是否切题 回答与问题的语义相关性 [0, 1]
Context Precision 检索内容中相关部分排名是否靠前 相关 chunk 在检索结果中的位置 [0, 1]
Context Recall 检索内容是否覆盖了回答所需信息 回答中的信息在上下文中的覆盖比例 [0, 1]

原理拆开看

RAGAS Faithfulness 计算流程

  1. 声明分解（Claim Decomposition）：将模型生成的回答拆分为一组原子声明（atomic claims）。例如，"张三毕业于清华大学计算机系，2020年入职" 拆分为 "张三毕业于清华大学"、"张三的专业是计算机"、"张三2020年入职"。
  2. 逐条验证（Claim Verification）：对每个原子声明，检查是否可以从检索上下文中推断出来。
  3. 计算得分：Faithfulness = 被支持的声明数 / 总声明数。

这种方法将复杂的"忠实度"判断分解为可操作的逐步验证，但依赖于声明分解的质量和验证模型的准确性。

其他幻觉检测方法

方法 原理 优缺点
SelfCheckGPT 多次采样同一问题，检查输出一致性 无需外部知识，但只检测"不一致"而非"不正确"
FactScore 将长文本拆分为事实，逐条验证 粒度细，但依赖可靠的知识源
NLI（自然语言推理） 用蕴含模型判断上下文是否蕴含生成内容 速度快，但 NLI 模型本身的准确性有限
LLM-as-a-Judge 用强模型（如 GPT-4）评估弱模型输出的忠实度 灵活，但裁判模型可能引入偏差
检索验证 将生成内容中的关键声明在搜索引擎/知识库中验证 可靠，但成本高且覆盖不全

幻觉的根源

从模型训练角度看，幻觉的根源包括：

  • 预训练数据的噪声：训练数据本身包含错误信息
  • 知识截止日期：模型无法获取训练后的新信息
  • 解码策略：采样温度过高增加随机性，导致偏离事实
  • 指令误解：模型将"创造性"与"事实性"混淆

设计时真正要权衡什么

取舍 说明
检测精度 vs 检测延迟 实时检测要求低延迟，但精确检测（如多次采样、检索验证）耗时较长
忠实度 vs 有用性 严格限制只输出上下文中的内容可能导致回答不够有用（上下文本身信息不足）
自动评测 vs 人工评测 自动指标（Faithfulness、FactScore）覆盖面广但精度有限，人工评测精确但成本高
声明粒度 粗粒度声明容易漏检，细粒度声明增加计算成本且可能过度拆分语义
缓解策略 检索更多上下文 vs 后处理过滤 vs 提示工程 vs 模型微调——不同策略的成本和效果差异显著

容易踩的坑

  1. "看似忠实"实则幻觉：模型对检索上下文进行不当推理，表面上引用了上下文但推理过程有误。例如上下文说"A 和 B 都可能"，模型输出"A 比 B 更可能"。
  2. SelfCheckGPT 漏检一致性幻觉：如果模型"非常自信地错误"，多次采样可能产生一致的错误输出。
  3. RAG 检索失败导致的幻觉：检索器返回了无关或过时的文档，模型基于错误上下文生成看似忠实但实际错误的内容。这不是模型的错，但评测需要区分。
  4. 过度拒绝（Over-refusal）：为避免幻觉，模型过度保守，对合理问题也拒绝回答，严重影响用户体验。
  5. 声明拆分粒度不一致：不同评测框架的声明拆分策略不同，导致 Faithfulness 分数不可跨框架比较。

工程落地时我会怎么做

  • RAG 场景必须评测 Faithfulness + Context Recall：前者确保模型不瞎编，后者确保检索系统提供了足够的信息。
  • 多方法交叉验证：结合 NLI 模型、LLM-as-a-Judge 和采样一致性检测，弥补单一方法的盲区。
  • 建立幻觉案例库：收集真实场景中的幻觉案例，定期回归测试。分类标注幻觉类型（内在/外在/事实性），针对性优化。
  • 在流水线中加入实时检测：对高敏感场景（医疗、法律、金融），在生成后、展示前增加一个验证环节。
  • 监控 Faithfulness 的分布而非均值：关注 Faithfulness 分布的低尾——少数严重幻觉可能比整体均值更致命。

如果要对外讲，可以怎么概括

"幻觉是大模型落地最大的阻碍之一。在评测层面，我关注两个维度：一是通用的幻觉检测，使用 SelfCheckGPT、FactScore 等方法，核心思想是将生成内容拆分为原子声明后逐条验证；二是 RAG 场景的忠实度评测，使用 RAGAS 框架中的 Faithfulness 指标，检查回答是否可由检索上下文支持。在缓解层面，从源头（更好的检索质量）、过程（提示工程、解码策略调整）和后处理（生成后验证）三个环节入手。关键的 trade-off 是忠实度与有用性——过度追求忠实度会导致模型拒绝回答合理问题，而过于宽松又会产生幻觉。在工程实践中，我会建立幻觉案例库并持续回归测试，同时监控 Faithfulness 分布的低尾而非只看均值。"

最后记几条

  1. 幻觉分为内在（与上下文矛盾）和外在（无法验证但可能错误），内在幻觉更容易检测。
  2. RAGAS Faithfulness = 被上下文支持的声明数 / 总声明数，是 RAG 场景幻觉检测的核心指标。
  3. SelfCheckGPT 通过多次采样检测一致性——但"自信的错误"会导致漏检。
  4. RAG 的幻觉可能源于检索失败而非生成失败——评测必须同时覆盖检索和生成两个环节。
  5. 过度拒绝（Over-refusal）是幻觉缓解的常见副作用——需要在安全性和有用性之间取得平衡。

参考资料

延伸阅读