本篇文章记录从0开始完成一篇Benchmark的经验。

什么是Benchmark？

Benchmark是AI发展的重要环节，通常是提出若干个任务，然后对某个领域的一系列模型进行评估。想要做一篇好的Benchmark，有几个必要的组成部分：1. 对领域的认识。2. 充足的算力资源（足以让你在有效的时间内完成评测。）3. 一支庞大的队伍。（Benchmark的主体通常为一个数据集，所以需要大量的人来完成数据收集、审核以及清洗的工作。）

从工作的角度来看，一个Benchmark的工作周期为：准备数据、清洗数据、数据审核（数据端）– 模型推理 — 使用Metric进行评分；而从论文的角度看，一篇Benchmark类型的论文的结构为Abstract-Introduction-Dataset本体（可以包含数据集的分类定义）、数据集的构建过程（其中可以包含数据的来源、数据的统计信息以及在做数据审核时遵守的一些Protocol）、Metric（也就是你输出的可量化指标）-Experiment（实验部分，通常是你选择的模型 + 分析部分，通常是你的实验结果），在给出实验结果后，一般会给Research and Analysis-Related Work-Conclusion。

以上就是一个基本的Benchmark应有的部分，但是仅仅有这些，会显得整个文章的贡献度较少，所以Benchmark通常会从以下两个角度将工作进一步深入：

• 提出解决问题的方法：比如我做一个幻觉的评测，那么我需要额外提出一个可能缓解幻觉的方法。
• 提出新的评测方法：过去的方法可能是昂贵的、速度慢的、不准确的或者狭隘的、与现实情况有偏差的，所以可以提出一个新的可以解决上述问题的方法。

如何去构建和管理数据？

构建的方式分为三种：

• 手工构建（最耗费资源的方式）。
• 使用LLM进行Self-Instruct，相信很多用GPT-3.5或者4进行self-instruct的同学都会发现，调API合成的数据通常存在多样性较差的问题，那么就需要在构建数据的过程中“添油加醋”，比如提供一个模板，提供更丰富的背景，提高temperature等，让模型生成更丰富的数据。
• 网络爬取 & 现有数据集的整合重组。网络爬取需要注意版权纠纷、数据脱敏的问题，现有数据集的重组就比较简单。

在构建完数据后，通常需要多人对数据的质量进行review，也就是quality control，这里通常检查数据是否存在质量或者道德上的问题。

在这个部分，最佳的数据管理方式是：数据+规则，如果构建数据采用人工众包的方式，最好能保存构建的规则，以便溯源。同时数据，应该以统一的格式进行管理，并且每个数据集包含一个meta.txt来说明这份数据集的数据量、用途以及构建时间。同时，众包的过程中应该保持统一的protocol，需要注意的点是：

• 数据命名：不要缺省或者添加额外的0，比如我需要命名为0030，结果直接命名为30。
• 格式问题：不要随意更改格式，比如文本对应的图片名称为”0030.jpg”，不要随意改为”0030.JPG”或者”0030″或者”0030.jpg.jpg”。
• 注意乱码和不同的字体问题：由于标注者使用不同的操作系统或者字体，容易出现明明含义相同或者看起来相同，但是无法聚类的问题，通常是存在乱码或者不同的字体。
• 注意冗余文件：不要出现.DStore等冗余的文件，否则批量处理时容易导致index编号错误。

上述问题可以在清洗数据的过程中，通过在代码中引入special case进行处理，但是最好还是在源头就提高质量。

如何进行评分？

评分的方法分为三种：

1. 基于规则。比如True/False，或者选择题，或者进行子串匹配。

2. 基于Metric。比如BLEU，PPL这些常用的Metric，通常还会对这些Metrics进行组合，提出一个新的Metric。

3. 基于Specific-Evaluator。现有的工作很喜欢用闭源LLM比如GPT进行Zero-Shot和ICL这些闭源模型进行评分。但是实际使用中都会发现，使用这些LLM存在一定的问题：

• 潜在的Bias。比如有工作研究LLM会识别出自己LLM的回答，并且给出更高的评价。
• 答案难以约束。答案通常需要清洗，一般会用Please just answer with number（这样的prompt进行约束）。
• 准确率低。对于简单的问题，GPT确实能很好的回答，但是这样的话，benchmark中的prompt其实在一定程度上就缺乏价值了，但是对于困难的问题，GPT很难从简短的prompt中理解。
• 不稳定。大家都知道的是，随着时间的推移，GPT的能力是会发生变化的，而且完全受控于OpenAI，这样的Evaluator给打分过程带来了不稳定性。
• 慢且贵。为了防止账号被封禁，大家至少设置5s的休眠时间，这导致推理的时间过长。贵就不多说了。

但是使用Specific-Evaluator也存在一些问题：

• 需要人工标注：数据少了Specific-Evaluator就训不出来，所以需要大量的人工标注数据。
• 准确率也无法达到100%：这主要取决于任务本身的设定，通常与分类的类别数量相关，一般在三分类以及以上达到70，80已经是较好的效果。

如何写对实验的分析？(Research and Analysis)

Research and Analysis通常指的是对实验结果进行分析，并且通过已有或者补充的实验，给出新的实验发现，起到一个提高论文价值、为同领域同行指出新的研究方向的作用。Research and Analysis在结构上通常体现为4~5个Q（问题）+A（答案）。

Research and Analysis是整个Benchmark中最容易出technical insight的部分，也是我认为最考验researcher对这个领域理解程度的部分。RA如果写的泛泛而谈，则很容易被argue没有novelty或者不够surprising；而如果写的过于浮夸，实验验证跟不上，又有可能会被reviewer argue overclaim。

那么如何写好对实验的分析呢？除开平时多看相关领域的论文，了解这个领域最关注的问题外，我总结了一些经验化的方法：

• 聚类。对评测的对象进行聚类，寻找某个方面的共性。那么就会存在共性–结果趋势上的联系。
• 消融。有一些很常见的消融思路，比如说Model Size，Direction，training dataset等。
• 异常。寻找异常结果，比如最好的、最差的。

如何写Related Work？

Related Work通常为2~3个小的段落，其作用为给出与领域相关的工作，以便读者能够通过你的这篇论文找到同领域的其他论文。在写Related Work时，我们常常会像写中文论文的关键词一样，以关键词为种子，衍生到一个具体的Topic。

比如说我做一个大模型幻觉的评测，那么我的关键词也许是大语言模型，有些人会直接对Large Language Models做Related work，那么我认为这样的作法是对这个部分有点不负责的，更好的做法可能是像DFS一样把depth设置为2，即再往下深入去寻找一层，直接以Benchmarks for LLM Hallucination会更好一点。

当选定Topic后，就要寻找这个Topic的论文路线，随后就是经典的聚类。比如现在对LLM Hallucination的Benchmark路线通常分为几种，谁谁谁属于第一种，谁谁谁属于第二种。