Just-in-Time Agentic OCR：两段式文档解析省 90% token 成本 · 干货攻略

  • 链接: https://x.com/jerryjliu0/status/2099534215973064764
  • 分类: x-tips
  • 来源: X @jerryjliu0
  • 作者: Jay
  • 更新: 2026-10-09

这是什么

Just-in-Time Agentic OCR（JIT OCR）是 LlamaIndex CEO Jerry Liu（@jerryjliu0）命名并系统阐述的一种文档解析模式，官方博客完整阐述见 llamaindex.ai/blog/just-in-time-agentic-ocr。

核心思想很简单：不要一开始就对所有文档跑昂贵的 VLM OCR，先用轻量免费工具快速过一遍，找到真正需要精细解析的页面，再针对性地调用 VLM。

两段式流水线如下：

第一段（Skim）：用免费 / 开源文档解析工具对全部文件做轻量文本提取。输出不够完美，但足够做 grep 关键词检索和轻量语义索引。这一步几乎零成本，可快速处理 10–100 个文件。

第二段（Zoom-in / JIT）：Agent 检索到相关页面后，用 VLM 质量的 OCR 工具（如 LlamaParse）对指定的那几页做精准解析。只解析真正被命中的页面，大幅降低调用量和 token 成本。

Jerry Liu 将其与 CPU 架构的 JIT 编译类比——按需解析精确页面，而非预加载全部内容。

为什么值得关注

谁分享的，解决什么问题

Jerry Liu 是 LlamaIndex 联合创始人兼 CEO，长期深耕文档智能与 Agent 架构。他的核心观察是：

当前主流 Agent 框架（Cowork、Codex、Grok 等）在处理用户上传的「数据房」（Data Room）——10–100 份文档合集——时，默认采用两段式文档处理，只是实现方式原始（pypdf + 内置 VLM），既贵又不准。

原始实现的三个问题：

  1. Opus 5 不是最好的 OCR VLM：前沿模型（Opus 5、GPT-5.5、Gemini 3.1 Pro）post-training 方向是推理 / 数学 / 编程，而非文档 OCR，ParseBench 评分普遍低于 LlamaParse，且成本高达 6–16¢/页。
  2. pypdf / pdftotext 第一段太弱：只能拉出 PDF 内嵌文本层，扫描件返回空内容，多栏布局文字交错，表格被逐列 dump，Word / Excel / PPT 等格式完全不支持。
  3. Agent 写大量一次性代码：每次 session 都要重新推导表格结构、截图表格、猜测单元格边界，既费 token 又不可复用。

JIT OCR 用 LiteParse + LlamaParse 替换这套原始流程，在数据房场景下实现成本与质量的双赢。

核验过程

本攻略所有关键数字均来自以下官方来源：

来源 核验内容
LlamaIndex 官方博客（Jerry Liu） 两段式流程描述；84 份 SEC 文件 12,013 页实验数据；LiteParse 32 秒数字；仅解析 2/12,013 页的案例
run-llama/liteparse GitHub（Apache 2.0，12k+ stars） ~2-5ms/页；50+ 格式；lit is-complex 复杂度检测；多语言绑定
run-llama/ParseBench GitHub（arXiv:2604.08538） ParseBench 评分体系（2,078 页，167k+ 规则，5 个维度）；LlamaParse Agentic 87.01% @ 1.25¢/页；Fable 5.1 78.92% @ 16.05¢/页；Opus 4.8 视觉 grounding 仅 18.7 vs LlamaParse 84
llamaindex.ai ParseBench 博客（2026-04-13） ParseBench 发布公告；LlamaParse Agentic 84.9%（旧测）/87.01%（GitHub 更新）；LlamaParse Cost Effective 0.38¢/页

交叉验证结论：

  • 博客原文 LlamaParse Agentic 得分 84.9%，ParseBench GitHub README 更新为 87.01%，以 GitHub 最新数据为准。
  • 博客称 LiteParse 32 秒处理 12,013 页（--no-ocr），GitHub README 确认 PDFium spatial parsing 速度 ~2-5ms/页，数据相互印证。
  • 原帖声称「省 90% 以上 token 成本」，由「仅解析命中的 2 页 vs. 全部 12,013 页」案例支撑，属合理估算。
  • ParseBench 数据显示 Opus 4.8 视觉 grounding 18.7%（博客原文），LlamaParse 84%，两者差距巨大，与 Jerry Liu「Opus 缺乏 grounding」的论断高度吻合。

未核验 / 标注：

  • 原帖提及 Codex、Cowork、Grok 等框架默认两段式，属 Jerry Liu 观察性陈述，LlamaIndex 博客未提供第三方来源印证，攻略中仅作为背景引用。
  • 90% token 成本节省为基于案例的估算，非严格 A/B 测试结果。

上手步骤

方案一：LlamaIndex 全家桶（推荐）

适合已在 LlamaIndex 生态中的团队，官方打通了两段式工具链。

第一步：LiteParse 第一段扫描

pip install liteparse

或通过 LlamaIndex Agent Skill 在 Claude Code / Cowork 中直接调用：

