领域特定 LLM 微调的合成数据流水线

你在合成数据上微调的模型在内部评估中得分 95%。然后你部署了它，它却自信地编造出不存在的药物相互作用，引用了案件编号错误的法律先例，并幻觉出名称听起来很合理的 API 端点。模型的流畅度没有退化——它以一种流畅度指标完全无法察觉的方式变得更糟。研究人员称之为知识崩溃 (knowledge collapse)：事实准确性下降，而表面连贯性完好无损。这是合成数据训练中较为隐蔽的失败模式之一，通常发生在工程师构建流水线却未考虑到这一点时。

对于在特定领域微调 LLM 的团队来说，合成数据生成已变得不可避免。大规模的人工标注不仅昂贵、缓慢，且对于需要专业知识的任务来说是不可能的。由能力强的教师模型生成的合成数据可以廉价地填补这一空白。但流水线并不只是“向 GPT-4 索要示例，然后训练你的模型”那么简单。细节决定了你得到的是一个在特定领域表现优于通用模型的专业系统，还是一个流畅但事实漏洞百出的系统。

两条路径：蒸馏与自我提升

每种合成数据策略都属于这两个阵营之一。了解两者的区别决定了你将生成什么样的数据，以及你面临哪些失败模式。

蒸馏 (Distillation) 使用更强大的教师模型为较小的学生模型生成训练示例。教师模型可能是一个 70B 参数的模型、类似 GPT-4o 或 Claude Opus 的前沿 API，或者是多个小模型的集成。学生模型则是你实际部署的模型——通常是 7B 到 13B 的模型，需要在生产环境中快速且廉价。教师模型生成指令-输出对、思维链追踪或偏好比较；学生模型根据这些信号进行训练。

自我提升 (Self-improvement) 使用正在训练的模型生成自己的示例，然后经过过滤或排序后用作训练数据。变体包括自博弈 (self-play，模型同时生成问题和答案)、拒绝采样 (rejection sampling，生成多个输出并保留最好的) 以及宪法 AI 风格的批判循环。当模型在某项任务上已经具备部分能力，而你希望进一步提升它时，这种方法非常有效。

对于从零开始的领域特定微调——将通用基础模型适配到法律、医疗、金融或技术领域——蒸馏几乎总是正确的起点。自我提升要求模型已经具备足够的自我评估能力。如果它无法完成任务，就无法可靠地判断自己的输出。

构建流水线

生产级的合成数据流水线包含四个必须协同设计的阶段。

阶段 1：种子数据 (Seed data)

种子数据是基础。它定义了任务分布——即你的最终模型应处理的问题类型、上下文和输入。对于领域特定工作，种子来自真实的文档：客户支持工单、临床记录、法律文件、技术文档、内部维基。即使是 50–200 个真实示例也足以生成数千个合成示例，但种子的质量和多样性直接限制了生成内容的质量和多样性。

这里最常见的错误是从实际分布的一个狭窄切片中提取种子。仅根据内部 FAQ 文档作为种子的医疗问答模型，在面对患者实际提出的边缘案例时会失败。在进行大规模生成之前，请审核种子的覆盖范围——你无法在后期弥补多样性的缺失。

阶段 2：教师生成 (Teacher generation)

在这一阶段，请使用你能负担得起的最强模型。教师模型仅在数据准备阶段运行，不在生产环境中运行，因此成本是有限的。对于你的任务，准确率达到 80%+ 的教师模型就足够了——验证环节会捕捉错误。不要为了优化教师模型的选择而牺牲生成策略。

存在三种策略，你选择哪一种取决于你相对于种子数量的查询预算：

• 答案增强 (Answer augmentation) 为现有提示词生成多个响应。当你预算有限且拥有一套充足的提示词时，这种方法最便宜且最有效。这相当于针对同一个问题获取多个专家意见。
• 问题改写 (Question rephrasing) 生成现有问题的改写版本。对较弱的教师模型具有鲁棒性，有助于在学生模型中建立改写不变性。
• 新问题生成 (New question generation) 从种子中生成全新的提示词。随着预算增加，这成为最优策略，因为答案增强的多样性上限受限于你的种子提示词。

来自 Scale AI 的研究表明，这种转变在数学、通用问答和 text-to-SQL 领域是一致的：当预算受限时，增强答案更胜一筹；随着预算增加，生成新问题更胜一筹。根据你的查询预算比例（可用的 LLM 调用次数除以种子数量）来选择正确的策略，而不是默认选择生成数据量最大的那一种。

阶段 3：质量过滤 (Quality filtering)

在实践中，缺乏质量过滤的大规模数据是合成数据流水线失败最常见的原因。在训练之前，你需要剔除：

• 无效示例——格式错误的输出、截断的响应、教师模型的拒绝回答
• 重复和近乎重复的内容——这些会导致过度代表的模式被隐式加权
• 低质量输出——教师模型出错的输出；如果你的教师模型准确率为 80%，那么定义上你 20% 的数据是错误的

过滤策略从基于规则的（长度检查、格式验证、正则表达式模式）到基于模型的（使用评测模型对输出质量进行评分），再到基于嵌入的（通过余弦相似度去重）。正确的组合取决于你的领域。对于 SQL 或代码等结构化输出，基于规则的验证既便宜又有效。对于开放式生成，评测模型更可靠，但会增加成本。

