很多人第一次接触 RAG（Retrieval-Augmented Generation，检索增强生成）时，会有一个很自然的理解：

大模型自己会胡说，那我给它接一个知识库，让它先查资料再回答，不就不会胡说了吗？

这个思路没错，但只对了一半。

RAG 的确是目前降低大模型事实性错误、补充私有知识和更新知识最常用的方法之一。最早的 RAG 工作，就是把模型参数里的“内部记忆”和外部可检索知识结合起来，让生成结果更具体、更可更新，也更容易追溯来源。

但 RAG 从来不等于“事实数据库直出答案”。

它更像是：在模型回答之前，有一个搜索系统先从一堆资料里挑出几段“可能相关”的内容，然后把这些内容和问题一起塞给大模型。最后真正组织语言、做判断、拼接结论的，仍然是生成模型。

所以，RAG 解决的是“模型回答时能不能看到外部知识”，而不是“模型看到知识以后一定会严格按照知识回答”。

这也是为什么一个 RAG 系统完全可能出现一种很迷惑的现象：资料明明接进去了，回答甚至还带着引用，但内容依然错得很自信。

一、先把 RAG 拆开：它其实是一条流水线

一个最简单的 RAG，大致可以写成：

用户问题
   ↓
查询处理
   ↓
向量检索 / 关键词检索
   ↓
得到 Top-K 文档片段
   ↓
重排、过滤、拼接上下文
   ↓
大模型生成回答
   ↓
引用 / 校验 / 返回结果

只要理解这条链路，就会发现一个关键问题：

最终答案的可靠性，不只取决于大模型。

前面任何一个环节出问题，错误都会被一路传递到最终回答。

2024 年 ACL 的 RAGTruth 工作专门构建了 RAG 幻觉数据集。它说明了一个很现实的问题：即便已经使用了检索增强，模型仍然会生成检索内容没有支持的说法，甚至直接生成与检索内容矛盾的说法。

换句话说，RAG 是在降低幻觉，而不是消灭幻觉。

二、第一种胡说：检索器一开始就找错了

这是最容易被忽略的一类问题。

假设知识库里有两份文件：

  • 《2025 年学生奖学金评定办法》
  • 《2026 年学生奖学金评定办法》

用户问：

今年一等奖学金要求是什么？

如果向量检索因为语义相似度，把 2025 年的文件排在最前面，而 2026 年文件没有进入 Top-K，那么对生成模型来说，它看到的“世界”就是错的。

模型可能完全忠实地阅读了上下文，也完全忠实地复述了上下文，但最终答案依然是错误的。

这时候你去改 Prompt，通常没什么用。

因为问题根本不在生成，而在检索。

2025 年 ACL 的一项研究把这种现象概括得很形象：错误或带偏差的检索结果，会继续误导后面的生成，形成一种“在幻觉之上继续幻觉”的情况。

所以评价 RAG，不能只问：

模型回答得像不像？

还要先问：

正确证据到底有没有被检索出来？

三、第二种胡说：检索到了，但只检索到半句话

RAG 系统通常不会把整本 PDF 或整份制度文件直接塞进模型，而是先做切块（Chunking）。

问题就在这里。

比如原文是：

学生申请一等奖学金，原则上要求专业排名前 10%。对于参加重大科研项目并取得突出成果者，经学院评审委员会审核，可适当放宽排名要求。

如果切块刚好把它拆成：

Chunk A：
学生申请一等奖学金，原则上要求专业排名前 10%。

Chunk B：
对于参加重大科研项目并取得突出成果者，经学院评审委员会审核，
可适当放宽排名要求。

检索时只拿到 Chunk A，模型就很容易回答：

一等奖学金必须专业排名前 10%。

这句话看起来有来源，也不是模型凭空编的，但它把“原则上”变成了“必须”，还漏掉了例外条款。

所以 “检索到了相关内容”不等于“检索到了完整证据”。

很多 RAG 项目效果差，不是 embedding 模型不够强，而是文档结构在入库时就已经被切碎了。

表格、标题层级、附件、脚注、上下文引用、跨页段落，这些东西一旦在解析阶段丢失，后面的大模型再强也补不回来。

四、第三种胡说：资料都对，但模型看错重点

