别再把每一页都送给视觉模型：来自花旗、安永与英伟达研究员的实践启示

在工程团队为检索增强生成（RAG）构建文档处理流水线时，技术讨论往往迅速演变为一场大模型的“选型大乱斗”：究竟是调用 Gemini 3.1 Pro，还是将页面路由给 Mistral OCR v3，抑或是采用 Granite-Docling 这类紧凑型轻量模型？

由 Abbas Raza Ali（花旗集团 / Citigroup）、Muhammad Ajmal Siddiqui（安永 / Ernst & Young）和 Moona Zahid（英伟达 / NVIDIA）联合撰写的论文 Smart Content Ingestion for Generative AI Workloads，为这场讨论注入了一剂清醒的生产环境现实。该论文于 2026 年 10 月 5 日以预印本形式发布，目前正处于 MLSys 2027 的审稿阶段。

通过对包含 180 份文档、共计 10,507 页的内部语料库进行实测，作者给出了两个对文档摄入架构设计极具指导意义的数据：

1. 在最快的配置下，约 77% 的提取实际耗时（wall-clock time）花在了共享预处理上。 图像增强与版面解析耗时约 2,062 秒，而 Mistral OCR 的模型推理仅耗时 611 秒。在最慢的配置下，Granite-Docling 的推理耗时约 1,350 秒，预处理时间仍占总提取耗时的约 60%。
2. 约 92% 的页面走的是原生提取路径。 在全部 10,507 页中，仅有 853 页超过了系统的图像面积阈值并触发了页面级 OCR。其余 9,654 页均通过原生提取路径处理，模型成本几乎为零（不过提取出的配图仍可能触发视觉描述生成 / captioning）。

如果你过去习惯把所有文档一股脑全传给视觉 API，该架构提供了一种替代方案：优先提取可直接获取的原生内容，仅将页面级 OCR 留给以图像为主的页面。文档摄入绝不仅仅是一项 Prompt 工程；该论文将其视作一个四阶段的系统级流水线——上游的解析错误会直接导致下游检索丢失关键信息。

Agent 系统的感知层

在传统机器学习中，数据准备通常范围狭窄且高度受限于 Schema。任务定义、数据表征、标注和模型架构之间紧密耦合。

生成式 AI 改变了这种关系。基座大模型能够通过自然语言指令和上下文支持多种下游任务。然而，随着模型端变得日益通用，数据端却带来了独特的挑战：企业知识沉淀在 PDF、演示文稿、电子表格、扫描件、表单、表格以及图表之中。

这些文件将文本、视觉、几何与结构信息打包融为一体。如果摄入解析器将双栏排版的文档压平并交错混杂在一起，或者丢失了财务报表内部的关联关系，下游组件接收到的将是受损的数据表征。向量检索器无法可靠地找回索引中根本不存在的信息，重排器（Re-ranker）也无法还原在提取阶段被丢弃的列对齐关系。

作者将经过量化评估的内容提取定位为企业级 Agent 系统的“感知层”。他们的核心观点是：下游的一切推理能力，都取决于在该边界处是否准确还原了源数据。

论文提出了一个划分为四个连续阶段的生产级架构：

• 阶段 1：多模态内容提取（Multimodal Content Extraction），结合选择性 OCR 路由与启发式原生文本提取。
• 阶段 2：数据策展与提取评估（Curation and Extraction Evaluation），利用多标签稀缺优先采样（scarcity-first sampling）基于真值（ground truth）对解析器进行审计。
• 阶段 3：结构感知父子分块（Structure-Aware Parent-Child Chunking），将检索单元与阅读上下文解耦。
• 阶段 4：只读检索评估（Read-Only Retrieval Evaluation），生成有据可依的合成问题以测试可检索性。

该架构遵循三大工程原则：结构先于语义（structure before semantics）、绝不篡改被测对象（never mutate what you measure）、精打细算利用标签（budget your labels）。

选择性路由：让 PyMuPDF 承担主要流量

