SacreBLEU 怎样保存可复现的评分配置签名

如果实验记录里只写了一个 BLEU 数值，过几天往往很难判断它是用什么 tokenizer、是否区分大小写、采用哪种平滑方式算出来的。SacreBLEU 的做法是把评分配置压缩成一个 signature，并与分数放在同一份输出中。要保存可复现记录，优先归档 JSON；需要放进论文或表格时，再额外提取短签名。

官方地址：https://github.com/mjpost/sacrebleu

先看清楚：分数和签名分别回答什么问题

SacreBLEU 官方仓库把可比较性放在核心目标里。一个分数只能回答“这次得到多少”，而签名还会说明参考数量、大小写规则、有效 n-gram 处理、tokenizer、平滑方式和工具版本。只要其中一项不同，两个看起来相近的分数就不一定能直接比较。

例如 BLEU 的签名可能类似 nrefs:1|case:mixed|eff:no|tok:13a|smooth:exp|version:2.0.0。它不是模型名称，也不是实验数据集的完整描述，而是 SacreBLEU 计算配置的紧凑摘要。因此归档时应把它当作“结果的配置指纹”，而不是只把它贴在标题里。

用 JSON 一次保存完整评分记录

SacreBLEU 2.x 默认采用 JSON 输出。把 JSON 保留下来，比复制终端中的一行分数更适合后续检索；团队可以从同一份文件读取 score、signature 和各个展开字段。

# 让评分结果以 JSON 保存，保留分数、签名和配置字段
SACREBLEU_FORMAT=json sacrebleu -t wmt17 -l en-de -i output.detok.txt > score.json

# 提取完整签名，作为报告索引或实验清单的一列
jq -r '.signature' score.json > score.signature

# 同时保存测试集与语言对，避免只凭签名猜实验范围
printf '%s\t%s\t%s\n' 'wmt17' 'en-de' "$(jq -r '.signature' score.json)" > score.manifest.tsv

这里的 score.json 是主记录，score.signature 和清单只是便于搜索的派生文件。不要只提交派生文件：签名能解释评分配置，但不能代替输入输出文件、测试集名称和语言对。

完整签名与短签名怎么选

如果目标是长期归档，选择完整 JSON；如果目标是把配置放进一行表格或论文脚注，可以使用短签名。官方示例中的短签名会把字段压缩为 #:1、c:mixed、tok:13a 等更短的形式，适合展示但可读性较弱。

# 生成适合人类阅读的短签名，仍然从同一份输入计算
sacrebleu -t wmt17 -l en-de -i output.detok.txt --short -f text

# 需要稳定解析时，优先从 JSON 取完整 signature，而不是解析展示文本
jq -r '.signature, .score, .tokenize' score.json

比较方案时可以这样判断：需要自动化检索、审计或复盘，就保存 JSON；只需要在结果表中标记配置，就保存短签名；需要跨工具统一实验元数据，则在 JSON 旁边维护自己的清单，把 SacreBLEU 签名作为一个字段。

一份可复用的归档清单

• 不同 tokenizer、大小写或平滑选项会改变签名，不能只比较 score。
• 更新 SacreBLEU 后，即使命令不变，版本字段也可能提醒你重新核对结果。
• 自定义参考文件时，要把参考文件路径或内容版本纳入自己的实验清单；签名本身不包含全部数据集信息。

常见问题

signature 能不能代替完整命令？

不能。它是评分配置的摘要，不会完整记录输入文件、测试集来源和你的流水线环境。长期归档时应同时保存命令、数据标识和 JSON 结果。

为什么不直接保存一行文本输出？

文本适合人看，但自动化解析更脆弱。JSON 能直接按字段取出分数和签名，短文本则适合作为展示层。

短签名和完整签名要二选一吗？

不必。把完整 JSON 作为事实源，再从其中派生短签名，是兼顾可复现和可读性的做法。