Agent‑RAG 如何处理复杂 PDF？生产级 PDF 检索增强全流程方案
摘要：在 RAG 项目开发中，直接把 PDF 转纯文本再切片，是 Demo 级别的简单做法。面对真实业务 PDF：多栏排版、表格、扫描件、图表、合同层级页眉页脚，简单文本切片会带来上下文断裂、表格信息损坏、无法溯源等一系列问题。本文梳理工业界 Agent+RAG 处理 PDF 的四层架构，讲清楚生产环境 PDF RAG 完整落地思路，同时说明如何规避大模型幻觉问题。
前言
很多同学做 RAG，上手就是PyPDF2/pdfplumber提取文本，再按固定长度切 chunk，送入向量库。这个方案跑简单文档 Demo 效果尚可，但一旦面对真实业务 PDF：财报、合同、扫描版资料、多栏技术文档，整套链路就会大量出问题。
传统 "转文本 + 切片" 方案的痛点
为什么简单 PDF 转文本切片是外行方案？真实业务 PDF 的复杂度远高于纯文本：
- 上下文断裂：粗暴按字符切割，会把完整章节、段落强行截断，丢失宏观语义，模型拿到残缺片段，回答容易跑偏。
- 图表表格数据损毁：表格被扁平化乱序，图表、图片说明直接丢失，财报、统计类文档直接失效。
- 无法精准溯源：丢失页码、标题层级，模型输出答案，却找不到原始出处，无法做引用校验，幻觉风险飙升。
- 无法处理扫描件：图片形式的 PDF，普通文本提取工具完全拿不到内容。
- 多栏排版干扰：双栏文档文字乱序，页眉页脚冗余信息混入切片。
生产级 PDF‑RAG 不能只做文本提取，需要多模态解析、结构还原、语义切片、Agent 工具调用、溯源防幻觉整套链路。
生产级 PDF RAG 四层架构
第一层：多模态解析与页级定位
抛弃老旧纯 OCR 流水线，走向多模态文档解析。
- 文档类型动态判别：先区分是原生文本 PDF，还是扫描图片 PDF。
- 多模态模型直接解析：不再只提取文字，把 PDF 页面当做图像喂给多模态大模型，一次性输出文字、表格、图表、图片信息。
- 工业界趋势：按页向量化 不要直接把全文切碎，为每一页独立生成 Embedding。
- ✅ 精准语义定位，溯源直接绑定页码索引
- ✅ 原生支持以图搜图，基于页面截图做跨页检索
优势：整体成本可控，对表格、扫描件、图文混排文档效果远好于传统 OCR。
第二层：文档结构 100% 还原，提取元数据 Metadata
RAG 不只是拿文字，元数据才是可追溯的关键。解析 PDF 的时候，必须完整提取保存这些元信息：
- 页码、页眉页脚
- 标题层级 H1‑H6
- 章节结构、段落边界
- 表格编号、表头
- 图片说明、脚注
不同业务文档侧重点不一样：
- 合同类 PDF：重点标记章节、条款编号、跨页状态。
- 财报类 PDF：绑定数字、表名、指标、对应年份。
元数据会跟随每一个 chunk，后续检索、回答引用、溯源全部依赖这套信息。
第三层：语义切片，携带上下文的索引构建
不是简单按 token 长度硬切，采用页内语义切片策略：
- 段落聚合：同一个标题下的短段落，合并存放，保证语义完整。
- 表格图像特殊处理：表格单独结构化输出；图表生成文字摘要；超长表格做行列转换，改造为适合向量库存储的多行结构化文本。
核心工程技巧：Chunk Context Injection（片段上下文注入）
给每一个切片，强制前置全局上下文元数据。
示例片段前缀：
该片段属于【文档X】第3章，页码：17，讲述了风险控制标准
把 DocID、PageNumber、章节标题、TableID、版本信息强制放到 chunk 头部。解决检索回来之后，切片丢失宏观语义的经典问题。
向量库里面存储的不只是原始文本，是「元数据 + 正文」的完整片段。
第四层：Agent 工具链动态调用，按需加载
核心原则：永远不要把 PDF 全部内容塞进 Prompt 上下文，按需加载。
把 PDF 相关能力封装成 Agent 工具集：
根据用户问题意图，Agent 自动调度不同工具：
- 简单事实查询：语义召回 + Read_Page 读取页面获取细节。
- 复杂对比问题：全局检索章节，Agent 规划多步阅读路径，跨页面聚合信息。
- 图表统计问题：调用 Extract_Table 抽取表格，Analyze_Chart 解析图表。
生产环境规避幻觉的三条硬性红线
光靠检索不能解决幻觉，必须设置系统硬性约束：
- 强制溯源，UI 支持跳转原文回答输出必须附带页码、章节、原文片段引用；前端 UI 支持点击引用直接跳转到 PDF 原文高亮位置。
- 基于证据的闭环逻辑 模型回答只能使用召回 Chunk 里面的证据；证据不足时，必须输出：
当前文档中未找到相关内容，禁止模型自行脑补编造信息。 - 立体化评测闭环评测不只看回答语义是否正确，还要校验三件事：
- 检索出来的片段，是否命中正确页码
- 输出表格数值，和原始 PDF 是否完全一致
- 图表分析结论，是否和原图匹配
PDF‑RAG 面试标准答案（可直接背诵）
面试官提问：Agent 的 RAG 遇到 PDF 应该怎么处理？
- 第一步：多模态解析并按页定位抛弃简单转文本直接向量化的 Demo 方案；先区分 PDF 类型，采用多模态模型解析页面，同时做页级 Embedding，保留页面原始信息。
- 第二步：文档结构还原与语境补全完整提取标题、页码、表格等元数据；做语义切片，使用 Chunk 上下文注入，给每个片段补齐宏观文档上下文。
- 第三步：Agent 工具链按需加载封装 PDF 检索、读页、抽表、看图等工具，Agent 根据用户问题动态调度工具，按需读取信息，不做全文灌入。
- 第四步：高阶能力闭环，对抗幻觉全程保留页码引用溯源；设置证据约束，证据不足如实告知；做多维度评测闭环，抑制幻觉。
面试官听到这套回答，就能区分你是跑过 Demo，还是真正理解生产级 PDF‑RAG 的难点。
思考题：一万份合同 PDF，如何回答 "违约条款最多的三种情况"
用户问题：一万份历史合同 PDF，查询出现违约条款最多的三种情况，底层索引和召回链路如何设计？
思路参考：
- 预处理阶段：多模态解析全部合同 PDF，识别、结构化提取所有违约条款，把违约条款单独抽出来，带上合同 ID、页码、条款类型元数据存入向量库，同时存入结构化数据库。
- 查询阶段：
- 方案 A（向量 + 统计）：向量检索召回全部违约相关 chunk，交由 Agent 做聚合归类、统计频次；适合数据量不大。
- 方案 B（预处理提取实体）：解析阶段用大模型把违约类型抽成实体字段存入结构化数据库；查询直接对实体字段做统计，再通过向量检索拿到对应原文片段做引用。
一万份文档，纯向量召回后再统计压力大；优先预处理提取实体，结构化数据库做统计，向量库做溯源举证，两者结合。
总结
PDF RAG 的难点不在向量库，而在文档解析、结构保留、元数据管理、Agent 按需读取、幻觉约束。简单的文本切片适合玩具 Demo；面向财报、合同、扫描件等真实业务文档，必须采用多模态解析 + 元数据 + Agent 工具链的整套方案，才能保证结果可靠、可溯源。