阶段 1 提升效率的核心逻辑非常简单：直接提取原生可读内容而无需 OCR，并利用图像面积启发式规则将以图像为主的页面路由至视觉模型。

对于输入的每个 PDF 页面 $p$，系统会计算图像面积覆盖率：

$$r(p) = \frac{A_{\text{img}}(p)}{A(p)}$$

如果内嵌图像的总面积 $A_{\text{img}}(p)$ 超过页面总面积 $A(p)$ 的 80%（$\tau_{\text{cov}} = 0.8$），该页面将被路由到 OCR；否则，将保留在由 PyMuPDF 驱动的原生提取路径上。

在作者包含 180 份文档的 Orion 数据集上，10,507 页中仅有 853 页（8.1%）走了 OCR 路径，其余 91.9% 均走原生提取。需要说明的是，这是 Orion 数据集上的实测路由比例，并非对所有企业文档的普遍性估计。

此外，策展引擎在标注扫描件页面时采用了双信号测试：

$$s(p) = 1_{|T(p)| < \kappa ;\wedge; r(p) > \tau_{\text{cov}}}$$

在设定 $\kappa = 40$ 的情况下，一个页面必须同时满足“可提取字符少于 40 个”且“图像覆盖率高”这两个条件，才会被打上扫描件标签。这样可以避免包含大图但同时具有丰富文本层的页面在策展过程中被误标为扫描件。该规则不会改变提取路由器仅基于面积的判定逻辑。

对于以图像为主的页面，论文描述了一套可选的图像增强处理流程：去除边框、通过拉普拉斯方差（Laplacian variance）估计噪声以在高斯滤波、双边滤波或非局部均值滤波中进行选择、对比度受限自适应直方图均衡化（CLAHE）、反锐化掩模（unsharp masking）以及三次样条放大（cubic upscaling）。光栅化后的页面随后被发送至 OCR 后端。推理基础设施还包括针对 429/5xx 响应的重试与退避机制，以及针对 401 状态码的 OAuth2 令牌自动刷新。

无需深度学习的确定性版面重构

对于原生文本页面，结构重构阶段避开了复杂的学习型模型，转而依赖确定性的启发式规则：

• 字号校准（Font size calibration）： 提取器计算整篇文档中出现频率最高的众数字号 $f^$，将其视为标准正文字体。满足 $f \ge 1.12 f^$ 的不同字号将被列为标题候选。这些字号按降序排列并划分为不同的层级（最高达到配置的最大深度），以生成 Markdown 标题。
• 页眉页脚抑制（Header and footer suppression）： 系统检查页边距内的文本块，将数字进行归一化处理（使“Page 4”与“Page 9”共享相同的键），并丢弃在超过 50% 的页面中重复出现的边距匹配内容。
• 双层表格检测（Two-tier table detection）： 有线表格（ruled tables）使用 PyMuPDF 中的 lines_strict 进行捕获。当表格策略设为 auto 时，词对齐检测器还会通过将词聚类成行并利用 x 轴对齐容差将列分组，以检测无线表格（borderless tables）。同时设有防护机制，以剔除看似表格但实为并排散文的段落。
• 行粒度对齐调节（Line-granularity reconciliation）： 该流水线不会直接丢弃与检测到的表格发生重叠的整个文本块，而是逐行进行测试。只有当单行文字超过 50% 的面积位于表格矩形内部时才会被抑制，从而保留仅因同处一个文本块而靠近表格碎片的周围句子。
• 光栅图去重（Raster de-duplication）： 大于 $32 \times 32$ 像素的内嵌光栅图像使用 MD5 哈希进行去重，并使用类似 ## Figure-{page}.{n} 的图片占位符表示。保留下来的占位符会触发视觉描述生成，架构图中展示的模型包括 Gemma-3 和 Llama-4-Scout。

阶段 1 的输出是带有显式标记的 Markdown，其中保留了明确的 ### Page: N、表格以及图片标记。原生结构重构与视觉描述生成是该流程中相互独立的两个部分。

稀缺性陷阱：当 90% 数据为纯文本时如何审计提取质量

