RAG PDF：pdf-inspector 和 OCR 怎么选？

官方仓库当前展示的基准结果中，pdf-inspector 在 200 份文档上完成一次完整解析的中位耗时为 0.470 秒，但该数据来自 Apple M4 Pro、固定语料和特定版本，不能直接当成所有生产环境的速度承诺。可执行的结论是：不要在 pdf-inspector 和 OCR 之间二选一；先检测，再把扫描页或低质量文本层送入 OCR。(github.com)

这篇文章适合三类读者：正在从零搭建 RAG 摄取链路、需要确定第一版方案的开发者；已有 OCR 流程但处理慢、结果不稳定的团队；以及准备租用远程算力做批量回归、需要先定义测试指标的技术负责人。

最后更新于 2026 年 8 月 10 日，信息核实自 pdf-inspector 官方仓库、其变更与示例资料，以及 PDF 文本提取和 OCR 工具的官方文档。性能结论只引用公开基准，不替代目标样本上的实测。

先看评分：混合路由通常是生产默认选项

把 PDF 送入 RAG 前，真正需要决定的不是“要不要 OCR”，而是“哪些页面值得 OCR”。原生文本提取、隐藏文本层和 OCR 输出各有边界：

原生文本层通常保留字符、坐标和部分字体信息，适合直接进入切分。
低质量隐藏文本层可能“看起来有字符”，但阅读顺序、断行和页码映射已经损坏。
OCR 能处理扫描页和图片文字，却可能丢失原始字体、表格关系、公式结构和精确版面。

pdf-inspector 官方定位是 PDF 分类与文本提取入口，可返回 text_based、scanned、image_based 和 mixed 等类型，并提供逐页路由信息；这意味着它更适合做前置检测与原生解析，而不是被当成完整的 OCR 或文档理解系统。(github.com)

方案	文本质量控制	延迟与吞吐	复杂版面	维护风险	推荐评分
全量直接 OCR	扫描件覆盖面高，但会引入识别错误	所有页面都承担渲染与识别成本	对图片文字有效，表格和公式仍需单独验收	容易出现语言包、超时和版本差异	2 / 5
先用 pdf-inspector 原生解析	文本版质量较好，但不能修复扫描页	对无需 OCR 的页面可跳过额外步骤	多栏、表格和混合页需人工标注验证	需要处理分类误判和回退	4 / 5
检测后混合路由	原生页保留结构，异常页单独补 OCR	避免对全部页面重复处理	能按页处理混合 PDF，但需要统一输出格式	路由、日志和回归体系更复杂	5 / 5

导入 RAG 的 PDF 是否都要先经过 OCR？
不必一概而论。文本型 PDF 应先尝试原生提取；只有当页面没有可用文本、文本量异常低、字符顺序不可读，或页面主要由图片构成时，才进入 OCR 分支。官方 PDF 文本提取文档也建议先判断页面是否需要 OCR，再对图像型页面调用 OCR。(pymupdf.readthedocs.io)

文本存在不等于文本可用

RAG 的第一道验收不能只写成“提取结果非空”。如果隐藏文本层把双栏内容交错排列，向量检索可能仍然返回片段，但生成模型拿到的上下文已经失去语义顺序；如果页码没有保留，回答中的引用就很难回溯到原始文档。

建议把文本质量拆成以下几层：

字符层：中文、英文、数字、标点是否完整，是否出现大量乱码。
顺序层：双栏、页眉、页脚、脚注是否按合理阅读顺序排列。
结构层：标题、段落、列表、表格和代码块是否能被区分。
定位层：每个切片是否能追溯到文件名、页码、页内坐标或块编号。
检索层：人工准备的关键词能否召回正确页面，而不是只召回相邻但无关的内容。

通用 PDF Parsing 工具通常能完成字符提取，却不一定能保证自然阅读顺序。官方文档明确说明，简单文本提取可能保留 PDF 内部编码顺序，不负责自动美化换行或重排；这正是“有文本但不能直接进 RAG”的典型原因。(pymupdf.readthedocs.io)

仅靠 pdf-inspector 就能完成扫描文档识别吗？
不能把它视为 OCR 替代品。它可以帮助判断页面类型，并对原生文本页面做结构化提取；但扫描页中的文字仍然需要 OCR 引擎识别。更稳妥的定义是：pdf-inspector = 检测器 + 原生解析入口，OCR = 扫描内容的条件处理器。

第一阶段：先建立逐页路由，而不是按文件名决策

混合 PDF 是最容易被错误处理的一类文件。一本技术手册可能前半部分是数字文本，后半部分是扫描附件；财务文件可能有可复制的正文，也夹杂盖章图片；论文中的公式和图表则可能是矢量对象或嵌入图片。

