长PDF数据提取:LLM直读为何失效及Agentic IDP方案

整份PDF扔给LLM会静默丢数据,Agentic IDP逐页解析加跨页提取是可行路径。
本文指出把200页PDF整体交给LLM提取表格几乎必然失败,原因包括回复容量有限、长上下文中间信息精度下降、成本随页数线性上涨,以及模型无法告知遗漏内容。按页或固定长度分块虽解决窗口问题,却导致跨页表格断裂、文档级字段不可见、拼接代码失控。文章对比五种方案后推荐Agentic IDP模式:先逐页并行OCR与版式解析,再由Agentic提取器跨全部页面块判断表格连续性并拼接,用一份Schema同时返回文档级字段与表行,每个值附带置信度、来源文本和页码。校验须内建,包括数行数、对合计、看置信度、检查分页接缝四步。成本按credits计费,建议先用标准模式,仅对出错文档切到Agentic。
把一份200页PDF整体扔给LLM,然后期待它吐出完整表格——这条路几乎每个团队都走过,结果也几乎一样:行数缺失、合计对不上、模型自信地给出错误答案。问题不在Prompt写得不够好。
LLM的设计目标是预测下一步文本,而非逐页阅读一份结构化长文档并完整返还。上下文窗口可以很大,但回复容量有限,长表格根本放不下;长上下文中间位置的信息精度明显下降(Liu et al., 2023);成本与延迟随页数线性上涨;最要命的是,模型不会告诉你它漏了什么——错误答案和正确答案看起来一样流畅。

