面试官问你：RAG 如何处理 PDF——别再说"转文本切片"了
面试官问你：Agent 的 RAG 遇到 PDF 应该怎么处理？
千万不要上来就说"把 PDF 转成文本，然后切片入库"——这个答案太浅了，只能说明你只做过 Demo，没做过生产级项目。
真实业务里的 PDF，不只是纯文字，里面可能有：目录、页眉页脚、表格、图片、流程图、合同条款、扫描件，甚至一页里面有多栏排版。如果你直接粗暴抽文本，最后 RAG 很可能检索到一堆断裂、重复、缺上下文的垃圾片段。
这篇文章给你一套生产级 PDF RAG 的标准回答框架，帮你在面试中给出让面试官点头的答案。
核心回答：四层标准架构
正确的回答应该是：PDF 处理要分成四层架构，逐层解决问题。
第 1 层：解析层——先判断 PDF 类型，再选解析方式
不要所有 PDF 都用同一种方式解析，先分类处理：
| PDF 类型 | 解析方式 | 说明 |
|---|---|---|
| 原生文本 PDF | 直接提取文本 | 最常见的类型，用 PyMuPDF、pdfplumber 等工具 |
| 扫描件 PDF | 必须走 OCR | 不能直接抽文本，否则拿到的都是空白 |
| 图文混排 PDF | 视觉理解/多模态模型 | 图表、流程图、截图、复杂表格，不能只抽文字 |
实际生产中，很多 PDF 是混合型的——前半部分是原生文本，后半部分夹带了扫描的发票或签章页。所以成熟的 systems 会走一个自动分类流程：先尝试直接抽取文本，如果某一页抽到的字数低于阈值（比如 50 个字），就自动触发 OCR 流程。这种混合策略能覆盖绝大多数场景。
目前主流的 OCR 工具包括 Tesseract（开源免费）、PaddleOCR（中文识别效果优秀）、以及商业 API 如百度 OCR、腾讯 OCR 等。对于英文文档，Tesseract 加上图像预处理基本够用；但对于中文文档，特别是含有手写体或复杂排版的场景，PaddleOCR 的识别准确率明显更高。
面试怎么说：
"第一步是判断 PDF 类型。原生文本 PDF 直接提取文本；扫描件 PDF 必须走 OCR（光学字符识别）；图文混排 PDF 需要走视觉理解或多模态模型。比如 Anthropic 的 Claude PDF Support 就是这个思路，它不是只能读文字，还可以理解 PDF 里的图片、图表和表格。"
第 2 层：结构还原——不要把 PDF 当成一整坨纯文本
要尽量保留 PDF 的原生结构信息，不能把所有内容揉成一团：
必须保留的信息：
- 页码
- 标题层级
- 章节
- 段落
- 表格
- 图片说明
- 脚注
- 页眉页脚
结构还原是很多人容易忽略的一步。很多开发者提取完文本后，直接把整本书的内容当成一个巨大的字符串来处理。这样做的问题在于：每当你检索到一个片段时，不知道它来自第几章第几节，回答问题时无法标注准确的引用来源。
典型场景：
| 场景 | 结构还原的重要性 |
|---|---|
| 合同 PDF | 切片时要知道这是第几章、第几条、第几页 |
| 财报 PDF | 要知道这个数字来自哪张表、哪个指标、哪个年份 |
| 技术文档 | 代码示例属于哪个功能模块，参数说明属于哪个 API |
核心意义： 否则 Agent 回答的时候看起来很自信，但你根本追不回来源，无法验证对错。
一个实用的做法是：在解析阶段给每个文本块打上"章节路径"标签，比如 第3章 > 3.2 性能优化 > 第二段。这样即使检索系统把内容切片了，每个切片仍然知道自己在原文中的位置。这在金融和法律场景尤为重要——监管要求 AI 回答必须可以溯源到原始文件的具体页面和章节。
第 3 层：切片和索引——按语义结构切，不要按固定字数切
PDF 的 chunk（切片）不能只按固定 1000 字一刀切，更好的方式是按语义结构切片：
切片规则：
- 标题下面的段落放一起
- 表格单独做结构化处理
- 图片和图表生成专门的摘要
- 长表格可以按行列字段转成结构化文本
按字数切片的弊端很明显：一句话可能被切断，一段话可能从中间断开，一个标题可能被分到两个切片里。特别是对于技术文档，一个 API 说明通常包含"参数描述""请求示例""返回示例"三个部分，如果被切成两半，每一半都语义不完整。
每个 chunk 必须带完整的 metadata（元数据）：
- 文档 ID
- 页码
- 章节标题
- 表格编号
- 图片描述
- 时间版本
关键优化：给每个 chunk 补一段上下文说明
让模型知道这个片段在原文中属于哪一部分，避免检索回来以后"只见树木，不见森林"。这也是 Anthropic 官方推荐的 Retrieval 优化思路。
例如，一个关于"HTTP 状态码 401"的 chunk，可以在前面补一句上下文："以下内容为《Web API 设计规范》第 7 章'错误处理'的 7.2 小节，介绍认证失败场景。"这样 LLM 在生成回答时既知道答案本身，也知道上下文范围，避免断章取义。
第 4 层：Agent 调用——把 PDF 能力封装成工具链
Agent 不应该一次性把整个 PDF 塞进上下文，而是把 PDF 能力封装成独立工具，按需调用：
常用工具：
| 工具 | 功能 |
|---|---|
search_pdf |
负责检索相关片段 |
read_page |
负责读取指定页的完整内容 |
extract_table |
负责提取指定表格 |
analyze_chart |
负责分析图表 |
quote_source |
负责返回引用来源 |
调用逻辑：
- 用户问简单事实 → 走向量召回
- 用户问复杂对比 → 先检索多个章节，再让 Agent 规划阅读顺序
- 用户问表格和图表 → 调用专门的表格或视觉工具
这种工具化封装的核心思想是：不要试图用一个巨型上下文窗口装下整个 PDF，而是把 PDF 当成一个可以按需查询的数据库。LangChain 的 create_retrieval_chain 和 LlamaIndex 的 QueryEngine 本质上就是在做这件事——它们把切片的索引和 LLM 的推理能力串联起来，让 Agent 既能精准检索，又能基于检索结果做推理和归纳。
面试加分项：两个生产级细节
最后一定要补这两个生产级细节，直接拉开你和 Demo 选手的差距：
加分项 1：必须做可追溯引用
回答里最好能带页码、章节、原文片段，避免模型幻觉（Hallucination）。
官方标准：Anthropic 的 Citation 文档里也明确提到，PDF 可以按提取出的文本做引用，并返回页码范围。
可追溯引用的好处不仅仅是防止幻觉，还能建立用户对系统的信任。当用户看到"根据第 3 页第三段..."这种回答时，他会自己去翻 PDF 验证，发现内容确实如此，信任感就建立起来了。反之，如果 AI 答了一大堆内容却找不到出处，用户会越来越不信任这个系统。
加分项 2：必须做评测闭环
评测时不能只看最终答案对不对，还要单独评测这几个维度：
- 检索片段是否命中原文
- 页码是否正确
- 表格是否解析准确
- OCR 是否漏字
- 图表信息是否被正确理解
这套评测体系在生产环境中至关重要。建议用 RAGAS、TruLens 等评测框架建立基准测试集，包含至少 100 条涵盖不同 PDF 类型的测试用例。每次更新解析器或检索策略后回归测试一次，确保改动不会导致某个维度的质量下降。
标准答案总结
所以这道题的完整标准答案不是"PDF 转文本再向量化"，而是：
先识别 PDF 类型，再做多模态解析，然后还原文档结构，按语义切片，给 chunk 补上下文，建立向量索引和关键词索引，最后通过 Agent 工具链按需检索、读页、抽表、看图，并且全程保留页码引用和评测闭环。
这样回答，面试官基本就能判断你不是只做过 Demo，而是真的理解 PDF RAG 的生产难点。
📌 深入阅读： 想系统学习如何落地生产级 PDF RAG？推荐阅读 生产级 PDF RAG 完全指南：从解析到评测的四层架构实战，深入讲解每层的代码实现、技术选型和评测方法。