RAG系统如何检测幻觉并做事实校验

可视化演示

展示RAG幻觉三大类型、多路检索交叉验证与引用溯源对齐流程，切换模式观察如何科学检测和缓解大模型幻觉问题。

幻觉成因分类

后厨里最怕的不是菜难做，而是厨师长“自由发挥”。菜谱明明写着“少许糖”，他心情一好倒进半罐；锅里的鱼只够清蒸，他偏要加剁椒；最麻烦的是菜谱缺了一页，他怕客人等，干脆按印象编了一道“家传秘方”。客人吃到的，就成了没有依据的“幻觉菜”。

在 RAG 系统里，菜谱就是检索模块从知识库捞回来的文档片段，厨师长就是大模型。系统把片段拼进提示词，让模型“基于材料回答”。可材料只是被“看见”，不代表被“服从”——模型可能只揪住一句话不放，可能从材料里推出材料没有的结论，甚至直接无中生有。要治理幻觉，第一步是给幻觉“分型”，就像厨师先分清是刀工、火候还是原料的问题。

业界把 RAG 幻觉归纳为四类。断章取义：模型抽取文档中孤立片段，脱离上下文导致原意被歪曲，典型是只引用“低盐饮食有益”却忽略“需遵医嘱”；过度推理：从材料中的相关性推出因果性、从样本推出全称结论；编造事实：输出中出现的实体、数字、条文明明在检索结果里不存在，也叫外来幻觉；上下文丢失：检索召回不足或切片过碎，模型在证据缺失的情况下硬着头皮作答。

所以质检体系的第一道工序不是“抓”，而是“分诊”。看到客人投诉菜不对，先问是哪一类：是火候过度（过度推理）、理解偏差（断章取义）、凭空捏造（编造），还是压根没进到货（上下文丢失）。分型不同，后面的校验手段完全不同。

自我校验机制

分完型，厨师长开始学着“出锅前自己尝一口”。他给自己立规矩：每道菜装盘前，对照菜谱逐一核对步骤——这一步有依据吗？那一味料是菜谱上写的吗？没有依据的，立刻挑出来。

这对应 RAG 里的自我校验（self-verification）。流程是：让模型把生成答案拆解成若干个原子主张（claim，即不可再分的事实陈述），再逐条回到检索上下文里找证据。每条主张要么找到支撑，要么被标记为“高风险主张”。这一步的关键是“拆”——把一段话拆成最小可验证单元，才能精确知道哪句站得住、哪句在裸奔。

实现上有两种主流做法：一是 LLM-as-judge，用独立的裁判提示词扮演事实警察，逐句判断主张是否被材料蕴含；二是用自然语言推理（NLI）模型打分。以 NLI 为例，模型同时编码主张与证据，输出蕴含、矛盾、中立三个类别的概率，用支持概率衡量一句主张的可靠程度：

自我校验相当于第一道自检线：成本低、速度快，但和厨师长自己尝菜一样，只能拦住“明显翻车”。尝不出来时，还得靠后面的双人采购（多路检索验证）和质检员（评估指标）来把关。

多路检索验证

为了不让厨师长一个人说了算，后厨引入“双采购制”：两位采购员各自按清单去不同的市场进货，回来当面对账。同一样食材两边都买到了，才敢写进菜单；只有一家买到，就要标注“来源待确认”。

对应到 RAG，就是多路检索交叉验证。系统用多个异构检索通道同时召回——稀疏的 BM25 关键词检索、稠密的向量语义检索、再叠加查询改写或多种召回策略——形成一个“证据矩阵”。对答案中的每个主张，统计它在几路证据里出现：多路共同命中，说明证据扎实；只有一路命中，可能是偶然噪声，需要降权或剔除。

交叉验证的数学表达很直观：假设有 K 路检索通道，每条通道对主张 c 给出一个支持分 s_k(c)，当分数超过阈值 τ 时记该路命中，把所有通道的平均命中率作为证据一致性分数：