再进一步。

假设检索器真的找出了 10 个相关片段，其中 2 个是核心证据，8 个只是“沾边”。

很多系统会简单粗暴地把十段文字全部拼接起来：

Context 1
Context 2
Context 3
...
Context 10

然后让模型回答。

问题是，上下文越多，不一定越安全。

噪声可能稀释真正重要的证据，多个相似文件还可能互相冲突。

更麻烦的是，模型对上下文的位置也可能敏感。ACL 2026 的 Stable-RAG 研究指出，仅仅改变检索文档的排列顺序，都可能影响模型的推理和最终回答，并引发不同程度的幻觉。

这件事很反直觉：

明明是同样几份资料，只是顺序不一样，答案怎么还能变？

但生成模型不是 SQL 引擎。

它没有一个保证“逐条读取所有证据、比较冲突、按照确定规则求值”的执行器。它仍然是在一个长上下文里，根据注意力和概率分布生成下一个 token。

五、第四种胡说：外部知识和模型自己的“记忆”打架了

RAG 还有一个非常典型的问题：参数知识和外部知识冲突。

大模型在预训练阶段已经学过大量信息。

RAG 又给它塞了一份新的资料。

理想情况下，我们希望模型遵循新的外部证据。

但实际情况并不总是如此。

例如知识库写着：

本系统从 2026 年起不再支持密码登录，仅允许统一身份认证。

而模型训练语料里大量软件系统仍然是“用户名 + 密码”。

如果 Prompt、证据强度和模型本身的指令遵循能力不够好，它可能会把两者混起来，生成：

用户可以通过统一身份认证，也可以使用用户名和密码登录。

其中后半句根本没有证据。

这类错误尤其危险，因为答案通常听起来非常合理。

六、第五种胡说：模型开始“帮你补全逻辑”

大模型最擅长的能力之一，本来就是根据已有信息补全后续内容。

这在写作里是优点，在事实问答里却可能变成风险。

假设资料只说：

项目通过学院初审后提交学校复核。

用户问：

学校复核需要几个工作日？

知识库没有答案。

一个严格系统应该回复：

当前资料中没有找到学校复核时限。

但一个普通 RAG Prompt 很可能让模型继续发挥：

学校复核通常需要 3～5 个工作日。

“3～5 个工作日”听起来非常像正常制度，甚至比“不知道”更像一个有用的回答。

问题是，它是编的。

这其实揭示了 RAG 的核心矛盾：

语言模型天然倾向于完成答案，而可信系统更需要它在证据不足时停止回答。

七、为什么它能胡说得这么自信？

因为 RAG 并没有改变大模型最底层的生成机制。

一个简化的理解是：模型仍然在做

给定：问题 + 检索上下文 + 已生成文本
预测：下一个最合适的 token

它并没有一个内部按钮叫：

事实正确 = true

也不会天然执行：

if 没有证据:
    return "不知道"

RAG 只是给它增加了更好的输入材料。

材料质量越高、约束越强，回答通常越可靠；但“更可靠”和“确定正确”完全不是一回事。

八、几个常见误区

1. Top-K 调大一点就好了？

未必。

Top-K 太小会漏证据，太大会引入噪声。

正确做法通常不是无脑增加数量，而是提高召回之后再做 rerank，并根据问题动态控制最终送给模型的上下文。

2. 换更大的模型就不会幻觉？

也不成立。

更强的模型往往能更好地理解资料，但如果检索出来的东西就是错的，它甚至可能把错误资料解释得更漂亮。

3. 让模型“必须引用来源”就安全了？

引用只能证明模型输出了一个引用标记。

它不能自动证明：

  • 这条引用真的支持前面的结论；
  • 模型没有过度推断；
  • 引用的文件没有过期；
  • 检索到的文件就是正确版本。

所以真正需要验证的是 Claim → Evidence，而不是“回答末尾有没有 [1]”。

4. 上长上下文模型，就不用 RAG 了？

长上下文解决的是“能装多少”，不是“该装什么”“证据是否可信”“冲突怎么处理”。

把几百页资料一次性塞进去，也可能只是把检索问题变成注意力分配问题。

九、工程上到底怎么降低 RAG 幻觉？

真正靠谱的方案，通常要同时管四层。

