1. 起因菜单没翻译明白反而变成了一台“乱码生成器”1.1 用户反馈的怪象肉眼能读的内容译文全成了猜谜先说一个我真实做“图片翻译”Demo时遇到的场景。某个周末我把一个带拍照翻译能力的小工具发给几位朋友内测其中一个人拍了一张日料店的菜单。原图里的“炙烤三文鱼寿司”印得清清楚楚但我这工具给出的译文却是“烤鱼寿司”再加一行莫名其妙的字符。更离谱的是当图片里有红底白字、艺术字体、便宜打印机打出来的小票时译文常常连“人工智障”都算不上基本是在给用户表演“看图编故事”。复盘时问题其实不难定位图片翻译不是“看图说话”而是“先把图片变成文字再把文字变成另一种语言”。前者是 OCR后者是翻译模型。只要 OCR 这一环吐出来的文本是乱码翻译模型拿到的就不是“原句”而是一堆长得像原语言的噪音。很多做图片翻译的人第一个想到的是换个更贵的 OCR 引擎第二个想到的是换个更强的翻译模型。但实际上OCR 在复杂背景、低分辨率、异形字体下必然出错翻译模型又对纯噪音文本毫无抵抗力。真正能把两条断桥接起来的是中间那个看起来不太起眼的角色——LLM 校对员。1.2 为什么直接把 OCR 文本丢给翻译模型等于让模型吃夹生饭我见过不少项目流程看似很顺拍照 - OCR - 得到字符串 - 拼接成段落 - 丢给翻译模型。但问题就藏在“拼接”这一步。OCR 的输出并不是干净语料它的特征非常折磨人行尾可能没有标点词和词之间可能多出空格相近的字会被识别成另一个字表格里的数字和文字混在一起。更致命的是OCR 返回的内容往往还带置信度信息但很多接 OCR 的人完全忽略了这个字段把低置信度的识别结果和高置信度的结果一视同仁。翻译模型的训练数据几乎是干净文本它默认输入是“人写出来的句子”。一旦 OCR 把“己”识别成“已”把“末”识别成“未”把横线当作连接符翻译模型并不会像人一样停下来怀疑它会在损失函数允许的范围内给出一个“自洽却错误”的译文。就像你给一个人听一句话其中两个关键字被念错了他能猜出原意但你给一个人一张纸条上面有十个字被涂改笔画他大概率只能顺着错字编故事。翻译模型就是那个顺着错字编故事的人。所以后来我调整了思路不要求 OCR 一步到位不指望翻译模型有超能力而是把 LLM 放进流程里让它专门做“校对员”。这个动作才是图片翻译准确率从翻车走向可用的分水岭。下面我会把完整思路、提示词设计、评测方法和踩过的坑一次性说清楚。2. 把乱码拆开看OCR 不是读错而是读“碎”了2.1 形近字混淆和笔画粘连最典型也最难防的一类错误OCR 出现乱码绝不总是“整个字都认错了”。大多数时候它只是认错了局部笔画。中文字形信息密度高几个常见字形在低分辨率下几乎没有差别。比如“己、已、巳”三个字就差半开的程度“干”和“千”就差一横的长短“天”和“夭”、“未”和“末”更是考验人类的眼力。OCR 引擎本质上是一套视觉分类器它看的是像素模式不是语义。当字体非常规、笔画较粗、背景有纹理时分类器很容易在 top-1 上摇摆而我们通常只取 top-1 结果这个错误就顺理成章地流到了下游。我把这类错误归纳成下表项目里排查问题时可以直接对照。错误形态典型例子根因校对难度短横长横混淆王 - 玉、干 - 千图像分辨率不足、字体笔画粗细不均低语义可纠正半封闭结构混淆己 - 已、已 - 巳字符检测框边缘切割导致缺口丢失中需上下文多点少点鸟 - 乌、免 - 兔低对比区域丢点中需上下文左右偏旁倒置部 - 陪、邻 - 怜视觉模型对左右结构位置不敏感低通常可纠多字合并/拆字“朋友”读成“月月又”字符检测框漂移把一个词切成两个块高需要语言模型参与处理这类错误的思路不是靠更好的 OCR而是靠 LLM 的语言先验。一个足够大的语言模型见过“朋友”这个词的无数种写法当输入是“月月又”时它会更倾向认为这是 OCR 对“朋友”的误读而不是一个新造的汉字组合。2.2 标点、空格和分行信息丢失乱码不只是字错还是语境崩塌很多人只顾着看单字却忽略了 OCR 乱码里更隐蔽的杀手标点丢失、断行错误、空格错位。拍摄菜单时餐厅的排版是多栏的打印小票时文字大小不一拍书页时行距会被透视拉扁。OCR 为了适应版面经常把一行完整的话拆成两行半或把两个半行拼成一句。结果就是翻译模型拿到手的“段落”根本不是人类的自然段落。举一个很常见的例子原句是“本店招牌每天限量供应”OCR 可能分成两行输出“本店招牌每”和“天限量供应”。从单行去看每句话都缺胳膊少腿。如果这时候直接翻译模型看到是“本店招牌每”它会翻译成类似 every signboard 的荒谬句子。而 LLM 校对员要做的事不只是纠单字更要通过整段上下文把断裂的部分重新接好。校对 prompt 里我会专门告诉它“允许根据上下文调整断行但不要改变原有顺序和语义。”2.3 语言模型凭什么能“脑补”正确内容LLM 之所以能当校对员核心是它学过的语料里包含了大量正确的文本分布。给它的输入是一串带噪声的字它会计算在真实语言里“本店招牌每天限量供应”的概率远高于“本店招牌每”加“天限量供应”的概率。于是它把高概率序列作为修正结果输出。这个过程的本质是按语言先验做重排和纠错。用个通俗类比在嘈杂的饭馆里朋友说“明天一起爬香山”你只听清了“明天一起”和最后两个字你会自动脑补出“爬香山”因为这是符合语境的推测。LLM 做校对就是类似的推测只不过它脑补的粒度更细可以精确到一个字、一个标点。但它有个前提上下文不能太少。所以校对时不能一次性喂五个字要喂完整段落至少也要十几行让模型有足够的“证据”去猜测。3. 搭建一条“OCR→校对→翻译”流水线中间这步是灵魂3.1 整条链路的技术结构和数据流向我在项目里把链路拆成五个阶段图片预处理、OCR 识别、LLM 校对、翻译引擎、结果回填。预处理解决倾斜、反光、对比度问题OCR 输出带位置信息的文本块LLM 对照原始 OCR 文本进行纠错翻译引擎基于纠错后的文本翻译最后把译文按原坐标回填到图片上或者直接在界面上展示。这里最关键的是第四步和第三步之间不要直接共用同一段文字。很多人在工程上省懒事OCR 返回什么LLM 校对函数就拿什么来读读完了再调用翻译接口。这样做不是不行但会丢失一个特别有价值的信息每行的置信度。我通常会让 OCR 输出一个结构化 JSON包含四个字段行号、文本、置信度、检测框坐标。然后把行号和置信度一并交给 LLM让它在校对时特别关注低置信度的行。数据流向大致是这样图片 - 倾角矫正与对比度增强 - 文本检测 - 逐行识别 - 结构化结果结构化结果 - 合并为段落 - 喂给 LLM 校对模块 - 得到规范化的文本规范化文本 - 按原始行号切分 - 翻译引擎 - 译文按坐标回填3.2 校对 Prompt 的设计什么该管什么不该管必须写清楚LLM 校对模块能不能做好八成靠 prompt。我的第一版 prompt 写得太简单只说“请修正 OCR 错误”结果模型把原本正确的专有名词改了还把“NIKE”改成了“耐克”把“hello”改成了“哈罗”最后翻译出来一团糟。后来我把要求收敛成四条保持原语言不变不要翻译原文。只修正 OCR 识别错误不要润色文风。遇到不确定的内容保留原文并加标记。每行只输出修正结果不要解释。给一段我实际在用的提示词模板脱敏后。你是一名 OCR 校对员。我会给你一组从图片中识别出的文本它们可能包含形近字错误、 断行错误、标点缺失和多余空格。请根据上下文推测原始内容输出修正后的文本。 要求 1. 保持原语言不要翻译 2. 专有名词、品牌名、地名人名不要主动改写 3. 不确定的地方保留原字符并在两侧加“[?]”标记 4. 只输出修正后的内容不要解释过程。 待校对文本 {OCR 文本拼接段}加了“不确定就保留”这条之后效果立刻不一样了。模型不再自作主张而是把真正的难点留给后续翻译模块或人工复核乱改专有名词的问题基本消失。3.3 坐标回填和分段策略别让编排毁掉准头另一个容易被忽略的工程细节是分段。OCR 输出的行数可能非常多如果一股脑把几百行文本全喂给 LLM既容易超上下文窗口又容易出现“中间部分被忽略”的问题。我按版面块去分段而不是按行数硬截。比如菜单的“主菜”区域是一块“饮品”区域是一块每一块之间用空行隔开并告诉 LLM“空行表示自然段落”。翻译完之后的回填同样有讲究。译文长度通常和原文字数不对等中文译成英文时会变短英文译成中文时会变长如果直接按原始位置贴上去字会溢出图片外。我的做法是回填前先跑一次“文本框自适应”根据检测框宽度和字数估算字号超宽就自动折行或缩字号。这个不算核心原理但做不好会让整个功能显得不专业。很多人的图片翻译之所以效果差不是校对、翻译没做好而是最后一步排版把一切毁于一旦。4. 想谈 99.9%先建立一个不骗自己的评测集4.1 我搭建的评测集不能只在两张菜单上测效果网上很多人张口就是“准确率 99.9%”但真正的问题在于99.9% 是什么的准确率是 OCR 字符准确率还是最终译文的语义准确率是同一批固定图片的准确率还是随机抽样的真实场景准确率如果不提前定义这个数字没有任何参考价值。我给自己搭了一套评测集一共 120 张图按来源分成四类打印文档截图、手机翻拍菜单、发票小票、带水印的网页截图。每类 30 张每张图里都有对应的标准翻译文本作为标注。这样做的原因是只测干净的截图很容易但手机翻拍有透视形变小票有低对比度网页截图有水印干扰这些才是真实场景的复杂度来源。4.2 三种准确率口径字符级、行级、语义级测试集建好之后我把结果按三个维度分别统计。口径定义我实测的大致区间说明字符级译文中的字词与原译文标注完全相同的比例95% - 98%容易受标点、断行影响行级整行译文语义等同且无关键错误的比例90% - 95%要求更严格受专有名词影响大语义级用户能否准确理解译文要表达的含义98% - 99.9%干净场景这个口径最容易刷到漂亮数字你会发现标题里那个“99.9%”只有在“语义级 干净印刷体”这一特定条件下才成立。真实场景里混合手机翻拍、艺术字体、小票时语义级准确率会回落到 96% 左右。所以以后看到别人宣称“99.9%”第一反应不是羡慕而是问他用的是哪个口径、哪个测试集。4.3 实测结论LLM 校对能把准确率从不可用拉到可用我做过一次对照组实验一组直接用 OCR 文本 翻译模型另一组用 OCR 文本 LLM 校对 翻译模型。实验结果是第一组的语义级准确率只有 78%挑剔一点的用户在手机上根本没法用第二组在干净场景下达到 99% 以上在小票类图片上也有 95%。这说明 LLM 校对真正救的不是那些已经识别得很准的内容而是把“基本可用”拉到“可用”的关键一环。但这里必须说一个容易被忽略的点LLM 校对提升的是“文本规范性”不是“翻译质量”。如果你用的翻译模型本身很弱即使校对得再干净译文依然会很生硬。我试过一次把校对后的文本喂给一个轻量翻译接口准确率反而比不校对更低因为轻量模型对术语和语序的处理能力有限。后来我改用更强的翻译模型校对的收益才完全释放出来。这条经验值得记下来校对是必要条件不是充分条件。5. 过度纠正的翻车现场什么文本千万别让校对员乱改5.1 专有名词和品牌名LLM 最爱“好心办坏事”的地方我发现 LLM 校对有一个难以抑制的冲动把看起来像错别字的东西“修正”成常见词。最典型的例子是品牌名。某运动品牌包含一个非常规拼写的词LLM 不认识看到 OCR 结果里有一串类似拼写就自动“纠正”成它自己熟悉的单词。这在做菜单翻译时尤其致命因为菜品名称里本来就有大量音译词、方言词、特殊命名。我的应对办法是建一个“受保护词表”。在 prompt 里附上一句“以下词汇为本项目常见专有名词禁止改写”并把这些词列表传进去。另一个办法是只对低于置信度阈值的区域启用校对高置信度区域直接原样转发。这样即使 LLM 想乱改也没有机会接触正确的内容。5.2 多语言混排日文汉字、英文、数字三板斧多语言混排是目前最难处理的场景。日文菜单里大量出现汉字字形和中文字体不完全一致。OCR 可能把日文的“駅”识别成“驿”再把“营业时间”识别成繁体或者错体。LLM 校对时如果设定的“主语言”是中文它会把日文汉字全改成中文甚至把日文专有名词抹掉。我现在的做法是给校对模块传一个 language_hint 参数明确告诉它源语言是什么。例如“该批文本主要语言为zh-CN允许出现 ja/en 专有名词和数字”。同时我会在 prompt 里强调“全角半角差异不算错误保持原样”。对于数字、日期、时间我直接要求 LLM 不得修改只修复与数字相邻的字符错误。这样能有效减少“脑补语义”带来的误伤。5.3 化学式、代码片段和 ID 编号宁可让 OCR 裸奔也别让校对乱跑有些内容天然就不能被“语言模型”纠正。最典型的三种化学分子式、代码片段、订单编号。拿代码片段来说“ifname main:” 这一行如果被 OCR 识别成“if name ! main”LLM 很可能自作聪明地补成“if name main”因为它觉得这更符合 Python 语法。但补完之后代码的行为可能完全不同。处理这类内容我的策略是提前识别并绕过。通过正则或字段分类在进入校对模块之前把含大括号、分号、等号或连续数字的块直接标记为“非自然语言文本”直接走翻译原样通道。如果翻译模型对代码翻译无意义那就干脆只做“原样回填”。这个细节在财报、报表、学术截图场景下特别重要。宁可保留 OCR 的不完美也不要让校对员自作主张地创造语义。6. 工程化落地成本、延迟和置信度分级策略6.1 对低置信度区域做“分级校对”别让每张图都跑LLM最开始我把所有 OCR 文本都送进 LLM 校对准确率确实上来了但成本也上来了。项目跑到第 5 天我的账单就超出了预算。后来我加了一个逻辑置信度高于 0.97 的文本直接跳过校对置信度在 0.85 到 0.97 之间的交给 LLM 校对置信度低于 0.85 的内容除了校对还要额外加[recheck]标记方便人工介入。这一改动让 LLM 调用量减少了大约 60%而语义级准确率只下降了 0.8%。这笔账很划算。另一个优化是“按块去重”图片中重复出现的招牌、店名第一次校对完就缓存结果后续图片直接复用减少了大量重复调用。6.2 批量请求与上下文复用给“校对员”完整的证据再干活LLM 校对非常依赖上下文。如果我只是把孤零零的一行文本发给模型纠错效果会大打折扣。工程化时必须把同一版面块的多行文本拼成一段再发出去。我用两次批量调用完成一个任务第一次调用只读上下文识别断行和疑似错误第二次调用在前一次结果基础上只对标记为不确定的行做二次校对。两轮校对的好处是第一轮产生“可疑点”第二轮专注处理可疑点避免模型来回反复。这里有个重要细节不要让 LLM 自己生成行号。OCR 输出的结构化结果里有真实行号我会把行号当作不可变 ID 传给模型并要求它必须在每行输出前保留对应行号。虽然这会增加一点 token 开销但能彻底避免“校对完不知道哪段文字属于哪个检测框”的尴尬。6.3 什么时候别自己搭这套东西如果你只是偶尔翻译一两张截图完全没必要搭这么重的流水线。直接用普通翻译软件或端到端多模态大模型就够了。端到端大模型的优点是中文名翻译更自然理解长文本上下文的能力强缺点是不好控制位置信息对版面复杂、表格密集、需要精确回填的场景并不友好。我的判断标准是这个如果项目里需要“文字位置精确对应原图”那端到端多模态模型反而不如 OCR LLM 校对 翻译的流水线如果只需要“大致看懂意思”端到端模型更省事。两种方案并不冲突可以在系统里做路由。文档处理类走专业 OCR 流水线快速翻拍类走端到端模型综合效果最好。在这套流程跑起来之后我最大的体会是不要把 LLM 当成万能钥匙而要把它当成一个“有常识但手容易痒的实习生”。给它明确边界、给它必要的证据、最后再给它一把只能修错字的改刀它才能真正做好校对员这个角色。最后留一个小经验上线之前务必准备一个十张图的“烟囱测试集”每轮改完算法都先跑一遍对比前后准确率和调用成本。你肉眼看起来“好像更准了”的效果和测试集里的数字往往是两回事。