我们构建了一个文档 OCR 路由器，它可以估算每一页的复杂度，并用相应的模式进行解析

• 有些页面全是原生文本，可以直接用 LiteParse 处理
• 有些页面包含扫描图像或表格，可以用我们的高性价比层或智能体层来处理
• 有些页面包含乱码文本——解码后是垃圾内容——所以你需要一个更重量级的 VLM 来理解文本元素
• 有些页面包含大量视觉元素，例如带标签或不带标签的图表或示意图，这同样需要更深入的视觉处理

通过 LiteParse 中的 is_complex 开关，你实际上可以免费获得路由能力。下一步是搞清楚如何用相关的 VLM 模式来解析不同复杂度的页面。LlamaParse 在这方面做得很好！

博客：https://llamaindex.ai/blog/parse-gateway-smart-page-level-document-parser-routing…

LiteParse：https://github.com/run-llama/liteparse…

LlamaParse：https://cloud.llamaindex.ai

Parse Gateway：智能的页面级文档解析路由

来源：https://www.llamaindex.ai/blog/parse-gateway-smart-page-level-document-parser-routing 智能体的兴起已将软件行业的关注点从“为每个任务使用最好的模型”转向“寻找最好的模型组合，以便快速、可靠且以相对可控的价格完成每个特定任务”。

这种转变背后的概念被称为路由：虽然早期的实现（https://github.com/run-llama/llama_index/blob/main/llama-index-core/llama_index/core/query_engine/router_query_engine.py）在几年前就已经开始流传，尤其是在 RAG 领域。随着最近 token 消耗的激增，这一理念真正重新流行起来。

