LiteParse 更新:PDF 解析提速 20%–25%,并加入复杂度路由

9月22日，LlamaIndex 发了一篇 LiteParse 更新，标题里最抓人的不是某个模型名字，而是几个很工程师的数字，文本提取 2.76ms/页，Markdown 渲染 3.94ms/页。

PDF 解析这件事，平时很少有人觉得它性感。大家更容易讨论模型多大、上下文多长、Agent 能不能自己干活，至于一份 PDF 怎么被拆成文字、表格和版面结构，往往被塞进系统最底下，只有出了乱码、错列、引用飘走的时候，才突然想起来它有多重要。

这次 LiteParse 的更新，让我感兴趣的也不是单纯的快，而是它把 PDF 处理拆成了两个问题，一个是能不能更快地把内容拿出来，另一个是拿出来之后，能不能知道这份文档到底有多难。

先看速度。

LlamaIndex 说，LiteParse 维护了自己的 PDFium fork。它在底层做了几件不太容易被用户直接看见，但会实打实影响耗时的事，包括缓存和记忆化，修复二次复杂度，及时释放内存，以及引入 mimalloc。

官方称，这些 PDFium 优化让文本提取耗时降低了 20% 到 25%。在 LiteParse 自己的测试集里，2.14.6 的文本提取是 2.76ms/页，LiteParse 2.1 是 3.51ms/页。

坦率地讲，这个数字确实漂亮，但我觉得不能只盯着 2.76 这几个数字发出一声惊呼，然后把它当成所有 PDF 的通行证。这个数字很容易让人先冒出一句，？？？官方给出的结果来自特定测试集，OCR 开关、数据集和硬件条件都会影响结果。工程上的好消息，应该被准确地使用，而不是被夸张地使用。

同一张对比表里，Markdown 渲染也有一组很有意思的数据。LiteParse 2.14.6 是 3.94ms/页，pdf-inspector 是 5.72ms/页，opendataloader 是 24.15ms/页。

你会发现，PDF 解析不是只有把字抠出来这一关。文本出来之后，还要变成能继续进入 RAG、文档智能体和企业数据处理链路的结构。慢的地方，可能不在某一个大模型，而在底层库、内存分配，以及版面结构恢复这些看起来不够热闹的环节。

这也是 LiteParse 这次更新里，我觉得更值得聊的一层。它不是只在做一个更快的文本抽取器，而是在把解析过程往文档理解的入口处推。

官方还报告了两项结构相关的提升，OpendataLoader-Bench 的表格指标从 0.693 提升到 0.818，olmOCR table_tests 从 48.2 提升到 52.5。

这两个数字不能直接被翻译成所有表格都变得完美，但至少提醒了我们，速度和结构准确率必须放在同一张桌子上讨论。一份 PDF 如果 2 毫秒就读完，却把表头、单元格和上下文关系拆得乱七八糟，后面的检索再聪明，也只能在一地碎片上努力。

然后是视觉定位。

LiteParse 新增的能力，是把 Markdown 元素作为 block 输出，同时关联回原始页面上的 bounding box。也就是说，抽取结果不只是有一段文字，还能告诉你这段文字在原页面的哪个位置。

这一下给引用、审计和多模态 RAG 留出了更大的空间。你不只是拿到一条看起来正确的答案，还可以继续追问，它来自第几页，落在页面什么区域，旁边是不是一张表，或者是不是和另一个版面元素挨在一起。

说真的，PDF 最麻烦的地方，很多时候不在文字本身，而在文字之间的距离、顺序和位置。两栏排版里，阅读顺序可能横着走，也可能竖着走。表格里，一个数字离开了自己的列，语义就会突然变形。视觉定位没有自动解决所有问题，但它至少让解析结果没有彻底脱离原始页面。

对企业用户来说，这个回到原页面的能力挺关键。做知识库的人需要引用，做审计的人需要回看，做文档智能体的人需要把回答和证据对上。只给一段干净的 Markdown，有时候还不够，大家还想知道这段内容是怎么从页面里长出来的。

更有意思的，是 LiteParse 新增的 is-complex API。

这个 API 会去判断页面是不是扫描页，文本覆盖率怎么样，有没有乱码、表格、多栏和高图形密度等特征，并且可以返回页面级 JSON 结果。官方称，这个复杂度判断大约需要 3.5ms/页。

我喜欢这个设计，是因为它承认了一件很现实的事，PDF 从来不是一种难度。一个规整的文字型报告，和一份扫描文档、复杂表格、多栏页面，表面上都叫 PDF，实际上完全不是同一类任务。

以前很多文档系统的做法，有点像不管来的是自行车、卡车还是一辆拖拉机，都先把它们推进同一条处理链路。简单文档当然能跑，复杂文档就开始出现识别失败、内容错位，甚至整个链路成本被拖高的情况。

is-complex 做的事情，是先判断，再路由。简单页面走轻量链路，扫描、乱码、表格和多栏布局更集中的页面，可以被送到更合适的处理链路里。

这里需要把边界说清楚。is-complex 负责的是判别和路由，不是自动解决复杂 PDF 的完整方案。它像一个分诊台，不是手术室。它能告诉你哪里可能需要更强的处理，却不会凭空把扫描件变成完美的结构化数据。

你不是每次都需要最贵、最重的方案。很多规整 PDF 如果都被送进高级链路，成本和时间都会被白白消耗。可如果你只追求快，把所有复杂文档都当成普通文本，最后又会在引用、表格和版面关系上付出代价。

真正有用的系统，应该允许这两件事同时成立，简单文档快速通过，复杂文档得到更认真对待。

LiteParse 目前使用 Apache-2.0 许可，也提供 Node、Python、Rust 和 WASM 生态的安装方式。对不同技术栈的团队来说，这让它更容易被放进现有的文档处理链路里，而不是只能停留在一个演示页面上。

再回头看那几个数字，LiteParse 每周包下载量超过 30 万，GitHub stars 超过 1.2 万，累计提交超过 1000 次，贡献者超过 30 人。它已经不是一个刚刚冒出来的实验性小玩具，而是在持续被维护、被使用、被修补的基础设施。

但数字越好看，越需要知道它们的边界。LiteParse 2.14.6 的 ParseBench 结果，来自特定测试集，表格、内容忠实度、语义格式和视觉定位这些指标要一起看，不能只截取速度最快的那一格。工程判断不是挑一个最容易传播的数字，而是看它在自己的文档分布里能不能稳定工作。

PDF 解析一直有点像被忽略的地基。房子上面可以挂大模型、RAG 和 Agent，地基却决定了这些东西到底站不站得住。LiteParse 这次更新让我看到的，不是一个更快的 PDF 转换器，而是一种更务实的路线，先把底层性能磨出来，再把页面位置保留下来，再承认文档有难有易，并为这种差异安排不同的处理方式。

真实世界里的文档不会排队等着被同一种算法优雅处理，它们会带着扫描痕迹、表格和多栏布局一起冲进来。

所以，下一次再看到一个解析器只说自己有多快，我可能会多问一句，它知道自己面对的 PDF 有多难吗？它能不能把复杂的页面挑出来？它能不能让我回到原始页面，确认答案到底来自哪里？

快，很好。

但知道什么时候不能只追求快，可能更重要。