RAG系统AI问答胡说八道？从文档解析到检索重排的幻觉排查指南

上周有个做医疗器械售后系统的朋友跟我倒苦水：他们把几百页产品使用手册、故障代码表、维修记录全部传进了AI知识库，结果AI被问到"某个型号的报警代码是什么意思"时，一本正经地编了一个不存在的报警项，连型号都对不上。这不是个例。我这两年帮不同团队调AI文档问答系统，几乎每隔一阵就会收到类似的反馈："文档都传进去了，AI怎么还在胡说八道？"

先说结论：问题大概率不在模型本身，而在你搭的那条"文档上传→解析→切片→向量化→检索→生成"的链路。每个环节都可能把正确答案弄丢，而模型又回答得又快又自信，最后只能靠想象补上缺口。这篇文章我会把我实际排查过的幻觉来源、对应修法，以及一套可复现的排查流程完整讲一遍。不管你是刚把文档塞进知识库的新手，还是已经在线上跑了一段时间RAG的开发者，应该都能从里面找到自己系统的影子。

1. 先搞清楚"胡说八道"是怎么来的：被忽略的三类幻觉源头

处理这类问题最怕一上来就动手改。你得先给幻觉分个类，因为三种幻觉的修法完全不同，甚至可能互相冲突。我通常只分成三类：检索漏了、被无关信息带偏、模型自信脑补。

1.1 检索漏了：你以为是模型的错，其实是索引的锅

这类幻觉最典型，表现是AI回答的内容和文档完全不搭界，但语气极其自然。比如你问"这台设备的质保期是多久"，知识库里明明写着"整机质保十二个月"，AI却回答"一般情况下为一年以上，以实际合同为准"。看起来很合理，但根本不是文档里的话。

我判断这类问题的第一步，永远是拿同一个问题去检索接口里跑一遍，看看召回结果的前几名里到底有没有正确答案。如果前五名全是无关片段，那问题根本不在生成阶段，而在索引阶段。常见原因包括：PDF扫描件没做OCR就直接入库，表格被解析成乱序文本，分块把一句话从中间拦腰切断，嵌入模型在专业词汇上效果太差。文档入库坏了，后面怎么调模型都白搭。

我习惯用一个很粗浅但管用的类比：这是开卷考试，你把资料塞进书包，但资料是用乱码打印的，翻遍整本书也找不到那句话。这时候你怪自己临场发挥不行，方向就找错了。

1.2 检索到了却被淹没：上下文窗口里的信息争夺战

第二种幻觉更隐蔽。你把问题拿去检索，答案明明命中了，正确的片段就在召回结果里，但AI给出的核心结论还是错的。我见过一个售后知识库，用户问"电池保修多久"，召回Top5里有电池章节，也有其他配件的保修条款，结果模型综合出来一句"电池保修两年、其他配件保修一年"，而文档真实规定是电池和其他配件都保修一年，只是适用条件不同。

问题出在哪？模型在生成时收到的不是一条孤立的正确答案，而是好几段拼接起来的上下文。正确片段可能只占其中很小一块，其余全是"相关但没用"的内容。这时候模型会倾向在整体上下文里找"最大公约数"，把几个片段的元素混在一起凑答案，特别是当正确片段出现在后排、前列又被大段无关文字占据时，它很容易被带偏。

这就像开卷考时资料确实摆在桌上，但前面垫了三页隔壁科目的笔记，你抄着抄着就不自觉把两边内容缝到一块了。

1.3 检索到了也用不上：模型"看到"和"会用"是两件事

第三种是我最常被问到的。检索返回的片段里确实有完整答案，可模型偏偏不用，非要从自己的训练记忆里找一个类似但不准确的答案。比如文档明确写"该型号最大支持功率为120W"，模型却回答"通常这类设备为150W左右"，然后还补一句"具体以说明书为准"——说明书就在它手边，它就是不读。

这里有两层原因。第一，现阶段的模型普遍有"帮忙惯性"，你问它一个问题，它倾向于给你一个有信息量的回答，而不是说"我不知道"。即便你把检索片段塞给它，它也可能把片段当成参考背景，而不是唯一依据。第二，提示词约束不够强。如果你只写了"请根据以下资料回答"，没有明确指出"只能、必须、不得使用模型自身知识"，模型的行为会非常摇摆。