# 复杂度预检：哪些页面需要 VLM？
lit is-complex /path/to/doc.pdf

# 免费文本解析（无需 OCR，~2-5ms/页）
liteparse /path/to/doc.pdf --no-ocr --format markdown -o output.md

# 批量处理整个目录（12k 页 ≈ 32 秒）
liteparse ./sec-filings/ --no-ocr --format markdown --output-dir ./skimmed/

lit is-complex 输出每页 needs_ocr: true/false 及其原因（scanned / sparse-text / embedded-images 等），可直接喂给 Agent 判断是否需要 VLM 段。

第二步：LlamaParse 第二段精准 OCR

注册并获取 API Key：https://cloud.llamaindex.ai（免费 10,000 credits）

from llama_parse import LlamaParse

parser = LlamaParse(
    api_key="your-api-key",
    result_type="markdown",      # 或 "html"（保留 rowspan/colspan 表格结构）
    page_separator=True,
)

# JIT 模式：只解析检索命中的那几页，而非整文档
documents = parser.parse("path/to/doc.pdf", pages=[24, 25])

LlamaParse 的 pages 参数是 JIT 模式的关键——只花 VLM credits 在真正需要的那几页上。

第三步：用 estimateFileComplexity 自动化路由（可选，LlamaParse MCP 接口）

# MCP 工具：先问 LlamaParse 每页该走哪个 tier，再决定用 LiteParse 还是 LlamaParse
# 3M 10-K 实测：约 2/3 页面 LiteParse 足够，~35% 需要 LlamaParse

方案二：独立工具链（不依赖 LlamaIndex）

适用于非 LlamaIndex 技术栈的团队，核心接口均已开源。

第一段（LiteParse）：

# macOS / Linux / Windows 均支持
pip install liteparse

# 输出带 bounding box 的 JSON（用于后续表格重建）
liteparse doc.pdf --format json --output structured/

# Worker pool 模式（并行处理，防单个慢文件卡死）
liteparse ./docs/ --format markdown --workers 8 --timeout 30000

LiteParse 支持 Python、Node.js、Rust、WASM（浏览器端），并内置 Tesseract OCR 作为零配置备选。

第二段（选任一 VLM OCR）：

工具 得分（ParseBench） 成本/页 视觉 grounding 适用场景
LlamaParse Agentic 87.01% 1.25¢ 84.25 首选，质量和成本最优
LlamaParse Cost Effective 80.61% 0.38¢ 67.29 预算敏感场景
Fable 5.1 78.92% 16.05¢ 68.3 不推荐，成本太高
Opus 4.8 63.7% 7.3¢ 18.7 不推荐，grounding 极差

LlamaParse Agentic 在 ParseBench 的 5 个维度（表格、图表、内容忠实度、语义格式、视觉 grounding）均领先其他方案。

坑与适用边界

适用场景 ✅

  • 数据房（Data Room）：10–100 份文档的临时集合，ad-hoc 提问，不适合全量预解析。
  • Agent 迭代式文档交互：Agent 用 grep / 语义搜索快速找到候选页面，再针对性地「放大」——正是 JIT 模式的最佳拍档。
  • 大规模离线索引前的快速预览：先 JIT 跑一遍，确认文档质量，再决定要不要全量 VLM 解析。

不适用场景 ❌

  • 超大批量（1k–1M+ 文档）离线 RAG 管道：此时检索必须精准，检索质量依赖解析质量，必须 VLM OCR 全量前置。JIT 的「靠搜索弥补解析缺陷」策略失效。
  • 高精度字段提取场景：发票提取、KYC、claims intake 等——每一个字段都必须正确，没有「zoom in later」的余地，必须全量 VLM 解析并输出 bounding box + confidence score 供人工审计。
  • 10 页以下小文档：文档量太少时两段式的复杂度不值当，直接全量 VLM 解析更简单。

关键坑

  1. LiteParse --no-ocr 不处理扫描件：对扫描 PDF 返回空内容。lit is-complex 会报告 scanned / no-text，需要走 LlamaParse 第二段。
  2. LiteParse 输出表格需后处理：原始 markdown 表格在某些复杂多行表头场景下不完美，需要 LlamaParse 的 HTML 表格输出来确保行列对齐。
  3. LlamaParse MCP 的 estimateFileComplexity 需提前调用：要规划 VLM 消费，必须先单独跑一次 estimateFileComplexity，再决定哪些页面上 LiteParse，哪些上 LlamaParse。
  4. 背景缓存策略：在第一遍 JIT 结果返回用户后，立即在后台对全量文档跑 LlamaParse 并缓存——这样后续 session 就不重复花 VLM 费用了。这是生产环境的标准做法。

一句话结论

JIT OCR = LiteParse 快速过滤 + 按需 LlamaParse 精准解析，在 10–100 份文档数据房场景下比全量 VLM OCR 节省 90%+ 成本，同时 ParseBench 87% 准确率碾压各路前沿模型；记住它是「数据房 ad-hoc 专用」，大规模离线管道请直接全量 VLM OCR 上游。