RAG检索为什么漏掉关键文档

一、问题不是出在模型，而是出在上下文

在很多RAG系统的调试过程中，开发者最先怀疑的往往是大模型能力不足、提示词设计不合理，或者向量检索参数没有调好。但当真实业务查询第一次进入系统时，问题经常出现在一个更前置的环节：喂给大模型的“上下文”本身就不包含正确答案。

一个非常典型的场景是：业务方上传了一份几十页甚至上百页的财报PDF，然后提出一个看似清晰的分析请求，例如要求基于某一业务线在上一季度的毛利率变化趋势，给出原因分析。这个问题在业务人员看来非常自然，因为整份财报就是围绕公司整体与各业务线的经营数据展开的。

系统返回的结果却可能是“根据提供的信息，无法找到相关数据”。开发者打开调试日志后会发现，检索阶段确实召回了一些文本片段，但这些片段要么是财报封面、目录、风险提示，要么是完全没有业务线财务数据的文字段落。真正包含毛利率明细的那张表格，根本没有进入LLM的上下文窗口。

所以问题的本质并不是大模型不会回答，而是检索链路没有把包含答案的文档片段找到并送入上下文。也就是说，RAG系统的最终效果，很大程度上取决于“喂给模型的那一段上下文质量”。

二、PDF解析是第一个被低估的环节

RAG系统通常会把PDF当作一种普通的文本来源来处理，但PDF的内部结构与纯文本文件完全不同。很多PDF并不是按段落顺序存储文本的，而是以绘图指令、文本块、坐标信息和字体描述的方式组织内容。如果直接用基础文本提取方式处理，很可能出现以下几种情况：

1. 文本顺序错乱，段落之间的逻辑关系被打断；
2. 表格内容被拆成零散的单元格文本，列与列之间的对应关系丢失；
3. 页眉、页脚、页码等噪声混入正文；
4. 双栏排版的文档被从上到下通读，而不是按左右栏阅读；
5. 扫描版PDF完全没有文本层，需要先进行OCR识别。

对于财报这类文档，表格往往是数据密度最高的部分。毛利率、收入、成本、同比变化等关键指标通常以表格形式呈现。如果解析阶段不能保留表格结构，后续即使向量检索再精确，也无法从一堆被打散的单元格文本中还原出“某业务线毛利率”这一完整信息。

因此，在RAG系统设计之初，就应当对PDF解析结果进行质量评估，而不是默认解析出来的文本可以直接使用。需要关注的指标包括：段落完整性、表格结构是否保留、标题层级是否清晰、是否存在明显的文本错乱等。

三、切片策略决定了检索的最小单位

即使PDF解析结果比较理想，切片策略仍然会直接影响检索效果。切片是RAG检索链路中的关键步骤，其目标是把长文档切成大小合适、语义相对完整的片段，并将这些片段向量化后写入索引。

常见的切片方式包括固定长度切片、按段落切片、按标题层级切片等。不同的切片方式适用于不同类型的文档。对于财报来说，单纯按固定长度切片很容易把一张完整表格从中间截断，导致表格的上半部分在一个片段中，下半部分在另一个片段中。这样一来，任何一个片段都无法独立回答“毛利率是多少”的问题。

更合理的做法是结合文档结构进行语义切片。例如，以标题层级作为切片边界，让同一个章节下的内容尽量保持在同一片段中；对于表格，优先以完整表格为单位进行切片；对于表格过大的情况，可以按业务线或指标名称进行拆分，但需要在每个片段中保留表格表头与文档来源信息。

切片大小还需要与向量模型的能力相匹配。不同模型对长文本的编码效果不同，过长的片段可能导致语义信息被稀释，过短的片段则可能丢失必要上下文。实践中通常需要根据具体文档类型和查询场景进行多轮测试。

四、向量检索并不天然理解“业务线”这个词

在财报场景中，用户查询中的“XX业务线”往往是一个业务系统中的常用名称，而PDF原文中可能使用“XX事业群”“XX分部”“XX板块”等不同表述。如果检索系统只做简单的向量相似度匹配，很可能因为词汇不一致而漏掉正确段落。

这就是RAG系统中经常被忽视的“查询与文档之间的语义鸿沟”问题。解决这个问题至少可以从三个方向入手：

一是对文档进行元数据标注。在解析和切片阶段，可以借助规则或模型识别出文档中的业务线名称、指标名称、时间范围等信息，并将这些信息作为元数据与片段一起存储。检索时可以对元数据进行过滤或加权。

二是对查询进行改写与扩展。在查询进入向量检索之前，可以先生成多个语义等价的查询版本，例如将“XX业务线”扩展为“XX事业群”“XX分部”等，提高召回率。

三是引入混合检索。除了向量检索之外，同时使用关键词检索，例如BM25算法，来覆盖精确词汇匹配的场景。向量检索擅长语义匹配，关键词检索擅长精确匹配，两者结合可以显著提升复杂查询下的召回效果。

五、多跳问题需要更长的推理链路

“分析毛利率变化趋势及其原因”这个问题本质上不是单跳问题，而是需要多个信息片段共同支撑的复合问题。要回答这个问题，至少要找到以下信息：

• 该业务线在上一季度的毛利率数值；
• 该业务线在更早季度的毛利率数值，以便比较趋势；
• 财报中关于毛利率变化的解释性文字，例如成本上升、产品结构调整、价格变化等原因。

这些信息很可能分散在文档的不同章节，甚至不同的表格与段落中。如果RAG系统只做单次检索，取Top K个片段作为上下文，很容易只召回其中一部分信息，而遗漏其他关键片段。

针对这类场景，可以考虑引入查询拆分与多步检索机制。系统先识别出用户查询中的多个子问题，然后分别执行检索，最后将多路召回的结果合并去重后送入大模型。也可以在第一次检索的基础上，根据初步召回内容生成补充查询，进行第二轮检索，从而覆盖更多相关信息。

六、评估不能只看“有没有召回”

很多团队在优化RAG检索时，只关注召回片段中是否包含正确答案。这个指标虽然重要，但并不充分。因为即使正确答案被召回，如果它被淹没在大量无关内容中，或者片段之间缺乏逻辑连贯性，大模型仍然可能给出错误回答。

更全面的评估应当关注上下文质量，包括：

• 召回片段的精确率：Top K中有多少片段确实与查询相关；
• 信息完整性：回答查询所需的关键信息是否全部包含在上下文中；
• 顺序与连贯性：片段之间的排列是否有助于模型理解；
• 噪声比例：无关片段是否干扰了模型的判断。

这些评估指标可以通过构建一个带有标注的测试集来量化。测试集应当来自真实业务场景，而不是仅由开发者自己构造的简单样例。只有基于真实查询与真实文档进行评估，才能准确反映系统的实际表现。

rag-">七、把文档理解能力当作RAG的基础工程来建设

RAG系统本质上是一个从非结构化文档到结构化可用知识的转换过程。这个过程的每个环节都会影响最终答案。与其在模型选型上反复纠结，不如先把文档解析、切片、检索与上下文组织这些基础工程做好。

对于复杂PDF文档，建议建立一套从解析到检索的完整质量监控体系，包括解析结果抽查、切片质量评估、检索召回分析以及最终答案与上下文的一致性校验。只有把这些环节都纳入系统化的工程流程，RAG系统才能在真实业务中稳定输出可用结果。