因此，路由粒度最好至少达到“页”，而不是只给整份文件打一个标签。建议采用以下流程：

固定输入副本：保存原始文件哈希、文件大小、页数、加密状态和元数据，避免后续处理覆盖证据。
运行 PDF 检测：记录整份文件类型、逐页类型、置信度以及检测版本。
执行原生解析：对文本型页面提取 Markdown、文本块、坐标和页码信息。
计算质量信号：检查字符数、有效字符比例、连续空白、乱码比例、段落长度和标题数量。
触发 OCR 分支：对扫描页、图片页或低质量文本层渲染后 OCR；不要仅因“文件中包含图片”就全量 OCR。
统一输出格式：把原生解析与 OCR 结果都转换为相同的文档块结构，保留来源页码和处理路径。
再做切分与嵌入：先通过质量门槛，再执行 chunk、embedding 和入库，避免把坏文本固化到向量库。
保存失败回退：OCR 超时、语言识别错误、页面损坏时，进入人工复核或备用解析器，而不是静默丢页。

可复制文本的 PDF 和扫描图像型 PDF 应如何分流？
可复制文本页面先进入原生解析；扫描页面先渲染并 OCR，再进入同一套清洗与切分；混合文件按页分流，最后合并为统一的中间格式。这样做的重点不是工具数量，而是保证不同路径输出的字段一致，否则后面的切分和检索会被路径差异放大。

OCR 输出也不是“恢复原始 PDF 结构”。官方 OCR 文档指出，识别结果通常以隐藏文本层写入，字体样式信息可能被简化，矢量图形也不属于 OCR 能识别的对象。(pymupdf.readthedocs.io)

第二阶段：用指标判断是否应该继续 OCR

文档预处理的指标不应只看平均耗时。对 RAG 来说，错误召回、引用不可追溯和重复 OCR 往往比单次处理慢更难修复。

建议至少记录：

路由命中率：多少页面直接原生解析，多少页面进入 OCR，多少页面触发回退。
有效文本率：提取字符中可识别中文、英文、数字和标点的比例。
结构保留率：标题、列表、表格、页码和段落边界通过人工标注的比例。
引用可追溯率：随机抽查的回答片段能否定位到原文件和页码。
检索召回质量：用固定问题集检查正确页面是否出现在前若干个结果中。
失败率与重试率：区分文件损坏、权限、渲染、语言包、OCR 超时和解析异常。
单位任务成本：按处理页数、处理时长、算力租赁周期和存储量核算，而不是只看工具是否开源。

RAG PDF 预处理应该重点评估哪些指标？
至少要同时评估质量、效率和可运维性。质量方面看有效文本率、结构保留率、检索召回和页码引用；效率方面看每批任务的处理时长、OCR 页面占比和重试率；运维方面看失败原因是否可追踪、依赖升级后能否复现，以及同一份样本是否能得到可比较的结果。

OCR 速度不能脱离环境给固定数字。官方文档将 OCR 与标准文本提取区分为数量级不同的处理路径，并建议每页只执行一次 OCR、缓存识别结果，后续搜索和提取复用同一个结果对象。(pymupdf.readthedocs.io)

复杂版面需要分工，不要期待单个工具全包

在多栏文档中，原生解析器可能保留坐标，却仍然需要按版面规则重排；在表格中，文字被提取出来并不代表行列关系仍然存在；在公式页中，OCR 可能识别出普通字符，却无法还原数学语义。

可以按职责拆分：

pdf-inspector：判断 PDF 或页面类型，优先处理原生文本和基础结构提取。
通用解析器：负责文本块、坐标、阅读顺序、表格候选区域或 Markdown 输出。
OCR：只处理没有可靠文本层的页面，或处理已经通过质量规则判定为低质量的页面。
RAG 预处理层：统一页码、标题层级、表格标记、文档 ID 和错误状态。
回归评测层：用人工标注样本比较三条路径，而不是只比较最终回答是否“看起来正确”。

第三阶段：把成本写成公式，避免被单价误导

持续摄取和周期性批处理的资源形态不同。小型原型可以在单机上完成验证；峰值批量导入更关心并发、队列和失败重试；持续生产摄取则更关心环境稳定性、版本固定和长期日志。

成本项	计算方式	需要记录的变量	常见遗漏
检测与原生解析	任务量 × 单任务处理时长 × 算力单价	文件数、页数、路由比例	把全部页面按 OCR 成本计算
渲染与 OCR	OCR 页面数 × 单页处理时长 × 算力单价	分辨率、语言、重试次数	忽略超时页和失败重跑
嵌入	有效文本块数 × 单块处理成本	切分规则、重复块比例	OCR 后文本膨胀导致块数增加
存储与日志	原文件、处理中间文件、结果和日志的保留量	保留周期、备份策略	只计算向量库，不计算中间产物
环境租赁	租赁周期 × 环境单价	峰值时长、空闲时间、并发度	用长期环境承载一次性批处理

