Just-in-Time Agentic OCR：两遍范式搞定临时数据房 · 干货攻略
- 链接: https://www.llamaindex.ai/blog/just-in-time-agentic-ocr
- 分类: x-tips
- 来源: X @jerryjliu0
- 作者: Jay
- 更新: 2026-09-17
这是什么
Just-in-Time（JIT）Agentic OCR 是 LlamaIndex 联合创始人 Jerry Liu 在 2026 年 9 月提出的一种两遍文档处理范式，核心思想是：
不要对每个文档一开始就做昂贵的 VLM-OCR，而是在需要的时候才精准放大（zoom in）到相关页面。
传统方案（全量 VLM-OCR）的问题：贵、慢、没必要。JIT-OCR 的答案：先廉价扫全量，再对关键页做高精度视觉解析。
两遍流程：
用户上传 10~100 份文档
↓
Pass 1（Skim）：LiteParse 免费文本提取，32 秒扫完全量，建立轻量索引
↓
检索（grep / 语义搜索）→ 找到相关页码
↓
Pass 2（Zoom in）：LlamaParse 只对相关页做 VLM-OCR，输出表格结构 + 边界框 + 置信度
适用规模：~10–100 份临时文档（ad-hoc data room）。离线 pipeline（1k–1M+ 文档）不适用此模式。
为什么值得关注
谁分享的、解决什么问题
@jerryjliu0（Jerry Liu，LlamaIndex 联创）在 X 发帖并同步官方博客，揭示了一个当前 Agent 文档处理的普遍痛点：
做 VLM-OCR 全量扫描 10–100 份文档既慢又贵，但 Agent 其实只需要找到几个关键页。问题是：Agent 的开箱工具链（pdftotext / pypdf / Opus 5 直接读 PDF）精度不够，也太贵。
这背后有一个正在形成的主流趋势：Claude Cowork 和 Codex 等 Agent harnesses 已经默认使用两遍文档处理，但它们的开箱方案（pdftotext + Opus 5 直接读 PDF）有两个根本问题：
- Opus 5 不是最优 OCR 模型：前沿模型 post-training 主要优化推理/数学/编程，不优化文档 OCR。ParseBench 实测 Opus 4.8 视觉定位（visual grounding）仅 18.7 分，远低于 LlamaParse Agentic 模式的 84 分。
- 开源工具（pypdf / pdftotext）能力有限：只能抽出 PDF 内嵌文本层；扫描页返回空内容；多栏布局被穿插搅乱；表格按列吐出而不是按行。
解决了哪类问题
- 临时数据房（due diligence、合同审阅、财报问答）：用户偶尔上传一批文档问几个问题，不需要对每份文档都做全量 VLM-OCR。
- Agent 文档 pipeline 降本：当前 Agent 在文档处理上浪费大量 tokens 和预算做不必要的全量视觉解析。
核验过程
官方来源
| 来源 | 读取内容 |
|---|---|
| LlamaIndex 官方博客（2026-09-11，作者 Jerry Liu） | 完整两遍范式描述；84 SEC filings 实测数字；ParseBench 各模型分数；LiteParse/LlamaParse 工具能力 |
| run-llama/liteparse GitHub（v2.x） | 12.3k stars；Apache 2.0；PDFium spatial parsing；lit is-complex复杂度检测；50+ 格式支持 |
| superpowerdaily 报道（2026-09-14） | 交叉验证 84 filings / 12,013 pages / 32 秒 / 2 页 VLM-OCR 关键数字 |
交叉验证结论
| 说法 | 来源 | 状态 |
|---|---|---|
| LiteParse 扫描 84 份 SEC 文件（12,013 页）用时 32 秒 | 官方博客 §FinanceBench 示例 | ✅ 官方博客原文 |
| FinanceBench：84 filings、150 题、12,013 页 | 官方博客 §FinanceBench | ✅ 官方博客原文 |
| 对一个问题，VLM-OCR 只处理了 2 页（其余用 grep 定位） | 官方博客原文 | ✅ 官方原文 |
lit is-complex 标记 2,605 / 12,013 页（21.7%）需要 OCR |
官方博客原文 | ✅ 官方原文 |
| LiteParse GitHub：12.3k stars、Apache 2.0、PDFium spatial parsing | GitHub README | ✅ 已确认（搜索结果交叉验证） |
| ParseBench LlamaParse Agentic：87.0 @ 1.25¢/页 | 官方博客 §Issues | ✅ 官方原文 |
| ParseBench Opus 4.8：63.7 @ 7.3¢/页，visual grounding 18.7 | 官方博客 §Issues | ✅ 官方原文 |
| ParseBench Fable 5.1：78.9 @ 16¢/页 | 官方博客 §Issues | ✅ 官方原文 |
| LlamaParse estimateFileComplexity 工具支持按页复杂度分层路由 | 官方博客 §Tools | ✅ 官方原文 |
原帖主张标注：X 原帖（@jerryjliu0 status/2099629838005149854）链接已失效，文章内容来自 LlamaIndex 官方博客（2026-09-11）。X 帖核心观点与博客一致，博客内容更完整翔实，以博客为主要官方来源。
上手指册
工具选型
| 工具 | 角色 | 成本 | 适用场景 |
|---|---|---|---|
LiteParse (run-llama/liteparse) |
Pass 1 廉价扫描 | 免费、开源、本地 | ~10–100 文档的首遍扫描；复杂度检测 |
| LlamaParse (cloud) | Pass 2 精准放大 | ~1.25¢/页（Agentic 模式） | 关键页的 VLM-OCR；表格结构提取；背景预解析 |
| pdftotext / pypdf | 备选 Pass 1 | 免费、开源 | 仅数字 PDF；无扫描页的场景（不如 LiteParse） |
完整两遍流程（LlamaIndex + Claude Code / Cowork）
Pass 1：LiteParse 全量廉价扫描
# 安装 LiteParse（npm，TypeScript/Rust 实现）
npm install -g @llamaindex/liteparse
# 对整个目录做 spatial 文本提取（无 OCR，32 秒扫完 12k 页）
liteparse parse ./data-room --no-ocr --output ./skimmed/
# 或者用 Python API
from llama_indexParse import LiteParse
parser = LiteParse()
result = parser.parse("./data-room/3m-2022-10k.pdf", do_ocr=False)
print(result.text) # markdown，含 bounding boxes
复杂度检测：提前知道哪些页需要 VLM
# 对每页评分，找出需要 OCR 的页（扫描页、表格密集页、无文本层页等）
liteparse is-complex ./data-room/3m-2022-10k.pdf
# 输出示例（官方博客数据）：
# 12,013 页中 2,605 页（21.7%）被标记需要 OCR
# 其中：253 页含嵌入式图片，75 页无文本层
# Python: estimateFileComplexity（LlamaParse MCP 接口）
# LlamaParse 的 estimateFileComplexity 工具可按页返回解析层建议：
# - tier 1: LiteParse（免费）
# - tier 2: 专用 VLM
# - tier 3: 前沿 VLM
检索定位候选页
# 关键词 grep（最快的第一层过滤）
grep -r "Organic sales" ./skimmed/
# 语义搜索（LlamaIndex ChromaDB / FAISS）
# 用 skimmned 文本构建向量索引
Pass 2：LlamaParse 只对目标页做 VLM-OCR
from llama_index.llamaparse import LlamaParse
parser = LlamaParse(
api_key=os.environ["LLAMAPARSE_API_KEY"],
result_type="markdown",
parse_mode="agentic"
)
# 只解析相关页，而非整份文档
documents = parser.parse(
file_path="./data-room/3m-2022-10k.pdf",
pages=[24, 25], # 只解析这两页
)
# 背景预解析：用户先拿到 skim 结果，后台跑完整文档
# 下次同一文档直接用缓存，不需要重新 VLM-OCR
parser.parse_in_background(
file_path="./data-room/3m-2022-10k.pdf",
cache_key="3m-2022-10k-v2"
)
LlamaParse MCP Server 方式（Agent 直接调用）
# 在 Claude Code / Cowork 中，LlamaParse MCP server 已内置
# Agent 只需要说 "parse pages 24-25 of this 10-K"
# MCP server 自动路由到 LlamaParse，page_numbers 参数精准放大
判断自己该用哪种模式
| 场景 | 推荐方案 |
|---|---|
| ~10–100 份临时文档，一次性问答 | 两遍 JIT-OCR（LiteParse 扫 → grep/semantic → LlamaParse 放大） |
| 1k–1M+ 文档，离线索引，长期复用 | 全量 VLM-OCR 上游（每页都做 LlamaParse） |
| 发票/KYC/理赔等字段级准确率要求极高的提取 | 全量 VLM-OCR 上游（需要每字段可审计的 bounding box） |
| 合同/财报 due diligence，可穷举搜索 | 两遍 JIT-OCR + 穷举 grep（Agent 主动多轮搜索） |
坑与适用边界
⚠️ 第一遍召回风险（核心限制）
两遍模式的前提是第一遍能"找到"相关内容。如果：
- 表格被错误表示（如 pdftotext 把表格按列吐出，grep 可能匹配不到关键词）
- 扫描页无文本层（liteparse --no-ocr 对扫描页返回空）
- 关键词出现在"错误位置"（比如在脚注而非正文）
检索就可能错过该页。不过，84 filings 示例中 Agent 可以穷举搜索（不只是 grep 一次），多轮检索弥补了单次召回不足。在 ~10–100 份文档规模下，穷举搜索的延迟可以接受，但这个策略在 1M 文档规模下不可扩展。
⚠️ 开箱工具精度不够（Agent 自己重建的代价）
Jerry Liu 指出，当前 Agent harnesses 默认用 pdftotext + Opus 5 直接读 PDF 存在三重问题： - Opus 5 不是最优 OCR 模型（ParseBench 上低于 LlamaParse 17 分以上） - pypdf/pdftotext 无法处理 Word/PPT/Excel/邮件导出格式 - Agent 会写大量一次性 Python 代码重建表格和截图（不可复用，消耗 tokens）
LiteParse + LlamaParse 的组合解决了这三层问题：LiteParse 支持 50+ 格式含 Office 格式，LlamaParse 返回结构化 Markdown + HTML 表格 + bounding box，不需要 Agent 自己重建。
⚠️ 背景预解析不等于实时 JIT
背景预解析（parse_in_background）只是提前把 VLM-OCR 结果缓存起来，不是 JIT 模式本身。真正的 JIT 价值在于：Agent 通过检索找到相关页之前，不浪费任何 VLM 调用。背景预解析是用户体验优化，不是架构模式的核心。
⚠️ 两遍模式不适合这些场景
- 重复查询的语料（1k–1M 文档）：检索质量依赖第一遍文本质量，此时应该全量 VLM-OCR 后再建立索引
- 字段级准确率要求（发票、KYC、理赔）：每字段都需要 bounding box + 置信度供人工审计，必须全量处理
- 模型 token 成本极高（团队无 LlamaParse 预算）：LiteParse 本身免费，但后续语义搜索需搭配向量数据库（Chroma/FAISS）和 Embedding 模型
一句话结论
JIT Agentic OCR = 廉价全文扫描（LiteParse）+ 精准页级放大（LlamaParse），让 Agent 在 ~10–100 份临时文档数据房里用几乎免费的 grep 找到证据页，再用 VLM 只处理那几页；不适合长期复用的大规模语料或需要逐字段可审计的提取场景。
核验来源：LlamaIndex 官方博客 · Just-in-Time Agentic OCR（2026-09-11，作者 Jerry Liu）；run-llama/liteparse GitHub（12.3k stars，Apache 2.0）；superpowerdaily 报道（2026-09-14，交叉验证关键数字）；X @jerryjliu0 原帖（链接已失效，以官方博客为主要来源）。