为什么大模型在 OCR 任务上表现不佳？
编者按： 你是否曾经用最先进的大语言模型处理企业文档，却发现它把财务报表中的“$1,234.56”读成了“123456”？或者在处理医疗记录时，将“0.5mg”误读为“5mg”？对于依赖数据准确性的运营和采购团队来说，这些问题不仅影响工作效率，更可能导致财务损失、法律风险甚至造成医疗事故。
本文深入揭示了大语言模型在 OCR 任务上的根本局限，不只是指出问题，更从技术原理层面详细分析了出现这些问题的内在机制。这些见解来自 Pulse 项目团队的一线实战经验，他们在为大型企业构建数据提取解决方案的过程中，积累了宝贵的第一手资料。
作者 | Sid and Ritvik (Pulse Founders)
编译 | 岳扬
我们启动 Pulse 项目的目标，是为那些在数以百万计电子表格和 PDF 中处理关键业务数据的运营/采购团队构建解决方案。当时我们还未曾意识到，在实现这一目标的过程中，会遇到一个障碍，而这个障碍彻底改变了我们对 Pulse 的开发思路。
起初，我们认为只需接入最新的 OpenAI、Anthropic 或 Google 模型就能解决“数据提取”难题。毕竟这些基础模型每个月都在刷新着各项基准测试的最好成绩，开源模型也已经赶上了最好的专有模型。那为何不让它们去处理大量的电子表格和文档呢？说到底，这不就是文本提取和 OCR 吗？
本周有篇爆款博客讲述了使用 Gemini 2.0 解析复杂 PDF 的案例，这让许多人得出了和我们近一年前完全相同的假设。数据摄取（Data ingestion）是一个多步骤的流程，要确保数百万页非确定性输出的可靠性是个大难题。
LLM 在复杂的 OCR 任务上表现不佳，而且这种情况可能还会持续很久。LLM 在许多文本生成或文本摘要任务中表现出色，但在处理 OCR 这类需要精准完成、注重细节的工作时却力不从心 —— 特别是在面对复杂布局、特殊字体或表格时。 这些模型会“偷懒”，常常在处理数百页的内容时无法始终遵循提示词指令，无法解析信息，还容易过度思考。
01 LLM 如何“查看”和处理图像？
本节并非从零开始讲解 LLM 架构，但理解这些模型的概率特性为何会在 OCR 任务中造成致命错误非常重要。
大语言模型通过高维嵌入处理图像，本质上是创建优先考虑语义理解而非精确字符识别的抽象表征。 当大语言模型处理文档图像时，它首先通过注意力机制将其嵌入到高维向量空间中。这种转换在设计上就是有损的。
(source: 3Blue1Brown[1])
这一流程中的每一步都会优化语义，同时舍弃精确的视觉信息。 以一个包含“1,234.56”的简单表格单元格为例。大语言模型可能会理解这是一个千位数，但会丢失一些关键信息，比如：
小数点的精确位置
是否使用逗号或句号作为分隔符
具有特殊含义的字体特征
单元格内的对齐方式（如数字右对齐等）
如果进行更深层次的技术分析，注意力机制存在一些盲点。
将它们分割成固定大小的 patches（通常为 16×16 像素，如原始 ViT 论文所述）
将每个 patch 转换为带位置嵌入的向量
对这些 patch 应用自注意力机制
因此，
固定的 patch sizes 可能会将单个字符分割开
位置嵌入会丢失细粒度的空间关系，导致无法支持人工介入评估、置信度评分及边界框输出。
（此图取自《From Show to Tell: A Survey on Image Captioning》[2]）
02 幻觉从何而来？
LLM 通过使用概率分布进行 token 预测来生成文本：
使用这种概率方法意味着模型会：
优先选择常用词汇而非精确转录
“自作主张”地“纠正”源文档中存在的错误
根据学习的模式、统计规律合并或重新排列信息
由于随机采样机制的原因，相同的输入会产生不同的输出
对于 OCR 任务来说，使用 LLMs 非常危险，因为它们倾向于做出一些微妙的替换，可能会彻底改变文档含义。不同于传统 OCR 系统在不确定的情况下会明显失效，LLM 会做出一些看似合理但可能完全错误的"有根据的猜测"。 以“rn”与“m”为例，对于快速扫读的人类读者或处理图像块（image patches）的 LLM，这两者可能看起来几乎相同。接受过海量自然语言训练的模型在不确定时，会倾向于识别成统计上更常见的"m"。这种行为不仅限于简单的字符对：
原始文本 → 常见的 LLM 替换词
"l1lI" → "1111" 或 "LLLL"
"O0o" → "000" 或 "OOO"
"vv" → "w"
"cl" → "d"
2024 年 7 月（在 AI 世界已属于远古时期）有篇优秀论文《Vision language models are blind》[3]指出，这些模型在五岁儿童都能完成的视觉任务上表现惊人地糟糕。更令人震惊的是，我们在最新的 SOTA 模型（OpenAI 的 o1、Anthropic 的新版本 3.5 Sonnet 和 Google 的 Gemini 2.0 flash）上运行相同测试时，所有模型都会犯完全相同的错误。
提示词：这张图片中有多少个正方形？（答案：4）
3.5-Sonnet：
o1：
随着图像变得越来越复杂（但仍可被人类轻易识别）时，模型性能会急剧下降。 上面的正方形示例本质上就是表格，当表格出现嵌套结构、奇怪的对齐方式和间距时，语言模型会完全无法解析。
表格结构的识别与提取可能是当前数据摄取（data ingestion）中最困难的部分 —— 从微软等顶级研究实验室到 NeurIPS 等顶级会议，已有无数论文致力于解决这个问题。特别是对于 LLM，在处理表格时，模型会将复杂的 2D 关系扁平化为 1D 的 token 序列。这种转换会丢失关于数据关系的关键信息。我们通过所有 SOTA 模型测试了一些复杂表格并记录输出如下，各位可以自行判断其性能有多糟糕。当然这并非一个可量化的基准测试，但我们认为这些视觉测试能很好地说明问题。
下面是两张复杂的表格，并附上我们使用的 LLM 提示词。我们还有数百个类似的案例待展示，如有需要请随时告知！
提示词如下：
03 现实世界中的应用故障与隐性风险
我们还观察到几类对关键业务应用（Business-critical applications）具有灾难性影响的故障，尤其是在法律[4]和医疗等行业。这些严重问题可归类如下：
1) 篡改财务与医疗数据
货币金额中的小数点移位（例如 1,234.56→123456）
尤其常见于低质量图像中，而传统 OCR 却能正确处理
货币符号的丢失引发歧义（€100 → 100）
药物剂量误读（0.5mg → 5mg）
擅自将非标准化单位转换为标准化格式，导致原始语义被意外篡改（5mL q4h → 每隔 4 小时 5 毫升）
2) 方程求解问题
我们遇到的最令人惊讶的行为是 LLM 会试图求解数学表达式，而非转录它们。例如，我们测试了包含多个数学/物理问题+答案的文档：
模型因为被训练成“非常乐于助人”，会擅自计算结果而非保留原始表达式。这种行为在技术文档这一场景非常危险，因为原始公式本身就携带有重要信息。
3) 提示词注入+伦理漏洞
或许最令人担忧的是，我们发现含有特定文本模式的 PDF 文件会触发 LLM 的非预期行为。
我们在文档中添加以下注入指令（使用与前文相同的提取提示词）：
实验证明，这一攻击成功欺骗了部分 2B、4B、7B 参数开源模型，而无需事先进行任何微调。
我们团队测试的部分开源 LLM 模型会将方括号文本解读为指令，导致输出污染。此外，LLM 有时会拒绝处理包含其认为不当或不道德文本内容的文档，这对处理敏感内容的开发者造成极大困扰。
Thanks for reading!
Hope you have enjoyed and learned new things from this blog!
END
本期互动内容 🍻
❓如果要加强 LLMs 在 OCR 任务上的性能，你认为有哪些可行的技术突破方向？
🔗文中链接🔗
[1]https://www.3blue1brown.com/
[3]https://arxiv.org/pdf/2407.06581v1
原文链接：
版权声明: 本文为 InfoQ 作者【Baihai IDP】的原创文章。
原文链接:【http://xie.infoq.cn/article/fa172db1f0d51cabe4cdd2b77】。
本文遵守【CC-BY 4.0】协议，转载请保留原文出处及本版权声明。
AI训推云平台：GPUaaS, MLOPs, MaaS 2021-08-31 加入
IDP是AI训推云平台，旨在为企业和机构提供算力资源、模型构建与模型应用于一体的平台解决方案，帮助企业高效快速构建专属AI及大模型。 在这里见证IDP的蜕变成长，共探行业和AI技术的迭代发展！
评论