1. 机器翻译到底在解决什么问题机器翻译Machine Translation简称 MT这个词听起来像是学术圈的专属名词但在实际工作里它离我们非常近跨语言电商的商品标题、出海应用的界面文案、跨境合同的初稿、多语种客服的自动回复背后大概率都跑着一套 MT 系统。它的任务说白了就一句话——把一种语言的文本转换成另一种语言里意思对等、表达自然的文本。输入端叫源语言source输出端叫目标语言target中间那套把符号序列映射到另一个符号序列的机制就是我们要聊的全部内容。我给不少团队做过技术咨询发现一个共性现象大家对 MT 的预期往往在两个极端之间摇摆。一端是把它当成万能翻译官觉得丢进去一段话就能直接对外发布另一端是被早期机翻的糟糕效果伤过认为它根本不可用。真实情况在中间——现代 MT 在通用领域、句式规范、术语重复度高的文本上已经能做到人工稍作润色即可发布的水平但在口语化、强文化背景、专业术语密集、需要严格格式对齐的场景里它依然需要工程手段去约束和兜底。所以判断一个 MT 方案好不好不能脱离场景谈分数。这篇文章面向三类人想搞明白 MT 原理和工程链路的开发者、需要把翻译能力集成进产品但不知从何下手的技术负责人、以及已经跑起来但效果卡在瓶颈上想找优化方向的从业者。我会从技术路线选型、数据准备、训练实操、评测体系、部署优化、故障排查这几个层面把标题背后真正该掌握的东西拆开讲。文中涉及的具体参数和配置一部分来自公开论文的经典设定一部分来自我和团队在项目里反复试出来的经验值我会明确区分哪些是通用实践哪些是我的偏好方便你按自己的条件调整。1.1 从词对词替换到意义重建难点究竟在哪很多人第一次接触 MT直觉是查词典不就行了。真动手做一遍就明白问题在哪。假设源句是 He kicked the bucket词典会老老实实给出他 踢 那个 桶而目标语言读者需要的是他去世了。这不是词汇量不够而是语言单位之间存在多对多、非连续、依赖上下文的映射关系。具体来说难点可以归成四层。第一层是词形与语序屈折语、黏着语、孤立语的形态变化差别巨大德语动词可能跑到句尾日语谓语在最后直接顺序替换必然乱套。第二层是多义消歧一个词在不同上下文里对应完全不同的译法bank是河岸还是机构run是跑还是经营人类靠语境秒判模型要靠上下文向量去学。第三层是结构重组定语从句、被动语态、量词搭配、敬语体系源语言和目标语言的组织习惯不同逐词对应会得到语法正确但读起来别扭的句子。第四层是语用与文化敬称、委婉语、习语、单位与日期格式、姓名顺序这些不是语法问题是约定问题。现代 MT 的核心思想是把这四层难题统一交给一个端到端的序列到序列映射去学而不是逐层写规则。模型不再显式地区分先做词形还原再调语序而是从海量双语对照里自己归纳出看到这样的源句目标端应该长什么样。这个转变的意义在于规则是人工枚举的覆盖有限而学习是从数据里长出来的只要数据够长尾也能覆盖。代价是——你对模型内部的可控性下降了出了问题往往只能从数据和约束条件上找原因这也是后面排查章节要重点讲的东西。1.2 三种典型场景对应三套完全不同的技术选型同样是要翻译不同业务的最优解差别很大。我把常见的需求分成三类配一个选型对照表。场景类型典型特征推荐方案关键考量通用内容翻译领域宽、句式规范、无强术语约束通用大模型直接调用或通用 NMT 服务成本与延迟长尾覆盖垂直领域高重复文本术语固定、句式模板化、量大在通用模型上做领域微调 术语表约束术语一致性、单位成本强格式/强约束文本字幕、合同、代码注释、界面文案定制 NMT 后处理规则 人工校审闭环长度对齐、占位符保护第一类最省事直接用现成能力工程重点放在调用链路的稳定性和成本控制上。第二类是大多数企业的真实战场产品名、型号、法规条款、医学名词翻错一个就是事故这时候通用模型的高频词优先策略反而会害你必须用领域语料把模型拉过来。第三类最容易被低估尤其是界面文案和字幕——界面文案有长度限制和变量占位符比如{count}、%s模型很可能把占位符翻译掉或者拆散字幕有单行字数上限和阅读速度要求翻译得再准一行放不下也是废的。我的建议是先用通用方案跑通闭环收集真实错误分布再决定要不要投入训练资源。很多团队一上来就想训自己的模型结果发现 80% 的问题出在标点、大小写、占位符和术语表缺失上这些用规则和后处理就能解决根本不需要动模型。1.3 一个几乎人人都踩过的认知误区有个误区值得单独拎出来说把评测分数当成上线标准。BLEU 高 2 分不代表用户体验好 2 分。我见过模型在通用测试集上分数漂亮上线后客服投诉集中在数字翻错和人名音译不统一而这两类问题在语料平均意义上权重极低分数根本反映不出来。正确的思路是建分层评测通用能力看自动指标业务关键项看专项测试集数字、日期、金额、型号、专有名词最终体验看人工抽检和用户反馈率。这三层缺一不可。后面第 5 章我会具体讲怎么搭这套东西。2. 技术路线的演进与选型逻辑理解演进史不是为了考试而是为了知道每一代方案为什么被淘汰、哪些思想被继承下来。这直接决定了你在资源有限时该往哪个方向投人。2.1 规则、统计、神经三代方案的取舍最早的一代是基于规则的翻译RBMT。语言学家把语法规则、词典、转换模板写成代码系统按规则拆句、转换、生成。它的优点非常明确可控、可解释、术语准确、低资源语言也能上手。缺点是维护成本随语言对数量呈爆炸式增长而且规则之间会打架——你修好了 A 句型B 句型又崩了。这套方案今天在极少数专业领域还有残余价值比如术语极其固定、句式高度受限的标准化文本但作为主力方案已经退场。第二代是基于统计的翻译SMT。它把翻译拆成翻译模型和语言模型两部分前者从双语语料里统计短语之间的对应概率后者从单语语料里学习目标语言像不像人话然后解码时在两者之间做权衡。这套思路的贡献是革命性的——它第一次让数据驱动成为主流也让用单语数据提升流畅度成为标准做法。但 SMT 的硬伤是以短语为基本单位长距离依赖处理不好短语切分边界一旦错了整句就散了而且特征工程极其繁琐。第三代是神经机器翻译NMT。它用一个端到端的神经网络直接把源序列映射成目标序列中间不需要显式的短语切分和对齐。这个转变带来的最直接好处是句子表征是连续的、全局的长距离依赖能被建模。NMT 在 2016 年前后迅速超越 SMT此后基本成为默认答案。我想强调的是三代方案不是简单的替代关系而是思想被继承。RBMT 的术语表 约束思想今天以术语干预、约束解码的形式活在 NMT 里SMT 的双语数据 单语数据思想今天以回译、去噪自编码的形式活在 NMT 里。你如果在做领域适配用的其实就是这些老思想的现代版本。2.2 Transformer 架构为什么成了默认答案NMT 早期用的是循环网络RNN/LSTM加注意力机制。这类结构的问题是必须按时间步串行计算长句子一长梯度传播路径就长训练慢且难并行。Transformer 用自注意力self-attention把序列里任意两个位置直接连起来路径长度变成常数级同时整个序列可以并行计算——这两点叠加让它在大数据和大算力条件下优势尽显。一个标准的翻译模型是编码器-解码器结构。编码器把源句的每个词变成一个上下文相关的向量解码器在生成每个目标词时通过注意力机制回看编码器的输出决定现在该重点关注源句的哪一部分。核心超参在经典设定里是这样的模型维度 512、注意力头数 8、编码器和解码器各 6 层、前馈层隐层 2048、dropout 0.1。这不是唯一正确的配置但它是一个被大量复现验证过的安全起点。训练侧的经典配方也值得记一下因为它解释了很多人训练不收敛的原因优化器用 Adamβ10.9、β20.98、ε1e-9其中 β2 调高是为了让方差大的稀疏梯度更稳定学习率不用固定值而是预热 反平方根衰减前 4000 步线性升温之后按步数的平方根倒数下降。预热的意义是避免训练初期参数剧烈抖动标签平滑label smoothing取 0.1缓解模型过度自信对翻译质量有稳定提升批次不按句子条数算而按词元总数算通常每批 2.5 万到 5 万词元这样长短句混在一起时梯度尺度更一致。提示如果你在复现时发现 loss 前期剧烈震荡先检查 warmup 是否真的生效再看批次是不是按句数而非词元数设置的。这两个是最常见的配置错误。2.3 通用大模型与传统 NMT 的分工近两年最实际的问题变成了既然通用大模型翻译效果已经不错还有必要自己训 NMT 吗我的判断是分场景看做一个对照。维度传统 NMT专用小模型通用大模型单次调用成本极低自建推理可控相对高按量计费延迟几十到几百毫秒可控通常更高受并发影响术语一致性可通过微调强约束需靠提示词和术语表稳定性一般长尾与口语依赖数据覆盖通常更强格式/占位符保持需专门训练或后处理也需专门约束容易漏可控性与可解释高可固定版本低版本可能变动我的实践经验是混合架构最划算高频、模板化、量大的内容走自建小模型把成本压下来低频、长尾、需要理解力的内容走通用大模型两条链路共用一个术语库和一套后处理规则保证对外表现一致。这样做的好处是成本可控同时不牺牲长尾体验。纯靠一种方案要么贵要么差。3. 数据决定翻译质量上限的那一环模型结构决定了你能达到的上限数据决定了你实际能摸到多高。我在项目里见过太多次换模型没效果洗数据立刻见效的情况。数据工程的投入产出比远高于调参。3.1 平行语料的来源与合规边界双语平行语料是训练的核心燃料常见来源有这么几类公开的多语语料集、企业内部的历史翻译资产人工译审过的双语文档最有价值、产品界面文案的多语版本、带双语字幕的内容。这里必须提醒一句语料的使用要严格遵守授权与合规要求来源不明的抓取数据不要用涉及个人信息的内容必须脱敏这一点在项目立项时就该确认清楚不要等训练完了才发现不能用。从质量排序看人工专业译审 人工翻译未审 产品官方多语文案 社区协作翻译 自动对齐挖掘。很多团队忽视了企业内部的历史资产其实那些经过译审的文档是性价比最高的数据因为它们天然贴合你的领域表达习惯——你的产品名怎么译、你的品牌调性怎么把握都藏在里面。单语数据同样重要。目标语言的单语语料可以用来做回译把目标语文本用反向模型翻成源语言构造伪平行句对和语言模型预训练对提升流畅度帮助很大。回译的一个实用细节是给回译生成的源端句子加噪声随机替换、删除、调换词序效果通常比干净回译更好因为这让模型学会了应对不完美的输入。3.2 清洗与对齐把脏数据挡在训练之前原始语料的脏超出很多人的想象。我一般按这个顺序过一遍语言识别过滤用轻量语言识别模型判断每条句子是不是声明的语言把混入的其他语言句子剔除。阈值不要设太死短句容易误判可以按长度分档设阈值。长度比过滤源句和目标句的词元数比例通常在 0.5 到 2.0 之间超出这个范围大概率是错对齐。这一步能干掉大量噪声。去重完全重复和近似重复都要处理。近似重复用句子级哈希或向量相似度重复数据会让模型过度拟合特定句式。异常字符与编码清洗统一 Unicode 形式处理全角半角、零宽字符、乱码、HTML 残留标签。质量打分用双语句向量模型算源句和目标句的语义相似度或者训练一个轻量的质量评估模型把明显不匹配的句对过滤掉。这一步对低质量挖掘语料尤其关键。人工抽检随机抽几百条人眼看这一步不能省。自动指标只能告诉你大概齐人眼才能发现整批数据都是机器翻译的机器翻译这种系统性问题。注意过滤比例要留痕。我习惯记录每一步过滤掉了多少条、占比多少。如果某一步砍掉了 30% 以上通常说明上游数据源有问题应该回去查采集环节而不是硬着头皮往下走。3.3 数据配比与课程式训练思路当你手上有多个来源的语料时配比就是一门手艺。通用语料量大但和你的领域不贴领域语料贴但量小。直接混合训练模型会被大量通用数据冲淡领域表现上不去。我常用的做法是温度采样式的加权给领域数据更高的采样权重让它在一个 epoch 里被重复看到更多次但不要简单复制文件那样会造成过拟合。通常领域数据权重设为通用数据的 2 到 5 倍具体看量级差距。如果领域数据只有几千句那更稳妥的路线是先在大规模通用语料上预训练再用领域数据做小学习率微调而不是一开始就混着训。另一个细节是课程式排序训练初期先用短句、干净句中后期逐步引入长句和带噪样本。这符合先学简单规则再学复杂例外的直觉实测在收敛速度和最终质量上都有小幅提升。不过这个技巧的收益没有数据清洗大属于锦上添花别把它当救命稻草。4. 从零训练一个可用模型的实操路径这一章讲落地。假设你的目标是训一个中英双向的领域模型手上有百万级句对单机多卡或小规模集群。下面是我会走的流程。4.1 环境与显存估算先把账算明白显存估算是很多人第一步就卡住的地方。训练时显存主要被三部分吃掉模型参数、梯度、优化器状态。用混合精度训练时大致可以按参数量 × 16 字节来粗算常驻部分——比如 1 亿参数的模型参数加梯度加 Adam 的两个动量大约 1.6 GB。真正的大头往往是激活值它和批次大小、序列长度成正比长句多的时候能翻好几倍。所以调参的顺序应该是先定模型规模再根据显存反推批次最后用梯度累积把有效批次补到目标值。举例单卡只能跑 4000 词元/批目标是 32000 词元/批那就设累积步数 8这样梯度更新的尺度和大批次一致只是耗时变长。这比硬撑大批次导致显存溢出要务实得多。其他环境层面的经验固定随机种子以便复现训练日志至少记录 loss、学习率、梯度范数、吞吐词元/秒每 N 步存一次检查点并保留最近几个我曾因为只存最新检查点在后期 loss 突然崩掉时无点可回白跑了两天。4.2 分词与词表被低估的关键决策分词器决定了模型看到的最小单位。子词切分BPE 或 Unigram是当前主流它能在词表大小和未登录词之间取得平衡。几个实操要点词表大小通常在 3 万到 5 万之间。太小会导致常用词被拆得很碎序列变长、计算变贵太大则低频子词学不充分且嵌入矩阵占显存。双语场景下我倾向于共享词表尤其是其中一方是低资源语言时共享能带来正迁移让两种语言在同一个语义空间里对齐。分词器的训练语料必须和实际数据分布一致。我踩过一次坑分词器用新闻语料训的实际数据是技术文档结果大量专业词被切成单字符碎片模型学得很吃力。正确做法是拿清洗后的真实语料可以混一点通用语料保证覆盖面来训分词器。数字和标点的处理要单独考虑。有些实现会把数字按位拆开好处是没见过的大数也能处理坏处是序列变长整体保留则相反。我的偏好是数字整体保留配合后处理的数字格式规范化因为翻译场景里数字的语义完整性比长度更重要。占位符保护要在分词前做。把{name}、%s、b这类标记替换成特殊占位符训练和推理都保持翻译完再还原。不做这一步模型有相当概率把标签翻译掉或者挪位置。4.3 训练过程与收敛判断配置层面除了前面提到的经典超参我再补充几条实战参数dropout 在数据量小时取 0.2 到 0.3数据量大时 0.1 就够梯度裁剪阈值设 1.0防止偶发的大梯度把参数带飞验证集每 1000 到 2000 步跑一次用验证 loss 加一个小规模 BLEU 双指标观察只看 loss 容易误判。判断是否该停验证 loss 连续若干次不再下降且验证集 BLEU 停滞就可以考虑停止或降低学习率。但要注意训练 loss 和翻译质量不是单调关系过度训练会导致模型在训练集上背句子表现为验证集分数先升后降。我通常会保留验证分数最高的那个检查点用于上线而不是最后一个。训练中常见的一个现象是训练初期输出全是高频词。这不是 bug是模型还没学到对齐关系时的保守策略。如果训练几万步还是这样那就要检查数据对齐是否有问题、学习率是否过大、分词是否把词切得太碎。4.4 微调与领域适配小数据也能出效果当你已经有一个通用模型想让它贴合自己的领域微调的性价比远高于从头训。具体做法是加载通用模型权重用领域数据以较小的学习率通常是原训练的十分之一到三十分之一继续训练同时混入一定比例的通用数据防止灾难性遗忘。这个混入比例很关键我一般从 1:4领域:通用开始试。另一种更轻的做法是术语表 约束解码完全不改模型在解码时对特定源词强制输出指定译文。实现方式是在解码打分时给目标词加偏置或者用有限状态约束限制候选集。这种方式适合术语数量不大几千条以内、变更频繁的场景维护成本比重新训练低得多。还有一种是检索增强建一个翻译记忆库遇到相似度高的源句时把对应的参考译文拼进提示或作为解码约束。这对重复度高的业务文本比如产品说明书的不同版本效果极好因为很多句子只改了几个数字。5. 评测别只看一个分数评测体系没搭好后面所有优化都是盲人摸象。我见过团队花了两个月调模型最后发现测试集里有一半是训练集泄漏的句子。5.1 BLEU 怎么算以及它为什么不够BLEU 的核心是 n-gram 精确率的几何平均再乘一个长度惩罚因子。公式大致是BLEU BP × exp( Σ w_n × log p_n ) BP min(1, exp(1 - r/c))其中 p_n 是 n-gram 精确率n 通常取 1 到 4权重各 0.25r 是参考译文长度c 是模型输出长度BP 用来惩罚过短的译文——因为短译文天然容易拿到高精确率。它的局限很明显只看表面词形匹配同义替换一律判错立刻和马上在 BLEU 眼里毫无关系对语序变化不敏感对多参考译文的覆盖依赖参考数量不同分词方式下分数不可比。所以我从不单独用 BLEU 做决策。5.2 一套分层可用的评测组合层级指标/方法用途频率自动指标BLEU、chrF、TER快速对比模型版本每次训练语义指标基于预训练模型的相似度打分弥补 BLEU 对同义替换的盲区每次训练专项测试集数字/日期/金额/型号/术语准确率抓业务致命错误每次发版人工评测充分性、流畅性分档打分判断真实可用性里程碑节点线上指标用户修改率、投诉率、采纳率最终验证持续chrF 基于字符级 n-gram对形态丰富的语言更友好中文场景下常比 BLEU 更稳。语义指标能抓到意思对了但用词不同的情况。专项测试集是我最看重的一环因为业务事故几乎都从这里来——我会专门构造几百条包含数字、单位、日期、专有名词、占位符的句子人工确认标准答案每次发版必跑准确率掉一个点都要查原因。人工评测的设计也有讲究。我通常用 1 到 5 分的充分性意思有没有丢和流畅性像不像人话双维度加一个是否有致命错误的布尔标记。评测员必须看源句不能只看译文——只看译文会觉得很多句子挺通顺实际意思已经偏了。样本量至少 200 条随机抽样且要覆盖不同文本类型。5.3 评测集构建最容易犯的三个错第一是训练集泄漏。构建评测集时一定要和训练数据做去重比对包括近似重复改了几个词的也算。有个简单的检查方法拿评测集跑一遍训练好的模型如果某些句子输出和参考译文完全一致八成是泄漏了。第二是参考译文质量不齐。多个译者翻的参考风格和术语可能不一致模型无论怎么翻都会得罪其中一份。我倾向于每个源句配一到两份高质量参考而不是凑数量。第三是领域不匹配。用新闻测试集评估客服翻译系统分数再高也没意义。评测集必须从真实业务分布里抽而且定期更新——业务在变测试集不变指标就会失真。6. 部署与推理优化模型训出来只是半成品能不能扛住线上流量、延迟能不能接受、成本能不能覆盖才是决定项目生死的东西。6.1 批处理、长度分桶与解码参数推理和训练不一样请求是零散到达的而 GPU 最怕一次只算一条。最基本的优化是动态批处理设一个很短的时间窗比如 10 到 50 毫秒把窗口内到达的请求攒成一批一起算显存允许按词元总数控制批量。紧接着是长度分桶把长度接近的句子放在一批里避免一个超长句把整批的填充长度拉满。这个优化对吞吐的提升往往比换更快的显卡还明显因为填充浪费是纯浪费。解码参数方面束搜索宽度beam size从 4 调到 8质量通常有些许提升但耗时接近翻倍。我的经验是 4 到 5 是性价比拐点除非是离线批量任务否则不建议超过 8。长度惩罚length penalty要按语言对调整有些语言对天然输出偏短需要正惩罚把长度拉回来否则会出现漏译的错觉。缓存的利用也很关键。自回归解码时已生成部分的历史状态可以缓存复用KV cache避免每生成一个词就重算全序列。这是标准做法但如果你的批处理实现里每条请求独立管理缓存显存碎片会很快耗尽资源需要做统一的显存池管理。6.2 量化与加速先测质量损失再上量化是降本的主要手段。把权重从 32 位浮点压到 16 位几乎无损且显存减半再压到 8 位整型显存再减半但翻译质量可能有可见下降尤其是低频词和长句。我的做法是先上 16 位观察延迟和显存是否满足如果还不够再做 8 位量化的对比评测用第 5 章那套分层评测跑一遍确认业务关键项没有退化才放量。注意量化后的质量损失不是均匀的。通用测试集可能只掉 0.5 分但数字和专有名词的准确率可能掉好几个点。所以量化评估一定要跑专项测试集不能只看总指标。其他加速手段包括算子融合、推理图编译、把小模型部署到更便宜的硬件上。有一条经验值得说不要过早优化。我见过团队花两周做深度优化最后发现瓶颈在业务层的一次多余序列化和网络往返上把那个改掉延迟直接降了一半。6.3 术语一致性与译文风格的工程化控制企业场景里翻得对不如翻得一致。同一个产品名文档里叫 A界面上叫 B客户就会认为是两个东西。控制手段有三层第一层是术语库前置。翻译前先做术语识别把命中的术语替换成占位符翻译完再填回标准译法。这种方式最硬命中率取决于术语识别的召回优点是绝不走样。第二层是约束解码。在生成时对术语对应的目标词加正向偏置让模型优先输出。比第一层灵活能处理词形变化但偶尔会为了满足约束牺牲句子流畅度。第三层是后处理校验。翻译完成后用规则检查术语是否出现、占位符数量是否一致、数字是否变化、括号是否配对。这一层是兜底成本低、收益高我建议任何翻译链路都加上。风格控制则更偏软约束。可以通过在训练数据里刻意控制风格比如只用简洁风格的译文或者在提示里给出风格示例。这里没有银弹效果取决于数据一致性。如果历史译文本身风格就混杂模型学出来的也会混杂这时候要先做数据治理而不是调模型。7. 常见问题与排查实录这一章是我最想写的部分因为前面讲的都是应该怎么做而实际项目里 80% 的时间花在为什么不对上。7.1 症状对照速查症状可能原因优先排查方向整句漏译或只输出半句长度惩罚过强、最大长度限制过小、束搜索提前终止解码参数、输入是否超长被截断重复输出同一片段解码陷入循环、训练数据含大量重复句加重复惩罚、清洗语料输出语言混杂训练数据语言标签不清、多语混训未加语言标记数据语言识别、加目标语言标识数字/日期被改写分词把数字拆散、训练数据数字格式不统一数字整体保留、后处理校验术语译法不统一无术语约束、语料本身不一致术语库、约束解码长句质量断崖式下降训练集长句稀少、位置编码外推不足补长句数据、切分策略输出过度意译/加戏训练数据含大量编译式译文、解码温度过高温度归零、数据质量治理占位符丢失或错位未做占位符保护前置替换 后处理校验7.2 三个真实排查过程细节做了脱敏案例一上线后漏译投诉集中爆发模型指标却正常。我们查了三天最后发现漏译集中在超过 200 词的段落上。原因是服务端为了控制延迟设了单次输入的最大词元数超长输入被静默截断模型老老实实翻译了前半段。这个问题在离线评测里完全暴露不出来因为测试集都是单句。修复方案是加输入长度检查超长自动按句切分再合并同时在响应里返回分段信息。教训是评测要用真实长度的输入不要只用单句。案例二某批术语突然全部译错。排查发现术语库更新后新术语的键值对里混进了全角空格匹配失败全部走了模型自由翻译。这类问题很典型——数据管道里的隐形字符。后来我们在术语加载环节加了强制规范化去空白、统一大小写、NFKC 归一化和加载后的抽样自检每次上线前跑一遍。案例三模型版本升级后流畅度提升但客户投诉变多。人工抽检发现新模型倾向意译把一些合同条款里的限定词给省了读起来更顺但法律含义变了。根因是新版本混入了较多编译类语料模型学会了改写。处理办法是把这部分语料降权并对合同类文本单独做一个保守解码配置——降低温度、加大长度惩罚、禁用过度改写。这个案例说明流畅度和忠实度在某些场景下是冲突的不能一概而论地追高分。7.3 上线后该盯哪些指标离线指标只能管到发版那一刻真正的质量在线上。我一般会埋这几类指标长度比异常率译文长度与源文长度的比值超出正常区间比如 0.6 到 1.8的比例突增通常意味着解码异常数字保留率源文中的数字在译文中出现的比例掉下来就是事故前兆占位符完整率翻译前后占位符集合是否一致这个必须做到 100%做不到就报警术语命中率术语库里出现的词译文用了标准译法的比例人工修改率如果有译后编辑环节用户对译文的修改幅度是最真实的质量信号比任何自动指标都可靠回译一致性抽样把译文回译成源语言与原文算相似度能抓到意思跑偏这类自动指标看不见的问题。这套监控搭起来之后大部分问题在用户投诉之前就能被发现。我印象最深的一次是数字保留率在某个时间点掉了 3 个点追下去发现是上游一个数据源开始用中文顿号分隔数字列表分词器把这个顿号处理掉了导致相邻数字被合并。如果没有这个指标这个问题可能要等客户发现。7.4 几条不太好写进文档的经验第一新模型上线一定要做灰度对比而且要看业务指标不只看翻译指标。我遇到过一次新版模型自动指标全面领先但用户修改率上升了因为新版把用户习惯的固定表达改掉了。用户要的是和以前一样不是更好。第二保留一个降级开关。线上翻译链路出问题时能一键切回上一个稳定版本或切到通用服务比事后紧急修 bug 重要得多。这个开关要在设计阶段就预留。第三别迷信大而全的评测集。一个 500 条、覆盖你真实业务、每条都人工确认过的专项集价值远高于一个 5 万条的公开测试集。前者能告诉你能不能上线后者只能告诉你大概什么水平。第四数据治理的收益是复利的。每次发现一类错误就把对应的数据和规则沉淀下来错了的句子进测试集错了的词进术语库错了的格式进后处理规则。跑上一年你的系统会越来越懂你的业务而模型可能一次都没重训过。第五对人机协作的预期要现实。我参与过的项目里纯自动发布只在内容容错率高的场景成立对外的正式文档、法律文本、医疗内容始终是机器初翻 人工译审的闭环。把 MT 定位成把人从 80% 的重复劳动里解放出来而不是取代人这个定位既符合现实也更容易在组织内推动落地。如果你正准备启动一个翻译相关的项目我个人的建议是从最小闭环开始先接一个可用能力把术语库、占位符保护、后处理校验、分层评测这四件事做扎实跑一两个月收集真实错误分布再决定要不要投入训练资源。这四件事做好很多团队的效果就已经够用了剩下的才是模型本身的活儿。