双采购制不能保证每次都对——两家市场可能同时缺货或同时被误导——但它能极大过滤“单点噪声”。多路证据互相印证后，模型才敢把结论写进答案，这也是对付“巧言令色”的最朴素武器：让几张嘴说同一件事。

引用溯源对齐

这家餐厅还有一条规矩：每道菜上桌，必须挂食材小票编号。宾客按编号能查到采购记录：这条鱼是哪天进的、哪个供应商送的。如果小票编号编得对不上任何进货单，或者小票写着“白菜”盘子里却是“萝卜”，这道菜立刻退货。

这就是引用溯源（attribution）。RAG 系统要求模型生成答案时，为每条关键陈述显式标注来源编号，编号对应检索返回的某个片段。但这只是“形式合规”——模型完全可能编一个不存在的编号，或者把 A 片段的内容安到 B 片段头上。所以必须再做一步对齐校验：把编号对应的原文片段拉出来，与这句主张做语义比对，确认“票货一致”。

对齐校验的质量用两个指标量化：引用精确率，衡量模型标出的引用里有多少真正支撑了对应陈述；引用召回率，衡量所有需要证据支撑的陈述里，有多少被模型正确标出了引用：

小票制度的威力在于“可回溯”：一旦宾客（或质检员）对某句话存疑，顺着编号就能翻到原始材料。对不上的引用在端上前就被拦截，幻觉也就无处遁形——这是让模型承担“举证责任”的设计。

防幻觉提示策略

后厨墙上挂着一块白板，写着三条铁律：缺货就写明“沽清”，不许拿相似食材顶替；菜谱没写的步骤不许自行发挥；每道菜必须写清楚用了哪几号食材。

对应到 RAG，这就是防幻觉提示策略——把纪律写进指令，在生成前就约束行为。常用的提示有三条：一，只依据给定材料回答，不得使用内部知识补充；二，每条关键陈述必须附引用编号；三，材料中没有依据时，直接回答“资料不足，无法确认”。第三条最重要，它给了模型“认怂权”，从源头掐断编造冲动。

除了提示词，还要配检索兜底（fallback）：首轮检索的相关度低于阈值时，不急着让模型硬答，而是触发二次检索——改写查询、扩大召回范围、换个检索器再试。仍找不到足够证据，就输出拒答。用门控逻辑表示就是：

提示词不是魔法咒语，它的本质是把“不许犯错”变成“宁可少答”。就像白板铁律一样，厨师有权利说“这道菜今天做不了”，但不能骗客人说“我们就是这么做地道的”——模型的“沽清”，是用户最需要的诚实。

检测评估指标

光靠口头规矩不够，后厨引入了质检打分表。质检员每周随机抽一百道菜盲测，按固定量表记录：这道菜严格按食材小票做了吗？摆了盘却找不到依据的工序有几处？打分表把“感觉”变成数字，月度趋势一目了然。

对应到 RAG，指标中最核心的是忠实度（faithfulness），它回答的问题是：答案里有多少内容是检索上下文真正撑起来的？计算时先把答案拆成原子主张，逐一判断是否被上下文支持，然后统计占比：

忠实度之外，还有一组配套指标：答案相关性衡量回答是否切题，上下文相关性衡量检索回来的材料是否跟问题有关，引用准确率衡量溯源可靠性，幻觉拦截率衡量校验器的生产力。评测时要建一个覆盖典型问题与边界问题的黄金集（golden set），定期跑批量，观察均值与 P95，知识库一更新就回归一遍。

打分表不是为了扣厨师奖金，而是让后厨知道哪类菜最容易翻车：如果本周“断章取义”类投诉上升，就该检查食材切片是不是太碎了（检索切片过大/过小）；如果“编造”类上升，就该想想是不是该重新培训厨师（调 prompt）。指标是预警灯，不是绩优表。

