如何获取高质量数据进行代码指令调优？

之前很多研究都聚焦在如何生成、发现和筛选高质量的通用指令微调数据上。但随着大家对代码任务的关注度越来越高，一个很自然的问题就浮出水面了：我们到底该如何专门为代码任务构建更好的指令微调数据？

最近读到一篇非常应景的文章，它把这个事儿拆解得挺清楚。核心思路是从指令的复杂度、回复的质量，以及指令本身的多样性这三个维度，来给数据样本做“体检”，挑出最优质的。文章同时还指出了一个挺有意思的现象：目前部分代码指令数据在 HumanEval 基准测试上存在严重的数据泄露问题。这些信息都来自论文和开源项目（Paper, Github, Data-HF），我们来仔细看看。

数据筛选：三个维度，一把标尺

整个筛选流程，可以看作是对一个海量数据池进行“选优”。具体操作上，会先用一个复杂度评分器和单元测试模型，给池子里的每条数据分别打上复杂度分和质量分。接着，把这两个分数归一化后做个线性组合，得出一个综合评分。最后，根据这个综合评分排序，并引入多样性进行迭代采样，直到筛选出的数据集达到预期规模。整个算法流程，可以参考下图。

• 复杂性评分器：
  怎么做？先利用 self-instruct 方法搞一个小规模的种子数据集，再学 WizardCoder 的思路，对提示词进行多次深度进化，产生多轮数据。这个轮次数，就被直接当作了复杂性的度量值，并用来训练最终的评分器。

• 单元测试模型：
  代码好不好，跑个测试最直观。这里，通过单元测试的数量被看作是响应质量的度量。具体做法是用6k数据训练了一个基于 LLaMA3-70B-Base 的模型来做这事儿。测试时，模型为每个样本生成12个测试用例并执行，通过的用例数就是质量分。

• 多样性采样：
  这一步是迭代进行的。每次从数据池中选一个样本，判断它是否能提升当前数据集的数据多样性。如果答案是肯定的，就把它加进去。多样性的贡献度，是由样本与其在数据集中最近样本之间的嵌入距离和一个超参数共同决定的。

效果分析：精挑细选，效果拔群

为了拼出最好的代码指令微调数据集，研究者们收集了各种开源数据，总共有250万条。数据池太大，肯定得过滤。流程是：先选取几个成熟的学术数据集，然后筛出长度最长的20万条，再从中挑出复杂度评分最高的20万条，最后一步是去重。最终，他们得到了33.6万条精炼数据。

在 LLaMA3-8B-Base 上做的实验很有说服力。只用40K数据，在 LiveCodeBench 和 BigCodeBench 上就已经超越了基线模型的效果；当数据量增加到80K时，各项指标还在持续提升。

基于 LLaMA3-70B-Base 训练出的 XCoder-70B 模型，一举成为当时效果最佳的开源代码大模型。

但有意思的是，它在 HumanEval 上并不是最优的。原因也不复杂：Magicoder-Evol-Instruct 和 Codefuse-Evol-Instruct 这两个数据集在 HumanEval 上存在数据泄露问题。

为了解决这个问题，研究者还提出了一个叫 TLI（测试泄露指标）的新指标，用来量化训练集对测试集的泄露程度。它的原理是对数据集生成 n-gram 片段，看测试集样本的 n-gram 有多大比例与训练集重合，重合度越高，泄露风险越大。

后续的消融实验也证实，复杂性、响应质量和多样性这三个维度，对最终数据质量的提升都确有助益。一个更直观的结论是：在复杂性评估这个环节，复杂性评分器的效果远好于指令长度、困惑度，甚至优于随机筛选。而在单元测试模型方面，他们自己训练的 Llama3-70B 模型表现，甚至超过了 GPT-4。

最令人印象深刻的一点是，用 XCoder 方法精选出的10K数据，其训练效果就已经可以媲美随机选择的160K数据，效率提升了整整16倍。同时，文章还分析了 XCoder 的数据组成，重新评估了不同数据源的优缺点，这对于后续的数据构建工作非常有参考价值。