1. 从两张发票说起：OCR和文档信息抽取到底差在哪
上个月帮一个做供应链金融的朋友看系统，他们业务部门提了个需求，说“要能自动读取合同里的收入、单位、时间这些关键字段”。技术负责人第一反应是“这不就是OCR吗，接个接口就完事了”。结果真上手才发现，接口返回的是一大段密密麻麻的文本，字段是读出来了，但哪个是收入、哪个是单位、哪个是签约时间，全靠人眼去认。业务部门当场就炸了：我要的是能直接进数据库的结构化数据，不是把纸质文件变成电子版文字。
这个场景我见过太多次了。问题的根子在于，很多人把OCR和文档信息抽取当成一回事，实际上它们解决的是完全不同层次的问题。OCR干的是“把图片里的字认出来”，文档信息抽取干的是“把认出来的字变成有业务含义的字段”。前者是眼睛，后者是大脑。你光有眼睛没有大脑，看到的只是一堆散乱的文字；你光有大脑没有眼睛，连字都读不进去。
这篇文章我想把这两层能力彻底掰开揉碎讲清楚。不管你是刚接触这块的技术选型人员，还是正在被业务方追着要“自动读取合同字段”的开发者，或者只是好奇为什么OCR识别完了还要做抽取的同行，看完应该能少走不少弯路。我会从底层原理讲到实操方案，从工具选型讲到踩坑经验，尽量把每个“为什么”都说透。
2. 先搞清楚OCR到底在做什么
2.1 OCR的本质：像素到字符的翻译机
OCR全称是光学字符识别，它的核心任务就一件事：给定一张包含文字的图片，输出图片里有哪些字、这些字在什么位置。你可以把它理解成一个翻译机，输入是像素矩阵，输出是字符序列加坐标框。
这个翻译过程大致分几步走。第一步是图像预处理，包括灰度化、二值化、去噪、倾斜校正这些。为什么要做这些？因为原始图片可能有光照不均、有噪点、有倾斜，直接丢给识别模型效果会很差。我试过拿手机拍的发票直接跑识别，因为拍的时候手抖了，文字有轻微倾斜，识别率直接从95%掉到70%多。后来加了一步倾斜校正，识别率就回来了。
第二步是文字检测，也就是找到图片里哪里有文字。这一步输出的是一个个文本框，告诉你“这块区域有字”。第三步是文字识别，把每个文本框里的内容认出来。最后可能还有一步后处理，比如语言模型纠错、格式化输出。
2.2 主流OCR方案怎么选
现在市面上的OCR方案大致分三类，我列个表对比一下。
| 方案类型 | 代表工具 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 开源本地部署 | Tesseract、PaddleOCR、Umi-OCR | 免费、数据不出本地、可定制 | 需要自己调优、准确率依赖训练数据 | 对数据安全要求高、有技术团队 |
| 云服务API | 百度OCR、腾讯OCR | 开箱即用、准确率高、支持多种票据 | 按量收费、数据要上传 | 快速验证、中小规模、无运维能力 |
| 商业软件 | 各类文档处理软件 | 功能完整、有界面 | 贵、定制难 | 非技术团队、标准化场景 |
Tesseract是老牌开源OCR，安装包到处都能找到，惠普最新版驱动里有时候也会带一些扫描软件的OCR组件，但Tesseract本身对中文的支持需要额外下载语言包。我早期用Tesseract识别固定模板票据，英文数字效果还行，中文就有点勉强，尤其是宋体小字，错得比较多。
PaddleOCR这两年在中文场景下表现很突出，尤其是PP-OCRv4之后，轻量模型在CPU上也能跑得动。有个做问卷系统的朋友，在问卷里加了拍照上传功能，后端就是用PaddleOCR做识别，然后前端展示识别结果让用户确认。他遇到的问题是韩文识别不了，代码里写的是from paddlex import create_pipeline，pipeline创建的时候没指定韩文模型，默认只加载了中英文模型。这个坑后面讲多语言的时候再细说。
Umi-OCR是个带界面的本地OCR工具，适合不想写代码的人用。它底层也是调PaddleOCR或者Tesseract，但封装好了，批量处理图片很方便。我有时候需要快速识别一批截图里的文字，就直接拖进Umi-OCR，比写脚本快。
云服务API里百度OCR用得比较多，Java对接的案例一搜一大把。但有个常见问题：上传合同文件时返回file format error，log_id是2104391514326391551这种。这个错误一般是文件格式不对，比如传了个加密PDF，或者图片格式服务端不支持。百度OCR对图片格式有要求，一般支持JPG、PNG、BMP，PDF的话要看具体接口。
2.3 OCR的能力边界在哪里
OCR再强，它输出的也只是文本。你给它一张发票，它返回的是“发票代码 12345678 发票号码 87654321 金额 1000.00 日期 2024-01-01”这样一串字符。它不知道“12345678”是发票代码，“1000.00”是金额。这些字符在OCR眼里是平等的，没有语义标签。
这就是为什么光有OCR不够。业务系统需要的是{"invoice_code": "12345678", "amount": 1000.00, "date": "2024-01-01"}这样的结构化数据，而不是一串文本。从文本到结构化数据，中间隔着的就是文档信息抽取。
3. 文档信息抽取：从文字到业务字段的最后一公里
3.1 信息抽取要解决什么问题
文档信息抽取的任务是：给定OCR输出的文本（可能还带位置信息），识别出文本中哪些片段对应哪些业务字段，并输出结构化的键值对。它要回答的问题是“这段文字是什么含义”，而OCR回答的是“这段文字是什么字”。
举个例子。合同里有一行字是“本合同项下服务费总额为人民币伍拾万元整”。OCR输出就是这行字本身。信息抽取要做的是：识别出“服务费总额”是字段名，“伍拾万元整”是字段值，并且把“伍拾万元整”转换成数字500000，字段名映射成service_fee，最终输出{"service_fee": 500000}。
这个转换过程涉及几个子任务。一是字段识别，找到哪些文本片段是字段名，哪些是字段值。二是关系建立，把字段名和字段值配对。三是归一化，把“伍拾万元整”转成500000，把“2024年1月1日”转成“2024-01-01”。四是校验，检查抽取结果是否符合业务规则，比如金额不能为负、日期不能晚于今天。
3.2 三种主流抽取方案对比
文档信息抽取的实现方式大致分三类，各有各的适用场景。
基于规则模板的抽取是最传统的方式。你针对每种文档类型写一套规则，比如“金额”字段的规则是：找到包含“金额”“总额”“费用”等关键词的行，提取后面的数字。这种方式的优点是准确率高、可解释性强、不需要训练数据。缺点是每换一种文档格式就要重写规则，维护成本高。
我做过一个固定模板票据识别的项目，票据格式很固定，就是那几种。用规则模板的方式，半天就把主要字段抽出来了，准确率99%以上。但后来业务方说“能不能支持一下新版的票据”，新版票据字段位置变了，规则全部要重调。所以规则模板适合格式极其稳定的场景。
基于机器学习序列标注的抽取是中期主流方案。把抽取任务当成命名实体识别来做，用BiLSTM-CRF或者BERT这类模型，标注一批数据训练。优点是泛化能力比规则强，能处理一定程度的格式变化。缺点是需要标注数据，而且标注成本不低。
基于大模型提示词的抽取是最近比较火的方式。把OCR文本和抽取要求一起塞给大模型，让大模型直接输出JSON。优点是开发快、泛化能力强、不需要标注数据。缺点是成本高、有幻觉风险、对长文档支持有限。
| 方案 | 开发成本 | 维护成本 | 准确率 | 泛化能力 | 适用场景 |
|---|---|---|---|---|---|
| 规则模板 | 低 | 高 | 高 | 低 | 格式固定的票据、表单 |
| 序列标注 | 中 | 中 | 高 | 中 | 有一定格式变化的文档 |
| 大模型提示 | 低 | 低 | 中高 | 高 | 格式多变、快速验证 |
3.3 为什么企业真正需要的是抽取层
回到标题的问题：企业真正需要的是哪一层能力？我的答案是，OCR是必要但不充分的条件，文档信息抽取才是直接产生业务价值的那一层。
原因很简单。OCR的输出是给人看的，信息抽取的输出是给系统用的。企业上这套东西，不是为了把纸质文件变成电子文字存档，而是为了让业务系统能自动处理这些数据。合同管理系统需要知道合同金额、签约方、有效期；财务系统需要知道发票号码、金额、税额；风控系统需要知道担保方式、抵押物、还款计划。这些字段不抽出来，系统就没法自动流转。
我见过一个反例。某公司花了不少钱上了OCR，把历史合同全部扫描识别了一遍，存了几十万个文本文件。结果业务部门要用的时候发现，还是得人工打开文件去找字段，因为系统里只有文本，没有结构化数据。这就是典型的只做了OCR没做抽取，钱花了但价值没出来。
4. 从OCR到抽取的完整实操链路
4.1 整体架构设计
一个完整的文档信息抽取系统，大致分四层：图像预处理层、OCR识别层、信息抽取层、业务应用层。
图像预处理层负责把各种来源的图片统一成OCR能处理的格式。包括格式转换、分辨率调整、去噪、纠偏、版面分析。版面分析这一步很关键，它要识别出文档里哪些区域是正文、哪些是表格、哪些是页眉页脚。表格区域和正文区域的OCR策略是不一样的。
OCR识别层就是调各种OCR引擎。这里有个策略选择：是用一个通用OCR全量识别，还是针对不同区域用不同OCR。我的经验是，对于表格区域，用支持表格结构的OCR（比如PaddleOCR的表格识别模型）效果更好；对于正文区域，通用OCR就够了。
信息抽取层是核心。它接收OCR的文本和位置信息，输出结构化字段。这一层可以级联多个抽取器：先用规则抽取高置信度的字段，剩下的用模型抽取，最后用大模型兜底。
业务应用层负责把抽取结果对接业务系统，包括字段映射、数据校验、人工复核流程。
4.2 图像预处理的关键参数
图像预处理这一步很多人不重视，但它对最终效果影响很大。我列几个关键参数。
分辨率方面，OCR引擎一般要求文字高度在20到40像素之间。太低识别不准，太高浪费算力。如果原图分辨率不够，可以适当放大，但放大倍数不要超过2倍，否则插值带来的模糊反而会降低识别率。
二值化阈值方面，Otsu算法是常用的自动阈值方法，但对于光照不均的图片，全局阈值效果不好，要用自适应阈值。OpenCV里cv2.adaptiveThreshold可以设置块大小和常数C，块大小一般取11到31之间的奇数，C取2到10。
倾斜校正方面，用霍夫变换检测直线，计算倾斜角度，然后旋转校正。角度超过5度就要校正，否则文字检测会漏检。
去噪方面，中值滤波对椒盐噪声效果好，高斯滤波对高斯噪声效果好。但要注意，去噪力度太大会把细笔画去掉，反而影响识别。我一般用3x3的中值滤波，力度比较温和。
4.3 OCR引擎的调用与结果解析
以PaddleOCR为例，Python调用的基本流程是这样的。
from paddleocr import PaddleOCR ocr = PaddleOCR(use_angle_cls=True, lang='ch') result = ocr.ocr('invoice.jpg', cls=True) for line in result[0]: box = line[0] # 文本框坐标 text = line[1][0] # 识别文本 confidence = line[1][1] # 置信度 print(f"文本: {text}, 置信度: {confidence}, 位置: {box}")这里有几个参数要注意。use_angle_cls=True会启用方向分类，能处理旋转的文字，但会增加耗时。如果文档都是正向的，可以关掉。lang='ch'指定中文模型，如果要识别韩文，需要改成lang='korean'，而且要先确认模型文件下载了。前面提到的韩文识别不了的问题，就是因为没指定韩文模型。
百度OCR的Java调用也类似，但要注意文件格式。上传前最好把图片转成JPG或PNG，PDF的话要先转成图片再上传。返回的file format error很多时候是因为传了服务端不支持的格式。
// 百度OCR Java调用示例 public String recognize(BufferedImage image) { String base64 = ImageUtil.toBase64(image); JSONObject params = new JSONObject(); params.put("image", base64); params.put("recognize_granularity", "big"); params.put("detect_direction", "true"); String result = HttpClientUtil.post(OCR_URL, params.toJSONString(), "Content-Type", "application/json"); return result; }4.4 信息抽取的规则引擎实现
规则引擎适合字段格式比较固定的场景。核心思路是：定义每个字段的匹配模式，然后在OCR文本里搜索匹配。
以合同金额抽取为例。金额通常出现在“金额”“总额”“费用”“价款”等关键词附近。规则可以这样写：
import re def extract_amount(text): # 匹配"金额"后面跟的数字 patterns = [ r'(?:金额|总额|费用|价款|报酬)[：:\s]*([0-9,，.]+)\s*(?:元|万元)', r'(?:人民币|RMB)[：:\s]*([0-9,，.]+)\s*(?:元|万元)', ] for pattern in patterns: match = re.search(pattern, text) if match: amount_str = match.group(1).replace(',', '').replace('，', '') amount = float(amount_str) # 处理万元单位 if '万元' in match.group(0): amount *= 10000 return amount return None这个规则能处理大部分情况，但有几个坑要注意。一是中文数字，比如“伍拾万元整”，正则匹配不到，需要额外做中文数字转换。二是金额可能跨行，OCR输出的文本行和实际文档的行不一定对应，需要把多行文本拼起来再匹配。三是可能有多个金额，比如合同里既有总金额又有分项金额，规则要能区分。
中文数字转换可以用现成的库，比如cn2an。安装很简单，pip install cn2an，然后cn2an.cn2an('伍拾万', 'smart')就能得到500000。
4.5 大模型抽取的提示词设计
大模型抽取的优势是灵活，不需要写规则。但提示词设计很关键，设计不好容易出幻觉。
一个比较稳的提示词模板是这样的：
你是一个文档信息抽取助手。请从以下文本中抽取指定字段，以JSON格式输出。 需要抽取的字段： - contract_amount: 合同金额，数字类型，单位为元 - sign_date: 签约日期，格式为YYYY-MM-DD - party_a: 甲方名称，字符串 - party_b: 乙方名称，字符串 要求： 1. 如果某个字段在文本中找不到，值设为null 2. 金额如果原文是中文数字，请转换成阿拉伯数字 3. 日期如果原文是"2024年1月1日"，请转换成"2024-01-01" 4. 只输出JSON，不要输出其他内容 文本内容： {ocr_text}这个提示词有几个要点。一是明确字段名和类型，让模型知道要抽什么。二是给出格式要求，避免输出格式混乱。三是明确找不到时的处理方式，避免模型瞎编。四是限定输出格式，方便后续解析。
但大模型抽取有个问题：长文档会超出上下文窗口。合同动辄几十页，OCR文本可能上万字，塞不进模型。解决办法是分段抽取，每段抽完后合并。但分段会切断字段和值的关联，比如字段名在第一段末尾，值在第二段开头。所以分段的时候要留重叠，一般重叠200到500字。
5. 常见问题与排查技巧实录
5.1 OCR识别率低的排查思路
OCR识别率低是最常见的问题。排查的时候按这个顺序来。
先看图片质量。把图片打开，放大到100%，看看文字是否清晰。如果人眼都看不清，OCR肯定也认不出来。图片质量差的原因可能是扫描分辨率低、拍照模糊、光照不均、有阴影。解决办法是重新扫描或拍照，或者用图像增强算法预处理。
再看文字方向。如果文字有旋转，OCR会漏检或错认。用方向分类器检测一下，或者手动旋转校正。
再看语言模型。如果文档是韩文，但加载的是中文模型，识别率肯定低。确认OCR引擎加载了正确的语言模型。
最后看字体。有些特殊字体OCR训练数据里没有，识别率会低。这种情况可以考虑自己训练模型，或者换一个对该字体支持更好的OCR引擎。
5.2 字段抽取不准的常见原因
字段抽取不准，原因通常有这几类。
一是OCR文本有错别字。比如“金额”被识别成“金頟”，规则匹配不到。解决办法是在规则里加入模糊匹配，或者用编辑距离容忍一定程度的错字。
二是字段名和字段值不在同一行。OCR按行输出文本，但实际文档里字段名和值可能跨行。解决办法是把相邻行合并后再匹配，或者用位置信息判断字段名和值的空间关系。
三是多个同名字段。比如合同里甲方和乙方的地址都叫“地址”，规则分不清哪个是甲方的哪个是乙方的。解决办法是结合上下文，比如“甲方”后面的“地址”才是甲方地址。
四是非标准格式。比如金额写成“壹佰万元”，规则只认阿拉伯数字。解决办法是加入中文数字转换。
5.3 多语言场景的坑
多语言场景的坑主要集中在模型加载和字符编码上。
PaddleOCR默认加载中英文模型，如果要识别韩文，需要显式指定lang='korean'。而且韩文模型文件要单独下载，不是默认就有的。如果代码里写的是from paddlex import create_pipeline，创建pipeline的时候要指定lang='korean'，否则默认只加载中英文。
Tesseract的多语言支持需要下载对应的语言包。比如中文是chi_sim，韩文是kor。下载后放到tessdata目录，调用的时候用-l chi_sim+kor指定多语言。
字符编码方面，OCR输出的文本可能是UTF-8，也可能是GBK，要看具体引擎。处理的时候统一转成UTF-8，避免乱码。
5.4 性能优化的实操经验
OCR和抽取都是计算密集型任务，性能优化很重要。
批量处理方面，不要一张一张图调OCR，要批量调。PaddleOCR支持批量推理，把多张图组成一个batch，能显著提升吞吐量。
异步处理方面，如果是在线服务，OCR和抽取可以异步做。用户上传图片后立即返回“处理中”，后台异步识别和抽取，完成后推送结果。
缓存方面，相同的图片不要重复识别。可以用图片的MD5做key，缓存OCR结果。
模型选择方面，如果对准确率要求不是极致，可以用轻量模型。PaddleOCR的mobile模型比server模型快好几倍，准确率只低一点点。
5.5 常见问题速查表
| 问题现象 | 可能原因 | 排查方法 | 解决方案 |
|---|---|---|---|
| 识别率低 | 图片质量差 | 人眼看是否清晰 | 重新扫描或图像增强 |
| 识别率低 | 文字旋转 | 检查文字方向 | 方向分类或手动校正 |
| 识别率低 | 语言模型不对 | 确认加载的模型 | 加载正确语言模型 |
| 字段抽取不到 | OCR有错别字 | 对比原文和OCR结果 | 模糊匹配或纠错 |
| 字段抽取不到 | 字段跨行 | 检查文本行分布 | 合并相邻行 |
| 字段抽取错误 | 多个同名字段 | 检查上下文 | 结合上下文区分 |
| 接口报错 | 文件格式不对 | 检查文件格式 | 转成支持的格式 |
| 处理速度慢 | 单张处理 | 检查是否批量 | 批量推理或异步 |
6. 企业级方案选型的几个关键决策
6.1 自建还是用云服务
这个决策取决于几个因素。数据敏感度高的，比如合同、财务票据，建议自建，数据不出本地。技术团队强的，自建可控性高。业务量小的，用云服务更划算，省去运维成本。
我一般建议混合方案：核心敏感数据自建OCR，非敏感数据用云服务。这样既保证安全，又控制成本。
6.2 规则和模型的配比
纯规则维护成本高，纯模型需要标注数据。实际项目中，我一般用规则加模型的混合方案。高频、格式固定的字段用规则，低频、格式多变的字段用模型。规则抽取的结果置信度高，可以直接用；模型抽取的结果置信度低，走人工复核。
6.3 人工复核流程的设计
完全自动化的抽取在现阶段还不现实，人工复核是必要的。但复核流程要设计好，不能让复核变成重新录入。
我的做法是：系统展示原图和抽取结果，抽取结果按置信度排序，高置信度的字段默认折叠，低置信度的字段展开让复核人员确认。复核人员只需要修改错误的字段，不需要重新输入所有字段。这样复核效率能提升好几倍。
6.4 持续优化的闭环
文档信息抽取系统不是上线就完事了，需要持续优化。优化的数据来源就是人工复核的结果。复核人员修改的字段，就是模型的错误样本。定期把这些样本收集起来，重新训练模型或调整规则，系统会越来越准。
我一般建议每周做一次错误分析，看看哪些字段错误率高，针对性地优化。每月做一次模型迭代，把新积累的样本加进去训练。
7. 一个完整的合同字段抽取实例
7.1 需求拆解
假设有一个合同管理系统，需要从上传的合同PDF中自动抽取以下字段：合同编号、甲方名称、乙方名称、合同金额、签约日期、有效期。合同格式不固定，有扫描件也有电子版。
7.2 技术方案
PDF先转成图片，用PyMuPDF或pdf2image。图片预处理用OpenCV做去噪和纠偏。OCR用PaddleOCR，中文模型。抽取用规则加BERT的混合方案。规则抽合同编号、金额、日期这些格式固定的字段，BERT抽甲方乙方名称这些格式多变的字段。
7.3 关键代码
import fitz # PyMuPDF import cv2 import numpy as np from paddleocr import PaddleOCR def pdf_to_images(pdf_path): doc = fitz.open(pdf_path) images = [] for page in doc: pix = page.get_pixmap(dpi=200) img = np.frombuffer(pix.samples, dtype=np.uint8) img = img.reshape(pix.height, pix.width, pix.n) images.append(img) return images def preprocess(img): gray = cv2.cvtColor(img, cv2.COLOR_RGB2GRAY) # 去噪 denoised = cv2.medianBlur(gray, 3) # 自适应二值化 binary = cv2.adaptiveThreshold(denoised, 255, cv2.ADAPTIVE_THRESH_GAUSSIAN_C, cv2.THRESH_BINARY, 15, 8) return binary def extract_fields(ocr_result): full_text = '\n'.join([line[1][0] for line in ocr_result[0]]) fields = {} # 合同编号 match = re.search(r'合同编号[：:\s]*([A-Za-z0-9-]+)', full_text) fields['contract_no'] = match.group(1) if match else None # 金额 fields['amount'] = extract_amount(full_text) # 日期 match = re.search(r'签约日期[：:\s]*(\d{4})[年\-](\d{1,2})[月\-](\d{1,2})', full_text) if match: fields['sign_date'] = f"{match.group(1)}-{match.group(2).zfill(2)}-{match.group(3).zfill(2)}" else: fields['sign_date'] = None return fields7.4 效果与调优
这套方案在测试集上，合同编号和金额的抽取准确率能到98%以上，日期95%左右，甲方乙方名称因为格式多变，准确率在85%左右。甲方乙方名称的准确率提升靠的是BERT模型，用了几百份标注合同训练，准确率从70%提升到85%。
调优过程中发现，PDF转图片的DPI很关键。DPI太低文字模糊，DPI太高处理慢。200 DPI是个比较好的平衡点。另外，扫描件的预处理比电子版重要得多，扫描件不做预处理直接OCR，准确率会低10到20个百分点。
8. 写在最后的一些个人体会
做文档信息抽取这些年，最大的体会是：不要指望一个方案解决所有问题。OCR、规则、模型、大模型，每种技术都有它的适用场景和边界。实际项目里往往是组合使用，取长补短。
另一个体会是，数据质量比算法重要。OCR识别率低，很多时候不是算法不行，是图片质量太差。抽取不准，很多时候不是模型不行，是OCR文本错太多。把数据质量搞上去，效果提升比换算法明显得多。
还有一点，人工复核不是丢人的事，是现阶段必要的环节。完全自动化是目标，但不要为了自动化而自动化。系统加人工的混合模式，在准确率和成本之间能找到很好的平衡。
最后分享一个小技巧：如果OCR识别固定模板票据，先用模板匹配定位字段区域，再对每个区域单独OCR，比全图OCR再抽取准确率高很多。因为区域限定后，OCR的搜索空间小了，错认的概率也低了。这个技巧在发票、票据、表单这类场景特别管用。