在将提取出的 Markdown 传入 Embedding 模型之前，必须验证提取器的实际效果。这便引出了阶段 2：数据策展与提取评估。

在企业级知识库中评估文档提取质量时，常常会遇到一个棘手的采样难题：如果绝大多数页面都是纯文本，那么随机抽样会导致扫描页、图表和信息图的样本极度匮乏，无法准确评估其提取质量。罕见的模态必须在评估集中得到专门的代表性覆盖。

作者将此形式化为一个每页包含多标签的集合覆盖问题（covering problem）。其分类体系包含：扫描件（Scanned）、纯文本（Text）、表格（Table）、示意图（Diagram）、图表/信息图（Graph/Infographic）以及照片/签名（Photo/Signature）。

假设在总计 $N$ 页的预算中，每种模态的目标配额为 $t_m = \lceil \phi_m N \rceil$，算法 1（Algorithm 1）采用了稀缺优先的贪心启发式策略：

1. 按目标配额升序对各模态进行排序。该顺序取决于设定的配额目标，而非语料库中观察到的实际出现频率。
2. 针对当前选中的模态，按“增益得分”（helpfulness score）对候选页面进行排序：即该页面同时满足的其他尚未达标配额的数量。
3. 在该模态配额未满且仍有候选页时挑选页面，并同步更新所有匹配标签的未满足差额。
4. 用未选中的页面填补或剔除增益较低的已选页面以满足页面总预算，最后输出目标覆盖率与实际达成覆盖率的对比报告。

该方法是一种启发式算法，并不保证能够完全满足所有配额。被选中的页面可以导出为独立的单页 PDF，也可以在上下文至关重要时导出为完整的原始文档。一个包含六张工作表（sheet）的工作簿记录了配置参数、选中页面、统计数据以及达成的分布情况。随后，研究人员会对样本进行真值数字化（ground-truth digitization）与人工核验。

文本与表格保真度评分

评估框架通过 Unicode NFKC 标准化、大小写折叠（case-folding）、标点与连字统一、清除 Markdown/HTML 标签以及折叠空白字符来对文本进行归一化。随后通过莱文斯坦距离（Levenshtein distance）计算字符错误率（CER）和词错误率（WER），同时计算精确率、召回率、F1 值、词袋 F1 值、平滑 BLEU-4 以及长度比值 $(|\hat{c}| / |c|)$。

长度比值可以预警可能出现的过度生成或内容丢失，但仅凭该比值本身无法判断多余文本究竟是重复内容还是模型幻觉。

对于表格，评分系统引入了基于树编辑距离的相似度（TEDS, Tree Edit Distance-based Similarity）进行结构对比。管道符（Pipe）表格和 HTML 表格会被解析为矩形网格，并建模为树状结构（table -> row -> cell）。输出的相似度公式如下：

$$\text{TEDS}(T_a, T_b) = 1 - \frac{\text{EditDist}(T_a, T_b)}{\max(|T_a|, |T_b|)}$$

该指标不仅能衡量表格的组织结构，而且在文中所述的内容敏感模式下，还能衡量单元格字符串之间的差异。

最后，系统使用综合得分（$Q_m \in [0, 100]$）对各后端进行排序：

$$Q_m = 100 \cdot \frac{\sum_j w_j \mu_{j,m}}{\sum_j w_j} \cdot \text{cov}_m$$

这些指标以准确率为导向，并通过可配置的权重进行加权组合。变量 $\text{cov}_m$ 表示模型成功生成输出的文件占预期文件的比例。缺失文件会按比例扣减得分，以此明确惩罚那些直接跳过复杂/困难文档的引擎。

最终得出的是一个可配置的评估得分，而非一个孤立的“正确提取内容百分比”。

父子分块：大文件夹里的小卡片

阶段 3 聚焦于分块策略（chunking）。论文指出了两种相互对立的失效模式：

• 大分块（Large chunks） 会稀释相关段落对 Embedding 向量的贡献。根据论文采用的平均池化（mean-pooling）近似计算，随着句子总数的增加，单个相关句子的权重贡献会被稀释。
• 小分块（Small chunks） 则容易将完整答案撕裂成多个碎片，导致单片内容难以形成良好的检索匹配。