第一层：把知识库本身做好

先解决数据质量：

  • 文档版本要明确；
  • 过期制度要下线或降低优先级；
  • 标题、章节、表格结构尽量保留；
  • Chunk 不要只按固定字数硬切；
  • 给片段附带来源、时间、部门、权限等 metadata；
  • 同一事实如果存在冲突，要能够识别。

垃圾数据进入 RAG，不会 magically 变成正确答案。

第二层：把检索当搜索系统做，而不是当 Demo 做

生产环境一般至少要考虑：

  • 向量检索 + BM25 等关键词检索的 Hybrid Search；
  • Query Rewrite；
  • Metadata Filter；
  • Reranker；
  • 动态 Top-K；
  • 对时间、权限、组织范围进行过滤。

尤其是专有名词、编号、制度名称、代码、错误码这类信息，纯向量检索经常不如关键词检索稳定。

第三层：允许模型说“不知道”

这是很多系统最缺的一步。

可以明确设置 Answerability Gate：

如果检索证据不足以支持结论：
不要补充常识，不要猜测，不要根据经验推断；
明确告诉用户当前知识库没有足够信息。

这会让系统看起来没那么“聪明”，但会可靠很多。

第四层：生成以后再验证一次

不要把第一次生成直接当最终答案。

可以把回答拆成若干 claim，然后逐条检查：

结论 A → 来源 1 是否真的支持？
结论 B → 来源 2 是否真的支持？
结论 C → 没有证据 → 删除或标记不确定

对于高风险业务，还可以引入单独的 verifier、规则系统或者结构化校验。

ACL 2026 关于 RAG 错误分类的研究也强调了类似观点：真实 RAG 系统的错误来源很多，需要把错误拆成不同类型去评估，而不是只用一个“回答准确率”概括整个系统。

十、真正应该监控的，不只是最终准确率

如果要把 RAG 做成一个长期运行的系统，我更建议把指标拆开：

Retrieval Recall
正确证据有没有被召回？

Context Precision
送进模型的内容里，有多少是真正有用的？

Faithfulness
回答里的结论有多少能被上下文直接支持？

Answerability
没答案的时候，系统能不能正确拒答？

Freshness
使用的是不是最新版本资料？

Citation Correctness
引用是否真的支持对应结论？

只有这样，出问题的时候才知道该修 embedding、chunk、reranker、Prompt，还是模型本身。

否则所有问题最后都会变成一句：

大模型又胡说了。

这对排障几乎没有帮助。

结语：RAG 不是“知识外挂”，而是一条信息供应链

我更愿意把 RAG 理解成一条信息供应链。

知识库是原材料，解析和切块是加工，检索是选材，rerank 是质检，上下文组装是配送，大模型是最后的加工厂。

最后产品出了问题，你不能只盯着加工厂。

如果原材料就是旧的，检索拿错了版本，运输途中丢了一半，或者把真正重要的证据埋在几十段噪声里面，再强的模型也很难稳定地产出正确答案。

所以，一个真正可靠的 RAG 系统，重点从来不是“接上向量数据库以后能不能回答问题”，而是：

答案里的每一个关键结论，我们能不能知道它从哪里来，为什么成立；当证据不足时，系统又能不能克制住自己不去编。

做到这一步，RAG 才开始从一个 Demo，变成一个可以进入真实业务的知识系统。

参考资料

  1. Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, 2020.
    https://arxiv.org/abs/2005.11401
  2. Niu et al., RAGTruth: A Hallucination Corpus for Developing Trustworthy Retrieval-Augmented Language Models, ACL 2024.
    https://aclanthology.org/2024.acl-long.585/
  3. Hu et al., Removal of Hallucination on Hallucination: Debate-Augmented RAG, ACL 2025.
    https://aclanthology.org/2025.acl-long.770/
  4. Leung et al., Classifying and Addressing the Diversity of Errors in Retrieval-Augmented Generation Systems, EACL 2026.
    https://aclanthology.org/2026.eacl-long.147/
  5. Zhang et al., Stable-RAG: Mitigating Retrieval-Permutation-Induced Hallucinations in Retrieval-Augmented Generation, ACL 2026.
    https://aclanthology.org/2026.acl-long.1188/