上一期整理了六个RAG知识库调优案例之后不少做知识库落地、客服问答、内部文档检索的朋友在后台追问说还想看更多实战场景。这期我继续挑了六个案例和上一篇完全不重叠全部是真实项目里遇到过、并且花了不少时间才定位到根因的问题。如果你正在做RAG系统尤其是文档召回率不稳定、回答质量时好时坏的那一类这篇应该能帮你省下不少排查时间。先说清楚这六个案例覆盖的范围有切分策略翻车、有混合检索权重设置不合理、有rerank反而帮倒忙、有扫描版PDF直接入库变成乱码、还有检索完全正确但答案依然不对的诡异场景。这些问题表面上看都是“回答不准确”但真正排查下来根因分布在RAG链路的各个角落。每一个案例我都会按“现场还原、排查过程、根因定位、优化方案、效果数据”这个顺序讲方便你对照自己的项目排查。1. 案例一长query直接查询关键词被“稀释”了1.1 现场还原与最直接的排查用户问了一个很口语化的问题“公司去年裁员的补偿方案现在还能追溯吗”。系统返回的前五个片段全是入职培训、考勤制度、年假说明这些完全不相关的内容而知识库里明确存在一份《经济性裁员补偿管理办法》就是没被召回。我第一反应是看向量检索的分数。把query和top-10片段的相似度全部打印出来发现得分最高的一条也只有0.52其余都在0.4左右徘徊。这个分数说明不是“相关但排序靠后”而是“所有候选片段都不怎么相关”。接着我又拿BM25做了关键词召回结果依然不理想——问题出在分词上“追溯”被切成了“追”和“溯”“补偿”和“裁员”虽然在文档里有但因为和原问题里的其他词混在一起BM25的TF-IDF权重被稀释了。1.2 根因定位不是向量模型不行是“提问方式”不行这个案例的根因有两层。第一层用户的口语化长句包含多个语义实体直接塞进embedding模型后模型会把整句话编码成一个平均化的向量。比如“去年”“裁员”“补偿方案”“追溯”四个关键概念在向量空间里被拉成了一个模糊的“公司政策相关”的语义点反而丢失了具体的指向性。这不是模型本身的错是长query和短文本片段天然不匹配embedding模型对短文本的编码质量通常更高。第二层知识库里同一个实体存在多种表述。文档标题写的是“经济性裁员”用户的问法却是“裁员”虽然在人工理解看来是一回事但在向量空间里这两个词组的表征并不完全重合相似度可能只有0.6左右。1.3 优化动作query改写加多路召回针对这个案例我做了两个调整效果非常明显。第一步加了一个query改写模块。用户query进来之后先用LLM做一次轻量级重写把口语化长句提炼成适合检索的短关键词组合。我用的prompt大概是这样的你是一个检索query优化助手。用户输入一个自然语言问题请提取出3-5个与问题强相关的关键实体和概念用空格分隔不要输出任何解释性内容。 输入公司去年裁员的补偿方案现在还能追溯吗 输出经济性裁员 补偿方案 追溯 裁员补偿这一步看起来简单但对RAG整体效果的影响非常大。改写之后向量检索的top-5命中率从20%左右直接提升到了75%以上。第二步引入多路召回。向量召回、BM25关键词召回、以及简单的模板规则召回三路并行最后做归一化合并。这里要注意多路召回是手段不是目的如果只做一路召回的结果已经很好了没必要强行加路数反而增加合并排序的复杂度。提示query改写不要做得太激进不要提取出原文没有出现过的关键词也不要让LLM自由发挥生成大段描述否则会引入新的语义偏差。我自己在测试中就遇到过LLM把“裁员”改写成“人员优化调整”反而召回了更多无关的人力资源制度文档。2. 案例二表格被切分器“大卸八块”结构化信息全丢了2.1 问题表现检索结果里全是“碎尸万段”的表格单元格一个知识库里有大量PDF格式的薪酬绩效制度文档其中包含很多Excel风格的表格比如“岗位工资等级表”“绩效考核系数对照表”“排班补贴标准表”。用户输入“一线员工的绩效系数怎么算”系统返回的片段里前三条全是零散的单元格文本比如“B”“1.0”“月度考核”完全无法拼凑成一个完整的计算规则。我打开切分结果文件之后瞬间明白了问题所在。原来的切分策略是按固定长度切分embedding模型用的是256 token窗口结果就是一个完整的表格被从中间劈开表头在第一个chunk数据行在后面的chunk里甚至有的关键行被切到了两个chunk的中间。而RAG在召回时通常是按chunk粒度打分那些被切碎的chunk本身就没有完整语义模型自然不知道它们在说什么。2.2 从切分结果开始排查这类问题最快的方法是把切分后的数据直接dump出来用肉眼扫一遍。我建议团队在建立知识库的时候一定保留一份“切分预览”索引每次调整切分策略后都抽几个代表文档看效果。只看整体指标而不看切分实物的调优都是在盲人摸象。排查下来发现两个具体问题表格被切成多个chunk后表头和数据行失去关联。切分边界把完整的计算公式切成两半比如“绩效系数 考核得分 / 100 × 部门系数”被切成了“绩效系数 考核得分”和“/ 100 × 部门系数”两个片段。2.3 切分策略的调整方案针对表格密集型文档我把切分策略改成了“按结构切分”加“表格优先保留”。具体操作是先用文档解析器把PDF转成带结构信息的格式识别出哪些区域是表格哪些是普通段落。表格区域不按token切分而是整体保留并且在转换为Markdown格式后作为一个独立的chunk入库。普通段落则按段落边界切分不够长度的段落再和相邻段落合并。对于特别大的表格如果整体保留超过最大token限制就按行分组切成几个子表格同时保留原始表头。例如一个100行的工资等级表可以按职级切成“管理岗”“技术岗”“操作岗”三个子表每个子表都带上完整的列名。另外我给所有chunk加了一个metadata字段标记它的内容类型是“表格”“段落”还是“列表”。后续在召回阶段可以针对不同类型的查询做权重调整比如用户问“怎么算”“多少钱”这类问题时给表格类chunk更高的权重。注意固定长度切分并不是完全不能用但它适合的是纯文本、结构简单的文档。如果知识库里表格、代码、多级目录混杂就必须切换到按语义边界切分的策略。这里的核心原则是一个chunk内部尽量是一段完整的语义单元宁可单chunk长一些也不要切到一半。3. 案例一和案例二的组合拳多路召回和切分策略的协同案例一解决了query侧的问题案例二解决了文档侧的问题但是在实际项目里这两类问题经常是同时出现的。我遇到过不少团队已经做了多路召回也做了query改写但效果依然不理想最后发现是切分策略把文档搞得没法召回。反过来也有团队切分做得很细但用户query太长导致整体效果上不去。所以这里单独把两者的协同关系拿出来说。3.1 召回质量的评估方法在做任何优化之前先建立一个可量化的评估集。我通常的做法是从真实用户query里抽200条人工标注每一条query对应的正确文档位置。之后每次调整切分策略、召回策略都用这200条query跑一遍离线评测计算top-5召回率。只有建立这个评估闭环你才能知道某个改动到底是变好还是变坏。否则你很容易被两三例“看起来变好了”的现象误导实际上整体效果退化了。3.2 迭代顺序建议先修切分问题再改召回策略最后优化query侧。逻辑很简单切分是地基切分质量不行后面召回和重排做得再好也是白搭。query改写是锦上添花的部分只有当你确认切分和召回都没有明显问题时query改写的价值才会显现出来。我统计过在切分合理的前提下query改写带来的top-5召回率提升大约在15%到30%之间。但如果切分本身一塌糊涂query改写能把一个本来就很差的系统从“完全不可用”变成“偶尔能用”但离一个稳定可用的知识库问答系统还有距离。4. 案例三混合检索一加一小于二分数量纲完全不在一个量级4.1 现场现象向量召回和BM25各自都对合并之后反而错了这个项目同时做了向量召回和BM25关键词召回本想双保险结果用户问“跨部门转岗后年假怎么计算”向量召回的第一名是正确文档BM25召回的第一名也是正确文档但合并排序之后正确答案掉到了第五名系统最终返回了一个错误答案。排查的时候我把两路召回的具体得分打印出来瞬间就看出了问题。向量相似度是0~1区间的浮点数BM25的得分却是0~20之间的数值。合并排序时我直接用加法把两个分数相加BM25高得多的绝对数值完全压过了向量相似度。于是最终排序结果基本等于“只按BM25排序”向量召回那一路等于白做了。4.2 量纲归一化的两种常用方案混合检索合并有个基本前提各路得分必须映射到同一量纲或者采用不依赖绝对分数的排序融合方案。方案一归一化然后再加权。对向量相似度和BM25得分分别做min-max归一化或Z-score归一化再按权重相加。这个方法直观但问题在于每路得分的分布可能差异很大min-max归一化容易受离群值影响。方案二倒数排名融合也就是RRF。这个方法不直接使用分数而是用排名位置来融合。RRF的公式是score(d) Σ 1/(k rank_r(d))其中k是一个平滑常数通常取60。意思是文档d在每一路召回中的排名越靠前它的融合得分越高。因为用的是排名而不是分数天然避开了量纲问题对异常值也不敏感。具体计算过程如下向量召回中文档A排名第1贡献 1/(601) ≈ 0.0164BM25召回中文档A排名第3贡献 1/(603) ≈ 0.0159文档A总得分 ≈ 0.0323再看另一个文档B向量召回排第8BM25召回排第1总得分 1/(608) 1/61 ≈ 0.0311。在这种情况下文档A的融合得分高于B这是因为它在两路中都靠前。4.3 优化后的效果与调参心得切到RRF之后top-3准确率直接提升了20多个百分点。这个项目里的具体数据是优化前混合检索的top-3命中率只有45%左右优化后到了70%以上而且几乎没有“正确答案本来在前面却被合并挤到后面”的情况了。RRF里有一个参数k这个值的设置有点讲究。我试过k30、60、100实际效果是k60附近比较稳在大多数业务场景下都不错。k太小会让第一名权重过大k太大则各路召回的区别度变小。另外一个细节不同路召回的结果条数要设合理我一般每路取30~50条然后再做融合保证融合时各路的信息量是均衡的。经验混合检索合并时不建议直接用原生分数做加权平均除非你已经做过充分的数据分析和归一化。RRF的思路更稳健实现也就几行代码强烈建议直接用。5. 案例四加了rerank之后结果反而更差了5.1 问题现场模型选择了“看起来更新”的答案一个客服知识库系统在向量召回和混合召回之后接了一个bge-reranker-large模型想进一步提升排序质量。结果上线后测试发现用户问“2023年的报销标准是多少”答案却答成了2022年的旧标准。而且这个旧标准doc在rerank之前的排名并不高是rerank把它排到了第一位。我一开始以为是rerank模型本身有问题于是把召回候选集、rerank前后的排序结果全部打印出来对比。这一看才发现问题的根源在候选集。当时召回阶段只取了top-5也就是只有5个候选片段进入rerank。在这5个候选里有一份《2022年费用报销管理办法》和一个《2023年报销限额调整通知》。从语义匹配度看2023年的那个文档确实在query相关的匹配上弱一些因为它的文本更短、包含的报销项目词更少而2022年那份文档里报销项目和金额列得很全语义相似度天然更高。rerank模型严格按相关性排序在只有5个候选的情况下它只能在这5条里选“最像答案的”于是旧的详细文档排到了第一。5.2 根因候选集太小rerank没有足够的选择空间这个案例暴露的是RAG链路里的一个经典问题召回阶段得分最高的结果并不一定是排序阶段最想要的结果。排查下来的三个问题召回候选取太少top-5导致真正正确的文档根本没进候选集合的rerank再怎么排也排不出来。没有按时间元数据过滤。这个知识库的文档本身带着生效日期meta字段但检索阶段没有利用它导致不同年份的版本混杂在一起。rerank分数与业务规则的优先级关系没有定义清楚。业务上要求“同一主题优先最新的生效版本”但rerank模型只按语义匹配度排序不了解业务的时间优先级。5.3 优化方案扩大候选集加元数据过滤优化动作分三步走。第一步把召回候选集从top-5扩大到top-50让更多潜在相关文档进入rerank阶段。召回阶段的核心指标是“召回率”宁可多召回一些不相关的也不要漏掉正确的文档排序是否精准交给rerank来做。第二步在召回阶段就利用metadata做硬过滤。根据query里的时间词“2023年”直接在检索时候滤掉生效日期不在对应区间的文档。这个过滤必须在embedding检索之前做或者至少要在召回之后、rerank之前做。实现上可以给向量数据库的collection加filter条件或者在业务代码层面过滤候选集。第三步对rerank之后的top-3结果做业务规则干预。比如对于同一主题的多份文档优先选择元数据中生效日期最新的版本。这一步可以放在rerank后作为最终排序的一个业务修正。优化后这个案例的正确率从35%提升到了80%以上。核心不是rerank模型本身不够好而是整个链路的配合出了问题。提示rerank不是万能药。如果你发现加了rerank反而变差了先从候选集入手检查看看正确答案有没有出现在召回集合里。如果正确答案根本不在候选集里问题不在rerank在召回阶段。6. 案例五扫描版PDF直接入库向量化之后全是乱码6.1 现场现象文档明明有答案系统却一直说找不到这是一个法律合同知识库项目用户问“合同中关于违约金的最高上限是怎么约定的”系统从知识库里捞出来的片段要么是“甲方乙方签署页”这种版权页面要么是一堆肉眼看不明白的乱码序列。我把当时的处理链路翻了一遍发现这批合同文档是扫描版PDF也就是每一页都是图片没有文本层。入库时虽然调用了PDF解析器但解析器没有OCR能力提取出来的只是一堆近似乱码的文本。更麻烦的是向量模型把这堆乱码编码成了“语义向量”相当于在垃圾数据上做检索效果自然好不了。6.2 排查链路从源文档到切分结果一步一步查排查这类问题最关键的是把链路中的中间产物全部可视化。我把流程整理为检查源文件是否存在文字层用PDF阅读器打开能选中文字就说明有文字层选不中就是扫描版。直接输出解析器提取的纯文本内容观察是否存在乱码或大量空白字符。查看切分后的chunk文本确认乱码有没有被带进来。查看embedding后的向量检索结果确认垃圾向量有没有被命中。这个案例中第2步就暴露了问题。解析器提取出来的“文本”是一堆无法阅读的字符组合说明OCR环节缺失。6.3 OCR预处理流程与效果对比发现问题之后我在文档入库之前加了一条OCR前置处理流程具体步骤如下用PaddleOCR对扫描版PDF按页进行OCR识别输出文本和坐标信息。根据坐标信息重组版面结构识别标题、段落、表格区域。清洗OCR输出去掉明显的识别错误字符并把表格内容转成Markdown格式。确认每个页面的文本长度正常异常页面单独标记后续人工复核。最后再走正常的切分和嵌入流程。这一步改造带来的效果非常显著。同一批合同文档检索命中率从改造前的18%提升到了83%。而且不仅准确率上来了回答的引用来源也规范了——因为是OCR识别出来的文本可以定位到具体页数和坐标用户可以直接去原文核对。这里特别强调一个细节OCR之后的文本必须保留和原文页面的映射关系。知识库问答通常会要求“给出来源”如果没有页面映射就只能在chunk层面给一个模糊的文档名这对业务人员来说参考价值很有限。PaddleOCR输出的坐标信息完全可以支撑这种映射花一点时间把页面编号和chunk关联起来相当值得。注意OCR不是万能的对于手写体、印章遮挡、表格线复杂的文档识别效果可能很不稳定。我建议在OCR流程后面加一个人工抽检环节按批次抽查识别正确率尤其是合同这类高风险文档类型不要全部交给机器这是一个常见的坑。7. 案例六检索片段全对但LLM还是答错了7.1 问题现象召回精准答案诡异这个案例是最诡异的。用户问的是“三次劳动合同到期后续签公司有权拒绝吗”。检索出来的前三个片段有两个都是相关内容讲的就是连续签订两次固定期限合同后第三次的情况。按理说LLM拿到这些片段应该能给出正确答案但实际回答大段引用了一段已经废止的旧条例结论完全错误。我第一反应是提示词写得有问题或者LLM本身的幻觉。于是我把此次请求的完整链路日志翻了出来包括query、召回片段、拼接后的prompt以及LLM的完整输出。这时发现了问题。召回结果里出现了三份不同的合同续签政策文件其中一份标注“根据《劳动法》相关规定”一份是内部人事制度文件另一份是某省高院的司法解释。按时间元数据来看这三份的效力级别完全不同司法解释的权威性最高法律其次内部制度最低。但系统在拼接prompt时只是简单地按相关性分数排了一下没有按“法律效力层级”做排序。结果LLM在阅读这些片段时优先采信了排在前面的低效力文档导致最终答案出现了偏差。7.2 根因检索相关性和答案可采纳性是两回事这个案例反映出RAG系统里的一个深层问题我们做检索时按“语义相关性”排序但生成答案时LLM需要对多个片段做“内容可信度判断”。如果不同片段之间存在信息冲突LLM不知道应该采信哪一个。解决这个问题除了在检索阶段做相关性和业务规则的折中还需要在上下文构造阶段多做一步给每个chunk附加上“文档权威级别”元数据例如“法律法规”“司法解释”“内部制度”“新闻资讯”等。在拼接prompt之前按权威性做一次组内排序而不是完全依赖相关性排序。例如所有片段先按权威级别放到几个桶里然后桶内按相关性排序再按权威级别的优先级拼接。在prompt里增加一条指令告诉LLM如果多个片段存在冲突优先采纳权威级别更高的内容并说明判断依据。这里再强调一下prompt中片段过多并不一定是好事。有一次我测试时把top-10全部塞进prompt结果LLM面对太多信息反而不知道如何取舍。后来改成“先按权威级别排序然后每个级别最多取2条”总共5-6条作为上下文效果反而更稳定。上下文质量大于数量这是RAG调优中很重要的一点。7.3 效果与扩展向agentic rag演进的路径这个案例优化之后回答准确率提升明显。更重要的是它给团队指出了一个改进方向并不是所有query都适合直接走“一次性检索加一次性生成”的RAG链路。对于涉及政策法规判断、跨文档比对、信息冲突检测的复杂query可以引入agentic rag的思路。具体来说agentic rag的核心变化是系统不再只做“一次检索、一次生成”而是让LLM在回答过程中自主决策。比如先判断“这个问题需不需要先确认问题的法律适用地域”如果需要先查一下知识库里的地域标签再根据结果决定后续检索路径。这种多步推理的方式在处理跨文档、多条件、有优先级关系的领域问题时表现得比单轮RAG更稳定。不过要提醒的是agentic rag的链路更长排错也复杂得多。如果你当前的单轮RAG都还经常出错不要急着上agentic rag先把切分、召回、上下文物料这几层做扎实再考虑用多步推理去解决那些真正复杂的问题。8. 六个案例的问题速查与调优优先级参考六个案例讲完我整理了一张速查表你可以把它当成排查RAG知识库问题的快速索引。案例表面现象根因优先级快速优化动作长query检索效果差回答完全不相关query语义被稀释高用LLM做query改写提炼关键词组合表格文档无法检索返回的片段语义残缺固定长度切分破坏结构高表格类型文档整体保留并转Markdown入库混合检索效果更差正确答案排名下降不同路分数量纲不统一中改用RRF倒数排名融合加了rerank反而变差正确文档被挤出前列候选集太小中扩大候选集到top-50再配合元数据过滤扫描版PDF乱码检索结果无法阅读缺少OCR预处理高增加OCR流程入库前人工抽检检索正确但答案错误召回片段正确生成结果错误上下文排序和权威性冲突中按权威级别排序prompt中增加冲突处理规则从我多次实战的经验来看排查RAG问题应该先从哪个环节下手有个简单的判定方法如果回答内容杂乱无章优先检查切分如果回答相关但位置不对检查召回和重排如果回答看起来有模有样但结论错误检查prompt和上下文构造。9. 几个贯穿所有案例的排查工具和建议上面六个案例每个都有特定的排查手段但有几个通用的工具和建议我觉得值得单独整理一下。第一个是链路日志。RAG系统必须有完整、可追溯的请求日志从query进入、召回结果、重排结果、prompt拼接到LLM输出每一步的中间结果都要记录下来。没有这个日志所有优化都只能靠猜。这里的难点在于中间结果信息量大如果全部记录会导致日志体积膨胀。我的做法是平时只记录关键指标比如召回数量、平均相似度、耗时排查时再开启详细模式记录完整的中间产物。这样既能控制日志成本又不影响问题定位。第二个是离线评测集。任何调优动作上线之前都建议先用一批带标注的query做一次离线回归测试。200条高质量query标注就够用了不需要太多。有了评测集你才敢放心地调切分参数、改召回策略不然用户反馈一个你改一个永远被问题追着跑。第三个是分阶段验证。遇到“回答质量差”这种笼统的问题先判断是哪一个环节引起的。这里要特别提醒很多人在检索结果不理想时会直接换embedding模型觉得换个更大的模型就万事大吉这其实是很常见的一个误区。在换模型之前建议先把query改写、切分策略和召回融合这几个相对轻量级的优化做了效果往往会比单纯换一个大模型来得明显。如果这些层面都优化过了再用A/B对比实验来验证模型升级的效果会更稳妥。第四个是关注用户反馈。RAG知识库和传统搜索不一样它面向的是业务用户用户是否信任系统直接决定系统价值。即使检索准确率95%剩下5%的错误答案带来的不信任感可能比搜索里30%无关结果带来的还大。所以一定要在实际使用过程中持续收集“用户点了不满意”的数据从这些bad case里持续迭代。我自己在维护RAG项目时最大的感受是RAG调优没有一劳永逸的银弹大多数问题都需要一条一条链路去查一个case一个case去修。把日志、评测集、分阶段验证这些基本功做好比到处找“调参口诀”有用得多。