该架构通过将检索单元与上下文单元解耦来化解这一矛盾。

检索单元被称为子块（children）：类似于聚焦特定内容的索引卡片，目标大小约为 320 个 Token，普通散文文本上限为 512 个 Token。上下文单元被称为父块（parents）：类似于结构化的文件夹，配置上限为 3,500 个 Token。这些并不是绝对不可打破的硬性限制：超长的单句以及不可分割的原子表格或图表都会被完整保留，过大的表格或图片同样可能突破父块上限。

子块经由 GTE 模型生成 Embedding，完成 L2 归一化后，存入 FAISS 的精确内积索引（IndexFlatIP）中。父块则以 parent_id 到父块文本的映射形式保存在键值数据库（Key-Value Store）中。

在查询时，向量搜索首先检索到子卡片，随后通过一次 $O(1)$ 的快速查找将子块还原展开为其所属的父块。需要说明的是，该时间复杂度仅指上下文查找，并不代表向量搜索或整个查询过程的复杂度。

Document Markdown
       │
       ▼
[Parent Section Folder: configured maximum 3,500 tokens]
       │                                      (Key-Value Store)
       │
       ├──► Child Card 1: target ~320 tokens (FAISS Index)
       │      Optional prefix: "Doc > Section > Subsection (p.4)"
       │
       ├──► Child Card 2: target ~320 tokens (FAISS Index)
       │      Optional prefix: "Doc > Section > Subsection (p.4)"
       │
       └──► Child Card 3: whole atomic table (FAISS Index)

四大打包规则

在 pack_sentences() 函数内部，句子的打包过程遵循以下四项规则：

• 规则 1（Token 预算控制）： 使用 GPT-2 分词器将目标设定为约 320 个 Token，普通散文打包上限为 512 个 Token。
• 规则 2（句子完整性保留）： 绝不在句子中间进行截断。依据标点符号进行切分，同时保留末尾的引号和括号。若单句长度超过上限，则作为独立块直接输出，而不是强行截断。
• 规则 3（杜绝碎屑 / No crumbs）： 若打包好的文本组低于最小 Token 阈值，且与前一个分块的非重叠句子合并后未超过上限，则将其并入前一个分块。
• 规则 4（表格与图片原子化）： 当打包器遇到表格或图片时，会立即刷新输出暂存的散文内容，并将该完整结构单元作为单个子块输出，即使该单元超出了常规 Token 预算。

当一个分块因为下一句话将导致超限而闭合时，系统会将末尾最多 48 个 Token 的完整句子作为重叠上下文带入下一个分块。

为了在无需 LLM 进行文本重写的前提下补充位置上下文，系统提供了可选的面包屑导航机制，在每个子块的待嵌入文本前添加其结构层级地址：Document > Title > Section > Subsection (p.N)。而未经添加前缀的原始文本则单独保存以供前端展示。

审计检索效果：基于只读评估器的 25,050 个问题测试

阶段 4 通过 RetrievalEvaluator 实现了流程闭环。遵循“绝不篡改被测对象”的原则，评估框架使用 faiss.IO_FLAG_READ_ONLY 打开索引文件，并完全复用索引构建时所用的 GTE Embedding 指纹与页面标签语法。

对于包含达到配置最小 Token 数量的页面，评估器使用 Mistral-Medium 生成有据可依的合成问题。其提示词要求生成具体事实层面的问题以及综合全页内容的宏观问题，强制输出原始 JSON，并严禁引入外部知识。这些指令对生成过程起到了约束作用，但并不能独立证明生成的每个问题都是完全有效的。

每个问题均通过 GTE 进行向量化，并在其源文档范围内通过 FAISS 的 IDSelectorBatch 进行检索（当不支持选择器时，回退至全量过滤方案）。检索到的子块按 parent_id 进行去重，每个父块仅保留得分最高的子块。搜索过程会进行候选超额拉取（over-fetch），以确保能够返回足够数量的不同父块。

