评估 llm-jp-eval（评估很难）

随着 shisa-v2 训练的正式启动，我一直在深入研究 llm-jp-eval，我曾用它作为一个快速简单的基准，以在开发过程中跟踪 shisa-v1（尤其是基础模型）的性能。

WandB 已经实现了 Nejumi LLM 排行榜，其中包含一个 测试工具，用于修改设置并在 WandB 上上传/查看（这是我的工作区：https://wandb.ai/augmxnt/nejumi）。

首先我很好奇能否复现 shisa-gamma-7b-v1 的结果，尽管（在我看来）它已经被更强的日语模型取代，但它仍然位居日语调优的开源模型榜首。但是如果你查看 shisa-7b-v1，你会发现它基本上无法完成任务。这些模型基本上是在相同的数据集上进行调优的，那么到底发生了什么？

嗯，对于第二部分，这实际上相对容易回答。基础模型 base model 和最终的 shisa-7b 都要求使用 bos_token 进行训练（参见说明），否则它根本无法输出合理的内容。你可以看到，当使用包含默认提示并前置 bos_token 的配置时，它的分数几乎与 shisa-gamma-7b-v1 一样高。

现在，至于解开另一个谜团——令人惊讶的是，当使用原生（llama2）聊天模板进行测试时，它的性能实际上要差得多。这是为什么呢？嗯，我们来看看输出。事实证明，当你使用日语提示时……模型往往会用日语回答。

在不使用微调的聊天格式时，这种情况发生的可能性大大降低（它会恢复到更像基础模型的行为）。由于没有使用 logprobs，嗯，如果你用日语回复，那么这些基准测试的分数将是一个大大的零。我四处点击，发现许多收集到的分数都是精确匹配分数，因此这种以及其他“格式”相关的正确性问题普遍存在（这很重要，因为低于一定大小/能力水平的 LLM 将会非常脆弱；此外，针对单个单词答案进行微调往往会破坏较小模型的整体性能）。让我们深入研究一个例子。

如果你按照 JA MT-Bench 分数在 Nejumi 排行榜上排序，你会发现 Lightblue 的 lightblue/qarasu-14B-chat-plus-unleashed 是 MT-Bench 中得分最高的 JA 开源模型，但在 llm-jp-eval 上的得分却低得惊人，只有 0.1437。WandB 也提供了所有运行的信息，所以点击进去，我们看看。该模型在许多测试/类别中都得了零分。我们来看看 janli：

这里它返回的是日语，而不是英语。那么 jcommonsense 呢？

这需要更多检查，但我认为它肯定是一个解析错误……那么 mawps_exact 呢？

好吧，Qarasu 在数学方面表现不佳，但即使它*确实*得到了正确答案，它仍然得到0分，因为它的评分是基于*仅*一个数字作为答案的精确匹配。我的意思是，也许这测试了0-shot指令遵循，但我不确定它是否像人们在看“数学”分数时认为的那样有意义（或者测试人们认为它正在测试的内容）。

llm-jp-eval 1.1.0 运行速度非常快（对于 shisa-7b-v1，使用其高速分词器，在 H100 上 3 分钟即可运行），我认为它有其存在的价值，但我看到大多数日本 LLM 社区已决定将其用作“黄金标准”类型的基准，我不确定是否每个人都清楚一个好的分数到底意味着什么或不意味着什么。以下是一些改进它的想法：

• 虽然自然语言处理性能是 LLM 的重要方面，但随意点击响应时，我发现许多模型的得分反映了格式和性能。我认为指令/提示可能需要改进，同时还需要进行少量样本学习。

• 我认为模板化绝对是一个问题，并且我认为未来每个人都应该支持模型提供的聊天模板（如果它在分词器中提供的话）。我认为还需要考虑日语语言模型是否应该用英语回答日语问题……而不是精确匹配，也许 logprob 才是正确的方法，就像 lm-eval 所做的那样？

• 当然，所有这些测试都有可用的训练集，你可以用它们进行训练（我们把训练集放进了ultra-orca-boros-en-ja-v1，发现它改善了我们整体的日语性能，但是当我测试他们最初的1.0版“jaster”微调模型时，当用作主要sft时，它实际上完全破坏了所有通用性能（例如基本的日语连贯性、回答多于一个单词的能力）。

llm-jp-eval 仍在迭代中，看起来在 1.3.0 版本中，他们添加了维基百科和其他理解测试，但如果没有转向多项选择 logprob 或 oracle/llm-as-judge，那么可能需要重新审视。以下是 llm-jp-eval 团队提供的更多信息（以及他们自己的排行榜）。

总之，今天开始深入研究时有些惊讶，所以就想分享一下。

顺便说一下，JA MT-Bench 也有自己的问题。未经 JA 训练的模型有时会在其上表现出惊人的好成绩（由 GPT-4 评判）。嗯，运行一些简单的 JA 检测代码显示，一些得分最高的模型*根本没有输出日语*

~80% 是判断它是否真正用日语回复的截止点。

对于那些希望进行类似测试的人来说，我使用了非常简单（但足以进行粗略判断）的启发式方法

def is_japanese_char(char):
    # Check if the character falls within the Japanese Unicode codepoint ranges
    return any([
        0x3040 <= ord(char) <= 0x309F,  # Hiragana
        0x30A0 <= ord(char) <= 0x30FF,  # Katakana
        0x4E00 <= ord(char) <= 0x9FFF   # Kanji
    ])