文本型PDF,本地两百毫秒转成Markdown

别急着把 PDF 丢给 AI。

先过一道筛子。这话听起来像多此一举，但真正搭过文档管线的人知道，很多麻烦从这一步就埋下了：手里那几百份 PDF，到底哪些是需要重处理的，哪些本来就是干净的文本。

它先判断，再动手

这个库叫 pdf-inspector，用 Rust 写，做的是 PDF 分类与文本提取，默认动作分两步：先判断这份文件属于哪一类，再动手提取。

它把 PDF 分成四种：文本型、扫描型、图像型，以及几类混在一起的混合型。分类结果会直接给出来，往下怎么做，你心里就有底了。

判断完再提取，而且是带着位置信息提取，输出干净的 Markdown，表格、多栏排版、RTL 文本、旋转过的标注都不会被搅成一团。最关键的是：默认情况下它根本不走 OCR。一份本身就是文本的 PDF，不会被拖去跑一圈识别。

背后还有一道更细的活：分类这一步同时给出 0 到 1 的置信度，并且按页决定要不要送去 OCR，而不是整本一刀切。这层判断在真实管线里最值钱——一份 PDF 里夹了几页扫描件是常见事，老办法要么全 OCR（费钱），要么只丢给纯文本提取器（漏数据），它给的是「哪几页该走 OCR、哪几页不用」这种级别的建议。

省时间的地方在这里：不是识别得多快，而是干脆不识别。

大部分文档管线里，真正干净的文本型 PDF 占多数，剩下那部分才需要特殊处理。先分清这两拨，你就不会把力气花错地方。硬扛的做法是把所有文件都送去做识别，慢只是一方面，识别本身还会引入错误：本来没问题的文字，被重认一遍反而认错了。

为什么「带位置」这件事重要

纯文本提取最大的坑是顺序。两栏排版的文字，按阅读流读是一回事，按坐标顺序拼出来又是另一回事，表格更是直接散架。

每一段文字都带着自己在页面上的位置，这层信息保住了，下游的检索和问答才稳得住。官方给出的目标是：文本型的 PDF，在本地两百毫秒之内处理完。

这一点在知识库里被低估了。很多人把检索答不准归因于模型不行，回头查才发现，解析出来的文本本身就已经乱了顺序、丢了表格。上游错一步，下游怎么调都补不回来。所以这类「看起来只是前置小工具」的项目，实际上决定了整条链路的上限。

调用也很短：读文件、打印类型、打印 Markdown，三行就够。需要上 OCR 的时候另起一行（process_pdf_with_ocr），返回值里多了一个字段，告诉你到底有多少页被送去了识别。做管线的人会喜欢这个数字，它能直接告诉你「该不该花这道工序」。

pdf-inspector 由 Firecrawl 团队构建并开源（仓库 firecrawl/pdf-inspector），定位很直接：把文本型 PDF 在本地处理掉，绕开昂贵的 OCR 服务——README 里还特别点了一句，大约 54% 的 PDF 本来就不需要 OCR，这道筛子先拦住一半的浪费。

你做知识库的时候，有没有被解析这一步坑过？

接入和它的边界

Python、Node.js、浏览器 WebAssembly 三套绑定，外加命令行，前端后端都能接。浏览器里也能跑这一点，意味着有些场景可以完全不落到服务端。

一个要提前知道的边界：pdf-inspector 默认不含 OCR，扫描件需要另外接一个外部的识别运行时——OCR 这一步走的是 PP-OCRv6 Small，PDFium、ONNX Runtime 与模型文件保持外部按需加载，只在有页真正被路由到 OCR 时才被碰。这是官方给的定位：选择性开启，不是全能。所以如果你的资料绝大多数是扫描件，它帮你解决的是「先分类」这半步，剩下那半步得自己补。

它还有一道细节对长尾情况很顶：会主动检测字体编码问题，发现坏了直接标出来，让调用方决定要不要回退到 OCR。这一类出错以前要靠人肉看，现在这一步在解析时就被拦下了。

一段文档管线里，最容易被跳过、又最不该被跳过的，就是分类这一步。花两百毫秒先问一句「这份文件到底需不需要更多处理」，比后面收拾烂摊子便宜得多。

转给那个也在啃一堆 PDF 的朋友。