企业花了几百万建 AI 知识库，结果 AI 在一本正经地胡说——根源在这里

一家金融公司，耗时半年，把十年的研报和合规文档全部接入 AI 问答系统。

上线第一天，有人问：“这份合同的违约条款是什么？”

AI 给出了一个听起来完全合理的答案。

但那个答案，是错的。

不是模型的问题。模型没变笨。是它拿到的"原材料"从一开始就坏了。

RAG 系统里有一个环节，所有人都默认它没问题，但它正在悄悄把你的 AI 变成一个自信的骗子——文档解析。

你可能从来没意识到，PDF 有多难读

说一个很多人不知道的事：

PDF 格式天生不是给机器读的，它是给打印机读的。

PDF 里没有"标题"，没有"段落"，没有"表格"。

它存的是：在坐标 (120, 340) 这个位置，放一段 12pt 的 Helvetica 字体文字。在坐标 (380, 340) 这个位置，放另一段文字。

就这样。每个字都是有坐标的独立浮动对象。

所以当你用常见的 Python 库（pdfplumber、PyPDF2）解析一份双栏 PDF，你很可能得到这样的结果：

左栏第一行 + 右栏第一行 + 左栏第二行 + 右栏第二行 + ……

两栏文字被交叉混在一起。一个完整的句子，被切成两半，分别插进另一个句子里。

你把这堆乱文送进大模型，大模型会给你一个听起来非常有条理的答案——因为它很擅长从乱文里"脑补"出逻辑。

这才是真正可怕的地方：它不会告诉你它读错了，它只会用错误的信息，给你一个自信满满的回答。

为什么这个问题一直没被好好解决？

解析工具不是没有，但全都有各自的局限。

商业方案（Adobe API、LlamaParse）需要把文件传到云端，有数据合规问题，而且按页收费，大批量处理成本不低。

开源 Python 库（pdfminer、pdfplumber）速度慢，对扫描件无能为力，复杂排版基本抓瞎。

核心矛盾是：解析文档需要真正理解文档的空间结构，但大多数工具只是在顺序读取字符流，根本不懂"这几个字在空间上属于同一列"。

没有人用足够快的语言，认真地把空间重建这件事做好。

直到 liteparse 出现。

liteparse 做对了什么

LlamaIndex 团队（就是那个做 RAG 框架的）用 Rust 从头写了一个文档解析器。

为什么是 Rust？因为解析文档是高频任务，一个企业知识库可能要处理几万份文件。Rust 的速度是 Python 方案的数量级级别。

但更关键的是它的核心技术：空间文本重建（Spatial Text Parsing）。

它不是顺序读字符，而是先识别出每个字的坐标，然后在一个二维坐标系里重建整个页面的空间布局。

双栏 PDF？识别出两列的边界，分别提取，按正确顺序拼合。表格？根据行列坐标还原单元格结构，不再错位。

这是一个范式级的差异——不是改进，是换了一种思路。

加上内置 Tesseract OCR（扫描件开箱即用）、支持 DOCX/XLSX/PPTX 等格式、Python/Node.js/WASM 多种接入方式、完全本地运行无需上传数据……

它发布后在 GitHub 快速积累了大量 star，开发者社区反应热烈。

每一颗 star 背后，都是一个开发者在意识到——他们也踩过这个坑。

文档解析烂了，你的 AI 再强也没用

这不是危言耸听。

金融行业：合同条款解析错误 → AI 给出错误法律建议 医疗行业：病历扫描件识别混乱 → AI 辅助诊断数据失真 制造业：技术手册多栏错位 → AI 给出错误操作指引

模型能力每六个月翻一倍。

但如果地基是坏的，楼建得越高，倒得越惨。

liteparse 是免费的，开源的，今天就能用。

如果你的团队正在做 RAG 系统，或者已经在跑了——现在去检查一下你的文档解析环节。

不检查，你不会知道那里是不是已经在悄悄生产垃圾。

作者：Max | Sky 科技内容

字数：约 1100 字