我接触多语言翻译评测这些年，越来越觉得这件事不像跑个BLEU分数那么简单。你面对的是几十种语言、不同脚本、不同语系，还有通用场景和垂直领域混在一起。评测的目标不是给模型排个名就结束，它要回答几个很实际的问题：模型在哪些语言上真的能用，在哪些场景下会翻车，错误是来自语言覆盖不足、数据质量差，还是评测方法本身有偏差。我通常会把评测边界先划清楚，比如只评句子级还是也看文档级，只看通用新闻还是也覆盖医疗、法律这些领域。边界不清楚，后面选数据和指标都会乱。
我见过一些团队一上来就堆数据集，结果评测结果没法解释。核心问题其实就三个：评什么、怎么评、评给谁看。评什么决定语言和场景覆盖，怎么评决定自动指标和人工标注的配比，评给谁看决定报告里要不要放延迟、成本这些部署指标。我自己的习惯是先写一页评测目标说明，把不评什么也写进去。这样做看起来慢，后面复现和沟通会省很多事。
1.1 多语言翻译模型评测的目标、边界与核心问题
我做评测方案时，会先把目标拆成研究目标和产品目标。研究目标关心模型能力边界，比如跨语言迁移好不好、低资源语言有没有退化；产品目标关心用户能不能直接使用，比如术语一致性、格式保留、响应延迟。两类目标混在一起，评测结论很容易被误读。我一般会把边界写成清单：语言列表、领域列表、输入长度、是否允许外部词典、是否评多模态输入。清单越具体，后面选基准越有依据。
核心问题里，语言公平性是我特别在意的一个。高资源语言分数高，不代表模型在多语言场景下真的均衡。我遇到过英语到德语很稳，换到斯瓦希里语或僧伽罗语就出现大量漏译。评测目标里如果不写清楚语言权重，最后榜单会被高资源语言主导。另一个核心问题是评测污染，公开基准被模型训练见过以后，分数会虚高。我会在目标阶段就要求记录数据来源和发布时间，给后续污染检查留线索。
1.2 语言覆盖、语系差异与场景分类：通用翻译、领域翻译、低资源语言与多模态翻译
语言覆盖不能只看数量。我选语言时会看语系分布、脚本差异和形态复杂度。印欧语系内部差异小，模型表现往往比较接近；闪含语系、尼日尔-刚果语系、汉藏语系里的语言差异就大得多。脚本也是个大问题，拉丁字母、阿拉伯字母、天城文、西里尔字母混在一起，分词和子词切分策略会影响评测结果。我做多语言评测时会尽量让语言列表覆盖不同语系和脚本，不然结论会偏。
场景分类我会分成通用翻译、领域翻译、低资源语言和多模态翻译四块。通用翻译看新闻、网页、日常对话，领域翻译看医疗、法律、金融这些术语密集的场景，低资源语言看数据稀缺条件下的可用性，多模态翻译看图像、语音和文本混合输入。我印象很深的一次是同一个模型在通用新闻上表现不错，换到医疗问诊对话就出现术语错译和语气不当。场景不分开评，用户看到的平均分没有指导意义。
低资源语言评测最容易被做表面功夫。有些基准里低资源语言样本很少，评测结果波动大，我一般会看每个语言的有效样本量和置信区间。多模态翻译的评测更复杂，图像描述翻译、语音翻译、视频字幕翻译，评价维度不只是文本相似度，还要看时间对齐、视觉 grounding 和文化适配。我会把多模态评测单独放一块，不和纯文本分数混在一起比较。
1.3 评测生命周期设计：数据构建、基线选择、实验复现与结果发布
评测生命周期我习惯从数据构建开始。数据构建不是随便找一批平行语料，要看来源版权、领域分布、句子长度、对齐质量。我做过一次内部评测，数据里混进了大量模板句，模型分数很高，人工一看全是重复表达。后来我们加了去重和多样性检查，分数才回归正常。数据构建阶段还要留出开发集和测试集，测试集尽量晚公开，减少污染风险。
基线选择是很多评测容易被忽略的环节。我会选至少三类基线：强商业系统、开源多语言模型、任务专用微调模型。基线太弱，评测结论没有说服力；基线太强但不可复现，别人没法核对。实验复现我会要求记录随机种子、解码参数、提示模板和后处理规则。结果发布时，我会把分数、置信区间、失败案例和限制条件放在一起。只发一张榜单，读者很容易过度解读。
结果发布这块，我越来越看重可复现性。评测脚本、数据版本、模型调用时间都要写清楚。有些模型是API服务，版本会变，今天跑的分明天可能不一样。我会在报告里标注评测日期和接口版本。内部评测还会加一栏“已知限制”，比如某些语言样本太少、某些领域没有覆盖。这样读者知道分数能用到什么程度，不会拿一个通用分去推断所有场景。
1.4 多语言翻译模型评测基准数据集有哪些：通用基准、领域基准、低资源与方言基准、跨语言检索与多模态基准
通用基准里，WMT系列是我经常用的，新闻领域多语言覆盖比较广，评测组织也相对成熟。FLORES-200在低资源语言覆盖上很有价值，句子级平行数据适合做多语言横向比较。IWSLT偏向口语和会议场景，TED Talks数据更接近演讲字幕。OPUS是个语料集合，里面质量参差不齐，我会挑子集用。Tatoeba适合做日常短句评测，句子短、口语化，和新闻评测结果经常不一样。
领域基准我一般按业务场景选。医疗领域会看WMT biomedical相关的评测集，法律和金融领域更多用内部构建的数据，公开基准相对少。领域评测的关键是术语表和风格约束，通用基准很难覆盖这些。我做过一次法律合同翻译评测，模型在通用句子上很流畅，到了条款编号、定义引用和固定表达就出现不一致。领域基准要能暴露这类问题，不然评测价值有限。
低资源与方言基准这块，AmericasNLP、Masakhane相关评测集给了我很多参考，它们关注非洲和美洲原住民语言。方言评测更麻烦，同一个语言的不同方言在词汇和拼写上差异很大，Vardial这类评测活动会关注方言变体。跨语言检索基准像MIRACL、Mr. TyDi，可以看翻译模型在检索任务里的跨语言迁移能力。多模态基准里Multi30K比较常用，图像描述翻译能看视觉信息和文本翻译的结合。我选这些基准时会看任务和我的场景是否接近，不会因为名字里有“多语言”就直接拿来用。
1.5 基准数据集的选取与构建原则：代表性、质量、版权、污染控制与动态更新
选基准数据集，我第一看代表性。语言覆盖、领域分布、句子长度、文本类型都要和评测目标匹配。一个基准如果只有新闻句子，拿去评客服对话翻译就不合适。第二看质量，平行语料的对齐错误、翻译错误、标点混乱都会影响分数。我会抽样做人工检查，尤其看低资源语言部分。质量不过关的基准，模型分数再高也没有解释力。
版权和污染控制是我近两年特别重视的。公开数据集要确认许可证，商业评测要确认使用范围。污染控制方面，我会查基准的发布时间和模型训练数据截止时间，必要时做n-gram重叠检查。动态更新也很重要，静态基准用久了会被过度优化。我会保留一个内部动态测试集，定期换样本，观察模型分数有没有异常上升。基准不是越旧越稳，也不是越新越好，关键是版本可追踪。
构建内部基准时，我会把代表性、质量、版权、污染控制写成检查表。代表性看语言和场景覆盖，质量看抽样错误率，版权看许可证和数据来源，污染控制看训练数据隔离和重叠检测。动态更新不是每个月换一套题，而是保持测试集有新鲜样本，同时保留固定子集做纵向比较。我一般会维护一个“稳定集”和一个“挑战集”，稳定集看趋势，挑战集看边界。
1.6 数据集与评测任务映射：从句子级翻译到文档级、术语级与会话级评测
句子级翻译评测最容易做，也最容易高估模型能力。一句一句评，模型可以靠局部上下文猜对，到了段落和文档就不一定。我会把句子级评测当作基础能力检查，不把它当成最终结论。文档级评测要看指代、省略、篇章衔接和格式保留。我遇到过模型单句翻得不错，整篇文档里的人称和时态前后不一致。文档级评测需要更长的上下文和更细的标注规范。
术语级评测和会话级评测更贴近真实业务。术语级评测看术语表命中率、大小写、缩写和固定译法，法律、医疗、产品手册特别需要。会话级评测看多轮对话里的上下文保持、语气一致和省略补全。我做过客服对话翻译评测，单轮看没问题，多轮里用户改口、指代前文，模型就容易丢信息。任务映射要写清楚：哪个数据集评句子级，哪个评文档级，哪个评术语和会话。映射不清楚，分数就没法横向比较。
我现在的做法是给每个数据集打标签，标明任务层级、语言对、领域和输入长度。句子级数据集评基础翻译质量，文档级数据集评篇章能力，术语级数据集评约束满足，会话级数据集评交互场景。同一个模型可以在不同任务上得到不同结论，这很正常。评测报告里我会分开呈现，不做一个大平均分。读者能看到模型强在哪、弱在哪，选择时心里有数。
我评多语言模型这些年，越来越觉得指标选择比数据集选择还让人头疼。数据集选错了，换一套重跑就行；指标选错了，结论会从根上偏掉。BLEU分数高不代表用户能用，人工评分高不代表部署成本可接受。我经常跟团队说，指标不是裁判，它更像一副眼镜，你戴什么眼镜，就看到什么样的模型能力。多语言场景下这副眼镜还得能适配不同脚本、不同语系、不同资源条件，不然看到的东西是扭曲的。
我见过不少评测报告，开头列一堆指标，结尾给一个加权总分，中间没有解释为什么选这些指标、权重怎么来的。读者只能看到一个数字，没法判断这个数字对自己的场景有没有参考价值。我的习惯是把指标分成三层：自动指标看规模覆盖，人工判断看质量底线，业务指标看落地可行性。三层指标各司其职，混在一起容易互相掩盖问题。
2.1 自动评测指标：BLEU、chrF、TER、COMET、BLEURT、MetricX 等多语言适用性比较
BLEU是我最早接触的自动指标，基于n-gram精确率，计算快、可比性强。它在英语到德语、法语这些拉丁字母语言上还算稳定，换到中文、日文、泰语就麻烦。分词方式一变，分数跟着变。阿拉伯语和土耳其语形态丰富，一个词根能衍生出很多表面形式，n-gram匹配会低估语义正确的译文。我用BLEU时会固定分词工具和大小写处理规则，跨语言比较时特别小心，不会拿中文的BLEU和英文的BLEU直接比高低。
chrF是我在多语言评测里更愿意用的字符级指标。它看字符n-gram的精确率和召回率，对形态变化和分词差异没那么敏感。低资源语言里拼写变体多，chrF的表现通常比BLEU稳。我做过一次僧伽罗语评测，BLEU分数低得离谱，chrF却能反映出一部分译文其实可读。chrF不是万能的，它对语序和长距离依赖不敏感，句子结构错了也可能给不低的分。我一般把chrF当作辅助指标，和BLEU一起看。
TER基于编辑距离，衡量译文到参考译文需要多少修改操作。它对语序调整和增删词比较敏感，适合看译后编辑工作量。多语言场景下TER有个问题，不同语言的编辑成本不一样。黏着语的词形变化多，一个后缀错误可能被算成多次编辑；分析语里同样的语义错误可能只算一次。我用TER时会按语言分别看分布，不做一个跨语言平均。COMET、BLEURT、MetricX这类神经指标，基于预训练模型做语义相似度打分，和人工判断的相关性通常更好。它们对同义表达和语序变化更宽容，多语言覆盖也比传统指标广。
神经指标的问题在于训练数据偏差。COMET系列在多语言上表现不错，低资源语言和特殊领域还是可能失准。MetricX在WMT评测里经常出现，对不同语言对的敏感度不一样。BLEURT依赖预训练模型的质量，某些脚本覆盖不足时分数波动大。我的做法是自动指标至少选两个，一个传统指标加一个神经指标，再看它们和人工评分的一致性。只报一个指标，尤其只报BLEU，我现在基本不接受。
2.2 人工评测方法：直接评估、充分性与流畅性评价、MQM 错误标注与多语言标注规范
直接评估是我常用的人工方法，标注员看译文直接打一个整体分，通常用1到5分或1到100分的量表。它快，适合大规模抽样。直接评估的毛病是标注员对“整体质量”的理解不一致，有人看重流畅，有人看重忠实。多语言场景下这个问题更明显，不同语言社区的翻译规范不一样。我会给标注员一份简短的评分指南，明确说清楚这次评测更看重哪一面，是信息完整还是表达自然。
充分性和流畅性分开评，是我早期做评测时的标准做法。充分性看译文有没有保留原文信息，流畅性看目标语言是否自然。分开评的好处是能定位问题，是漏译还是表达别扭。坏处是两项分数可能冲突，充分性高但流畅性低，或者反过来。MQM错误标注更细，标注员按错误类型和严重程度标，比如术语错误、漏译、语法错误、格式问题。MQM的多语言标注规范要做得扎实，标注手册里得把每种错误类型举例子，最好用目标语言举例。标注员必须是母语者或接近母语水平，同一语言对至少两人标注，算一致性。
人工评测最大的约束是成本。全量标注不现实，我一般做分层抽样，按语言、领域、句长分层，低资源语言适当多抽一些。标注一致性用Krippendorff's alpha或Cohen's kappa看，低于阈值就回炉培训。我见过标注员把“可接受但不够地道”和“明显错误”混在一起，后来把评分锚点写得更具体，一致性才上来。多语言人工评测还要注意标注界面，阿拉伯语从右往左排版、天城文渲染、泰语断词，界面处理不好，标注员看错行，分数就废了。
2.3 基于大语言模型的评测方法：参考译文评测、无参考评测、提示设计与偏差校准
用大语言模型当评委，这两年越来越普遍。我试过两种方式：给参考译文让模型对比打分，或者不给参考直接评质量。参考译文评测适合有高质量平行数据的场景，模型判断译文和参考的语义接近程度。无参考评测更灵活，模型直接看原文和译文，判断忠实度和流畅度。多语言场景下，大语言模型对高资源语言的判断相对可靠，低资源语言就差一些，尤其是训练数据里覆盖少的语言。
提示设计对结果影响很大。我做过一个对比，同一个模型，提示里把评分标准写细一点，和只给一句“请打分”，分数分布能差出不少。评分量表用1到5还是1到100，用整数还是允许小数，都会影响稳定性。语言顺序偏差也常见，原文和译文谁放在前面，模型可能给出不同判断。我的做法是交换顺序跑两遍，取平均或看差异。长度偏差也要控制，长译文不一定更好，模型有时候偏爱更长的输出。
偏差校准我一般用三个办法。多评委投票，用不同模型或同一模型不同提示各评一遍，看一致性。位置交换，原文译文顺序对调，减少顺序偏好。和人工评分做对齐，拿一小批人工标注数据校准模型评分，拟合一个映射或者至少看相关性。低资源语言上，大语言模型评委的可靠性我会打问号，宁可多花点钱做人工抽查。模型评委适合做大规模初筛，不适合做最终裁决。
2.4 多语言特有问题评测：语言公平性、跨语言迁移、形态与脚本差异、文化适配与本地化质量
语言公平性是我做多语言评测时最看重的维度之一。我一般会按语言分别报分，再看语言间分数的均值和方差。高资源语言分数高、低资源语言分数低，这个差距本身就是评测结论。有些模型在英语到德语上接近商用水平，换到豪萨语或缅甸语就大量漏译。公平性评测不能只看平均分，平均分会被高资源语言拉高。我会画语言维度的分数分布图，标出哪些语言明显掉队。
跨语言迁移评测看模型能不能把高资源语言上学到的能力带到低资源语言。我常用的做法是选一组语言对，比较高资源直接训练、低资源零样本、低资源少样本几种设置。形态和脚本差异会影响评测指标本身，黏着语、屈折语、孤立语的处理方式不同，拉丁字母、阿拉伯字母、天城文、汉字混在一起，分词和子词切分策略要分别调。我会在报告里写清楚每种语言用的预处理方式，不然分数没法复现。
文化适配和本地化质量容易被指标忽略。翻译不只是词对词转换，敬语体系、日期格式、货币单位、颜色象征、宗教文化指代，都可能影响用户接受度。我做过一次阿拉伯语产品页面翻译评测，模型语法没问题，敬语层级用错了，目标用户一看就觉得不专业。本地化质量评测需要母语者参与，最好有当地文化背景。我会把文化适配单独列一个评分项，不和流畅性混在一起。
2.5 鲁棒性与泛化评测：噪声输入、领域漂移、低资源语言、代码混合与长文档翻译
鲁棒性评测我一般会自己构造压力测试集。噪声输入包括拼写错误、大小写混乱、标点缺失、社交媒体缩写、表情符号。真实用户输入很少像新闻语料那么干净。我做过一次客服场景评测，用户把“退款”打成“退宽”，模型直接翻错。噪声测试要看模型是 gracefully degrade 还是彻底崩掉。领域漂移评测看模型从通用新闻切到医疗、法律、金融时表现怎么变。我会选同一模型在通用集和领域集上对比，掉分幅度比绝对分数更有信息量。
低资源语言和代码混合是鲁棒性评测里的硬骨头。低资源语言样本少，评测结果波动大，我会看置信区间，样本量太小的语言不出单独结论。代码混合指一句话里混多种语言，比如中英混写、西班牙语和英语交替。多语言社区里这种现象很常见，模型处理不好就漏译或乱译。长文档翻译评测看篇章一致性、指代消解、术语统一。我遇到过模型单句翻得不错，整篇文档里同一个人名有三种译法。长文档评测要设计段落级和文档级指标，不能只靠句子级平均。
2.6 系统级与部署级指标：延迟、吞吐、成本、稳定性与人机协同效率
研究型评测经常只看翻译质量，产品型评测必须看系统指标。延迟我分首字延迟和整句延迟，交互式场景首字延迟很关键，用户等三秒和等三百毫秒体验完全不一样。吞吐看每秒能处理多少请求或多少字符，批量文档翻译和实时对话翻译对吞吐的要求差很远。成本按token、按字符或按调用次数算，多语言模型对不同语言的计费方式可能不同，低资源语言有时候反而更贵。
稳定性看API错误率、超时率、版本漂移。商业模型接口会更新，今天跑的分数下个月可能变。我会在评测报告里记录调用日期和接口版本，重要结论至少跑两次不同时间点。人机协同效率是我最近加进来的指标，看译后编辑时间、建议接受率、人工修改比例。一个模型自动指标稍低但译后编辑更省力，产品团队可能更愿意用。部署级指标要和业务场景绑定，不看场景只比延迟数字没有意义。
2.7 指标组合与权重设计：自动指标、人工判断与业务指标的协同使用
指标组合不是把分数加权平均就完事。我一般用分层评分卡：自动指标做大规模初筛，人工判断做质量校准，业务指标做最终决策。权重按场景调，研究型评测可以偏自动指标和人工判断，产品型评测要给延迟、成本、稳定性留足权重。低资源语言评测里，人工判断的权重应该更高，自动指标在那些语言上可靠性有限。
我还会设门槛指标，比如术语准确率低于某个值，总分再高也不推荐上线。门槛指标能防止平均分掩盖致命问题。指标冲突很常见，自动指标高但人工评分低，或者质量好但成本太高。遇到冲突我不强行合成一个总分，而是分开呈现，让读者自己判断。评测报告里我会写清楚每个指标的用途、权重和局限性。指标组合的目的是帮助决策，不是制造一个看起来很精确的数字。
说到底，多语言翻译模型评测的指标选择，反映的是评测者认为什么算“好”。我认为好翻译不只是词面相似，还要在目标语言里自然、在场景里可用、在成本上可持续。自动指标帮我看到规模上的模式，人工判断帮我守住质量底线，业务指标帮我把评测拉回真实世界。三样缺一不可，权重可以变，透明度不能丢。
指标和方法定下来之后，真正折磨人的是落地执行。我做过不少评测项目，回头看不成功的那些，问题很少出在指标公式上，多半是方案没设计清楚、实验过程没管住变量、结果出来了不会拆。评测这件事，做对一次容易，做对十次、让别人也能做对，得靠流程和规范撑着。这一章我想聊聊实操里的坑和心得。
3.1 评测方案设计：研究型评测、产品型评测与竞赛型评测的差异
我参与过三类评测，感受完全不一样。研究型评测追求的是把模型能力边界摸清楚，愿意花时间去测极端条件，比如零样本低资源语言、超长文档、代码混合输入。这类评测允许失败，失败本身就有信息量。产品型评测的目标不一样，它要回答的是“这个模型能不能上线、上了之后用户会不会骂”。产品评测里我会把延迟、成本、错误类型分布放在和翻译质量同等的位置看。
竞赛型评测又是另一套逻辑。竞赛有固定数据集、固定评分脚本、固定提交窗口，排名压力大，参赛队伍会针对测试集做优化。我做过一次竞赛的评测分析，前几名的分数差距很小，落到真实场景里表现未必分得出高低。竞赛型评测的价值在于推动方法创新和可复现对比，它不太适合直接拿来做选型决策。我会把竞赛榜单当参考，不会当答案。
选评测方案之前，我一般先问一句：这次评测要回答什么问题。答案不同，数据抽样、指标权重、报告写法全都不一样。拿研究型评测的结论去指导产品决策，或者拿产品型评测的分数去发论文，都会拧巴。我见过团队拿着WMT榜单排名去说服业务方采购，业务方上线后发现延迟扛不住，这就是方案和目标错位。
3.2 实验实施流程：数据准备、模型调用、评分计算、统计显著性与不确定性分析
数据准备是整个流程里最容易被低估的环节。清洗、去重、长度过滤、语言识别、平行句对齐，每一步都会影响最终分数。我有一次偷懒没做去重，测试集里混进了训练集的句子，模型分数虚高了好几个点，后来查了两天才定位到。数据分层也得提前设计好，按语言、领域、句长、资源等级分层抽样，后面做错误分析才有抓手。
模型调用要留痕。调用日期、接口版本、温度参数、提示模板、最大输出长度，这些我都要求写进实验日志。商业模型接口会静默更新，三个月后想复现同一个结果，没有日志就只能靠猜。评分计算我倾向于用固定版本的脚本，脚本改动要做版本记录。有一次同事升级了分词库，同样的译文分数变了两个点，整个对比实验白跑。
统计显著性分析在多语言评测里特别重要。低资源语言测试集往往只有几百句，点估计的波动区间很宽。我一般用bootstrap重采样算置信区间，样本量太小的语言不出单独排名。不确定性分析做扎实了，报告里就不会出现“豪萨语上模型A比模型B好0.3分”这种没意义的结论。评委看报告时我也会主动标注哪些差异在统计上站得住，哪些只是噪声。
3.3 结果解读与错误分析：语言维度、错误类型维度与场景维度的诊断方法
拿到一堆分数，第一反应不能是看总分排名。我会先把分数按语言拆开，看分布形状。高资源语言和低资源语言的差距，往往比模型之间的差距更有信息量。有一次评测，两个模型总分只差0.5，拆开看发现模型A在十个高资源语言上领先，模型B在二十个低资源语言上反超，总分把结构完全盖住了。语言维度的拆解还能看出模型的语言偏科，是拉丁语系强还是亚洲语言强，是形态丰富的语言吃亏还是脚本特殊的语言吃亏。
错误类型维度我一般用MQM标注结果来拆。漏译、过度翻译、术语错误、语法错误、格式问题、文化适配问题，各占多少比例，不同类型在不同语言上的分布不一样。中文到英文的评测里，量词和冠词错误很常见；阿拉伯语到英语的评测里，敬语层级和宗教文化指代容易出问题。我会把错误类型做成矩阵，行是语言对，列是错误类型，一眼能看出模型的结构性弱点。
场景维度的诊断容易被忽略。同一个模型在新闻、医疗、法律、客服、社交媒体上的表现可能差很远。我习惯把通用测试集和场景测试集分开报，掉分幅度比绝对分数更能说明问题。有次产品团队问为什么模型在客服场景里表现差，拆开看是用户口语化输入和表情符号处理不好，这类问题在新闻语料上根本测不出来。错误分析做完要形成闭环，把发现的问题反馈到数据补充、提示优化或者后处理规则里。
3.4 榜单、可复现性与评测透明度：开源数据、评测脚本、模型卡与评测报告规范
榜单的价值是横向对比，可复现性才是地基。我见过太多排行榜，分数很漂亮，复现不出来。评测透明度我一般看四样东西：测试数据能不能拿到、评分脚本是不是公开、模型卡写没写清楚训练数据和限制、评测报告有没有说明抽样和统计方法。四样缺一样，这个榜的参考价值就得打折。有些商业榜单出于版权考虑不公开数据，我可以理解，至少应该公开抽样协议和评分代码。
我复现过一次公开榜单的前几名，用他们公开的脚本跑，分数差了将近两个点。追查下去发现是数据预处理阶段的大小写处理和标点归一化不一样。这种细节不写进报告，复现就是碰运气。后来我自己写评测报告，会把配置文件、随机种子、预处理脚本全部作为附件放出来，读者愿意复现就自己跑一遍。评测报告的规范还应该包括局限性说明，哪些语言没覆盖、哪些场景没测、哪些指标不适用，这些写清楚比多报两个分数更有价值。
模型卡这件事，我觉得行业里做得还不够。很多模型只写支持多少种语言，不写每种语言的训练数据量、评测数据来源、已知弱点。多语言翻译模型尤其需要写清楚低资源语言上的表现边界，不然用户容易踩坑。我现在看模型卡，先翻到局限性那一节，那一节写得实在的模型，我才愿意花时间深入评。
3.5 多语言翻译模型评测的主要挑战：数据污染、低资源覆盖不足、指标偏差与人工成本
数据污染是头号麻烦。互联网语料里测试集和训练集高度重叠，模型在榜单上分数高，落到新数据上掉一大截。多语言场景下污染更隐蔽，低资源语言的公开数据本来就少，训练集里混进测试集句子的概率更大。我现在的做法是尽量用时间切分或者人工构造的新测试集，至少保留一个“干净”的评测集做交叉验证。污染检测工具能帮上忙，但查不全，尤其是释义改写过的污染。
低资源覆盖不足是结构性难题。全世界七千多种语言，主流评测覆盖的也就一百来种，很多语言连像样的测试集都没有。指标偏差也跟语言有关，BLEU在形态丰富的语言上系统性偏低，神经指标在小语种上训练不充分。人工成本更直接，一个语言对找两个合格的母语标注员，预算和周期都不是小数目。我做过一次二十种语言的人工评测，光标注员招募和培训就花了六周。
这些挑战互相缠绕。低资源语言样本少，统计不确定性大，自动指标不可靠，人工标注又贵，数据污染还更难发现。我在项目里一般会做取舍：高资源语言做全量评测，中资源语言做抽样评测加人工抽查，低资源语言做探索性评测，结论里明确标注置信度。硬要把所有语言用同一套标准评，资源撑不住，结论也未必可靠。
3.6 未来趋势：动态基准、多模态评测、智能体翻译评测、人机协同评测与持续评测机制
静态基准的生命周期越来越短。模型迭代快，测试集一公开，过不了多久就被针对性优化。动态基准是个方向，定期更新测试数据、轮换测试集、引入时间切分，能缓解污染和过拟合。WMT这几年也在做动态评测的尝试，效果还在观察。我自己的做法是维护一个内部动态测试集，每季度补充新数据，旧数据不公开，用来做长期趋势跟踪。
多模态评测的需求在涨。翻译早就不只是文本对文本，图片里的文字、视频字幕、语音对话、文档版式，都是翻译场景的一部分。多模态评测要把视觉、语音、文本的指标串起来看，评测设计比纯文本复杂得多。智能体翻译评测是另一个新方向，模型不只是翻译一句话，而是在多轮对话里完成任务，比如帮用户填表、订票、处理客服工单。这类评测要看任务完成率、交互轮次、错误恢复能力，传统翻译指标不够用。
人机协同评测和持续评测机制，我觉得是接下来最值得投入的方向。翻译系统上线不是终点，用户反馈、译后编辑数据、接受率这些信号要能回流到评测体系里。持续评测意味着评测不是一次性的项目，而是跟着模型版本和业务变化滚动跑。我最近在搭一个轻量的持续评测流水线，每周跑核心语言和核心场景，月度跑全量，季度做深度错误分析。评测这件事，做得久比做得大更重要。