对于大量扫描页，OCR 前的渲染分辨率、语言包和图像预处理会直接影响处理时长与结果质量；官方工具文档也将旋转校正、去倾斜、多语言和多核心处理列为可配置能力。(ocrmypdf.readthedocs.io)

因此，成本估算应至少比较两种方案：

全量 OCR：总页数 × OCR 单页耗时 + 全量渲染成本 + 重试成本。
检测后分流：检测成本 + 原生页解析成本 + OCR 页数 × OCR 单页耗时 + 路由维护成本。

第二种方案不一定在每个小样本上更快，但它能让持续摄取的成本随“需要 OCR 的页面数”增长，而不是随全部页面数增长。

按规模选择架构，而不是按工具热度选择

使用规模	推荐组合	适合原因	不建议的做法
小型原型	检测 + 原生解析，异常页手动 OCR	快速验证字段、切分和引用设计	一开始就搭建复杂队列和多级回退
周期性批处理	逐页检测 + 原生解析 / OCR 分流 + 失败队列	能控制峰值资源，并支持批量回归	用固定平均速度推算所有批次
持续生产摄取	版本固定的分级路由 + 缓存 + 监控 + 回归集	能追踪依赖升级、样本漂移和成本变化	OCR 全量运行且不保存路由日志

如果团队正在搭建第一版 RAG，建议先完成“检测、质量门槛、失败回退、来源定位”四件事，再决定是否引入更复杂的版面模型。对已经存在的 OCR 管道，优先检查是否把文本型 PDF 也送进了 OCR，以及是否每次检索都重复识别同一页面。

上线前可勾选的验收清单

[ ] 样本同时包含文本型、扫描型、混合型、多栏、表格、公式和图片文字页面。
[ ] 每个页面都有明确的处理路径：原生解析、OCR、备用解析或人工复核。
[ ] 输出字段统一包含文档 ID、页码、块 ID、解析版本和错误状态。
[ ] 对低质量隐藏文本层设置了回退条件，而不是只检查文本是否非空。
[ ] OCR 结果保留原始页码，并能从检索片段回到 PDF 页面。
[ ] OCR 超时、权限错误、损坏文件和语言包缺失都有可观测日志。
[ ] 依赖版本、模型版本、渲染参数和切分规则已固定。
[ ] 同一脱敏样本可以重复运行，并比较文本、结构、召回和成本变化。
[ ] 生产上线前分别测量小批量、峰值批量和增量摄取，不用单一平均值代替。
[ ] 向量库写入前存在质量门槛，失败页面不会静默进入正式知识库。

最终选型对照

判断条件	选择 pdf-inspector 原生入口	选择条件 OCR	选择混合路由
页面有稳定文本层	✅	❌	✅
页面完全由扫描图组成	❌	✅	✅
文件中逐页类型不同	⚠️ 需继续分流	⚠️ 不能盲目全量	✅
需要保留阅读顺序和页码	✅ 先验证样本	⚠️ 需额外映射	✅
追求最简单的原型	✅	⚠️ 仅限扫描样本	✅ 但可简化
持续批量摄取	❌ 单一路径不足	❌ 全量成本高	✅
需要长期可回归运维	⚠️ 需补日志和回退	⚠️ 需缓存与版本控制	✅

RAG PDF 的推荐默认架构是：pdf-inspector 检测 → 原生文本解析 → 质量评估 → 页面级 OCR 回退 → 统一清洗 → 切分与嵌入。这条链路并不承诺任何工具在所有 PDF 上都准确，而是把错误暴露在进入向量库之前。

如果当前方案是“所有 PDF 直接 OCR”，真实缺点通常包括：文本型页面承担了不必要的渲染与识别成本；OCR 结果可能丢失字体和结构信息；批量失败时难以区分输入问题、语言问题还是算力问题。若改用本地 Mac 环境进行回归，Mac 方案更适合把检测、OCR、解析和版本固定放在同一套可复现流程中；当团队只需要临时算力、批量测试或短期验收时，租赁 Zilmac 的 Mac 环境通常比长期购买并维护一台闲置设备更灵活。需要继续评估批量任务，可先参考云端 Mac 租用方案；需要把测试指标落成流程，则可结合 Mac 远程开发环境与 Mac VPS 方案比较任务周期、并发和数据保留要求。