PDF 没读对，后面的 AI 都是在瞎猜

很多 RAG 项目答错，第一反应都是怪模型。

模型不够强，prompt 不够好，检索参数没调对。

但我越来越觉得，很多问题更早就发生了：PDF 一开始就被读坏了。

表格错位，双栏串行，字段和值对不上。后面再接向量库、RAG、Agent，都是在一锅已经搅乱的文本里找答案。

PDF 不是一篇 Word

Word 更像一篇有顺序的文章。

PDF 更像一张被画出来的页面。

人眼看见的是：

Revenue    $1,234 Q1         $567 

程序拿到的可能是一堆坐标：

Revenue 在 x=50, y=100 $1,234 在 x=350, y=100 Q1 在 x=50, y=115 $567 在 x=355, y=115 

它知道字画在哪里，却不一定知道该怎么读。

所以 PDF 解析最麻烦的地方，常常在位置关系。

文档读错以后，模型看起来在理解，实际是在补洞。

LiteParse 值得看

最近 LlamaIndex 开源的 LiteParse，就卡在这个位置上。

它是一个本地开源的文档解析库，核心用 Rust 写，强调快速、轻量、保留空间布局。官方文档写得很明确：它在本机运行，没有云依赖，不用 LLM，也不需要 API key。

它能输出文本、JSON、bounding boxes，也能生成页面截图。开发侧可以从 Rust、Node.js/TypeScript、Python 或 Browser/WASM 接入。

这类信息对普通用户听起来有点硬。

但翻译成 AI 应用里的工作流，其实很简单：先让系统知道“这段文字在页面哪里”，再让模型回答。

关键是空间关系

LiteParse 的思路里有一个关键词：Grid Projection。

可以粗略理解成，把页面里的文字按坐标投到一个网格上，再尽量保留原来的对齐、缩进、列关系。

这件事对表格、财报、合同、技术文档特别重要。

RAG 最怕的情况，是检索到一段已经错位的内容。

金额跟错了字段，表头跟错了列，双栏内容被串成一行，模型再强也只能顺着脏数据编下去。

bounding boxes 还有一个额外价值：后面可以把答案指回原文位置。用户不只看到一句回答，还能看到它来自 PDF 哪一块。

适合做第一层入口

我会把 LiteParse 放在 AI 文档系统的第一层。

常规 PDF、合同、财报、说明书、表格型材料，先在本地快速解析，尽量保住版面关系。

如果是 Word、Excel、PPT 或图片，官方文档里的做法是先通过 LibreOffice 或 ImageMagick 转成 PDF，再进入同一套解析流程。

如果需要服务化，也可以用 liteparse-server，把解析能力挂成本地 HTTP 接口，给不同应用共用。

这比一上来就把所有文件丢给云服务更节制。

本地能读好的，先本地读。读不好的，再上更重的 OCR 或文档理解方案。

它也不是万能药

LiteParse 不是要替代所有解析器。

遇到扫描件、手写内容、图表密集报告、特别复杂的版式，还是可能需要 OCR，甚至需要 LlamaParse 这类更重的云端方案。

所以这篇真正想说的，不是“换一个解析库就万事大吉”。

而是做 RAG 和 Agent 文档读取时，要把入口检查前移。

别急着优化 prompt。

也别一上来就换更贵的模型。

先问一句：

你的 PDF，真的被 AI 读对了吗？

工具地址：https://github.com/run-llama/liteparse

留言区

你做文档问答时，最常见的问题是表格错位、双栏串行，还是引用找不到原文位置？