在实际工程里，这三类问题经常混着出现。所以下面每一章都围绕一个环节展开，但最终你还是要用第五章的排查流程把它们拆开，再逐个击破。

2. 从上传那一刻就开始丢分：文档预处理的四个失血点

我帮人调试RAG系统，第一站永远是看上传的原始文档怎么变成索引的。这一段的血抽得最多，而且一旦抽干了，后面检索、生成环节再努力都救不回来。

2.1 非结构化文档的解析黑洞

很多人对"上传文档"的理解，就是拖一个PDF进去，系统自动"看懂"了。实际情况远没那么美好。PDF尤其是重灾区：有的是扫描件，根本没有文本层，不改OCR就入库，索引里全是一堆乱码；有的是双栏排版，解析库按单栏顺序读，两栏内容就交错在一起；有的是表格，解析后表格边框没了，单元格拍平成一行，数字和单位错位。

我见过一个团队上传协议文档，解析后表格全部左对齐展开，金额列和条款列错位。AI回答"合同第X条约定付款金额为Y"，其实那个金额根本不是那个条款的。用户拿原文一对账就炸了。

所以在正式建知识库之前，一定要做一次"可读性验证"：把解析后的纯文本导出，随机抽十页人工通读一遍。判断标准很简单——如果只有这些文字、没有原始PDF，你能不能回答出文档里的问题？如果读起来语义断裂、表格串位，那就先把解析做好再往下走。这个步骤我每次做项目都不跳过。

2.2 分块策略：为什么直接按页切一定出问题

文档解析干净之后，进入分块环节。最常见也是最省事的做法是按页切，一个PDF页面变成一个文本块。问题是页不是语义单位——一页里可能讲了两个完全不同的主题，也可能一个完整的条款从上一页跨到下一页，按页切等于把答案劈成两半，检索时哪边都凑不齐整句话。

更稳妥的做法是控制块大小和重叠。我给多数场景的建议起点是：单块500到800字符，块与块之间重叠100到150字符。500字的数据是有讲究的：太短，一个完整答案经常被拆到几个块里，检索只能捞到一半；太长，向量的语义表达会被稀释，而且一次塞进上下文的块变少。重叠窗口则用来兜底——答案恰好落在两块交界处时，前后块都能覆盖到，不至于漏掉。

如果你的文档结构规整，更推荐做语义分块：按段落、按章节标题、按列表项切，保持一个语义单元完整。工程上复杂一点，但对检索质量的提升非常明显。我经常跟人说，RAG的成败一半在分块，这句话不是夸张。

2.3 嵌入模型与文档类型的错配

分块切好了，下一步是向量化，也就是把每块文本变成一个高维向量。这一步最容易被忽略的问题是：通用嵌入模型在专业领域上效果很差。

举个例子，某工业设备知识库里高频出现"报警代码E-114"，通用嵌入模型可能把它理解成"某种错误编号"，向量会和一堆不相关的"error""异常"挤在一起。你检索"E-114怎么处理"，召回结果里全是泛泛的错误处理流程，真正的E-114条目反而排到很后面。

如果是中文文档为主，优先选择在中文语料上训练得比较充分的开源嵌入模型，比如bge、text2vec这几个系列。还有一个笨办法：拿你真实的问答对做一次小范围检索测试，比较不同嵌入模型的召回命中率。一次投入两小时，换来的是长期稳定的检索效果，这笔时间花得很值。

2.4 被忽视的元数据与标题层级

第四个失血点很少有人主动处理：切片只保留正文，把章节关系、来源文件名、页码全部丢掉了。这在两个地方会坑你。

第一，模型生成答案时没有锚点。它知道"文档里说……"，但不知道这个内容属于哪个章节、自己凭什么引用它。第二，你要做引用溯源时无从下手。我建议切片时顺手保存元数据，至少包括：来源文件、一级章节标题、页码、行号范围。生成回答后，把命中的块编号跟着答案一起返回给前端，用户点开证据就能跳到原文位置。

