很多团队以为，把知识库内容塞进 prompt 之后，大模型就会老老实实照着资料回答，幻觉问题自然消失。但现实并非如此：检索到了内容，模型也可能不照着说；检索没召回到内容，模型更会用训练时"记住"的知识编一个听起来很对的答案。行业数据也从侧面印证了这一点------初代 RAG 的幻觉率高达 45%，引入稠密向量检索后降到 28%，直到引入查询重写、多路召回与生成验证等机制，行业平均幻觉率仍约 19%。 换句话说，幻觉不是"RAG 没做好"时才有的偶发问题，而是 RAG 系统里一个必须主动、系统地去防控的问题。
一、RAG 为什么还会幻觉？两类完全不同的来源
先说清楚"幻觉"是什么：它指模型一本正经地说了一件压根不存在的事。模型不是在撒谎，它只是在"预测下一个词"，当没有可靠依据时，就拼凑出一个"听起来合理"但内容可能错误的答案。
RAG 里的幻觉要拆成两类，它们的根源不同，解法也完全不同。
第一类是检索层幻觉------检索没有召回到相关内容。此时 prompt 里是空的或全是无关内容，模型不会说"我不知道"，而是用预训练时见过的知识编一个答案。这个答案可能和知识库内容完全相反，而且语气非常自信，用户根本看不出来。举个典型场景：知识库里写的是"7 天无理由退款"，但某次检索漏掉了这个 chunk，模型凭"常识"回答"30 天退款"，用户照做后退款失败------这就是检索层幻觉造成的实际损失。
第二类是生成层幻觉------检索到了，但模型没有严格照着说。这种更隐蔽，也更常见。相关 chunk 确实召回了，但模型在生成时"超发挥"，在资料基础上加了自己的推断、补充了原文没有的细节，甚至把两段不相关的信息混在一起拼出一个"更完整"的答案。读者很难分清哪句来自文档、哪句是模型自己加的。
一句话总结：RAG 幻觉不是"一个问题"，而是"检索层错误"和"生成层错误"两类问题。前者要靠检索质量门控拦截，后者要靠 Prompt 约束、引用核查和结构化溯源来压制。
二、四道防线：从成本最低到机制最严格
防幻觉不能只靠"在 prompt 里加一句请根据资料回答"。生产系统里更稳的做法，是把防线拆成四层，越往后越严格，成本和延迟也越高。
防线一：Prompt 强约束，先让模型知道边界
这是成本最低、最容易上手的一步。关键不是写一句"根据资料回答"，而是明确立四条规矩：只能使用参考资料中的信息回答、资料不足就明确说"无法回答"、回答时标注来源、不准推断和补充。
第一条让模型知道自己的边界------它只是个传话人，不是百科全书。第二条给了模型一个"合法的逃生出口"，让"说不知道"比"编一个合理答案"更被允许。第三条让模型在回答时主动对照原文，相当于加了一个自检动作。不过这一层主要压制生成层幻觉，对检索层幻觉帮助有限：如果 prompt 里根本没有相关内容，再强的约束也拦不住模型瞎编。
防线二：检索质量门控，检索差时直接拒答
既然检索失败时拦不住，不如在检索这一步就设一道闸：与其让模型在低质量上下文里硬生成一个"可能错"的答案，不如直接告诉用户"知识库里没有这个信息"。答错比不答更危险------一个看似智能却错误的回答，比"我不知道，请联系人工"的危害大得多。
具体做法是用 Rerank 模型给召回的候选 chunk 打 0 到 1 的相关度分，看最高分是否达到阈值。低于阈值就返回"知识库无相关信息，建议联系人工"；达标才把相关 chunk 喂给模型。阈值没有通用数字，需要按业务数据调，一般经验值在 0.3 到 0.6 之间：金融、医疗等对精度要求高的场景偏高，闲聊型问答偏低，可以先从中间值开始，根据线上误判样例上下调整。
防线一加防线二，是生产系统上线前必须做的基础配置，成本极低，却能同时压制两类幻觉：防线二负责"检索差时不让模型胡说"，防线一负责"检索还行但模型容易超发挥时把它框住"。
防线三：生成后引用核查，逐条校验有没有凭空捏造
前两道防线都在"生成之前"，万一还是漏了呢？这一层在"生成之后"做校验：模型生成完答案，再发起一次 LLM 调用充当编辑，把原始答案和 chunk 一起送进去，逐条核查每个关键声明在 chunk 里有没有对应依据。没有依据的内容就标注"无法核实"或直接删掉。
代价是多一次 LLM 调用，延迟增加、成本翻倍，所以一般只在准确性要求极高的场景（医疗问诊、法律咨询）使用。普通企业知识库问答，防线一加防线二通常已经够用。值得注意的是，检索质量对幻觉的影响往往被低估，有实践甚至发现，检索质量的提升对减少幻觉的贡献，远大于单纯堆大模型规模。
防线四：结构化输出强制溯源，让每条结论都有据可查
如果说防线三是在内容层面校验，这一层就是在格式层面约束。让模型输出结构化 JSON，每条结论都必须附上来源编号，大致如下：
json
{
"answer": "完整回答",
"statements": [
{"claim": "具体结论1", "source_ids": [1, 2]},
{"claim": "具体结论2", "source_ids": [3]}
],
"confidence": "high/medium/low"
}这一层有效有两个原因：一是模型在构建 JSON 时必须主动想"这条结论从哪条资料来的"，这个过程本身就减少了瞎编的概率------就像学生写论文必须标参考文献，自然不敢随便编；二是系统拿到 JSON 后可以做程序化验证，source_ids 里编号对应的 chunk 和 claim 明显不相关时，自动过滤掉这条结论。
三、四条防线怎么组合？
按场景递进来看：普通企业知识库和客服问答，防线一加防线二是必须做的基础配置，成本极低，能解决大半幻觉问题；金融分析、法律文档等对可信度要求高的场景，再加上防线四，让每条答案都带来源编号，用户可自行去原文核实；医疗问诊、合规审核等容错率极低的场景，四个方案全上，用延迟和成本的代价换取最高级别的准确性保证。已有工程案例显示，通过检索器调优、上下文融合与"三阶验证法"的组合，某头部券商知识库系统的事实错误率从 18.7% 降到了 5.2%。
四、结语：治幻觉，先治检索
规避幻觉没有一劳永逸的银弹。最核心的认知是：检索质量是幻觉的最大来源。检索到了正确内容，Prompt 再稍微约束一下，幻觉就已经少很多；如果检索这一步就烂，再多的生成层约束也填不了这个坑。所以，治幻觉，先治检索。
索到了正确内容，Prompt 再稍微约束一下，幻觉就已经少很多；如果检索这一步就烂，再多的生成层约束也填不了这个坑。所以，治幻觉，先治检索。
