延迟降至半秒每页：LlamaIndex 提取引擎的“Turbo”模式到底改变了什么

背景：为什么“快”突然成了提取服务的核心指标？

过去两年，我们在做文档智能时，往往把“准确率”放在第一位。毕竟，把发票、合同或采购单里的字段抽错一个数字，后续的业务逻辑就会全盘崩溃。但随着智能体（Agent）工作流的普及，提取不再只是后台的批处理任务，它开始直接卡在用户等待的路径上，或者成为智能体调用下一个工具的前置条件。这时候，速度就不再是锦上添花，而是决定整个系统能否流畅运转的生死线。

LlamaIndex 最近推出的 Turbo 提取模式，正是为了解决这个痛点。它不是简单的硬件升级，而是架构上的取舍：去掉了其他层级中独立的解析步骤，直接从文档页面进行并行提取。在官方基准测试 ExtractBench 上，Turbo 的处理时间中位数仅为每页 3.7 秒，而在中长文档上，由于固定成本被摊薄，速度甚至能飙升至每页 0.5 秒，同时保持 0.84 的值准确率（Value F1）。这意味着，对于许多实时交互场景，提取终于不再是瓶颈。

拆解：Turbo 到底快在哪里？

传统的文档提取流水线通常是“先解析，后提取”。解析阶段要把非结构化的文档转换成机器可读的格式（比如文本块、表格结构），这一步虽然必要，但非常耗时。Turbo 的核心思路是“跳步”：它省去了独立的解析通道，直接在原始页面上运行提取逻辑，并且把页面处理并行化。

你可以把它想象成去餐厅点餐。传统模式是“服务员先记单、后厨再备菜、最后上菜”，每一步都要等前一步完成；而 Turbo 更像是“开放式厨房”，厨师直接在食材上操作，多个厨师同时处理不同的菜。文档越长，这种并行化的优势越明显，因为启动任务的固定开销被大量页面分摊了。相比之下，其他系统在处理超过 16 页的文档时，延迟会陡峭上升，而 Turbo 的延迟曲线几乎保持平坦。

趋势洞察：实时提取正在重塑智能体架构

这件事背后，其实揭示了一个更深层的趋势：文档处理正在从“后台批处理”走向“实时交互”。以前，我们习惯把文档扔给后台，几小时甚至几天后拿结果。现在，用户上传一张发票，期望在几秒内看到表单自动填好；智能体读一份合同，需要在秒级内拿到结构化数据才能决定下一步动作。Turbo 的出现，标志着提取服务开始为“人在回路”和“智能体回路”的实时性需求做专门优化。

这也意味着，未来的提取服务可能会像今天的 API 网关一样，出现更细粒度的分层：有的追求极致准确（适合复杂合同），有的追求极致速度（适合实时表单），有的追求成本效益（适合批量归档）。开发者需要根据业务场景，动态选择最合适的提取策略，而不是一刀切。

实用价值：你该怎么用？

如果你是做表单自动填充、采购订单录入，或者构建需要实时读取文档的智能体，Turbo 值得优先尝试。它的响应速度足以让用户在一次会话中完成“上传-审核-确认”的闭环，或者让智能体在用户回复客户邮件的间隙内完成数据提取。不过要注意，Turbo 目前支持的输入格式和配置选项还比较少，不适合那些需要高度定制化解析规则的复杂场景。如果你的任务对延迟不敏感，但对成本敏感，传统的 Cost Effective 层级依然是更优选择。

反常识：快，不一定意味着“偷工减料”

很多人可能会担心，跳过解析步骤会不会牺牲准确性？但从 ExtractBench 的数据看，Turbo 的 Value F1 达到 0.84，与追求精度的层级差距并不大。这提醒我们，在文档智能领域，速度和准确并不总是零和博弈。通过架构优化和并行计算，我们完全可以在保持合理准确率的同时，把延迟压缩到人类可感知的阈值以下。对于大多数业务场景来说，0.84 的准确率加上秒级响应，远比 0.95 的准确率但等待几分钟要有价值得多。

原文地址: Introducing Turbo, our fastest extraction tier