企业官网建设流程全解析

• 推理引擎
• 大模型

本指南围绕 transformers 官方 seq2seq 示例目录中的romanian_postprocessing.md展开，系统讲解英→罗（English→Romanian）翻译评测中必须的语料后处理步骤：安装 Moses 工具链、编写ro_post_process后处理函数、对生成译文与参考译文做统一归一化后重新计算 BLEU。读完本文，你将掌握如何复现“不做处理 26.8、做处理后 37”这一显著提升，并能把这套管线迁移到自己的机器翻译评测任务中。

一、为什么罗马尼亚语翻译的 BLEU 需要“后处理”

原文文档在一开始就给出了一个非常直观的动机对比：

• 不做后处理：英→罗mbart-large-en-ro在 WMT 数据上的 BLEU 只有26.8；
• 做后处理：同样模型、同样生成结果，BLEU 可以提升到37。

同一份生成结果，分数却相差 10 分以上，原因不在模型，而在评测口径。罗马尼亚语文本带有大量变音符号（diacritics），而 WMT 参考语料（test.target）通常已经过标点归一化、变音符号移除和分词处理。若直接用原始生成文本去和参考文本做 n-gram 匹配，任何一个“带变音符号”的单词都无法与“无变音符号”的参考词精确对齐，BLEU 会被人为压低。后处理的作用，就是把生成译文与参考译文放到同一套归一化与分词口径下再比较。

这一点在仓库代码中也有印证：seq2seq 示例的run_eval.py计算翻译指标时直接调用utils.py中的calculate_bleu（内部使用 sacrebleu 的corpus_bleu），并不包含任何罗马尼亚语专属的归一化步骤。因此README.md中也特别提醒：MBART 的 BLEU 分数“低得可疑（suspiciously low）”。本文的后处理管线正是解决这个“可疑”的关键。

二、前置条件：先拿到test_generations.txt与参考译文

后处理流程的输入是两批对齐的文本，每行一条：

1. 模型生成译文：test_generations.txt（文档明确要求：开始后处理前必须已有该文件）；
2. 参考译文：test.target（以 WMT 英→罗测试集为例）。

在 transformers seq2seq 示例的工作流中，test_generations.txt由finetune_trainer.py在开启--predict_with_generate时自动写出：训练/评测脚本会把model.generate的解码结果逐行写入{output_dir}/test_generations.txt。对应的英→罗微调命令可参考train_mbart_cc25_enro.sh，其核心参数包括：

python finetune_trainer.py \ --model_name_or_path=facebook/mbart-large-cc25 \ --data_dir $ENRO_DIR \ --output_dir mbart_cc25_enro --overwrite_output_dir \ --src_lang en_XX --tgt_lang ro_RO \ --max_source_length 128 --max_target_length 128 \ --num_train_epochs 6 \ --do_train --do_eval --do_predict \ --predict_with_generate --logging_first_step \ --task translation \ "$@"

其中--predict_with_generate是产出test_generations.txt的开关，--data_dir指向 WMT 英→罗数据目录（包含train/val/test各自的.source与.target文件）。数据下载方式见README.md：下载wmt_en_ro.tar.gz并解压后，目录中即包含test.target等 6 个文件。

提示：也可以先用run_eval.py生成翻译结果文件，再进入后处理流程；本文后处理函数只关心“生成文本文件 + 参考文本文件”两个输入，与文件来源无关。

三、第一步：安装mosesdecoder与wmt16-scripts

后处理依赖两套外部工具，按文档要求克隆到$HOME下：

cd $HOME git clone git@github.com:moses-smt/mosesdecoder.git cd mosesdecoder git clone git@github.com:rsennrich/wmt16-scripts.git

• mosesdecoder：提供 Moses 生态的 Perl 预处理脚本（标点替换、归一化、去非打印字符、分词等），位于scripts/tokenizer/目录；
• wmt16-scripts：提供罗马尼亚语专属的 Python 脚本（normalise-romanian.py、remove-diacritics.py），位于preprocess/目录。

这两套工具共同组成了后续ro_post_process函数引用的完整工具链。注意它们是较早的经典工具链，运行环境需具备 Perl 与相应版本的 Python 解释器，克隆成功后建议先确认各脚本具有可执行权限。

四、第二步：编写ro_post_process后处理函数

原文文档给出了完整的 Bash 函数定义，这是整篇指南的核心。建议将其保存为可复用的 shell 函数（例如写入.bashrc或独立脚本），完整代码如下：