这一章说的四件事，没有一件特别性感，但每一个都直接影响后面检索能否命中。我见过不少团队在模型和提示词上反复折腾，最后发现根子在解析或分块。所以建议从源头开始检查，别跳步。

3. 检索才是RAG的心脏：召回与重排的工程实践

很多人把注意力放在"用什么模型""怎么写提示词"，但RAG的本质是检索增强——检索不行，增强就是负增强。这一章讲我在实践中反复调整的三件事：多路召回、重排、TopK取舍，以及最容易被忽略的拒答策略。

3.1 混合检索：向量、关键词和BM25为什么要一起上

单靠向量检索是绝大多数知识库的第一版做法，也是幻觉重灾区。向量检索擅长语义相似，比如"质保多久"能召回"保修期限"这种不同表达。但它在精确匹配上非常弱，尤其是故障代码、型号、订单编号、法条数字这类内容。你把"E-114"向量化之后，它可能在语义空间里跟"error""故障"靠得很近，跟真正的"E-114"精确条目反而没那么近。

我现在的默认方案是混合检索：一路向量语义召回，一路BM25/关键词精确召回，再用倒数排名融合（RRF）把多路结果合并。最简单的情况是，用户报一个故障代码时，BM25直接命中对应条目；用户换了种问法描述故障时，向量那路派上用场。两路互补，漏检率明显下降。

工程上可以给两路召回设置合理的候选数，比如各取20条，融合后取Top30给重排环节。数字不用死记，关键是理解为什么需要多路：没有一路检索策略能同时吃下"语义改写"和"精确编号"这两种完全不同的查询。

3.2 Rerank这一步不是可选项

召回之后直接拼上下文送进大模型，是很多知识库做得不够好的地方。向量检索返回的排序是按向量相似度来的，而向量相似度只代表"语义上有点像"，不代表"确实回答了用户的问题"。两个句子语义接近但说的根本不是一回事，这种情况太常见了。

所以我会在召回后面接一个重排（Rerank）环节。做法是把"用户问题"和"候选片段"成对喂给一个交叉编码器，逐对打分，分数高说明这条片段真正回应了问题。这一步很费算力，所以只对候选集做，比如候选50条，逐对打分后取最高的3到5条。

从实验数据上看，接上重排之后，回答正确率的提升经常是跳跃式的。原因不复杂：向量召回在Top1经常给"半相关"内容，而重排能把真正回应问题的片段捞到前面，模型拿到的上下文质量完全不同。

3.3 召回数量的权衡：TopK到底取多少

确定了检索策略，还得决定最终往生成上下文里塞多少片段。我见过有人把TopK设成10甚至更多，理由是"多给点信息，模型自己会挑"。实际效果是，正确答案被淹没在大量弱相关文本里，模型反而被带偏。

我的经验值是：重排之后取3到5条，全部片段控制在1500到2500字以内。如果两条片段互相矛盾，不要同时塞进去，先靠重排分数选一条，或者让模型对冲突内容做标注。还要算一下上下文占比：知识片段在你的输入里占比如果太低，模型对"必须基于资料回答"的感知会变弱。与其塞十段废话，不如只给它三段高质量的。

这条取舍在很多场景里比换模型更有效，因为它直接改变了模型"眼见"的信息结构。

3.4 检索不到时怎么办：拒答比胡说更重要

最后一条是心态问题。很多时候检索质量已经不错了，但用户问的问题超出知识库范围。此时AI的最佳策略是承认不知道，而不是硬答。可默认情况下模型一定会硬答，因为它的目标就是提供"有帮助"的回答。

解决办法是在重排分数上设阈值。跑一批测试问题，把正确命中的重排分数和错误命中的重排分数画出来，两者之间通常有一片空隙，阈值就取在中间。低于阈值时，让系统直接返回"知识库中暂无相关信息"，或者转人工。宁可多说几次"不知道"，也绝不能让它在保修政策、产品价格、操作安全这类话题上编内容。服务号被用户截图挂出去，代价比漏答大得多。

阈值设置还可以看业务：客服场景可以偏保守，因为答错了要赔钱；内部知识检索可以偏宽松，因为错了还能人工纠正。

4. 最后一公里：提示词设计与引用溯源

