最新资讯
stackoverflow.blog 欢迎来到芯片时代:半导体制造、AI 数据中心与芯片设计的未来 www.youtube.com AI Agent 总犯同样的错:CentralAgent AI 将记忆重构为经验系统 pub.towardsai.net Netflix 科学家建议重采样 LLM 评判:5 次仅将误差棒缩小 13% pub.towardsai.net Jev 作为 LLM 前的静默层:构建提示感知的模型路由器 reddit.com OpenAI 称 Astra 仅满足 10% 安全任务标准 dev.to FreeToken:在自有 GPU 上运行前沿 MoE 模型及其内存需求 dev.to 当 AI Agent 说“完成”时,究竟完成了什么? dev.to 部署 Underdog Bark 3.0 Pro:逐字转写、自定义后端与分块设置 dev.to 为艰难对话构建 AI:五个 Agent、一条安全正则与一位盲评监督者 techcrunch.com Palo Alto Networks 洽谈以 5 亿美元收购 AI Agent 安全初创公司 Clutch theinformation.com 黄仁勋被要求就涉华间谍指控向国会作简报 www.infoq.com Edera 推出 Object Capability Bounded Authority,试图将凭证与 AI Agent 工作负载隔离
多元动态
登录 注册
智能体 x.com · @jerryjliu0

LlamaIndex 提出“Just-in-Time OCR”两段式文档处理模式

原文 我的收藏

LlamaIndex 的 Jerry Liu 将当前 agent harness(如 Cowork、Codex、Grok)处理用户上传文档数据室的常见做法命名为“Just-in-Time OCR”:第一遍用免费/开源解析工具(如 Liteparse)低成本快速扫描上百份文档,第二遍用专用 OCR(如 LlamaParse)仅对需要精读的页面做高精度转写。作者称该模式在 10-100 份文档规模下效果良好,代价是成本与延迟,不能替代大规模离线索引与检索;并批评默认用 pypdf 加原生 VLM 的两遍方案既贵又缺乏准确性与 grounding。

AI推荐理由 LlamaIndex 创始人提出并命名“Just-in-Time OCR”两段式文档处理模式:先用免费 OSS 解析器(Liteparse)快速扫全量文档,再用专用 OCR(LlamaParse)按页号精读子集,并指出该模式适合 10-100 份文档、以成本与延迟换取精度,不适用于大规模离线索引。属于有具体方法、适用边界和工具指向的工程经验分享,但本质是自家产品推广,性能数字(如 32 秒)来自其博客,未在正文中独立验证。

72 浏览 426 点赞 4 评论 3 转发 0

正文

“Just-in-Time” OCR The latest agent harnesses (e.g. Cowork, Codex, Grok) do 2 passes of ad-hoc document processing when executing over a user-uploaded ‘data room’ of documents: 1️⃣ A fast and light pass using a free/OSS doc parsing tool, can be cheaply run over 100+ docs 2️⃣ A “just-in-time” pass using a dedicated OCR tool (like LlamaParse) that does more accurate transcription over a subset of pages. This pattern is common enough that I wanted to give it a name: “Just-in-Time OCR”. It works surprisingly well over a small to medium batch of docs (e.g. 10-100 docs); it is accurate at the expense of cost and latency. It’s not a substitute for large-scale offline indexing and retrieval. The ‘default’ approach for any frontier agent harness is to use an OSS tool like pypdf for the first pass and its native VLM (e.g. Fable 5.1) as the second pass. This is both expensive and lacks accuracy and grounding. If you’re a builder looking to implement this type of harness of a document data room, you can try out our suite of tools: - Liteparse as the first pass (the best/fastest OSS text parser) - LlamaParse as the second pass (most Pareto-efficient, includes grounding) Check out the blog post below! [llamaindex.ai/blog/just-in-t…](https://www.llamaindex.ai/blog/just-in-time-agentic-ocr) ![Tweet Image](https://pbs.twimg.com/media/HSMLPJXbIAAd6ud.png) ![LlamaIndex 🦙](https://pbs.twimg.com/profile_images/1967920417760251904/0ytfduMQ_normal.png) LlamaIndex 🦙@llama\_index just-in-time OCR is all the rage. most pipelines parse every page before anyone asks a question. for an agent working through an ad-hoc data room, that's slow, expensive, and most of those pages never get read. the better pattern is just-in-time OCR in two passes: ✅️ LiteParse (free, OSS, Rust, 50+ formats) does a fast layout-aware first pass: spatial text, bounding boxes, headings, tables, and a per-page complexity flag. a full data room in 32 seconds. ✅️ LlamaParse zooms in on only the pages that need it, by page number, and returns cell-level tables, bounding boxes, and confidence scores. the rest fills in the background. pypdf and pdftotext can't do the first pass well. parsing everything up front can't do it cheaply. two passes gets you both. full breakdown with numbers: [llamaindex.ai/blog/just-in-t…](https://www.llamaindex.ai/blog/just-in-time-agentic-ocr) ![Tweet Image](https://pbs.twimg.com/media/HSMGJrrWMAA2h1A.jpg) [🔗 View Quoted Tweet](https://x.com/llama_index/status/2099528648021745677)

来源报道 · 1 篇 · 以下链接均前往原始媒体

← 返回精选动态 原文

更多内容