工程落地实践

把整套质检体系装进真实运营，后厨做的第一件事不是开会喊口号，而是先把“质检”变成流程的一部分：晨会看投诉报表、采购对账、出菜抽查，一环扣一环。

RAG 工程落地同样讲究体系化。上线前，先建 200~500 条的评测集，覆盖真实问题分布、含 5% 以上的边界情形（材料缺失、问题模糊、多义术语），跑通基线。上线后，对每条回答实时计算忠实度与引用精确率，记录幻觉率走势；超过阈值的回答降级处理——标黄提示、附上“仅供参考”或直接转人工。

更关键的是反馈闭环：线上发现的高风险 bad case 回流到评测集，定期复盘是哪类幻觉——检索没召回？提示词约束不够？还是知识库本身过时？然后对应修正：更新知识库、调检索参数、改写 prompt，再跑回归评测，通过后才允许上线。高敏场景（医疗、法律、金融）还要加上人工抽检复核（human-in-the-loop），把阈值调得更严。

后厨最难的不是做出一道好菜，而是天天稳定地做出好菜。RAG 同理——幻觉检测与事实校验不是上线前的“一次性补丁”，而是持续运转的质量体系：分型、自检、交叉、溯源、提示、评估、复盘，七道工序缺一不可，最终形成闭环。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""RAG 幻觉检测与事实校验演示: 拆解主张 -> 证据比对 -> 忠实度打分"""import re  def extract_claims(answer):    """把回答拆成句子级原子主张"""    return [s.strip() for s in re.split(r"[。！？!?]", answer) if len(s.strip()) > 2]  def tokenize(text):    """用二元词组近似切分中文"""    return {text[i:i + 2] for i in range(len(text) - 1)}  def is_supported(claim, contexts, threshold=0.2):    """判断单个主张是否被任一检索片段支持"""    claim_set = tokenize(claim)    if not claim_set:        return False    for ctx in contexts:        ctx_set = tokenize(ctx)        union = claim_set | ctx_set        jaccard = len(claim_set & ctx_set) / max(len(union), 1)        if jaccard >= threshold:            return True    return False  def verify_answer(answer, contexts):    """事实校验主流程: 拆主张 -> 逐条核对 -> 计算忠实度"""    claims = extract_claims(answer)    details = [(c, is_supported(c, contexts)) for c in claims]    supported = sum(1 for _, ok in details if ok)    faithfulness = supported / len(details) if details else 0.0    return faithfulness, details  def demo():    contexts = [        "RAG先从知识库检索与问题相关的文档片段,"        "再把片段拼进提示词,让大模型基于材料生成回答。"        "研究显示,即便使用RAG,大模型仍可能出现与材料不符的幻觉。"    ]    ok_answer = "RAG会先从知识库检索文档,再让模型基于材料生成回答。"    bad_answer = "RAG系统完全不会产生幻觉,模型从不编造任何内容。"    for answer in (ok_answer, bad_answer):        score, details = verify_answer(answer, contexts)        print("回答:", answer)        print("忠实度: %.2f" % score)        for claim, ok in details:            print("  - %s -> [%s]" % (claim, "有依据" if ok else "无依据"))  if __name__ == "__main__":    demo()

1. claims = [s.strip() for s in re.split(r"[。！？!?]", answer) if len(s.strip()) > 2]把整段回答切成一句句“原子主张”，这是校验的最小单位
2. claim_set & ctx_set求主张与证据片段的重叠二元词，近似衡量“这句话在材料里有没有着落”
3. jaccard = len(claim_set & ctx_set) / max(len(union), 1)Jaccard 相似度，重叠越多说明越有依据
4. faithfulness = supported / len(details) if details else 0.0忠实度等于有依据主张数除以总主张数，对应正文的评估指标公式
5. if __name__ == "__main__":保证脚本可直接运行，也方便被其他模块引用

常见误区

面试题