文档理解与 OCR

把字符从页面上取下来，基本已经解决了。把文档从页面上取下来，还没有。

这个差距很要紧，因为几乎所有真实任务需要的都是结构，而不是字符。哪张表的哪个单元格。这段文字属于哪个标题。发票上三个金额里哪个是总额。双栏排版的阅读顺序。

大多数检索增强生成（RAG）流水线就是在这一步悄悄丢掉质量的，而且是在分块跑起来之前。

三种做法

传统 OCR 检测文本区域并识别字符，输出文字加边界框。快、便宜、成熟，在自己该干的事上做得很好。它给你词语和位置，但对这份文档是什么毫无理解。

**版面感知模型（layout-aware models）**接收 OCR 结果加上坐标，对结构做分类——这一块是标题，这些单元格构成一张表，这是一个表单字段及其取值。它们是为结构问题专门打造的，通常是高重复度、大批量文档最可靠的选择。

**视觉语言模型（VLM）**直接处理页面图像，回答关于它的问题，或者输出结构化结果。灵活得多：你可以按想要的形状索要想要的字段，不用为每种文档类型单独做工程。见视觉语言模型。

这个取舍很实在。VLM 能力强得多，可预测性也差得多。它们还可能幻觉出一些看上去就该在那儿的数值——在财务文档上这是真正危险的失效，而 OCR 不会犯，因为 OCR 不生成内容。

第一件要查的事是分辨率

视觉模型在看到任何东西之前会先缩放图像。小字就在这一步消失了。

所以「模型读不了这份文档」通常是预处理问题，不是理解问题，修起来也很机械：

• 发送更高分辨率的图像，如果服务商接受的话
• 裁切到关心的区域，而不是整页发送
• 把密集的页面拆成若干区域，逐块处理
• 对密集文字，先跑 OCR 再传文本——别让视觉模型去做字符识别，它做得更差

最后一点值得强调。把 OCR 文本和页面图像一起用，往往胜过任何单独一种：OCR 提供可靠的字符，图像提供文本流丢失的版面信息。

表格

表格是最难的常见情况，值得单独拎出来说。

表格是一个被压扁成一维文本流的二维结构，而压扁的过程恰好毁掉了你需要的东西。合并单元格、多行表头、跨页表格，以及只靠空白对齐才成形的无边框表格，都会让朴素的提取方式失效。

管用的做法，大致按可靠程度排序：用专门的表格检测模型输出单元格网格；直接向 VLM 索要结构化格式——markdown 或 JSON——因为它能对版面做推理，而文本流做不到；以及把 OCR 文本和图像一起传进去，让对齐信息保留下来。

不管用的是把表格当纯文本提取出来然后祈祷。结果看上去差不多对，错的地方却很难发现。

单说 PDF

PDF 与其说是文档格式，不如说是页面绘制格式，这带来一些具体问题。

数字版 PDF 含有可直接提取的文本——不需要 OCR。永远先查这一点，因为提取比识别更快也更准。但文本是以带位置的碎片形式存的，不是段落，所以阅读顺序要靠重建，双栏排版还经常交错在一起。

扫描版 PDF 本身就是图像，需要 OCR。

混合 PDF 两者都有，有时同一页里都有。要按页判断，而不是按整份文档判断。

双栏学术论文是这类失败的典型：朴素提取会横跨两栏读取，产出的文本局部通顺、整体错乱。下游任何环节都救不回来。

校验输出

提取失败是安静的。文本出来了，看着像那么回事，其实是错的。几个便宜的检查就能抓住大部分：

算术校验。 如果明细项加总应该等于总额，就验证一下。仅这一项检查就能抓住相当大一部分表格提取错误。

格式校验。 用预期模式去检查日期、货币和标识符。

置信度分数，在 OCR 提供的地方——把低置信度的区域标记出来送人工复查，而不是默默接受。

抽查阅读顺序，在多栏文档里取一些样本。别想当然。

对任何后果重大的场景，在低置信度提取上保留人在回路（HITL）。见人在回路的设计。

要点回顾

• 字符提取已经解决；结构提取还没有，而结构才是你需要的。
• 三种做法：OCR（可靠，但不理解）、版面模型（最适合高重复度的大批量场景）、VLM（灵活，但可能幻觉出数值）。
• 分辨率和裁切能解决大部分「读不了」的问题；把 OCR 文本和页面图像结合起来胜过任何单独一种。
• 表格是最难的情况——一定要索取结构化输出，绝不要纯文本。
• 先检查 PDF 里有没有可直接提取的文本；多栏阅读顺序是常见的静默失效。
• 用算术和格式校验来把关，因为提取失败是悄无声息的。

下一篇： 微调到底是怎么工作的