为什么分块也救不了长文档提取
既然整体处理不行,下一步自然是切块。按页或按固定长度切分解决了窗口问题,却引入了新麻烦。
一个跨8页的表格被切成8个互不相关的片段,每页重复的列头被当成数据读入,第1页才出现一次的供应商名或合同编号,到了第40页的chunk里完全不可见。很快,用于拼接结果的代码比提取逻辑本身还大,每换一种版式就崩一次。
更精细的做法——按章节切分或逐行并行提取——各有各的盲区:跨章节边界的表格会断,文档级字段仍然需要单独一次调用。
长上下文中间信息丢失现象("Lost in the Middle")由Liu等人于2023年系统验证:当关键信息位于上下文窗口的中间位置时,模型检索并利用该信息的准确率显著低于信息位于开头或结尾时。这一现象在需要精确定位的抽取任务中尤为致命,因为模型可能"看到"了目标内容却未能正确引用。读者若想进一步理解分块方案为何在长文档场景下频繁失效,可将其与"上下文窗口≠有效上下文"这一区分联系起来——窗口大小决定模型最多能接收多少token,而有效上下文取决于模型在多大范围内能保持可靠的注意力与检索能力,两者之间存在明显落差,分块正是在试图用工程手段弥合这一落差,但代价是破坏了文档的全局结构信息。
五种方案横向对比
| 方案 | 跨页表格保持完整 | 文档级字段与表行同出 | 能否告知行缺失 | 典型瓶颈 |
|---|---|---|---|---|
| 整份文档一次Prompt | 仅在回复容量内成立 | 是 | 否 | 输出上限、中间信息丢失、成本 |
| 固定长度或按页切块 | 否 | 否 | 否 | 拼接代码变成产品本身 |
| 按章节切分、并行提取 | 跨边界则否 | 需额外一次处理 | 否 | 跨章节表格 |
| 逐行并行提取 | 逐行成立 | 需单独调用 | 部分 | 文档上下文在另一次调用中 |
| Agentic IDP(逐页OCR+解析,跨页提取) | 是(需检测表格连续性) | 是,同一Schema | 是(需加入校验) | 依赖保留布局与结构的解析器 |
最后一行是真正站得住的模式,也就是Agentic IDP所做的事。
Agentic IDP:先逐页解析,再跨页提取
该模式分两层运作。
第一层:逐页并行解析。 OCR与版式分析把每一页拆成文本、表格、图形、页眉页脚等块,并修正阅读顺序。每页独立处理,300页就是300个小任务,而非一个巨型任务。扫描件先过OCR。
第二层:跨全部页面块提取。 一个Agentic提取器审视所有页面的块,判断哪些表格碎片属于同一张表并按顺序拼接,同时从任意位置读取文档级字段。你只需用一份Schema描述结果:一类是每份文档出现一次的值(供应商、合同编号、申报日期、总额),另一类是带列定义的表字段。一次运行同时返回两者,无需二次处理或事后join。
表字段是一个带嵌套列的object类型,包含description、quantity、unit_price、line_total等子字段。返回结果是逐行的列表,每个值都带有置信度以及来源文本和页码。
同一套解析步骤也可服务于RAG:文档被还原为保留完整表格的结构化文本,可直接索引。
Agentic IDP中的"Agentic"指的是提取器并非一次性读取全部文本后直接输出,而是像智能体一样主动规划:先判断表格碎片之间的连续性,再决定拼接顺序,并按需回溯任意页面的块以读取文档级字段。IDP是Intelligent Document Processing(智能文档处理)的缩写,涵盖OCR、版式分析、表格结构还原等一整套自动化流程。该模式与经典"先切块再拼接"的本质差别在于:切块方案在切片时就切断了跨页关系,只能靠事后启发式拼接补救;Agentic IDP则在解析阶段就保留了每页块的位置与结构元数据,使跨页判断成为提取阶段可执行的操作,从而让"表格连续性检测"与"文档级字段读取"在同一Schema下同时完成。
如何验证长PDF提取没有丢数据
长文档最容易发生静默丢失,校验必须内建到流程中。
- 数行数。 文档写明42项,提取结果就该有42行。对不上就标记该文档。
- 让合计对得上。 各行小计之和应等于印出的subtotal,subtotal加税应等于grand total。校验规则可对每份文档自动执行。
- 关注关键行的置信度。 设定阈值,低于阈值的转人工复核,复核者能同时看到源页面与提取值。
- 检查接缝处。 人工翻开测试文档的分页位置:上一页最后一行与下一页第一行,是表格最容易被截断或重复的地方。
每个值都带来源证据,点击数值即可跳到它所在的页面,这让人工复核极快。
成本参考
按credits计费,按页数和算子类型计算。标准Parse 25 credits加标准Extract 35 credits,每页60 credits;Agentic为100加150,每页250 credits。Business档每credit €0.001,Free和按需付费档€0.0015。
| 100页文档 | Credits | Business | Free/按需 |
|---|---|---|---|
| 标准Parse+标准Extract | 6,000 | €6.00 | €9.00 |
| Agentic Parse+Agentic Extract | 25,000 | €25.00 | €37.50 |
校验规则单独计费,按规则数、每次提取计一次,而非按页。建议先用标准模式,只对标准模式处理表格出错的文档切换到Agentic。
需要正视的限制
- 扫描件与照片 对所有方法的准确率都会下降,需配合置信度阈值与人工复核。
- Agentic模式暂不支持多文件文档(多个文件视为一份文档),需先合并再上传,或分开处理。
- 极不规则的表格(合并单元格、中途换列)需先用你自己的文件测试再决定是否信任。
- 准确率取决于你的文档。 在采信任何厂商的宣传数字之前——包括本文所涉产品的——先用自己50份文档测试,数行数、测字段级准确率。
文中反复强调的"置信度"是文档抽取领域衡量单个字段可靠性的常用指标,通常由模型对自身输出的概率估计或经校准的分数得出,取值范围一般在0到1之间。它的用途不是替代准确率评估,而是提供逐值的风险分层:高置信度值可自动放行,低置信度值需转人工复核,复核者借助来源文本与页码快速核对。实际落地时需注意置信度可能校准不良——模型对某些版式会给出虚高分数,因此建议在自有文档上先统计不同阈值下的精确率与召回率,再选定阈值,而不是直接采用厂商默认值。
如何挑选工具
文档短且干净,一次Prompt足够。文档长,则向每个工具问三个问题:跨页表格能否作为一个表返回?文档级字段能否在同一次结果中返回?什么机制能告诉我某一行丢了?答不上第三个问题的工具,会悄无声息地失败。
相关推荐

uGAP:统一100+非洲地理数据集的AI平台
uGAP是开普敦大学团队开发的非洲地理空间AI平台,统一120余个非洲数据集并提供Python SDK,支持数据发现、处理与模型训练一站式工作流,已用于气旋洪水制图等实战场景。

Cursor能控制你的电脑了:AI代理可驱动桌面应用测试
Cursor 新增桌面控制能力,AI 代理可驱动 iOS 模拟器等桌面应用测试自己构建的功能。本文分析这一更新对开发工作流的影响、技术实现可能路径及可靠性考量。

Vibecoding自研推理引擎:理想丰满,现实骨感
Reddit开发者分享Vibecoding自研推理引擎的真实经历:用WebGL2和GLSL在浏览器跑GGUF Q4模型,却陷入tokenizer调试地狱。本文分析浏览器端LLM推理的工程难点,以及为何直接clone llama.cpp是更理性的选择。