一个经过实证验证的结论：一千个经过验证的示例始终优于一万个嘈杂的示例。早期进行激进的过滤；这比后期调试训练不佳的模型要便宜得多。

阶段 4：训练学生模型 (Training the student)

LoRA (低秩自适应) 是大多数领域微调的默认选择。它速度更快，占用内存更少，且在这一规模下的大多数任务中产生的结果与全参数微调相当。当你要适配的任务与预训练分布在结构上差异巨大，以至于表面层级的适配器微调无法弥补差距时，全参数微调才有意义——而这在大多数领域应用中很少见。

durante 训练期间，请保留一个从真实示例中提取的验证集，而不是合成示例。合成验证数据会让你对你最关心的失败模式产生盲点。

模型崩溃陷阱

这是在合成数据方案中造成最长期损害的失效模式：递归训练。

发表在 Nature 上的研究确立了核心发现。当模型仅在由其先前版本生成的合成数据上进行训练时——研究人员称之为“替换”（replace）场景——每一代训练都会导致性能下降。模型的输出分布在每次迭代中都会变窄。罕见但正确的知识被挤出。长尾案例消失。最终，模型会产生流利、自信的输出，但与任务的真实分布几乎没有关系。

“积累”（accumulate）场景则避免了这种情况。在每次训练运行中保留一个非缩减的真实人类生成数据的锚点。合成数据可以扩大数据集，但它不能取代真实的基石。真实数据锚定了分布，并防止每一代训练向其自身输出的众数（mode）偏移。

对于构建版本化微调流水线的团队来说——例如模型 v2 可能会在模型 v1 增强的输出上进行训练——这一点至关重要。跟踪数据溯源（data provenance）。了解你的训练集中 AI 生成数据的百分比。设定一个上限并强制执行。永远不要让合成数据完全取代人工标注的示例。

知识崩溃是在精度至上的领域中需要关注的具体失效模式。它分阶段进行：首先，边缘案例的事实准确性下降。然后是典型案例。表面上的流利度在整个过程中保持完好，这意味着标准的困惑度（perplexity）和 BLEU 类指标无法捕捉到它。你的模型在围绕流利度构建的评估中会获得高分，但在真正重要的问题上却会失败。唯一可靠的检测方法是针对真实值语料库（ground-truth corpus）进行事实准确性评估——即具有可验证答案的任务。

将多样性作为一级指标

第二个被低估的维度是多样性。一个包含 10,000 个围绕五个 Prompt 模式紧密聚集的示例数据集，在功能上等同于 50 个高质量示例。嵌入空间覆盖度（embedding-space coverage）——即你的训练示例在输入分布中的跨度——比单纯的数据集规模更能预测下游性能。

ICML 2025 的最新研究引入了 DCScore，它将数据集多样性评估制定为一个样本分类问题，并显示出与下游微调性能的强相关性。实践中的启示：在训练之前，对你的训练集进行嵌入（embed）并可视化你的领域概念空间的覆盖情况。覆盖范围的差距就是模型能力的差距。

对于特定领域的应用，概念覆盖比一般多样性更重要。法律模型需要涵盖合同法、侵权法、合规性和诉讼——而不仅仅是表面看起来不同的问题。使用领域本体、主题聚类或精选类别列表来显式审计覆盖范围。生成数据直到填补缺口，而不是直到达到数量目标。

预算驱动的流水线设计

大多数团队没有内化研究中的一个综合结论：不存在单一的最佳合成数据策略。最佳方法取决于你的查询预算、种子数据规模和领域复杂性。

低预算，大种子集：优先考虑答案增强。为每个现有 Prompt 生成多个高质量回答。

中等预算，中等种子集：将问题重述与针对未覆盖主题的选择性新问题生成相结合。

高预算，小种子集：投资于新问题生成。增强的多样性上限是你的种子集；必须突破它。

在所有预算层级中：验证教师模型的输出，锚定真实数据，测量多样性，并保留真实示例用于评估。这些约束是不变量。

实践中的意义

构建高效合成数据流水线的工程师将数据生成系统视为产品，而非预处理步骤。它有自己的质量要求、失效模式和版本控制需求。

具体来说，这意味着：

• 跟踪数据溯源，以便了解哪些示例是人类生成的，哪些是合成的，以及来自哪个教师模型版本
• 在保留的真实值示例上运行事实准确性评估，而不仅仅是基于流利度的评估
• 在开始训练运行前测量多样性指标（嵌入覆盖度、DCScore）
• 在每一代训练中强制执行真实数据锚点
• 根据你的预算比例选择生成策略，而不是基于什么能生成最大的数据集

错过这些步骤的团队往往会在部署后发现问题，届时他们会收到用户关于边缘案例中“自信的幻觉”的投诉——而这正是他们的合成流水线从未覆盖的情景。在那时，修复成本非常高：追溯数据来源，识别覆盖缺口，生成有针对性的示例，并重新训练。

从一开始就将这种纪律融入流水线，比以后从生产故障中诊断问题要便宜得多。