该领域的许多参与者已经开始将路由作为其平台的核心部分，例如 OpenRouter 的Fusion (https://openrouter.ai/blog/announcements/fusion-beats-frontier/)以及 Sakana AI 的Fugu (https://sakana.ai/fugu/)，从这些服务中出现了一个模式：一个好的编排器/调度器是决定路由系统在执行任务时能否成功的关键要素。

虽然大多数路由领域都聚焦于为智能体提供动力的语言模型，但我们决定将同样的概念和经验应用于更贴近我们自身的事物：文档解析，借助我们的新 Parse Gateway (https://parse-gateway.dev/) Web 应用。

你并不总是需要最好的解析器

文档处理流水线往往倾向于高估每个文件的解析复杂度需求，更不用说文件中的每一页了。

相反，目前有两种普遍做法：

• 使用最好的解析器，以牺牲成本和延迟为代价换取输出质量
• 使用最快的解析器，以牺牲输出质量为代价换取更低的延迟和成本

这些策略通常是“扁平”的，意味着它们不加区分地适用于流经流水线的所有文档。即使在那些有一定区分度的系统中，区分也大多是在文件级别进行的，并且由人类或 VLM 来判断复杂度并路由到适当的流水线，这意味着更高的成本和更长的处理时间，从而让公司不愿采用这种方法。

通过 Parse Gateway，我们决定走一条不同的路，这是在 LiteParse v2.2.0 中引入 is_complex 功能之后。该功能在页面级别估算文档的复杂度，确定是否需要 OCR，以及为什么可能需要更高级的解析技术，同时也会参考布局复杂度的信号。

思路很简单：当文件上传后，LiteParse 会在页面级别估算其复杂度，然后根据每页为什么——以及多大程度上——需要比廉价纯文本解析更进一步的处理，将每一页路由到相应的 LlamaParse 层级。is_complex 揭示的每个原因都对应一个基准层级：

原因 | 解释 | 基准层级 no-text | 几乎没有可提取的原生文本，且背后没有整页栅格图像（例如空白页，或近乎空白的封面/分隔页）。 | 高性价比 scanned | 单个栅格图像几乎覆盖整个页面，且背后几乎没有可提取的文本（例如扫描或拍摄的页面）。 | 智能体 sparse-text | 有一些真实文本，但只覆盖页面的一小部分。通常是图像密集、只有简短标题的页面。 | 智能体 embedded-images | 大量嵌入式栅格图像与原生文本共存。 | 智能体 garbled | 原生文本解码后是垃圾内容（cmap 损坏 / Type3 字符编码回退），因此可见字形与提取文本不一致。 | 智能体 Plus vector-text | 文本以填充矢量轮廓的形式绘制，不在文本层内，因此没有原生文本项可以表示它。 | 智能体 Plus

但我们不会止步于基准层级。is_complex 还会返回每个原因背后的严重程度：页面实际被文本覆盖的部分有多小、乱码或矢量文本页面受影响的范围有多大、正文文本中穿插了多少个独立图像……Parse Gateway 会利用这些指标，在信号表明页面比单纯基于原因所暗示的更难时，将页面提升到基准层级之上。当一个页面同时触发三个或更多原因时，也会被升级，因为跨维度叠加的问题（例如，同一页上同时存在稀疏文本和嵌入式图像和乱码）往往比任何单一原因都更难处理。此外，布局复杂度信号（多栏阅读顺序、带框或无框的表格、密集的图形覆盖）也会被独立纳入考量：一个页面可能完全不需要 OCR，但如果其结构足够复杂，足以让单次提取失败，它仍然会被提升一个层级。

如果不需要 OCR 且布局简单，该页面会被路由到 LiteParse（从 v2.1.0 开始支持输出 Markdown）。这样，你就不会用一个解析器解析整个文件，而是根据每一页的实际难度将页面分散到不同的层级，从而降低非 OCR 页面的成本和延迟（LiteParse 在进程内运行，完全免费），同时不会损失那些路由到更强大的 LlamaParse 层级的复杂页面的准确性。

以下是路由流程的动画：

为所有人提供路由——包括你的智能体

Parse Gateway 提供的智能路由不仅限于 Web 应用：我们还将同样的能力带到了 MCP 服务器中。

通过在你的智能体中添加 https://mcp.llamaindex.ai/mcp（或者如果你只想要专门的解析工具子集，则使用 https://mcp.llamaindex.ai/parse/mcp）作为 MCP 服务器，你将获得两个额外工具：

• estimateFileComplexity — 预测文档是否需要完整解析，或者是否可以用 LiteParse 处理。
• parseWithLiteParse — 让你的智能体显式地将兼容文档路由到 LiteParse，以获得更低延迟和零成本、进程内解析。

这使得智能体能够自动做出解析决策：它们可以首先估算文档复杂度，然后选择最合适的解析层级，在速度、成本和提取质量之间取得正确的平衡，无需任何硬编码的启发式规则。

在底层，estimateFileComplexity 使用与 Parse Gateway 的 /is-complex 端点相同的算法，确保无论你使用的是 Web 界面还是由 MCP 驱动的智能体，路由决策都是一致的。

这对文档处理意味着什么

基于复杂度的路由可能是你的文档处理流水线中缺失的一环：PDF 和其他非结构化文档并不是同质的页面集合，它们通常混合了文本完全清晰的页面、图像页面、表格页面和扫描内容页面。

从这个意义上说，一刀切的方法不可避免地会带来一系列权衡，这些权衡偏向于成本-延迟-准确性三角中的一个顶点，而在其他方面有所损失。推断页面复杂度并使用专门的层级进行解析，是迈向兼顾所有三个顶点且在任何方面都不明显牺牲的解决方案的第一步。

你可以在 Web 应用演示中试用 Parse Gateway，并在 GitHub 仓库中找到代码：https://github.com/run-llama/parse-gateway。

欢迎告诉我们你的想法！

LlamaIndex 🦙 (@llama_index): 并非 PDF 中的每一页都需要相同的处理。

扫描的封面、密集的表格、清晰的文本页、图形密集的图表……大多数解析流水线会把所有这些页面交给同一个解析器，从而在整个文档中被迫在成本、速度和准确性之间做出权衡。

我们