PDF 解析开始回到本地:LiteParse 给 RAG 的信号

PDF 解析这件事，很多人第一反应还是“把文字抽出来”。

但如果你真的做过 RAG、知识库、合同问答、报告分析，就会知道：只拿到一串全文，往往还不够。

页码、坐标、截图、表格边界、段落结构、OCR 结果，这些东西才决定了后面的模型到底是在“理解文档”，还是只是在一团文本里猜。

今天看到的 LiteParse，释放的信号不是“又一个 PDF 工具”，而是：文档解析正在出现一个更轻、更本地、更工程化的输入层。

LiteParse 在 README 里的定位很直接：一个 standalone OSS PDF parsing tool，强调 fast and light parsing。

换成人话说，它不是要把 PDF 还原成漂亮页面给人看，而是把 PDF 处理成后续程序更容易消费的结构。

这对 Agent 和 RAG 很关键。

因为模型真正需要的经常不是“全文”，而是：

输入层能力对 Agent 的意义 spatial text parsing知道文字在页面上的位置bounding boxes能把答案和原文位置对齐screenshots能给多模态或人工复核留证据JSON/Text 输出能进入检索、索引和工作流OCR 支持能处理图片化页面或扫描内容

这类能力看起来很底层，但它决定了上层问答系统的可信度。

如果解析层把页眉、页脚、表格、脚注、正文都搅在一起，再强的模型也会被喂进一锅粥。

LiteParse 的路线：轻量、本地、开源

LiteParse 的几个关键词很值得注意：

• 使用 PDFium 做文本解析

• 内置 Tesseract OCR

• 可以接 HTTP OCR server

• 支持截图生成

• 输出 JSON 和 Text

• 支持 bounding boxes

• 可从 Rust、Node.js/TypeScript、Python、browser WASM 使用

• 支持 Linux、macOS、Windows

这些信息拼在一起，重点就很清楚了：它想成为一个可以嵌进工程链路里的本地解析层。

这跟“把文件上传到某个云端服务解析完再拿回来”是两种产品气质。

云端解析当然有它的价值，尤其是复杂表格、多栏布局、图表、手写、扫描件。LiteParse 自己的 README 也明确说，这类复杂文档用 LlamaParse 这类更强的云端解析会更合适。

所以这里不要误解：LiteParse 不是要承诺“所有 PDF 本地完美解析”。

它更像是给开发者一个轻量底座：在你不想把所有文档都送出本机，或者需要在本地预处理时，先有一个可控、可嵌入、可改造的解析入口。

做 RAG 的人经常盯着 embedding、rerank、chunk size、上下文窗口。

这些都重要。

但很多系统的瓶颈更早就发生了：文档进来的第一步，已经把结构弄丢了。

比如：

文档问题如果解析不好会怎样多栏排版阅读顺序错乱表格行列关系丢失页眉页脚噪音进入索引扫描件OCR 错误污染答案图文混排证据位置难以追溯

这就是为什么“本地轻量解析层”会越来越重要。

它不一定负责最终答案，但它决定了答案的原材料是否干净。

我的判断是：RAG 下一层竞争，不只是多塞文本、多调模型，而是谁能把输入清洗得更可信。

LiteParse 这类项目的价值就在这里。

它提醒我们：AI 应用的上限，有时不是模型，而是你交给模型的那份材料到底有多可靠。

• LiteParse GitHub: https://github.com/run-llama/liteparse

• GitHub API 核验时间：2026-05-31，7,990 stars，472 forks，Apache-2.0 license