检索做对了，只代表正确答案已经摆上桌。最后能不能把它正确地端出来，取决于生成阶段的约束和设计。这一章讲提示词、结构化输出、引用溯源，以及一个常被忽略的细节：怎么让模型"只能"基于证据。

4.1 系统提示词：把约束写死

大部分"给提示词"的建议都太软了。我见过最常见的写法是"请根据以下资料回答"，这等于给模型留了一扇门：资料给得不全的时候，它随时可以用自己的知识补。我推荐的写法会把门焊死，核心就三句话：

1. 只能基于检索片段回答。
2. 检索片段里没有的信息，直接回答"未在知识库中找到相关依据"，禁止推测。
3. 每个关键结论都要标注来自哪个片段编号。

有人担心这样写模型会变得机械，实际不会。知识问答场景里，用户要的是准确，不是文采。模型是"帮忙惯性"极强的系统，你不把禁令写清楚，它永远倾向于给你编一个顺耳的回答。

4.2 结构化输出：让模型"只能"基于证据回答

比提示词更进一步的做法，是让模型输出结构化结果，而不是自由发挥的一段文字。我通常会要求返回JSON，包含答案正文、依据片段编号列表、以及是否在片段中找到依据的标志。

这样做的价值在于程序可控性。比如我可以校验：如果标志是not_found，前端就显示"未找到相关资料"；如果依据编号列表为空但答案不为空，就说明模型在编，直接拦截。这就把"防幻觉"从依赖模型自觉，变成了程序强制校验。

import json def parse_model_output(raw, required_fields=("answer", "evidence", "status")): try: obj = json.loads(raw) except ValueError: return None if not all(k in obj for k in required_fields): return None if obj["status"] != "not_found" and not obj["evidence"]: return None # 有答案但没依据，直接判为非法输出 return obj

Temperature要调低。知识问答场景我一般设0.1到0.3，不要用默认值。温度高的时候，即便是对的检索结果，模型也可能给你换一种更"有创意"的错误说法。在覆盖准确性的任务里，创造性是敌人。

4.3 引用溯源：每个结论都可回溯

引用溯源不只是一个用户体验功能，它本身就是幻觉的过滤器。当系统要求模型在每个结论后面标出依据片段，模型的行为会发生微妙变化：它更倾向于照着片段原话说，而不是自己改写发挥，因为一发挥就标不出出处了。

实现上，我在切片阶段保留的元数据这时要发挥作用。每个片段带文件、章节、页码，生成答案时返回片段的编号列表，前端把编号映射成原文链接。用户点开"证据"，能看到原文片段，配合高亮，一行一行比对。很多原本会被用户当成"胡说八道"的回答，在这个环节就被事实拦住了。

我后来给某团队加上引用后，内部投诉AI乱答的比例明显下降。倒不是说模型变聪明了，而是每次回答都能落地到原文，用户和系统之间的矛盾从"信不信AI"变成了"对一对原文数据"，后者好解决得多。

5. 不靠感觉调优：一套可复现的幻觉排查链路

到了这一章，我要解决一个核心问题：当你的系统已经上线而且开始胡说八道，怎么定位到底哪一环出了问题。我见过太多人在聊天框里试几个问题就"感觉是检索问题"或"感觉是提示词问题"，全凭感觉改，改完更差。正确做法是建立一套可复现的排查链路。

5.1 先建失败案例库

任何调优之前，先把线上的坏案例收集起来。我从日志里捞两类记录：被用户标记"回答不对"的，以及系统给了答案但明显没有依据的。每条记录要保存当时的完整请求、召回片段、最终答案、所用模型版本和提示词版本。没有这些现场信息，事后根本没法还原。

然后把坏案例分类。我自己常用的标签是：检索失败（召回里没有正确答案）、上下文淹没（有答案但被无关片段冲散）、模型脑补（有证据但模型没用）、无依据硬答（知识库外问题）。分类表可以做成这样：

5.2 单点拆解：先断检索，再断生成

分类之后，进入单点测试。这里有个很实用的方法：把链路拆成两段分别验证。

第一步，拿坏案例里的原始问题直接调检索接口，人工看召回的前十名里到底有没有正确答案。如果前十名没有正确答案，问题在解析、分块、嵌入或检索策略，和生成模型无关，不要浪费时间改提示词。如果前十名有正确答案，再去检查生成环节。