ro_post_process () { sys=$1 ref=$2 export MOSES_PATH=$HOME/mosesdecoder REPLACE_UNICODE_PUNCT=$MOSES_PATH/scripts/tokenizer/replace-unicode-punctuation.perl NORM_PUNC=$MOSES_PATH/scripts/tokenizer/normalize-punctuation.perl REM_NON_PRINT_CHAR=$MOSES_PATH/scripts/tokenizer/remove-non-printing-char.perl REMOVE_DIACRITICS=$MOSES_PATH/wmt16-scripts/preprocess/remove-diacritics.py NORMALIZE_ROMANIAN=$MOSES_PATH/wmt16-scripts/preprocess/normalise-romanian.py TOKENIZER=$MOSES_PATH/scripts/tokenizer/tokenizer.perl lang=ro for file in $sys $ref; do cat $file \ | $REPLACE_UNICODE_PUNCT \ | $NORM_PUNC -l $lang \ | $REM_NON_PRINT_CHAR \ | $NORMALIZE_ROMANIAN \ | $REMOVE_DIACRITICS \ | $TOKENIZER -no-escape -l $lang \ > $(basename $file).tok done # compute BLEU cat $(basename $sys).tok | sacrebleu -tok none -s none -b $(basename $ref).tok }

4.1 逐段拆解

输入与输出约定

• 函数接收两个位置参数：$1为系统生成译文文件（sys），$2为参考译文文件（ref）；
• 对两个文件执行完全相同的处理管线（for file in $sys $ref），各自输出以basename命名的.tok文件。这一“两边同口径”的设计非常关键——只有生成与参考都经过同样的归一化，BLEU 才能反映真实翻译质量；
• 最后一行用 sacrebleu 计算并打印 BLEU 分数。

工具管线：六个步骤各司其职

原文作者也坦诚地写道，这套管线“移除变音符号并做了其他自己不完全理解的处理”——从脚本名称与 Moses 生态的通用约定看，前三步属于所有语言通用的文本清洗，后三步则是罗马尼亚语 BLEU 提升的关键：参考语料（WMT 官方）正是按这种“去变音、已分词”的形态发布的，把生成文本对齐到同一形态后，n-gram 才能正确匹配。

4.2 关于lang=ro的说明

-l $lang参数（$lang=ro）作用于normalize-punctuation.perl与tokenizer.perl，指示按罗马尼亚语的语言规则处理。如果你的任务换成其他语言，需要相应调整该变量，并确认工具链中有对应的语言规则文件。

五、第三步：对生成译文与参考译文执行后处理并重算 BLEU

函数定义好后，直接调用并传入两个文件路径即可（沿用原文示例）：

ro_post_process enro_finetune/test_generations.txt wmt_en_ro/test.target

执行后会发生两件事：

1. 写出两个后处理文件：在当前目录（调用函数的目录，而非输入文件所在目录）生成test_generations.txt.tok与test.target.tok——注意文件名取的是输入文件的basename，路径信息会被丢弃；
2. 打印新的 BLEU 分数：将test_generations.txt.tok与test.target.tok交给 sacrebleu 计算，命令为：

cat $(basename $sys).tok | sacrebleu -tok none -s none -b $(basename $ref).tok

其中-tok none表示文本已经由 Moses 分词、sacrebleu 无需再分词，-s none关闭平滑，-b（brief）只输出分值而不输出详细统计。

5.1 与仓库评测代码的衔接

仓库自带的评测路径（run_eval.py+utils.py）默认直接对未处理的输出算 BLEU，因此分数偏低。本文的ro_post_process相当于在最终计分之前插入了一道语料归一化关卡。两种方式对比：

六、结果解读与正确使用姿势

按原文文档，在 WMT 英→罗数据上，同一个mbart-large-en-ro模型：

• 未后处理 BLEU：26.8
• 后处理 BLEU：37

需要强调的是，后处理没有改变模型本身，它改变的是评测口径。因此：

• 若要将自己的分数与论文、排行榜对比，必须确认对方是否使用了相同的归一化/分词管线，否则 26.8 与 37 之间并不存在“模型好坏”的差距；
• 后处理文件（.tok）应妥善保留，作为评测的可复现证据；
• 若后续调整模型或解码参数（beam size、length penalty 等），只需对新生成的test_generations.txt重新调用一次函数即可，参考侧test.target的处理可复用。

七、常见问题与注意事项

1. 必须先有test_generations.txt：函数只做后处理与计分，不负责生成译文。译文文件需先由finetune_trainer.py（--predict_with_generate）或run_eval.py产出，路径随意，函数不关心其来源目录。

2. MOSES_PATH路径变量：函数开头export MOSES_PATH=$HOME/mosesdecoder假设工具链安装在$HOME下；若实际安装位置不同，必须修改此变量，否则后续六个脚本路径全部失效。

3. 输出文件位置：.tok文件写到当前工作目录，且以basename命名。若对多个目录下的文件做处理，注意同名文件会互相覆盖，建议在独立目录中调用。

4. sacrebleu 依赖：仓库 seq2seq 示例的requirements.txt已包含sacrebleu，执行前请确认已安装。旧版 sacrebleu 的参数风格与新版存在差异，若参数解析报错，可查阅本地sacrebleu --help调整-tok/-s/-b写法。

5. 工具链兼容性：wmt16-scripts与 Moses Perl 脚本属于较早期工具，个别脚本对解释器版本敏感；若运行报错，可从“该步骤脚本的具体报错”入手排查，通常与 Unicode 编码或 Python 2/3 差异相关（从脚本年代可以推断）。

6. 语言不可迁移性：remove-diacritics.py与normalise-romanian.py是为罗马尼亚语量身定制的；其他语言需要寻找对应的归一化工具，不能照搬本函数。

八、小结

本指南完整复现了romanian_postprocessing.md中的三步流程：安装 Moses 工具链 → 定义ro_post_process六段管线 → 对生成译文与参考译文统一后处理并重算 BLEU，使英→罗翻译评测从“低估的 26.8”回到真实水平“37”。这套方法论的本质是让评测口径与参考语料的发布口径一致，它不仅适用于 mBART，也适用于任何在 WMT 类数据上评测的罗马尼亚语翻译模型，并可作为其他语言评测后处理流程的设计范本。

• 推理引擎
• 大模型