RAG系统PDF解析瓶颈

有个做企业知识库的团队跟我吐槽：他们RAG系统的Retriever用了向量数据库，Generator接了大模型，Prompt工程也调了好几轮，但用户反馈回答质量依然不稳定。后来他们发现问题出在最早的一环——PDF解析。

企业80%的数据在非结构化文档里：合同、研报、产品手册、制度文件。这些文档被灌进RAG系统之前，需要先转成文本。但PDF这个格式天生是"给人看的，不是给机器读的"。PDF内部存储的是"这一页第3行第5个字是'营'，坐标(x,y)"，它不告诉你这个字属于哪个段落、哪个表格、哪个章节。

结果就是，多栏排版的文档被按行打断，表格变成乱序文字，页眉页脚混入正文。这些"被污染"的文本被切成chunk、向量化、存进数据库。检索时召回的片段语义断裂，大模型基于碎片推理，hallucination自然居高不下。

"看清每个字"和"看懂文档结构"，是完全不同的两件事

很多团队在处理PDF时，第一步就错了。他们把PDF当成图片做OCR，或者直接用某些工具类的产品按字符顺序提取文本。这两种方式都只能输出"一串字"，而丢失了文档的结构信息。

举个例子。一份产品手册里有一页，左栏是功能介绍，右栏是对应的表格（参数名、数值、单位）。如果按字符存储顺序提取，输出可能是：

"本产品的核心参数如下 参数名 数值 单位 工作温度 -20℃~60℃ 存储容量 512GB……"

人类看了费劲，大模型看了更懵——它无法判断"工作温度"和"-20℃~60℃"是一组键值对，而不是两个无关的句子。向量化之后，检索召回的片段更是可能只包含"存储容量 512GB"，而丢失了"这是哪个产品的参数"这一关键上下文。

文档解析的"三层修复"

• 第一层是区块识别。系统先"看"整页版面，把页面划分为段落块、标题块、表格块、图表块、页眉页脚块。这一步的核心价值是去噪——页眉的"XX公司内部资料"和脚注的"① 数据截至2025年底"被正确归类，不会混进正文chunk里污染语义。同时，表格块被识别为独立的结构化区域，而不是打散成普通文本。

• 第二层是阅读顺序还原。PDF不保存"先读哪一栏、再读哪一段"的信息，它只保存绘制指令。TextIn基于视觉版面关系重建人类阅读顺序：多栏页面按"左栏→右栏"顺序输出，而不是逐行交错；图文混排时，图片的标题紧跟图片，而不是插在无关段落中间。这一步保证输出的是"人类能读懂"的连续文本流，而不是"机器按存储顺序吐出来的字符序列"。

• 第三层是层级结构推断。PDF没有h1、p、table这类标签，但人类通过字体大小、加粗、缩进、编号就能判断"这是一级标题还是二级标题，这是正文还是列表项"。TextIn用同样的视觉信号反推文档的逻辑层级，输出带结构标记的Markdown或JSON。这样后续做切片时，可以按章节边界、表格边界智能切分，而不是无脑按token数砍断——避免"标题在A chunk里，正文在B chunk里"的语义断裂。

  
  

切片策略：为什么"切在哪"比"切多大"更重要

RAG系统里有个容易被忽视的细节：chunk的切分策略。很多系统固定按512 token或1024 token切，但忽略了文档本身的结构边界。

一份合同里，"第三条 付款方式"下面跟着三个子条款（3.1、3.2、3.3），如果切分点刚好落在3.2中间，检索时召回的片段就丢失了上下文——大模型无法判断这个付款条件属于"验收后30天"还是"预付30%"。

TextIn的做法是基于识别出的结构边界做"语义感知切片"，核心规则有两条：

• 第一条"标题跟随"：识别出的章节标题及其对应的正文内容优先保持在同一个chunk内，即使这一段文字超过了默认的token上限，系统也会优先保证标题-正文的完整性，而不是机械地按字数截断。

• 第二条"表格整表保留"：如果一个表格区块的token数在合理范围内（比如不超过2048），整个表格连同其表头一起放入一个chunk；只有当表格过大时，才按行切分，但切分点会选在"一级科目"层级（如"流动资产合计"后面），而不是随意截断某行中间。

具体例子：一份产品需求文档里有这样一段：

2.3 用户权限管理
系统需支持三种角色：管理员、编辑、访客。管理员拥有全部操作权限，包括……编辑可修改内容但不可删除……访客仅可浏览公开页面。

如果按固定512 token切分，"管理员拥有全部操作权限"和"编辑可修改内容但不可删除"可能被切到两个不同的chunk里。检索时用户问"编辑能做什么"，系统召回的片段可能只包含"可修改内容"而丢失了"不可删除"这个关键约束，大模型据此生成回答就可能给出错误信息。

TextIn处理时，会把"2.3 用户权限管理"识别为一个章节节点，其下所有正文作为一个语义单元整体放入一个chunk（假设未超上限），或者至少保证"管理员/编辑/访客"三个角色的描述不被拆散。最终检索召回的片段是一个自包含的语义单元，大模型可以基于完整上下文做出准确推理。

从解析到治理：非结构化数据的"最后一英里"

RAG系统的目标是把企业沉睡的文档数据激活。但如果解析环节就丢了结构、乱了顺序、混了噪声，后面的Retriever和Generator再强也只是在"垃圾进垃圾出"的泥潭里挣扎。

合合信息TextIn是大模型时代文本智能技术的领先者，其通用文档解析能力专注于把PDF、扫描件这类非结构化文档还原成机器可读的结构化数据。对于正在建设企业知识库或RAG系统的技术团队来说，在文档解析层投入适当的精度，可能比在Embedding模型或Prompt工程上反复调参的收益更高。毕竟，如果输入的数据本身结构完整、语义连贯，大模型的表现通常不会太差。

应用场景参考：企业知识库建设、法律/金融领域RAG问答系统、智能客服文档溯源、合规审计文档自动化处理。