实践：合成数据验证清单

合成数据生成是一个主要步骤。然而，在将这些数据用于大型语言模型（LLM）预训练 (pre-training)或微调 (fine-tuning)流程之前，有必要让它们通过全面的验证流程。你可以将此视为数据质量保证。系统检查能保障数据符合预期用途，与项目目标一致，并且日后不会引发意想不到的问题。一份实用的清单指导合成数据验证。

此清单并非线性流程；有些步骤可能是迭代或并行的。其目标是增强你对合成数据集的信心。

合成数据验证的一般工作流程，强调迭代优化。

1. 生成流程基本检查

在查看数据本身之前，请审查生成该数据的过程。

• 方法一致性：
  • 所选的合成数据生成方法（例如，基于规则、回译、基于LLM）是否适合你的具体目标（例如，扩充预训练 (pre-training)语料，创建用于微调 (fine-tuning)的指令遵循数据）？
  • 如果使用LLM进行生成，提示词 (prompt)是否设计得好？它们是否清楚地指定了所需的输出结构、内容、风格和约束条件？
• 源数据（如果适用）：
  • 如果你的合成数据生成流程依赖于种子数据（例如，用于释义、少量样本提示），这些源数据是否高质量、多样化，并与你的目标范围相关？
  • 源数据中是否存在任何可能已传播到合成数据集的已知问题（偏见、不准确性）？
• 参数 (parameter)化：
  • 生成参数（例如，LLM温度、top-p、top-k、基于规则的算法设置）是否已记录？
  • 是否有选择这些参数的理由，或者它们是否通过实验确定？

2. 定量评估

使用客观指标来得到数据集的统计概览。

• 体量和规模：
  • 生成数据的数量是否足以满足预期用途？
  • 数据量是否过多，可能导致过多的训练时间或成本，却未能带来预期的收益？
• 多样性：
  • 计算多样性分数。对于文本，这可能包括Self-BLEU（用于衡量生成样本间的相似度；值越低通常越好）、n-gram多样性（独特的n-gram与总n-gram的比例），或适合你的数据类型的其他多样性度量$D_s$。
  • 多样性是否符合你的要求？低多样性可能导致过拟合 (overfitting)。
• 语言质量（针对文本）：
  • 使用通用语言模型衡量困惑度（$PPL$）。非常高的$PPL$可能表明文本不自然或不连贯。如果有基线，请与基线进行比较（例如，真实数据的$PPL$）。
  • 使用自动化工具对样本进行语法正确性检查。记录错误率。
• 分布特性：
  • 分析样本长度（例如，词数、token数）的分布。它是否与你的预期或你可能正在扩充的真实数据分布一致？
  • 对于结构化数据（例如，指令-响应对），检查指令类型、响应长度或其他结构化特征的分布。
• 任务专用指标（针对微调 (fine-tuning)数据）：
  • 如果你正在为存在自动化指标的特定任务（例如，用于摘要的ROUGE、用于翻译的BLEU、用于问答的Exact Match/F1）生成数据，你能否使用这些指标评估你的合成数据的一个子集？这通常涉及使用“黄金”输入，并使用你的合成生成流程来创建输出，然后进行比较。

3. 定性审查（人工参与）

自动化指标无法说明全部情况。人工审查对于捕捉细节不可或缺。审查你数据中随机选择的、具有统计学意义的样本。

• 相关性和连贯性：
  • 每个样本是否与预期方面或任务相关？
  • 内容是否逻辑连贯且易于理解？
  • 在预期使用场景中是否合理？
• 准确性和真实性：
  • （特别对于信息类内容重要）检查是否存在事实不准确或“幻觉 (hallucination)”。估计的发生率是多少？
  • 是否存在任何误导性陈述？
• 指令遵循（针对指令微调 (fine-tuning)数据）：
  • 如果数据包含指令和响应，响应是否准确、安全、完整地响应指令？
  • 是否避免“模棱两可”或不必要地拒绝有效（但可能复杂）的指令？
• 风格、语调和角色：
  • 数据是否符合任何指定的风格指南（例如，正式、非正式、特定角色）？
  • 语调是否适合预期应用？
• 原创性和冗余：
  • 样本是否显得新颖，还是过度重复或只是少数模板的轻微变体？
  • 是否存在过多未能增加显著价值的近似重复项？
• 完整性（针对结构化数据）：
  • 每个数据点所有必要组成部分都存在吗（例如，对于问答对，是否存在问题、上下文 (context)和答案）？

4. 偏见、公平性和安全性

合成数据可能继承甚至放大偏见。主动检查是必要的。

• 代表性：
  • 审查数据是否存在潜在的人口统计学偏见（年龄、性别、种族等）或其他社会偏见。某些群体是否以可能带来问题的方式过度代表或代表不足？
  • 如果合适，使用偏见检测工具或关键词列表来扫描刻板印象关联。
• 有害内容：
  • 筛选毒性、仇恨言论、不雅语言或其他不良内容。自动化分类器可以提供帮助，但对于边缘情况也建议进行人工审查。
  • 数据是否无意中宣扬有害意识形态或行为？
• 应用安全性（特别针对指令/对话数据）：
  • 如果LLM遵循任何生成的指令或响应，是否会引发不安全行为？
  • 是否存在“越狱”尝试或旨在从模型中引出有害内容的提示？

5. 数据格式和完整性

确保数据在技术上可靠，并为你的训练流程做好准备。

• 文件格式：
  • 数据是否采用正确的文件格式（例如，JSONL、CSV、纯文本）？
  • 你的数据加载脚本能否正确解析这些文件？
• 结构和模式：
  • 每个数据点是否符合预期的模式（例如，JSON对象中正确的键、CSV中正确的列数）？
  • 数据类型是否正确（例如，预期为字符串的地方是字符串，预期为数字的地方是数字）？
• 特殊字符和编码：
  • 文本编码（例如，UTF-8）是否一致且正确？
  • 特殊字符是否处理得当？
• 唯一性：
  • 数据集中是否存在无意的完全重复项？虽然某些重复可能是出于策略，但无意的重复项可能使训练结果有偏差。

6. 对模型性能的影响（预估评估）

考虑潜在的下游影响。

• 模型崩溃的风险：
  • 如果迭代使用此数据或将其作为训练数据的重要组成部分，你是否已考虑模型对合成模式过拟合 (overfitting)并丧失泛化能力（模型崩溃）的风险？
  • 是否有缓解此风险的策略（例如，与多样化的真实数据混合，仔细监测模型在保留集上的性能）？
• 数据原创性与记忆化：
  • 合成数据是否真正扩展了模型的知识或技能，还是可能导致模型记忆特定合成示例？
  • 与用于生成数据的模型的训练数据相比如何（如果适用）？避免在生成器自身的训练数据上进行训练。

7. 文档和版本控制

良好的管理实践对于可复现性和协作是必要的。

• 数据集卡/数据表：
  • 你是否已记录了生成流程、源数据（如果有）、已知局限性以及此合成数据集的预期用途？
• 版本控制：
  • 此数据集是否已版本化？如果你重新生成或修改它，能否跟踪更改？

此清单提供了一个全面的起点。你可能需要根据你的具体项目、正在生成的合成数据类型及其预期用途添加或删除项目。最重要的是要彻底且批判性地进行。投入时间验证你的合成数据将带来回报，形成更可靠、更有能力、更安全的LLM。如果你的数据未能通过多项检查，通常最好是返回优化生成流程，而不是试图修补有缺陷的数据集。