你接手了一个图片翻译需求第一批样片刚跑完OCR 引擎就把“合同编号”识别成了“合同皌号”“发货日期”变成“发货凵期”。更气人的是这种乱码不是零散出现的同一个错字换个阈值就变一个花样。我早几年做文档数字化项目时被这类问题折腾过很长时间最后跑通了一套稳定流程在 OCR 和翻译之间插入一个 LLM“校对员”让大模型结合上下文把脏文本修回来再翻译。用这套方案在限定测试集上做过人工标定整图可读准确率能达到 99.9% 级别。这篇文章会把这套方案完整拆开讲讲乱码为什么会产生、LLM 为什么能当校对员以及一条从图片输入到翻译结果输出的完整流水线。想做好 OCR 应用、图片翻译工具、文档信息抽取的开发者应该能从里面找到可以直接复用的思路。1. 先看清问题OCR 乱码不是随机发散而是系统性失真1.1 乱码为什么会存在识别器本质上是在赌概率要修复乱码首先得明白乱码是从哪来的。常规 OCR 引擎的识别链路大致分成两步第一步是文字检测把图片里的文本框框出来第二步是文字识别对每个框里的图像特征做序列建模输出候选字符的概率分布最后取概率最高的字符作为结果。问题恰恰出在最后这一步。正常情况下一个清晰的大号字体模型对正确答案的置信度能到 0.95 以上概率分布很尖锐。但图片只要稍微模糊、分辨率不足、光照不均、或者文字笔画粘连模型看到的特征就变得模棱两可概率分布会被拉平几个候选字符的概率可能都只有 0.2 到 0.4。这时候引擎取 argmax 就有点像近视眼隔着毛玻璃猜字猜错的概率自然飙升。所以乱码并不是引擎“故意捣乱”而是它在低信息量下做了一个低置信度的判断。这个认知特别重要因为后面所有修复策略都是围绕“低置信度的错误”来设计的。如果错误是高置信度的说明图片本身或模型本身有问题那属于另一个层面的问题。1.2 真实业务里高频出现的四类乱码拿我手上的真实样片来分类长期跑 OCR 会遇到这么几类高频错误错误类型典型成因表现形式形近字混淆笔画相似图像分辨率不足“已”误为“己”“日”误为“曰”字母数字混淆字体渲染导致特征相近“0”与“O”“1”与“l”混淆字符丢失或重复笔画断裂或粘连检测框不完整“金额”变成“金页”少一笔乱序错位文本行检测偏差序列建模错乱双栏文本串行左右列文字交叉第一类形近字混淆最多中文里大量字形接近的字在 100 像素高度的图像里人眼都难分。第二类常见于英文和数字混排的型号、单号。第三类最隐蔽OCR 不是把字认错而是把字的一部分丢了整体看起来像个从来不存在的新字符。第四类在截图类素材里很常见表格和双栏排版下文本顺序错乱。我在项目里最怕的不是前三类而是第四类。因为前三类虽然“字错了”但上下文语境还在LLM 有机会根据前后文猜回来。第四类顺序错乱破坏的是整句的语义结构修复起来成本要高得多。后面第 4 部分会单独讲表格串列的排查思路。2. 为什么选 LLM 当“校对员”规则纠错卡在了哪2.1 词典纠错与形近字映射表的边界最直接的乱码修复方案是做一张形近字表比如“目/曰”“己/已/巳”“亻/彳”互相映射。再配合一个业务词典OCR 输出某个词不在词典里就用词典里形近的候选词替换。这种思路对固定术语场景很有效比如发票抬头、地址库、标准品名准确率能做得很高因为候选集合是封闭的。但真实业务里的文本是开放的。人名、公司名、街道名、非常规表达词典根本覆盖不过来。举个例子OCR 把“签闰合同”里的“闰”识别错了词典里根本没有“签闰”这个词自然不知道要改成“签暑”“签晋”还是“签订”。这时候任何一个固定映射表都会失灵。还有一个更隐蔽的问题规则纠错只能处理“词内错误”处理不了“跨词错误”。比如一句话里同时有两个形近字出错把“订单金额为500元”识别成“订单金页为500元”然后“页”又和后面的“为”串了语境。这种级联错误字符级规则根本无从下手。2.2 LLM 能“猜”出正确字语言模型在补上下文LLM 校对的核心逻辑和形近字表完全不同。它不是在找字形替换而是在做条件概率预测给定前后文当前位置最应该出现什么字。OCR 输出的句子里虽然有个别字是错的但前后的上下文保持了完整性这就给语言模型提供了足够的“线索”。比如“请于 2024 年 6 月 30 日前签_合同”这个下划线位置在自然语言里几乎只会填“订”“署”“妥”这类字再结合形近关系“闰”离“订”的形态差得远但离“署”和“订”更近模型能快速锁定。打个比方你看到一张照片墙上挂的画歪了不需要重新测量墙面角度只需要参照旁边的门框和地脚线就能很快把画扶正。LLM 干的是这个活OCR 负责“看见”LLM 负责“参照上下文把画面扶正”。另外要强调一点LLM 不是万能的。当 OCR 错误率超过一定比例我实测中文场景大概在 15% 以上上下文本身的“线索”也被污染了LLM 修复效果会断崖式下跌。所以这套方案的前提是 OCR 引擎本身不能太拉胯LLM 做的是把那几个百分点的错误收尾而不是从零开始识别。2.3 方案选型服务化调用还是本地推理确定了“LLM 当校对员”这个方向下一步就是选型。我的选择对比经验是对比维度商用大模型 API本地开源模型修复效果强尤其古文、非规范表达中上依赖参数量部署成本低按量付费高需要 GPU 资源数据隐私数据出网需评估合规数据不出机房时延网络往返 排队GPU 推理时延稳定批量吞吐受账号并发限制可自行扩容我自己的习惯是原型阶段一律用商用 API因为效果验证速度快省去部署调优的功夫。如果业务跑通、日均处理量上万再评估要不要切本地模型。如果图片里包含客户个人信息、合同金额、内部工单等敏感内容那直接从本地模型方案开始。选型时还要注意一个几乎没人提的点上下文窗口长度和分段策略。OCR 一张 A4 文档可能输出上千字商用 API 虽然有很长的上下文窗口但每次校对请求塞太多字会增加耗时和费用。要提前设计好分段策略按照自然段或者文本框切分每段控制在几百字以内LLM 的修复质量也更稳定。3. 一套完整的六步流水线图片翻译从进到出的实操方案3.1 第一步 图片预处理给 OCR 一个“看得清”的图很多人拿到图片就直接丢给 OCR这其实是把一道难题扔给最薄弱的环节。我在自己的流水线里固定了一套预处理流程先转灰度再用双边滤波或高斯滤波去噪然后做自适应二值化最后对倾斜文本做透视矫正。这里最要注意的是二值化。固定全局阈值在光照均匀时没问题但手机拍摄的图片经常有一半亮一半暗全局阈值会把亮部文字融掉、暗部背景变黑。自适应二值化会对每个像素邻域单独算阈值我在用 500 像素窗口、C 值设为 10 时对大多数拍摄样片效果最稳。当然这个参数要根据实际图像分辨率微调我通常是先跑几十张看输出文本的置信度分布再定。还要提一句倾斜矫正。手拍的图片文字经常歪几度OCR 检测框会跟着斜识别准确率显著下降。我在流程里先做一次边缘检测找出文本行的主导角度再旋转回水平。这个步骤能直接拉回 5 到 10 个百分点的字符准确率。3.2 第二步 OCR 抽取引擎选择与质量开关选 OCR 引擎时我最关注三个能力一是能否输出置信度二是能否返回每个文本框的坐标三是多语言混排的支持程度。置信度是后面整条流水线的核心信息没有置信度就只能盲修。坐标信息是处理表格和双栏排版的关键没有坐标就分不清哪段文字是属于哪个区域的。多语言混排则直接影响翻译场景——中英文混排是常态纯中文 OCR 引擎会把英文单词拆成乱码。我在实际项目里会把 OCR 结果抽成一个结构化的列表每一条记录包含文本、坐标、置信度。伪代码如下ocr_engine load_ocr_engine(langzhendigit) page_blocks ocr_engine.run(image) records [] for block in page_blocks: for line in block.lines: records.append({ bbox: line.bbox, # 文本框坐标 text: line.text, # 识别文本 confidence: line.confidence # 识别置信度0-1 })拿到这个列表后先做一次粗过滤把置信度低于 0.3 的疑似噪声行直接丢掉减少对后续 LLM 的干扰。要说明的是这里的阈值不是绝对的我见过某些样片里半截噪声行的置信度也有 0.5所以过滤后保留的内容还需要再人工复核抽检一轮。3.3 第三步 校对 Prompt 设计把“校对员”的岗位说明写好LLM 能不能当好校对员一半取决于模型本身另一半取决于你有没有给它一份清晰的“岗位说明”。我在反复试错后沉淀了一套 prompt 模板核心原则就四句话角色明确、任务单一、边界清楚、输出可控。修复场景的 prompt 模板你是一名 OCR 后处理校对员。下面是一段由光学字符识别系统输出的文本 其中可能存在错别字、多字、漏字、顺序颠倒等问题。 请结合上下文把文本修复为通顺、准确的原内容。 要求 1. 逐句修复不改变原意 2. 不确定的地方保留原文不要臆造 3. 不要补全原图片中不存在的信息 4. 只输出修复后的文本不要输出任何解释或分析。 待修复文本 {ocr_text}这里几个要求不是套话。第二条“不确定的地方保留原文”是为了防止模型发明内容这个我吃过亏第三条是防止模型顺着语感“补全”其实图片里没有的信息第四条是为了便于程序解析结果直接取输出文本即可。翻译场景我通常会把修复和翻译合并成一步减少一次 API 往返你是一名图片文本翻译助手。下面是一段由光学字符识别系统输出的文本 可能含有错别字、多字、漏字。请先修复为通顺的原文再翻译成英文。 要求 1. 修复时保持原意不确定处保留原文字 2. 翻译结果要忠实修复后的文本 3. 只输出翻译结果不要解释。 待修复文本 {ocr_text}实测下来修复和翻译合并做语义一致性比分开两步更好因为模型在翻译时能看到它自己修复的上下文而不是在两个独立生成过程中产生信息损耗。当然也有代价如果最终译文有问题你很难判断是修复阶段出的错还是翻译阶段出的错所以上线初期建议还是先分开跑攒一批对比数据后再合。3.4 第四步 修复与翻译单段处理与批量并发拿到结构化 OCR 记录后我按文本块为单位构造 prompt。每个文本块通常对应一个自然段或一个文本框区域。这里要控制每次请求的文本量我的经验是单次控制在 300 到 500 字以内太长了模型修复质量下降而且超时风险高。批量处理时要注意并发控制。直接循环调用 API一个响应慢了会阻塞整个队列。我在项目里会开一个固定线程池并发数在 4 到 8 之间再配合重试机制——超时或服务端返回异常时退避重试三次。重试时要注意幂等同一段文本不要因为重试而重复提交导致重复扣费。如果用的是本地模型批量处理反而简单直接拼接批量请求利用 GPU 的并行能力。但本地模型单条质量和商用 API 的差距在错字密度高时体现得最明显。我测试过本地小尺寸模型修复效果只能到商用 API 的七八成适合大体量但对效果要求不极致的生产场景。3.5 第五步 置信度分流让 LLM 只干它该干的活把全部 OCR 文本都交给 LLM其实是一种浪费。高置信度文本是正确的送进去反而存在被 LLM“改错”的风险后面 4.4 会展开讲。我的做法是按置信度分三条路置信度范围处理策略复核要求大于 0.95直接使用不送 LLM无需复核0.70 - 0.95送 LLM 修复抽样人工复核小于 0.70送 LLM 修复 原图对照建议人工逐条确认这套分流规则的核心思想是让 LLM 专注处理“可疑文本”而不是所有文本。一来提升效率二来避免正确的文本被模型“画蛇添足”地改出问题。阈值 0.95 和 0.70 不是固定不变的业务对错误的容忍度不同可以上下浮动。在合同信息抽取场景我会把高置信度阈值调到 0.98宁多不少在菜单翻译这类阅读性场景0.9 就够了。人工复核在产品上尽量做成并排对照的形态左边原图片段、中间 OCR 文本、右边 LLM 修复结果。复核人只需要判断右侧文字是否与左侧原图一致操作成本和认知成本都最低。3.6 第六步 效果度量99.9% 是怎么测出来的说准确率之前必须先统一口径。行业里常见的口径有这么几种字符级准确率、词级准确率、整图级可读准确率。字符级指标很严格一个标点错了都算错整图级可读准确率更接近用户的真实感知定义是“标注者认为在不看原图的情况下修复后的文本能否完整表达原图信息”。我对外汇报 99.9% 时用的就是“整图级可读准确率”。具体测法是抽 300 张覆盖不同版式、不同清晰度的样片用这条流水线处理后交给两名标注员独立判断每张图是否“可读无碍”两人意见一致且判定为可读的图片占比就是最终指标。实际操作时会剔除极端模糊、完全无法辨认的样片只在“人工能看清原图文字”的样本集上统计。建议你在自己的项目里也先定好口径再定目标。如果你拿字符级指标去要求 99.9%那几乎是做不到的因为单个字识别错误在真实图片里不可避免。反过来如果只报整图级可读准确率也要把抽样方法和标注规则写清楚否则数字没有任何说服力。4. 跑批时踩过的坑和排查实录4.1 低分辨率长截图上下文断裂是最大的坑有一次接到个需求用户上传一张很长的网页截图宽度只有 640 像素左右。OCR 引擎按行识别后我按文本框把结果拆成了几段再分别送给 LLM 修复。结果修出来的文本质量很差很多句子语义不通。排查后发现原因在于长截图被 OCR 切成了多个不连续片段每个片段单独看上下文信息不足。比如“本项目将于下月”和“正式启动”被切到两个文本框LLM 单独修复前一句时会丢掉后一句的信息关键实体名就被臆补错了。解决办法是合并上下文先用坐标信息把行按阅读顺序排序再按自然段语义合并成更大的文本块块之间保留少量重叠再送给 LLM。同时把预处理阶段对低分辨率图做一次文本区域增强比如对文字 ROI 区域做指定倍数的线性放大后再识别置信度会明显提升。4.2 艺术字和手写体修复是伪命题海报标题这类艺术字笔画变形程度大OCR 识别出来的结果经常是完全发散的。比如一个“每”字在夸张字体下被识别成“侮”或者“悔”这种错误不是形近字级别的而是整个字形特征被大幅扭曲。这类样本我走了不少弯路才接受一个现实明确定位为“LLM 无法可靠修复”的类型。在流水线里对这类文本不做强制修复而是把置信度极低的部分标注为“需人工确认”直接渲染到人工复核队列里。与其让模型乱猜不如老老实实让用户花几秒钟看一眼原图。手写体稍微好一点但同样没有通用解法。大量手写样张、连笔字识别Python 层面的后处理改善有限最有效的方案永远是换一个更强的手写识别模型或者训练领域专用模型。LLM 校对在这里只能做非常有限的干预比如修正标点、合并断行指望它把手写错字全部改对不现实。4.3 表格跨行串列坐标重排比 LLM 硬修更有效表格类图片是单独的一类难缠样本。OCR 按识别框输出时经常会因为列宽太窄、文字溢出而把左右两列的片段按行混排。LLM 收到这一行文本时根本分不清哪些字属于哪一列再怎么修也恢复不了表格结构。后来我的处理思路变了不把表格的原始文本流按行直接给 LLM而是先用坐标做结构化重排。坐标信息里 column 的位置固定我会先定义几个列区间然后把每个文本框按中心点 x 坐标分桶配合 y 坐标排序拼成列级文本块。比如“商品名称”列单独拼成一段“金额”列单独拼成一段两段分别送 LLM 修复和翻译。这一步能把表格翻译的整体可用率提升一个台阶。结构化重排还有一种更彻底的玩法把表格区域识别出来后用文字坐标生成一个简化版的结构化 JSON例如{ columns: [商品名称, 数量, 金额], rows: [ [苹果, 2, 10.00], [香蕉, 3, 15.50] ] }让 LLM 直接基于 JSON 结构修复和翻译就不会发生跨列串字的问题。代价是实现成本高一些要做列线检测或者列中心聚类但一旦跑通对票据、账单类图片的翻译效果提升是立竿见影的。4.4 LLM 幻觉把对的改成错的这是我在所有坑里最想提醒你注意的一个。LLM 校对最大的风险不在于它修不好错误而在于它会把本已正确的文本“修复”成错误内容。原因是模型有很强的“顺滑倾向”碰到一个我们人类看起来很常见的搭配会不由自主地补全或改写。我遇到过最典型的案例是图片里清清楚楚写着“首付 30%”OCR 也正确识别了LLM 却把它“修复”成“首付 30% 定金”。因为在日常语料里“定金”和“首付”经常一起出现模型顺着语感加了词。这在合同类场景是致命失误金额后面跟的术语完全变了。我的对策组合很有效高置信度文本走旁路不进 LLMPrompt 里反复强调“不确定处保留原文不要补全”模型温度调到 0关闭随机性修复前后做 diff对有改动的片段标记为“待确认”在人工审核界面里提示。LLM 修出来的结果一定要让用户或复核人有能力看到“它改了什么”而不是只看到最终结果。我会把 OCR 原文本和修复后文本做对比用 diff 的方式列出来这样任何一次模型“手滑”都能被快速发现。4.5 批量任务的成本与排队别让校对环节拖垮整体吞吐OCR 本身很快一张图几百毫秒但 LLM 校对环节可能让单张延迟涨到几秒甚至十几秒。如果做实时翻译工具这个延迟是致命的。批量离线任务的成本问题同样突出我见过有人把全部 OCR 文本都丢给 LLM 翻译导致单张成本翻了 5 倍还不止。我的成本控制策略有三个只送低置信度片段进 LLM高置信度直接透传这是最大头的节省对重复图片做内容哈希缓存同一张图二次处理直接读缓存对长文本块做重叠切分避免一次请求塞太多 token同时防止单次超时。排队问题在调用商用 API 时尤其明显。某个账号并发一高响应时间就开始膨胀而且不同时间段的稳定性差异很大。我的做法是做一个任务队列在调用 LLM 之前统计一下当前队列长度如果积压超过预设阈值就把部分低优先级任务切到本地小模型处理保证整体吞吐不中断。5. 一些不会写进文档的经验5.1 先定义“对”再追求 99.9%每次听到有人直接开口要“99.9% 准确率”我都会先反问一句你的“准确”是怎么定义的是按字符算、按句子算、还是按用户的使用体验算这三个口径对同一套系统可能差出十几个百分点。我建议做这类项目时先找业务方一起定下“可接受质量”的准确定义。如果目标只是“用户看翻译结果能看懂”那整图级可读懂准确率就是核心指标如果目标是“发票金额识别错了要赔钱”那单个数值字段的字段级准确率才是关键甚至要按关键字段单独统计。定义清楚了后面所有调优才有明确方向。5.2 Prompt 迭代比换模型更见效遇到修复效果不佳时第一反应别是“换更大的模型”。我实测过在同样的模型下把 prompt 调对效果提升可能比增加模型参数量还明显。我的迭代方法是维护一个错误样本库跑完一批样片后把修复失败的 case 收集起来分成三类——OCR 输出质量太差导致 LLM 没有足够线索、LLM 修错、LLM 漏修。针对每一类在 prompt 里增加边界条件说明。比如我手里积累了一批“已/己/巳”混淆的 case就在 prompt 里加了一句“注意区分已、己、巳三个字结合动词时态判断”。这样针对性提示的效果比笼统地说“请仔细校对”好得多。5.3 让用户有最后一道纠错权技术做得再完善也总会有极少数图片绕过所有防线。这时候产品不能设计成“黑盒输出”要让用户能方便地看到原图、看到 OCR 文本、看到翻译结果并可以一键纠正。我甚至建议对低置信度结果默认展示“原文对照模式”用户瞄一眼就能确认翻译对不对。这不仅是用户体验问题也是在为你的评测集积累数据。用户每一次主动纠错都是一条高质量标注样本比你自己费劲找标注员高效多了。5.4 积累评测样本才是长期资产最后分享一个我最有体会的建议从第一天开始就保存每一张样片的完整处理链路记录——原图、预处理参数、OCR 原始文本、置信度、LLM 修复文本、翻译结果、人工修正结果。这套数据积累三个月后你就有了一份覆盖各种真实场景、各种错误类型的评测集。之后无论换 OCR 引擎、调 prompt、还是升级模型都用同一份评测集去评估所有改动的好坏一目了然。项目做久了你会发现模型会过时、API 会涨价、prompt 会调优但那份属于自己的评测集是永远增值的资产。我个人的体会是OCR 图片翻译这个方向真正的门槛不在某一个模型有多强而在你把“看得见的文字”和“读得懂的语义”之间的桥搭得有多顺。OCR 负责看见LLM 负责读懂人负责确认三条腿配合好了剩下的事情只是让这个流程跑得更快、更稳、更便宜。
你接手了一个图片翻译需求第一批样片刚跑完OCR 引擎就把“合同编号”识别成了“合同皌号”“发货日期”变成“发货凵期”。更气人的是这种乱码不是零散出现的同一个错字换个阈值就变一个花样。我早几年做文档数字化项目时被这类问题折腾过很长时间最后跑通了一套稳定流程在 OCR 和翻译之间插入一个 LLM“校对员”让大模型结合上下文把脏文本修回来再翻译。用这套方案在限定测试集上做过人工标定整图可读准确率能达到 99.9% 级别。这篇文章会把这套方案完整拆开讲讲乱码为什么会产生、LLM 为什么能当校对员以及一条从图片输入到翻译结果输出的完整流水线。想做好 OCR 应用、图片翻译工具、文档信息抽取的开发者应该能从里面找到可以直接复用的思路。1. 先看清问题OCR 乱码不是随机发散而是系统性失真1.1 乱码为什么会存在识别器本质上是在赌概率要修复乱码首先得明白乱码是从哪来的。常规 OCR 引擎的识别链路大致分成两步第一步是文字检测把图片里的文本框框出来第二步是文字识别对每个框里的图像特征做序列建模输出候选字符的概率分布最后取概率最高的字符作为结果。问题恰恰出在最后这一步。正常情况下一个清晰的大号字体模型对正确答案的置信度能到 0.95 以上概率分布很尖锐。但图片只要稍微模糊、分辨率不足、光照不均、或者文字笔画粘连模型看到的特征就变得模棱两可概率分布会被拉平几个候选字符的概率可能都只有 0.2 到 0.4。这时候引擎取 argmax 就有点像近视眼隔着毛玻璃猜字猜错的概率自然飙升。所以乱码并不是引擎“故意捣乱”而是它在低信息量下做了一个低置信度的判断。这个认知特别重要因为后面所有修复策略都是围绕“低置信度的错误”来设计的。如果错误是高置信度的说明图片本身或模型本身有问题那属于另一个层面的问题。1.2 真实业务里高频出现的四类乱码拿我手上的真实样片来分类长期跑 OCR 会遇到这么几类高频错误错误类型典型成因表现形式形近字混淆笔画相似图像分辨率不足“已”误为“己”“日”误为“曰”字母数字混淆字体渲染导致特征相近“0”与“O”“1”与“l”混淆字符丢失或重复笔画断裂或粘连检测框不完整“金额”变成“金页”少一笔乱序错位文本行检测偏差序列建模错乱双栏文本串行左右列文字交叉第一类形近字混淆最多中文里大量字形接近的字在 100 像素高度的图像里人眼都难分。第二类常见于英文和数字混排的型号、单号。第三类最隐蔽OCR 不是把字认错而是把字的一部分丢了整体看起来像个从来不存在的新字符。第四类在截图类素材里很常见表格和双栏排版下文本顺序错乱。我在项目里最怕的不是前三类而是第四类。因为前三类虽然“字错了”但上下文语境还在LLM 有机会根据前后文猜回来。第四类顺序错乱破坏的是整句的语义结构修复起来成本要高得多。后面第 4 部分会单独讲表格串列的排查思路。2. 为什么选 LLM 当“校对员”规则纠错卡在了哪2.1 词典纠错与形近字映射表的边界最直接的乱码修复方案是做一张形近字表比如“目/曰”“己/已/巳”“亻/彳”互相映射。再配合一个业务词典OCR 输出某个词不在词典里就用词典里形近的候选词替换。这种思路对固定术语场景很有效比如发票抬头、地址库、标准品名准确率能做得很高因为候选集合是封闭的。但真实业务里的文本是开放的。人名、公司名、街道名、非常规表达词典根本覆盖不过来。举个例子OCR 把“签闰合同”里的“闰”识别错了词典里根本没有“签闰”这个词自然不知道要改成“签暑”“签晋”还是“签订”。这时候任何一个固定映射表都会失灵。还有一个更隐蔽的问题规则纠错只能处理“词内错误”处理不了“跨词错误”。比如一句话里同时有两个形近字出错把“订单金额为500元”识别成“订单金页为500元”然后“页”又和后面的“为”串了语境。这种级联错误字符级规则根本无从下手。2.2 LLM 能“猜”出正确字语言模型在补上下文LLM 校对的核心逻辑和形近字表完全不同。它不是在找字形替换而是在做条件概率预测给定前后文当前位置最应该出现什么字。OCR 输出的句子里虽然有个别字是错的但前后的上下文保持了完整性这就给语言模型提供了足够的“线索”。比如“请于 2024 年 6 月 30 日前签_合同”这个下划线位置在自然语言里几乎只会填“订”“署”“妥”这类字再结合形近关系“闰”离“订”的形态差得远但离“署”和“订”更近模型能快速锁定。打个比方你看到一张照片墙上挂的画歪了不需要重新测量墙面角度只需要参照旁边的门框和地脚线就能很快把画扶正。LLM 干的是这个活OCR 负责“看见”LLM 负责“参照上下文把画面扶正”。另外要强调一点LLM 不是万能的。当 OCR 错误率超过一定比例我实测中文场景大概在 15% 以上上下文本身的“线索”也被污染了LLM 修复效果会断崖式下跌。所以这套方案的前提是 OCR 引擎本身不能太拉胯LLM 做的是把那几个百分点的错误收尾而不是从零开始识别。2.3 方案选型服务化调用还是本地推理确定了“LLM 当校对员”这个方向下一步就是选型。我的选择对比经验是对比维度商用大模型 API本地开源模型修复效果强尤其古文、非规范表达中上依赖参数量部署成本低按量付费高需要 GPU 资源数据隐私数据出网需评估合规数据不出机房时延网络往返 排队GPU 推理时延稳定批量吞吐受账号并发限制可自行扩容我自己的习惯是原型阶段一律用商用 API因为效果验证速度快省去部署调优的功夫。如果业务跑通、日均处理量上万再评估要不要切本地模型。如果图片里包含客户个人信息、合同金额、内部工单等敏感内容那直接从本地模型方案开始。选型时还要注意一个几乎没人提的点上下文窗口长度和分段策略。OCR 一张 A4 文档可能输出上千字商用 API 虽然有很长的上下文窗口但每次校对请求塞太多字会增加耗时和费用。要提前设计好分段策略按照自然段或者文本框切分每段控制在几百字以内LLM 的修复质量也更稳定。3. 一套完整的六步流水线图片翻译从进到出的实操方案3.1 第一步 图片预处理给 OCR 一个“看得清”的图很多人拿到图片就直接丢给 OCR这其实是把一道难题扔给最薄弱的环节。我在自己的流水线里固定了一套预处理流程先转灰度再用双边滤波或高斯滤波去噪然后做自适应二值化最后对倾斜文本做透视矫正。这里最要注意的是二值化。固定全局阈值在光照均匀时没问题但手机拍摄的图片经常有一半亮一半暗全局阈值会把亮部文字融掉、暗部背景变黑。自适应二值化会对每个像素邻域单独算阈值我在用 500 像素窗口、C 值设为 10 时对大多数拍摄样片效果最稳。当然这个参数要根据实际图像分辨率微调我通常是先跑几十张看输出文本的置信度分布再定。还要提一句倾斜矫正。手拍的图片文字经常歪几度OCR 检测框会跟着斜识别准确率显著下降。我在流程里先做一次边缘检测找出文本行的主导角度再旋转回水平。这个步骤能直接拉回 5 到 10 个百分点的字符准确率。3.2 第二步 OCR 抽取引擎选择与质量开关选 OCR 引擎时我最关注三个能力一是能否输出置信度二是能否返回每个文本框的坐标三是多语言混排的支持程度。置信度是后面整条流水线的核心信息没有置信度就只能盲修。坐标信息是处理表格和双栏排版的关键没有坐标就分不清哪段文字是属于哪个区域的。多语言混排则直接影响翻译场景——中英文混排是常态纯中文 OCR 引擎会把英文单词拆成乱码。我在实际项目里会把 OCR 结果抽成一个结构化的列表每一条记录包含文本、坐标、置信度。伪代码如下ocr_engine load_ocr_engine(langzhendigit) page_blocks ocr_engine.run(image) records [] for block in page_blocks: for line in block.lines: records.append({ bbox: line.bbox, # 文本框坐标 text: line.text, # 识别文本 confidence: line.confidence # 识别置信度0-1 })拿到这个列表后先做一次粗过滤把置信度低于 0.3 的疑似噪声行直接丢掉减少对后续 LLM 的干扰。要说明的是这里的阈值不是绝对的我见过某些样片里半截噪声行的置信度也有 0.5所以过滤后保留的内容还需要再人工复核抽检一轮。3.3 第三步 校对 Prompt 设计把“校对员”的岗位说明写好LLM 能不能当好校对员一半取决于模型本身另一半取决于你有没有给它一份清晰的“岗位说明”。我在反复试错后沉淀了一套 prompt 模板核心原则就四句话角色明确、任务单一、边界清楚、输出可控。修复场景的 prompt 模板你是一名 OCR 后处理校对员。下面是一段由光学字符识别系统输出的文本 其中可能存在错别字、多字、漏字、顺序颠倒等问题。 请结合上下文把文本修复为通顺、准确的原内容。 要求 1. 逐句修复不改变原意 2. 不确定的地方保留原文不要臆造 3. 不要补全原图片中不存在的信息 4. 只输出修复后的文本不要输出任何解释或分析。 待修复文本 {ocr_text}这里几个要求不是套话。第二条“不确定的地方保留原文”是为了防止模型发明内容这个我吃过亏第三条是防止模型顺着语感“补全”其实图片里没有的信息第四条是为了便于程序解析结果直接取输出文本即可。翻译场景我通常会把修复和翻译合并成一步减少一次 API 往返你是一名图片文本翻译助手。下面是一段由光学字符识别系统输出的文本 可能含有错别字、多字、漏字。请先修复为通顺的原文再翻译成英文。 要求 1. 修复时保持原意不确定处保留原文字 2. 翻译结果要忠实修复后的文本 3. 只输出翻译结果不要解释。 待修复文本 {ocr_text}实测下来修复和翻译合并做语义一致性比分开两步更好因为模型在翻译时能看到它自己修复的上下文而不是在两个独立生成过程中产生信息损耗。当然也有代价如果最终译文有问题你很难判断是修复阶段出的错还是翻译阶段出的错所以上线初期建议还是先分开跑攒一批对比数据后再合。3.4 第四步 修复与翻译单段处理与批量并发拿到结构化 OCR 记录后我按文本块为单位构造 prompt。每个文本块通常对应一个自然段或一个文本框区域。这里要控制每次请求的文本量我的经验是单次控制在 300 到 500 字以内太长了模型修复质量下降而且超时风险高。批量处理时要注意并发控制。直接循环调用 API一个响应慢了会阻塞整个队列。我在项目里会开一个固定线程池并发数在 4 到 8 之间再配合重试机制——超时或服务端返回异常时退避重试三次。重试时要注意幂等同一段文本不要因为重试而重复提交导致重复扣费。如果用的是本地模型批量处理反而简单直接拼接批量请求利用 GPU 的并行能力。但本地模型单条质量和商用 API 的差距在错字密度高时体现得最明显。我测试过本地小尺寸模型修复效果只能到商用 API 的七八成适合大体量但对效果要求不极致的生产场景。3.5 第五步 置信度分流让 LLM 只干它该干的活把全部 OCR 文本都交给 LLM其实是一种浪费。高置信度文本是正确的送进去反而存在被 LLM“改错”的风险后面 4.4 会展开讲。我的做法是按置信度分三条路置信度范围处理策略复核要求大于 0.95直接使用不送 LLM无需复核0.70 - 0.95送 LLM 修复抽样人工复核小于 0.70送 LLM 修复 原图对照建议人工逐条确认这套分流规则的核心思想是让 LLM 专注处理“可疑文本”而不是所有文本。一来提升效率二来避免正确的文本被模型“画蛇添足”地改出问题。阈值 0.95 和 0.70 不是固定不变的业务对错误的容忍度不同可以上下浮动。在合同信息抽取场景我会把高置信度阈值调到 0.98宁多不少在菜单翻译这类阅读性场景0.9 就够了。人工复核在产品上尽量做成并排对照的形态左边原图片段、中间 OCR 文本、右边 LLM 修复结果。复核人只需要判断右侧文字是否与左侧原图一致操作成本和认知成本都最低。3.6 第六步 效果度量99.9% 是怎么测出来的说准确率之前必须先统一口径。行业里常见的口径有这么几种字符级准确率、词级准确率、整图级可读准确率。字符级指标很严格一个标点错了都算错整图级可读准确率更接近用户的真实感知定义是“标注者认为在不看原图的情况下修复后的文本能否完整表达原图信息”。我对外汇报 99.9% 时用的就是“整图级可读准确率”。具体测法是抽 300 张覆盖不同版式、不同清晰度的样片用这条流水线处理后交给两名标注员独立判断每张图是否“可读无碍”两人意见一致且判定为可读的图片占比就是最终指标。实际操作时会剔除极端模糊、完全无法辨认的样片只在“人工能看清原图文字”的样本集上统计。建议你在自己的项目里也先定好口径再定目标。如果你拿字符级指标去要求 99.9%那几乎是做不到的因为单个字识别错误在真实图片里不可避免。反过来如果只报整图级可读准确率也要把抽样方法和标注规则写清楚否则数字没有任何说服力。4. 跑批时踩过的坑和排查实录4.1 低分辨率长截图上下文断裂是最大的坑有一次接到个需求用户上传一张很长的网页截图宽度只有 640 像素左右。OCR 引擎按行识别后我按文本框把结果拆成了几段再分别送给 LLM 修复。结果修出来的文本质量很差很多句子语义不通。排查后发现原因在于长截图被 OCR 切成了多个不连续片段每个片段单独看上下文信息不足。比如“本项目将于下月”和“正式启动”被切到两个文本框LLM 单独修复前一句时会丢掉后一句的信息关键实体名就被臆补错了。解决办法是合并上下文先用坐标信息把行按阅读顺序排序再按自然段语义合并成更大的文本块块之间保留少量重叠再送给 LLM。同时把预处理阶段对低分辨率图做一次文本区域增强比如对文字 ROI 区域做指定倍数的线性放大后再识别置信度会明显提升。4.2 艺术字和手写体修复是伪命题海报标题这类艺术字笔画变形程度大OCR 识别出来的结果经常是完全发散的。比如一个“每”字在夸张字体下被识别成“侮”或者“悔”这种错误不是形近字级别的而是整个字形特征被大幅扭曲。这类样本我走了不少弯路才接受一个现实明确定位为“LLM 无法可靠修复”的类型。在流水线里对这类文本不做强制修复而是把置信度极低的部分标注为“需人工确认”直接渲染到人工复核队列里。与其让模型乱猜不如老老实实让用户花几秒钟看一眼原图。手写体稍微好一点但同样没有通用解法。大量手写样张、连笔字识别Python 层面的后处理改善有限最有效的方案永远是换一个更强的手写识别模型或者训练领域专用模型。LLM 校对在这里只能做非常有限的干预比如修正标点、合并断行指望它把手写错字全部改对不现实。4.3 表格跨行串列坐标重排比 LLM 硬修更有效表格类图片是单独的一类难缠样本。OCR 按识别框输出时经常会因为列宽太窄、文字溢出而把左右两列的片段按行混排。LLM 收到这一行文本时根本分不清哪些字属于哪一列再怎么修也恢复不了表格结构。后来我的处理思路变了不把表格的原始文本流按行直接给 LLM而是先用坐标做结构化重排。坐标信息里 column 的位置固定我会先定义几个列区间然后把每个文本框按中心点 x 坐标分桶配合 y 坐标排序拼成列级文本块。比如“商品名称”列单独拼成一段“金额”列单独拼成一段两段分别送 LLM 修复和翻译。这一步能把表格翻译的整体可用率提升一个台阶。结构化重排还有一种更彻底的玩法把表格区域识别出来后用文字坐标生成一个简化版的结构化 JSON例如{ columns: [商品名称, 数量, 金额], rows: [ [苹果, 2, 10.00], [香蕉, 3, 15.50] ] }让 LLM 直接基于 JSON 结构修复和翻译就不会发生跨列串字的问题。代价是实现成本高一些要做列线检测或者列中心聚类但一旦跑通对票据、账单类图片的翻译效果提升是立竿见影的。4.4 LLM 幻觉把对的改成错的这是我在所有坑里最想提醒你注意的一个。LLM 校对最大的风险不在于它修不好错误而在于它会把本已正确的文本“修复”成错误内容。原因是模型有很强的“顺滑倾向”碰到一个我们人类看起来很常见的搭配会不由自主地补全或改写。我遇到过最典型的案例是图片里清清楚楚写着“首付 30%”OCR 也正确识别了LLM 却把它“修复”成“首付 30% 定金”。因为在日常语料里“定金”和“首付”经常一起出现模型顺着语感加了词。这在合同类场景是致命失误金额后面跟的术语完全变了。我的对策组合很有效高置信度文本走旁路不进 LLMPrompt 里反复强调“不确定处保留原文不要补全”模型温度调到 0关闭随机性修复前后做 diff对有改动的片段标记为“待确认”在人工审核界面里提示。LLM 修出来的结果一定要让用户或复核人有能力看到“它改了什么”而不是只看到最终结果。我会把 OCR 原文本和修复后文本做对比用 diff 的方式列出来这样任何一次模型“手滑”都能被快速发现。4.5 批量任务的成本与排队别让校对环节拖垮整体吞吐OCR 本身很快一张图几百毫秒但 LLM 校对环节可能让单张延迟涨到几秒甚至十几秒。如果做实时翻译工具这个延迟是致命的。批量离线任务的成本问题同样突出我见过有人把全部 OCR 文本都丢给 LLM 翻译导致单张成本翻了 5 倍还不止。我的成本控制策略有三个只送低置信度片段进 LLM高置信度直接透传这是最大头的节省对重复图片做内容哈希缓存同一张图二次处理直接读缓存对长文本块做重叠切分避免一次请求塞太多 token同时防止单次超时。排队问题在调用商用 API 时尤其明显。某个账号并发一高响应时间就开始膨胀而且不同时间段的稳定性差异很大。我的做法是做一个任务队列在调用 LLM 之前统计一下当前队列长度如果积压超过预设阈值就把部分低优先级任务切到本地小模型处理保证整体吞吐不中断。5. 一些不会写进文档的经验5.1 先定义“对”再追求 99.9%每次听到有人直接开口要“99.9% 准确率”我都会先反问一句你的“准确”是怎么定义的是按字符算、按句子算、还是按用户的使用体验算这三个口径对同一套系统可能差出十几个百分点。我建议做这类项目时先找业务方一起定下“可接受质量”的准确定义。如果目标只是“用户看翻译结果能看懂”那整图级可读懂准确率就是核心指标如果目标是“发票金额识别错了要赔钱”那单个数值字段的字段级准确率才是关键甚至要按关键字段单独统计。定义清楚了后面所有调优才有明确方向。5.2 Prompt 迭代比换模型更见效遇到修复效果不佳时第一反应别是“换更大的模型”。我实测过在同样的模型下把 prompt 调对效果提升可能比增加模型参数量还明显。我的迭代方法是维护一个错误样本库跑完一批样片后把修复失败的 case 收集起来分成三类——OCR 输出质量太差导致 LLM 没有足够线索、LLM 修错、LLM 漏修。针对每一类在 prompt 里增加边界条件说明。比如我手里积累了一批“已/己/巳”混淆的 case就在 prompt 里加了一句“注意区分已、己、巳三个字结合动词时态判断”。这样针对性提示的效果比笼统地说“请仔细校对”好得多。5.3 让用户有最后一道纠错权技术做得再完善也总会有极少数图片绕过所有防线。这时候产品不能设计成“黑盒输出”要让用户能方便地看到原图、看到 OCR 文本、看到翻译结果并可以一键纠正。我甚至建议对低置信度结果默认展示“原文对照模式”用户瞄一眼就能确认翻译对不对。这不仅是用户体验问题也是在为你的评测集积累数据。用户每一次主动纠错都是一条高质量标注样本比你自己费劲找标注员高效多了。5.4 积累评测样本才是长期资产最后分享一个我最有体会的建议从第一天开始就保存每一张样片的完整处理链路记录——原图、预处理参数、OCR 原始文本、置信度、LLM 修复文本、翻译结果、人工修正结果。这套数据积累三个月后你就有了一份覆盖各种真实场景、各种错误类型的评测集。之后无论换 OCR 引擎、调 prompt、还是升级模型都用同一份评测集去评估所有改动的好坏一目了然。项目做久了你会发现模型会过时、API 会涨价、prompt 会调优但那份属于自己的评测集是永远增值的资产。我个人的体会是OCR 图片翻译这个方向真正的门槛不在某一个模型有多强而在你把“看得见的文字”和“读得懂的语义”之间的桥搭得有多顺。OCR 负责看见LLM 负责读懂人负责确认三条腿配合好了剩下的事情只是让这个流程跑得更快、更稳、更便宜。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
