文档解析又慢又贵?LiteParse 让 RAG 本地吃文档

做 RAG 或 Agent 项目的人，很多都会卡在同一个地方。

不是模型不够强。

不是提示词不会写。

而是文档根本没被好好解析出来。

PDF 里表格乱了。

Word 里的标题层级丢了。

Excel 读出来像一坨文本。

PPT 顺序不对。

扫描件还要额外接 OCR。

最后你把这些乱七八糟的内容塞给向量库，再让大模型回答问题，它当然容易胡说。

很多人以为 RAG 效果差，是 embedding 不行，是模型不行，是提示词不行。

但真实项目里，经常第一步就错了：

文档没解析干净。

所以今天这个工具值得看一下：LiteParse。

它是 LlamaIndex 团队开源的本地文档解析工具，目标很直接：让你在本地快速把文档解析成 AI 能用的结构化内容。

这件事听起来不性感，但非常关键。

因为只要你做过文档智能，就知道“解析”是整个链路里最容易被低估的一环。

你可以把 RAG 想成做饭。

大模型是厨师。

向量库是冰箱。

检索策略是菜单。

但文档解析是洗菜、切菜、去泥。

如果菜都没洗干净，后面厨师再厉害也救不回来。

LiteParse 解决的就是这件脏活。

它支持 PDF、Word、Excel、PPT、图片等常见文档格式。

更重要的是，它不是只把文本硬扒出来。

它会保留位置信息，也就是 bounding box。

这个东西对普通读者可能有点陌生。

简单说，就是每段文字、每个区域在页面上的位置坐标。

为什么重要？

因为文档不是纯文本。

一份 PDF 里，标题在哪里、表格在哪里、注释在哪里、页眉页脚在哪里，都会影响理解。

如果解析器只按文字顺序乱读，表格很容易散，布局很容易丢，模型拿到的上下文就会变脏。

有了位置信息，后面做表格还原、版面理解、截图定位、Agent 操作就更靠谱。

这也是 LiteParse 相比很多简单 PDF 文本提取工具更值得关注的地方。

它不是只服务“读文本”。

它更像是给 AI Agent 准备的文档入口。

比如一个 Agent 要处理合同。

它不只是要知道合同里有什么字。

它还可能需要知道某段条款在第几页、哪个区域，旁边是不是表格，是否有签字页，是否需要截图给用户确认。

如果底层解析没有坐标和布局，Agent 只能靠猜。

而一旦有了位置、截图和结构，Agent 就能更像人在看文档。

这就是文档解析对 Agent 的意义。

LiteParse 还有一个很大的优势：本地运行。

不用联网。

不用 API Key。

不用把客户合同、财务报表、内部资料上传到云端。

对很多项目来说，这不是锦上添花，而是基本要求。

尤其是做企业知识库、合规项目、医疗、金融、法务、政企资料处理时，文档能不能离开本地，本身就是一道红线。

云解析当然有它的价值。

像 LlamaParse 这种云服务，复杂文档、极端版面、高精度结构化场景会更强。

但不是每个项目一上来都需要云。

很多常规文档，完全可以先在本地吃掉。

只有特别复杂、特别脏、特别难的材料，再考虑上云。

这才是更现实的工程路线。

先本地解析。

本地解决不了，再上云增强。

这样既省钱，也更容易控制隐私边界。

从技术实现看，LiteParse 现在最被关注的一点，是它用 Rust 重写之后，速度有明显提升。

Rust 的优势不是“听起来高级”，而是适合做这种性能敏感、稳定性要求高的底层处理。

文档解析不是一次两次的小任务。

真正做 RAG 的时候，你可能要处理几百份、几千份，甚至更多文档。

这时候解析速度、内存占用、稳定性都会变成成本。

慢一点，看起来只是多等几秒。

但批量任务一上来，就会变成几个小时。

如果你还要反复调清洗策略、切分策略、索引策略，那解析慢会让整个开发过程非常痛苦。

LiteParse 的价值就在这里：

它把文档预处理这件事尽量做轻、做快、做本地。

对开发者来说，这比“又一个大模型包装工具”更实用。

它还支持多语言使用。

Python 可以用。

JavaScript 可以用。

Rust 可以用。

浏览器环境也能接。

这意味着你不一定非要把它塞进某一个固定技术栈里。

做后端服务，可以接 Python 或 Rust。

做前端工具，可以考虑 JS 或浏览器侧能力。

做桌面应用，也有更多组合方式。

对 AI 应用开发来说，这种工具最适合放在 RAG 的入口位置。

一个比较稳的流程是：

第一步，用 LiteParse 在本地解析原始文档。

第二步，保留文本、页码、坐标、布局信息。

第三步，按标题、段落、表格、页面区域做切分。

第四步，把切好的内容送进向量库或知识库。

第五步，Agent 回答问题时，不只返回文本答案，也能定位来源区域，必要时给截图。

这套流程比“直接把 PDF 文本提出来切块”要稳得多。

因为用户真正关心的不只是答案。

他还会问：

你这个答案来自哪一页？

原文在哪？

表格有没有看错？

能不能把那一段截图给我？

这时候，带坐标和布局的解析结果就很有用。

当然，LiteParse 也不是万能药。

特别复杂的扫描件、糟糕的图片质量、极端版式、手写内容、多语言混排，仍然可能需要更强的 OCR 或云解析服务。

所以我更建议把它当成本地第一层。

常规文档先用 LiteParse 快速处理。

本地解析质量不够，再把少量复杂文档交给 LlamaParse 这类云服务。

这样组合起来，比一开始全部上云更稳。

如果你现在正在做下面这些东西，LiteParse 值得放进工具箱：

企业知识库。

RAG 问答。

本地大模型应用。

AI Agent 文档工作流。

合同、报表、课件、论文、产品手册解析。

对隐私和成本敏感的文档智能项目。

它最适合的人群，不是只想随便读一个 PDF 的普通用户。

而是那些已经意识到“文档预处理决定 RAG 上限”的开发者。

很多 AI 应用做不好，不是因为最后一步不够酷。

而是第一步太粗糙。

文档没解析好，后面全是补锅。

LiteParse 这类工具的意义，就是把第一步做扎实。

让文档先变干净。

让结构先保住。

让 Agent 后面少猜一点。

如果你正在做 RAG，我建议你今天就检查一下自己的文档入口。

不要一上来就调模型。

先问三个问题：

我的文档解析后，表格还完整吗？

我的切片还能追溯到原文位置吗？

我的 Agent 能不能把答案对应到页面区域？

如果这三个问题答不上来，那 LiteParse 这种本地解析工具就值得试。

因为 RAG 的质量，不是从模型开始的。

它是从第一份文档被正确解析开始的。

评论区聊聊：你现在做 RAG 或 Agent，最头疼的是 PDF、Word、表格，还是扫描件 OCR？