这是 自动评估基准 系列文章的第四篇，敬请关注系列文章:

基础概念
设计你的自动评估任务
一些评估测试集
技巧与提示

通常我们会假设在互联网上公开可用的数据集是存在数据污染问题的。

缓解措施有：

测试集中加入 哨兵字符串 (canary string) (如BigBench)，这是一种特殊的字符组合，使得模型创建者可以在训练集中查找，来表明该数据中是否包含评估。https://github.com/google/BIG-bench
测试集采用 加密或门控 形式，以防被网络爬虫解析并意外地被加入训练集。https://arxiv.org/abs/2309.16575https://hf.co/datasets/Idavidrein/gpqa
进行动态基准测试，定期更新基准测试来防止模型 “死记硬背答案” (但会增加数据集成本)。https://arxiv.org/abs/2104.14337
进行后验污染检测，例如检验生成结果的困惑度，或者设计对抗版的 prompt 等。然而不幸的是，目前没有任何一种污染检测方法是完美的。https://arxiv.org/abs/2311.06233

不过也不用太担心，数据集被污染并不意味着训练过程就没有意义和信号收益。

可能遇到的实际问题

微调模型、系统提示和聊天模板

要避免指令微调模型的表现过于糟糕，需要做到：

在推理 prompt 的最前面添加系统 prompt
使用聊天模板 prompt (通常在对话轮次添加 Assistant 和 User 前缀，可以查看这篇指南了解详情)https://hf.co/docs/transformers/main/en/chat_templating

另外，你无需假设不同的分词器实际表现会相同，特别是在处理聊天模板的时候。更具体的说明可以查看这条推文中附带的图片。https://x.com/danielhanchen/status/1796952220619157694

分词

一般来说，在 MCQA 评估中将上下文与选项放在一起做分词会更好，因为这样生成的 tokens 序列对于模型来说会自然一些。

不过，有些分词器 (如Llama one) 不满足以下条件：enc(context + choice) = enc(context) + enc(choice) (并且有可能增加或删除空格)。因此把上下文和选项放在一起处理的话，上下文的分词结果会 “渗透” 到选项的分词结果中，进而导致选项的对数概率结果被混淆而不可信。

Llama onehttps://github.com/EleutherAI/lm-evaluation-harness/pull/531#issuecomment-1595586257

如果你的模型也有这个问题，你可以尝试分别对上下文和选项计算分词结果，然后去除额外添加的特殊字符，最后将两个结果拼接到一起。

起始 token：有些模型 (如 Gemma) 在推理时会对句子起始位置的 token极为敏感。要想知道你的模型是否存在这个问题，你可以多做几次实验，在每次评估中手动添加不同的起始 token 来检查一下。

句子起始位置的 tokenhttps://github.com/EleutherAI/lm-evaluation-harness/pull/1465

终止 token：有时候模型会出现无法终止生成的问题，也就是模型未能生成终止 token (比如 \n)，这是因为模型不会单独预测终止 token，而只能包含在更高级的 token (如 \n\n，在代码模型中也可能是单个 token) 中生成。此时可能需要添加一个特定的检查来 “回溯” 生成的文本来确保在正确的位置截断句子，以确保计算的度量指标无误。

在进行多语言评估时，需要根据评估任务和度量指标来确定文本分词方法。由于某些语言不使用空格作为单词间的分隔符 (例如韩语、泰语、日语和中文等)，所以需要特定语言的分词器才能合理的切分，否则就会影响一些度量指标分数，如BLEU、F1 分数等。

BLEUhttps://github.com/EleutherAI/lm-evaluation-harness/issues/212

代码模型通常会在训练时将 \n\t 单独作为一个 token。这意味着在生成文本时会将 \n\t 一步生成。如果某个任务将 \n 定义为终止 token (表示生成停止)，但模型生成单个 token 却是 \n\t，那生成过程就会无限持续。为了让模型能够停止生成，需要更新文本的终止 token，或者定义一种机制来回溯最新 token 的字符表征，以便停止 (并截断) 生成。

MCQA 评估的简单加速

如果你的 MCQA 评估任务只需要模型预测一个 token，那么预测速度就可以大大加快。

你可以单次运行 上下文 推理得到全词汇表 (其中就包括了所有的选项) 的概率分布，进而按对数概率获取你感兴趣的 token，这样就避免了对每个选项的多次推理 (上下文 + 选项 1, 上下文 + 选项 2, 等等)，从而实现加速。

(我们在 lighteval 中就是这么做的)。

如果生成式评估中的结果不及预期怎么办？

首先要经常检查模型的生成结果。排查可能原因时，需要关注以下常见问题：

由于模型输出的解析过于严格 (在计算指标之前) 而导致答案丢失
模型无法以 few-shot 的方式遵循输出格式 (这个问题在近期训练的指令模型经常出现，如 Llama 3.2 或 Qwen 2.5)。
解决方法：调整 prompt 格式，或者做一个模型能够遵循 few-shot 示例的假设
模型输出过于冗长而导致无法得到正确答案 (在长上下文模型中更为常见，如 Qwen 和 CommandR)
解决方法：增加上下文长度，或者在任务 prompt 中添加指令，还可以做一个模型能够输出简练回答的假设。

英文原文:https://github.com/huggingface/evaluation-guidebook/blob/main/translations/zh/contents/automated-benchmarks/tips-and-tricks.md

原文作者: clefourrier

译者: SuSung-boy

审校: adeenayakup