做 PDF 处理最冤的一件事，就是文件里明明有完整文本层，系统还是老老实实把每一页转成图片、丢给 OCR、等结果，再付一遍识别费用。绕了一大圈，拿到的文字可能还不如直接复制粘贴。
Firecrawl 最近开源的 pdf-inspector，干的就是这一步脏活：PDF 进来，先判断它到底是文字版、扫描版、纯图片，还是几种页面混在一起。文字版直接在本地提取并转成 Markdown，需要识别的页面再交给 OCR，不再整份文档一刀切。官方给出的分类耗时大约是 10～50 毫秒，本地处理文字型 PDF 可控制在 200 毫秒以内。
老鬼看这类项目，第一眼一般不看“解析能力有多强”，先看它能不能把 OCR 路由做细。这一点确实有点意思。
pdf-inspector 会返回置信度，还能列出具体哪些页面需要 OCR。比如一份 80 页的报告，前面是正常文字，后面塞了几张扫描附件，就不用把 80 页全部送去识别，只处理那几页就行。做批量论文、合同、财报入库时，这个差别不只是快慢，OCR API 的账单也是真金白银。
提取部分不是简单把字符薅出来。它会根据坐标和字体信息重建阅读顺序，处理多栏排版、标题层级和列表；表格则同时参考 PDF 里的矩形绘制信息与文字对齐关系，最终吐出相对干净的 Markdown。
不过先别急着吹。
它没有内置 OCR，也不是 Marker、MinerU 那种模型型文档解析器。碰到扫描件、坏字体编码，或者结构特别诡异的 PDF，还是得准备后备识别链路。好在它会主动标记编码异常和待 OCR 页面，不至于静悄悄吐一堆乱码，让你到了向量库里才发现数据脏了。
接口给得比较全：Python、Node.js、Rust 都能接，还有浏览器 WebAssembly 版本。后者可以直接在用户浏览器里解析文件，不需要把 PDF 上传到后端，对隐私文档和纯前端小工具尤其省事。
我会把它放在 RAG 入库链路最前面：先分类，文字版直接转 Markdown，剩下的按页送 OCR。别指望它包办所有 PDF，但用来砍掉那批根本没必要跑 OCR 的请求，很实在。
Github 地址：firecrawl/pdf-inspector | 
发表于 2 小时前
|
查看: 3|
回复: 0
