夜雨聆风为什么把文档放进向量数据库以后，RAG 还是会答错。
看完这篇文章，你会知道，问题不一定出在模型不够聪明，也不一定是向量数据库不行，而是复杂文档本身就不是一个干净的答案库。
我们先从最简单的 RAG 流程说起。
用户问一个问题。
系统把这个问题拿去向量数据库里搜索。
向量数据库返回几段相关文档。
然后大模型把用户的问题和这些搜索结果放在一起，生成一个答案。
这个流程听起来很顺。
但它有一个前提：搜出来的资料本身要清楚、一致、能回答这个问题。
真实工作里的文档，往往不是这样。
比如一家公司在 2019 年发过一版报销制度，2024 年又发了一版新制度。
新制度本来是替代旧制度的。
但如果两份文件都被放进向量数据库，用户问“现在差旅报销标准是多少”，系统可能同时搜到旧标准和新标准。
这时候大模型不是没有找到资料。
恰恰相反，它找到了太多看起来都相关的资料。
问题是，这些资料之间有版本关系，有适用时间，有废止关系。
如果系统不知道这些关系，就很容易把旧规定和新规定混在一起回答。
这就是复杂文档让 RAG 失效的第一类原因：文档本身有冲突。
这种冲突在政策、合同、法律条款、产品说明、客服知识库里都很常见。
有些文档是不同人写的。
有些文档跨了很多年。
有些内容是事实，有些只是意见。
还有些文件，表面上都在讲同一件事，但其实适用对象、时间范围、业务场景完全不同。
所以做 RAG 之前，第一步不是急着调模型参数，而是先管好文档。
哪些文档已经过期。
哪些文档只是历史记录，不能作为当前规则。
哪些文档可以被引用，哪些只能作为背景。
这些如果不先整理清楚，后面模型再强，也是在一堆互相打架的材料里找答案。
第二类问题，是用户的问题本身不够清楚。
比如用户只问一句：“这个能报销吗？”
这里面的“这个”是什么？
是住宿费、交通费，还是客户招待费？
是员工自己出差，还是替客户垫付？
是今年的规则，还是某个历史项目的规则？
如果系统直接拿这句话去检索，搜出来的结果很可能方向就偏了。
这时候更稳的做法，不是硬答，而是先追问。
这就是素材里提到的澄清循环。
澄清循环不是一个很神秘的技术。
它就是让 AI 在问题不完整、不具体、或者可能有多个解释的时候，先让用户补充条件。
比如它可以问：
你说的是哪类费用？
对应的是哪一年制度？
这个问题是要按员工政策判断，还是按客户合同判断？
问题问清楚以后，再进入检索和回答，答案才更可能对上用户真正想问的事。
第三类问题，也是最容易被忽略的一点：AI 的答案能力，不能超过数据本身。
这句话听起来有点绕，但意思很简单。
如果一个人把资料库里所有文档都读完，最后只能得出三个可能答案，那 AI 也不应该假装只有一个确定答案。
比如同一个客户合同里，正式合同写的是一个交付时间，后面的邮件补充协议又改过一次，项目会议纪要里还出现了第三种说法。
这时候系统如果只回答一个日期，看起来很干脆，但未必可靠。
更好的答案应该是：
根据正式合同，时间是 A。
根据后续补充邮件，时间可能已经调整为 B。
会议纪要里还出现过 C，但它是否具备最终效力，需要再确认。
这不是模型啰嗦。
这是模型承认数据本身存在复杂性。
很多所谓的 RAG 幻觉，其实不一定是真正的幻觉。
它可能是系统被设计成了“必须给一个确定答案”，但底层资料本来就不能支持这个确定答案。
尤其是法律意见、政策解释、历史版本、客户沟通记录这类文档，更不能把所有检索结果都当成同一种事实。
有些是正式规则。
有些是个人观点。
有些是旧版本。
有些只是某次沟通里的临时说法。
如果这些层级没有被标出来，RAG 就会把它们压平成一堆文本。
向量数据库能帮你找相似内容，但它不会天然理解哪份文件更新、哪份文件失效、哪段话是观点、哪段话是事实。
所以处理复杂文档时，可以先按三个顺序做。
第一，先清理文档库，别把不该参与回答的内容放进去。
第二，给文档补上必要的元信息，比如版本、时间、来源、适用范围、是否有效。
第三，在问题不清楚的时候，让系统先追问，而不是急着生成答案。
这样再去用向量数据库和大模型，RAG 才更像一个能工作的问答系统，而不是一个把相似文本拼起来的摘要工具。
下次遇到 RAG 答错，先别急着换模型。
先看一眼：它拿到的数据，真的足够支持那个答案吗。