第二步，把正确答案对应的片段单独塞给模型，不掺任何无关内容。如果模型这时能答对，说明问题在检索污染，具体说是TopK里塞了太多无关片段；如果模型连单个正确片段都不肯用，那问题在提示词约束或者模型对指令的遵循能力。这一步能清晰分离"检索端的锅"和"生成端的锅"。我帮某团队排查客服机器人时，就是用这两步定位到"退货政策"和"退款政策"在向量空间里被认成同义词，导致每问退货都召回退款页面，答案自然全错。换了混合检索后，问题立刻消失。

5.3 用回归测试集固化成败标准

定位并修复之后，最容易被跳过的一步是建立回归测试集。没有它，你这次修好了，下次改分块参数可能又改回去，你根本发现不了。

我做知识库项目必建一个标准问答集，先保证50到100条，覆盖不同文档、不同问题类型，每条手工写好gold答案，尽量标注期望检索到的片段。以后每改一处——换嵌入模型、改分块大小、调提示词、加重排——就把这个测试集完整跑一遍，记录四个指标：

有了这套基线，每一次改动的好坏都变成数字，而不是"我觉得这次回答得挺顺"。我在实际合作中看到太多团队卡在这一步，改了一周，最后连自己是变好还是变坏都不知道。

6. 别以为上线就完事了：知识库问答的持续运维与幻觉监控

RAG系统不是一次搭好就长期稳定的。文档会改、用户问题会变、模型接口可能换版本。很多幻觉问题上线时不存在，跑了两周才出现，根源往往在运维。

6.1 文档更新与索引同步

最容易被撞到的运维坑是：文档更新了，索引没跟上。业务团队改了产品手册，PDF已经替换，知识库索引里还是旧版本，AI答的条款和官网冲突。更麻烦的是增量替换，旧文本块删一半、新文本块插一半，索引里残留旧的。

我的建议是给知识库加版本管理：每次文档变更，记录变更时间和版本号；重跑索引时，把变更文档涉及的测试问题批量加入回归集，专门验证这次变更有没有把答案改坏。很多平台有定时重建功能，但定时重建不解决"重建时新老版本混用"的问题。稳妥做法是重建时让检索切到新索引，构建失败就回滚旧索引，不要在线替换。

6.2 线上日志与幻觉标记

运维的第二个重点是给线上回答建立"证据审计"机制。每次请求，把检索到的片段、最终答案、重排分数、模型和提示词版本全部落库。前端给用户看到回答时，同时展示"依据来源"；后台则给每个回答打上可用性标记，比如重排分数低于阈值自动标黄。

定期抽样人工复核一批日志，看有没有"模型已经走出知识库但还在硬答"的漏网案例。这些案例是持续优化最重要的素材来源。不要等用户投诉再被动查，主动抽样、每周清理一次坏Case，比上线前那轮测试值钱得多。

6.3 多路验证与兜底方案

最后一个兜底思路是多路验证。对价格、保修、安全规范这类高风险内容，可以让两个不同模型各自独立生成答案，只有结论一致时才输出。实现不复杂，成本翻倍但只对高危问题启用。

另外，我强烈建议在系统里保留"转人工"路径。涉及具体合同、医疗建议、操作安全的场景，AI可以给候选项和依据，但最终决策必须有人确认。这既是为了合规，也是为了避免AI一本正经地给出一个没人验证过的答案。

整个维护流程走到这里，才算是闭环：坏案例入库、分类、单点定位、修复验证、加回归测试、监控再收集。循环往复，幻觉会越来越少，而不是改一次少一分。

最后分享一个我自己的习惯：调RAG最忌讳"感觉变好了"。我见过好几个团队，在测试框里点了几条觉得不错就上线，查出来的都是表面问题。我现在改任何一处，不管是分块大小、检索方式还是提示词，都会把固定的回归测试集完整跑一遍，用数字说话。还有，如果你的AI已经开始一本正经地胡说八道，别急着怪模型，先老老实实从文档解析开始把链路走一遍。答案大概率藏在你以为绝不可能出错的那一步里。