当候选子块满足余弦相似度阈值 $s(q, c) \ge \theta$ 且其源页面与问题原始出处的距离在 1 页以内（$\delta = 1$）时，即判定为命中：

$$\text{hit}(q, c) = 1_{s(q, c) \ge \theta ;\wedge; |\pi(c) - \pi(q)| \le \delta}$$

在 Orion 语料库上，测试框架针对 180 份文档生成并评估了 25,050 个问题：

• hit@1: 68.58%
• hit@3: 82.30%
• hit@5: 87.66%
• hit@10: 92.77%
• 平均倒数排名（MRR, Mean Reciprocal Rank）: 0.7745
• 中位数排名（Median Rank）: 1.0（平均排名 Mean Rank: 1.81）
• 在所有评估位次中均未命中的问题数: 1,810（7.2%）
• 单次查询平均延迟（Mean Per-Query Latency）: 0.81 秒，据报告主要耗时在远程 Embedding 接口调用上

超过三分之二的问题在返回的第一个父块处就满足了命中标准；而在返回 10 个不同父块时，命中率达到了 92.77%。

需要注意的是，这些均为“代理评估指标”（retrieval-proxy results）。判定标准检验的是相似度和页面临近度，而非人工独立标注的精确目标段落，也未评估最终生成答案的正确性。此外，由于搜索被限定在源文档内部，这些数据并未衡量在全量语料库中跨文档定位目标文件的能力。

提取基准测试：大型后端 vs. 轻量紧凑模型

作者报告了四种生产级后端的提取表现得分。这些实测数据均来自系统在内部语料库上的内置评估器，并非第三方公开基准榜单。

模型	综合得分 ($Q_m$)	字符错误率 (CER)	词错误率 (WER)	表格相似度 (TEDS)	在 Orion 上的推理耗时	在 Orion 上的总耗时 (Wall-Clock)
Gemini 3.1 Pro	97.37	0.13%	0.13%	0.9952	未单独报告	未单独报告
Mistral OCR v3	95.98	1.39%	1.55%	0.9737	~611 s	2,672.67 s
Granite-Docling (258M)	92.92	2.60%	2.90%	0.9599	~1,350 s	3,411.86 s
SmolDocling (256M)	90.70	4.43%	4.82%	0.9274	未单独报告	未单独报告

注：提取总耗时包含约 2,062 秒的共享预处理时间（包括图像增强和版面解析）。论文指出另外两个后端的耗时介于这两个极值之间，但未给出具体数值。

Gemini 3.1 Pro 在报告的准确率排名中位列第一，取得了 0.13% 的 CER 和 0.9952 的 TEDS 得分。

Mistral OCR v3 以 95.98 的综合得分排名第二。其 CER 为 1.39%，大约比 Gemini 高出一个数量级，但它实现了最快实测提取速度。其模型推理部分耗时约 611 秒，而 Granite-Docling 约为 1,350 秒。

紧凑型模型 Granite-Docling 和 SmolDocling 的综合得分分别落后 Gemini 约 4.5 分和 6.7 分。报告的 CER 分别为 2.60% 和 4.43%，TEDS 得分分别为 0.9599 和 0.9274。这些均为聚合基准测试结果，并非针对纯文本正文或特定表格难度等级的单独评估。

论文还引用了早期基于 CNN 表格检测与双解码器（Encoder-Dual-Decoder）单元格提取的工作，后者在图像表格上报告了 85% 的词准确率。这提供了历史背景，但现有结果并未建立同等数据集上的对照实验，因而无法据此计算相比早期系统的确切改进幅度。

为什么这很重要：生产级文档流水线的现实权衡

如果你是一名负责为企业级搜索或 Agent 工作流构建文档摄入流水线的工程主管或产品经理，这篇论文提供了若干实操层面的启示：

1. 最划算的 OCR 调用是压根不发起的调用

选择性路由使 Orion 数据集中 91.9% 的页面免于走页面级 OCR 路径。这是一个非常明确的实测结果，值得你在自己的文档集上进行验证。

