RAG 系统如何规避大模型幻觉？
从“检索质量门控”到“答案逐条溯源”的生产级方案 一、为什么做了 RAG 还会幻觉？ 很多人以为 RAG 把知识库内容塞进 Prompt，模型就不会乱说。这个理解只对了一半。RAG 的确能降低幻觉，但不能自动消灭幻觉。因为系统里有两件事都可
从“检索质量门控”到“答案逐条溯源”的生产级方案
一、为什么做了 RAG 还会幻觉？
很多人以为 RAG 把知识库内容塞进 Prompt，模型就不会乱说。这个理解只对了一半。RAG 的确能降低幻觉，但不能自动消灭幻觉。因为系统里有两件事都可能出错：一是检索没有找到正确资料，二是资料找到了，但模型没有老老实实照着资料说。
核心判断：RAG 幻觉不是一个问题，而是“检索层错误”和“生成层错误”两类问题。前者要靠检索质量门控拦截，后者要靠 Prompt、引用和生成后核查压住。 |
检索层幻觉最危险，因为模型看到的是空上下文或错误上下文，却仍然会给出一个看起来很像真的答案。生成层幻觉更隐蔽，因为资料确实召回了，用户也会看到系统“有引用”，但答案里可能混入了原文没有的推断。
二、RAG 防幻觉的四层防线
规避幻觉不能只靠一句“请根据资料回答”。生产系统里更稳的做法，是把防线拆成四层：生成前约束、检索前后门控、生成后核查、结构化溯源。越往后越严格，成本和延迟也越高。
三、第一层：Prompt 强约束，先让模型知道边界
Prompt 不是万能药，但它是成本最低、必须先做的一步。关键不是写一句“根据资料回答”，而是明确告诉模型：只能使用参考资料，资料没有就拒答，每个结论都要标来源，不允许自己推断。
一个可直接落地的 System Prompt 可以这样写：
system_prompt.txt 你是企业知识库问答助手。请严格遵守以下规则： 1. 只能使用【参考资料】中的信息回答问题。 2. 如果参考资料不足，必须回答："根据现有资料，无法确认。" 3. 不得引入资料外的常识、经验、猜测或补充说明。 4. 回答中的每个关键结论都要标注来源编号，例如：[1]、[2]。 5. 如果多个资料冲突，要说明冲突点，不要自行选择看起来更合理的一方。 【参考资料】 {context} 【用户问题】 {question} |
这段 Prompt 的价值，不是让模型“更聪明”，而是让模型“更守规矩”。它给了模型一个合法出口：资料不足时可以说不知道。高风险系统里，允许拒答非常重要。
四、第二层：检索质量门控，低置信度直接拒答
如果检索召回的 chunk 本身就不相关，再强的 Prompt 也很难救回来。所以第二层要做的是质量门控：先召回 Top-K，再用 Rerank 模型打相关性分数。如果最高分低于阈值，直接拒答或转人工，不让模型在低质量上下文上硬生成。
Rerank 分数低于阈值时，系统应该拒答而不是强行编答案
阈值不能拍脑袋。更稳的做法是准备两批测试集：一批问题的答案确实在知识库里，一批问题的答案不在知识库里。跑完 Rerank 后，看两类样本的分数分布，再找一个能把二者尽量分开的切点。
python def answer_with_retrieval_gate(question: str) -> dict: candidates = retriever.search(question, top_k=20) reranked = reranker.score(question, candidates) best_score = reranked[0].score if reranked else 0.0 useful_chunks = [x for x in reranked if x.score >= 0.55] if best_score < 0.55 or not useful_chunks: return { "answer": "根据现有知识库资料，无法确认该问题。", "confidence": "low", "action": "reject_or_handoff" } return generator.answer( question=question, context=useful_chunks, require_citation=True ) |
这一步看起来会让系统“变笨”，但它能显著降低一本正经胡说的概率。对客服、金融、合规系统来说，答错比不答更危险。
五、第三层：生成后核查，像编辑审稿一样逐条检查
Prompt 和门控都属于生成前防控。问题是：模型还是可能漏掉约束，生成出没有证据支撑的句子。因此还需要生成后核查：先把答案拆成多个 claim，再检查每个 claim 是否能从召回的 chunk 中推出。
python def verify_claims(answer: str, chunks: list[dict]) -> list[dict]: claims = claim_extractor.extract(answer) verified = [] for claim in claims: evidence = evidence_matcher.find_supporting_chunks( claim=claim, chunks=chunks ) if evidence.supported: verified.append({ "claim": claim, "status": "supported", "source_ids": evidence.source_ids }) else: verified.append({ "claim": claim, "status": "unsupported", "source_ids": [] }) return verified |
生成后核查会多一次模型调用或 NLI/匹配调用，成本和延迟都会增加。因此一般不建议所有场景都默认开启。对医疗、法律、合规、合同审查这类高风险场景，可以用它换可靠性。
六、第四层：结构化输出，强制每条结论带来源
只让模型在自然语言里写“参考资料 1、2”还不够，因为程序不好校验。更稳的方式是让模型输出结构化 JSON，每个 claim 都必须带 source_ids。这样人能看，系统也能自动验证。
json { "answer": "根据资料，企业版支持离线部署，并提供私有化部署文档。", "statements": [ { "claim": "企业版支持离线部署", "source_ids": [2] }, { "claim": "企业版提供私有化部署文档", "source_ids": [5] } ], "confidence": "high" } |
拿到 JSON 后，系统可以继续做三件事：source_ids 是否真实存在；claim 和对应 chunk 是否语义匹配；如果 confidence 低，是否触发降级、追问或人工处理。
七、别只看答案，要拆开评估检索器和生成器
RAG 系统是否容易幻觉，不能只看最终答案“像不像对的”。要把检索器和生成器拆开看。检索器负责把证据找回来，生成器负责忠实使用证据。RAGAS 的 Faithfulness 指标就是衡量回答是否与检索上下文事实一致：一个回答只有当它的所有声明都能被上下文支持时，才算 faithful。
建议在线上保留这些日志：用户问题、召回 chunk、Rerank 分数、最终引用 source_ids、生成答案、核查结果、用户反馈。没有日志，就无法定位幻觉到底来自检索漏召回、召回噪声、生成乱发挥，还是知识库本身过期。
八、生产级方案：把防幻觉做成流水线
真正上线的系统，不应该把所有希望都压在 Prompt 上。更合理的流水线是：Query 改写提升召回，多路检索扩大覆盖，Rerank 门控控制质量，生成阶段强制引用，生成后再做 claim 核查，最后输出带来源的答案。
其中最基础、最值得优先落地的是“Prompt 强约束 + Rerank 门控”。这两个成本低、收益快。等业务风险变高，再逐步加结构化溯源和生成后核查。
九、不同场景怎么组合？
没有一种方案适合所有业务。普通知识库问答追求响应速度，金融法律追求可追溯，医疗合规追求低错误率。系统设计时要先确认业务风险，再决定防线开到几层。
十、落地清单：上线前至少检查这 12 项
☑ 是否区分了检索层幻觉和生成层幻觉？
☑ System Prompt 是否明确禁止使用资料外知识？
☑ 资料不足时是否允许模型回答“无法确认”？
☑ 是否记录了每次召回的 Top-K chunk 和 Rerank 分数？
☑ 是否设置了最低相关性阈值，低于阈值直接拒答？
☑ 是否要求答案标注来源编号？
☑ 是否能校验 source_ids 真实存在？
☑ 是否能发现 claim 与 source 不匹配的情况？
☑ 是否保留了线上错答样本，用于调阈值和改索引？
☑ 是否有知识库过期、权限不一致、重复文档的治理机制？
☑ 高风险场景是否开启生成后核查？
☑ 是否有转人工、追问、低置信度提示等兜底路径？
一句话总结：RAG 防幻觉不是“让模型别乱说”，而是用系统机制让它“没证据就不能说，有证据也必须标出来”。 |
要点速读
从“检索质量门控”到“答案逐条溯源”的生产级方案 一、为什么做了 RAG 还会幻觉？ 很多人以为 RAG 把知识库内容塞
- 从“检索质量门控”到“答案逐条溯源”的生产级方案 一、为什么做了 RAG 还会幻觉
- 很多人以为 RAG 把知识库内容塞
- 更多细节仍在持续更新中