不过这并不等同于总成本降低了 91.9%。原生提取仍然存在计算开销，且图片描述生成依然可能调用视觉模型。论文并未提供单页处理价格或改造前后的账单对比。该结论的实际指导意义更加严谨：对于可直接读取的原生文本，完全无需自动执行页面级 OCR。

2. 共享预处理应当计入延迟预算

图 4 清晰展现了提取耗时的分布：约 2,062 秒花在了共享的图像增强与版面解析上，而 Mistral OCR 的推理仅占 611 秒。

这意味着在最快配置下预处理占总提取时间的约 77%，在最慢配置下也占到了约 60%。作者已将其列为下一个重点优化目标。

虽然实测数据未进一步明确 CPU 利用率、串行执行开销，或是引入多进程/图像滤波算法优化能带来的具体加速比，但它们充分说明了：仅仅选择最快的 OCR 后端，依然无法解决占据提取耗时大头的预处理瓶颈。

3. 字符错误率只是提取质量的一部分

单一的文本评分无法完整反映表格的还原保真度。该论文兼顾了两者的评估，将字符级与词级指标与表格结构及单元格指标相结合。

在对比不同提取器时，务必保留这种区分。TEDS 结合 CER 和 WER 提供了结构层面的证据；综合得分整合了这些信号，但不应掩盖细节。此外，该论文的实验主要基于拉丁字母语系，而汉字作为包含数千字符且排版密集的表意文字系统，在中文 OCR 场景下的字形识别与版面切分往往面临更严峻的挑战。

4. 将检索卡片与上下文窗口解耦

论文提出的父子分块架构提供了一种既能精准匹配细粒度短段落、又能返回完整上下文的落地路径。结构化标签确保了表格和图表的完整性，而可选的面包屑导航为待嵌入文本补充了文档空间位置信息。

Orion 上的测试表明该设计能够进行大规模量化评估。不过论文尚未包含严格受控的检索消融对比，以证明父子分块在同一语料库上必然优于固定长度分块、语义分块或其他替代方案。

系统的局限性与边界

作者将该系统描述为生产就绪（production-ready），但现有的实验证据要求我们在解读其结果时注意以下边界：

• 对合成问题的依赖： 检索评测所用的问题全部由 Mistral-Medium 生成。论文明确指出，该代理评估的效果高度依赖生成器的质量，且未报告针对真实用户查询集合的验证结果。
• 限定在文档内部且基于页面的命中判定： 搜索范围被严格限制在问题所属的源文档内，且命中成功依赖于相似度与页面临近度。这些结果并不能证明系统在全语料库范围内的文档定位能力或最终问答的准确性。
• 内部评估与对比局限： 报告的分数均为内部语料库上的自测结果。论文未报告分块策略的消融实验，也未提供与文中所述其他替代策略在同等条件下的对照检索对比。
• 启发式路由规则的可配置性： 80% 的图像面积阈值是基于 Orion 数据集得到的路由比例。论文并未证明该阈值在其他不同类型的文档集上的路由准确率，且更严格的扫描页标注规则属于数据策展阶段，而非提取阶段的路由逻辑。
• 监控方案仍部分停留在构想阶段： 基于基准真值的 CER 和 WER 必须依赖真值标注。论文虽然探讨了无参考信号与校准策略，但将监控机制定性为一种假设或未来方向，而非已交付的生产校准代码。这类无参考信号本身无法独立反映真实的错误率。

结语

文档摄入绝不该只被当成写完即忘的临时脚本。在作者的定义中，它是生成式 AI 系统的感知层。

通过融合选择性路由、确定性版面重构、结构感知父子分块以及只读评估器，该论文提供了一套切实可行的方法，让文档摄入的各项工程决策变得清晰显式且可量化评估。其最大贡献在于将这些组件与它们自我生成的量化证据紧密联结在一起。

在决定再花一周时间微调 Prompt 或测试重排模型之前，不妨深入审视一下你的文档摄入层。如果解析器在一开始就丢失了页面上的关键信息，下游检索将从一个可能根本无法修复的缺陷中起步。