合成数据（synthetic data）生成：从大模型训练到软件测试

服务商文档及输出使用条款已于 2026 年 10 月 22 日核实。 下文的客服工单和试点规模均为本文设计的示例，并非实际模型实验的报告。

什么是合成数据（synthetic data）生成？

合成数据生成，就是为特定目的创建人工构造的记录或样例。对使用大语言模型（LLM）的开发者来说，通常是根据任务规范和少量经过批准的样例，生成客服请求、问答对、信息抽取样例或对话等文本。

可以把它想成驾驶模拟器：不用等现实道路上再次出现同样的情况，就能反复练习通过一个复杂路口。但通过模拟测试，并不能说明这种路口在实际交通中出现得有多频繁，也不能证明你能应对所有道路。合成数据集同样需要区分练习覆盖了什么，以及有什么证据能说明真实世界的情况。

采用哪种方法很重要。基于规则的生成器会按指令工作，例如确保订单总额等于各明细项之和。表格数据合成器学习列与列之间的规律。LLM 则根据提示词和给定上下文生成语言。几种方法也可以配合使用：用代码创建有效订单，再让 LLM 撰写客户针对该订单的投诉。

合成数据也不等于对记录做掩码处理。替换客户姓名，并不会改变其余经历。数据增强是在已有样例上做改动，例如改写问题；生成的衍生样例仍与源样例有关联。这两种操作都不会自动保障记录的隐私，也不会自动产生独立证据。

评测：设计挑战，并独立核验标准答案

对应用开发者来说，合成评测样例最适合覆盖已知的失效情形：信息缺失、指令冲突、不支持的请求，以及不常见的表达方式。评测就是对系统行为进行可重复的测试。

如果客服助手在账号问题不明确时必须追问，就有意生成含糊的请求，再请人依据处理规则核验预期动作。不能因为生成器的回答看起来很笃定，就直接把它当成标准答案。

条件允许时，应另留一套来自获准使用的真实流量的评测集。如果不能使用真实流量，就请熟悉任务的人独立编写案例。这能检验任务规范，却不能据此确定系统在生产环境全部用户中的准确率。

微调：教会模型一种明确的行为

对需要适配模型的开发者来说，合成样例可以示范现有数据中覆盖不足的格式、分类规则或回答风格。微调是通过样例训练来更新模型。

先从可观察到的失误入手：例如，模型总把含糊的工单分给账单处理。补充经过审核的歧义样例，再用未参与训练和调优的样例，将调整后的模型与原有基线比较。训练文件变大，本身不是成功指标。

任务和验收集稳定后，再采用微调工作流。如果问题出在事实背景缺失或不断变化，应先修复提供给应用的上下文，再考虑通过生成的答案教模型记住事实。

测试数据生成：让应用真正跑到边界条件

对软件开发者来说，合成测试数据应让应用的各项规则得到检验：字段缺失、重复提交、异常文本长度、无效的状态转换，以及存在关联的数据库记录。

结账测试需要订单、客户和付款之间的关系有效，不需要语言模型来编造算术。先用代码落实这些约束，再在真实语言能发挥作用的地方引入 LLM，例如生成一条与收货地址矛盾的配送备注。

采购数据集的负责人应先问清楚，它服务于哪一种用途。适合演示的数据集未必适合训练，训练语料也不会自动成为评测集。

实操流程：从种子样例到经过审核的候选数据

先选一个范围明确的任务，而且不借助生成器，也能解释为什么某个答案正确。下面的流程将构造虚构客服工单的候选样例，用于把工单分到 billing、access 或 human_review。

示例中的规则很简单：付款和账单问题交给账单处理；登录和密码问题交给账号访问处理；不明确的请求，或同时涉及两类问题的请求，交给人工审核。不要推断客户未提供的事实。

合成数据示例：六个边界清晰的种子样例

用以下人工编写的种子样例说明分类边界：

• “我的卡被扣了两次款。” → billing
• “这张账单上的套餐不对。” → billing
• “重置链接过期了。” → access
• “重置密码后，我还是登录不了。” → access
• “我付过款了，但登录不了。” → human_review
• “还是不行。” → human_review

后面的样例与那些一眼就能分类的样例同样重要。它们让生成器知道，不确定也是一种有效结果。少样本提示指南介绍了如何通过样例传达规则，补足一般性指令可能留下的模糊之处。

清理后的候选记录可能如下。这是一条示例记录，并非实际捕获的 API 输出：

{
  "case_id": "billing-frustrated-indirect-a",
  "text": "Another invoice with the wrong plan, seriously?",
  "proposed_label": "billing",
  "policy_reason": "The customer identifies an invoice problem."
}

真正重要的结果，是可追溯、经过审核的案例。初次生成是否返回了全部请求数量，反而是次要问题。不要为了凑够数量，给质量薄弱的组合硬补样例。

合成数据生成工具：文档承诺了哪些能力？

选工具时，要看它负责流程中的哪一环。模型 API 是代码请求模型输出的接口，批处理服务负责调度这些请求；数据集库组织生成与反馈；表格数据合成器学习结构化数据中的关系。这些能力都不能替代你自己的验收标准。

用生成式 AI 生成合成数据：批处理 API

OpenAI API 的 Batch 支持通过 JSONL 文件提交异步请求，也就是每行一个 JSON 对象。文档要求提供唯一的 custom_id，并提醒输出顺序可能与输入顺序不同。应按标识匹配结果，然后在解析候选样例前检查失败请求和未完成的生成。OpenAI Batch 文档。

Anthropic 的 Claude API 提供 Message Batches，用于处理相互独立的 Messages 请求。结果区分成功、出错、已取消和已过期的请求，并通过 custom_id 关联对应输入。这里要注意执行层面的限制：批次被接受，不等于每条样例都已完成。应按标识重试缺失的工作，而不是重新生成整个数据集。Claude 批处理文档。

Google 的 Gemini API 提供 Batch，既可以直接内嵌请求对象，也可以上传 JSONL 文件。文件方式的请求使用 key 标识对应结果。较大的离线数据集适合采用文件方式；文档中的处理时长是目标值，因此不要让交互式流程依赖批处理立即完成。Gemini Batch 文档。

以下是会影响任务拆分的批处理限制，均已在所链接的文档中核实。它们并不限制通过多个任务累计构建的数据集总量。

一条批处理请求和一条候选样例是不同的计数单位。如果每个成功请求会返回多个候选样例，就应分别记录两种数量。除了传输错误，还要记录解析失败、拒绝回答和输出截断。HTTP 响应成功，不代表就得到了一条可用的训练数据。

Distilabel：组织生成与反馈流程

Distilabel 是面向合成数据和 AI 反馈的框架，可以把生成、评估和数据处理步骤组合成流水线。文档列举了分类、信息抽取、对话和指令生成等用途。当一次性脚本逐渐扩展成多个生成和筛选阶段时，这类框架就能发挥作用。Distilabel 文档。

该项目采用 Apache-2.0 许可证。仓库还说明，原作者已转向其他工作，目前由社区协作者维护。采用时应固定版本并完成验证。实际限制仍在评估器：把模型判断编排进流程，不会让判断自动变得独立或正确。Distilabel 仓库。

Faker：无需语言模型，也能构造测试数据

Faker 是一个 Python 包，通过 provider 生成虚构数据，支持地区语言设置和随机种子。当应用测试需要的是可控字段，而非自然语言推理时，它适合用来构造测试数据。其仓库标明采用 MIT 许可证。Faker 文档、Faker 仓库。

业务关系仍需自己用代码表达。各自独立生成的地址、日期和交易，并不能组成真实可信的客户历史。尽可能使用专门保留的测试标识和域名，并防止生成的测试数据触发消息发送或其他生产操作。

Synthetic Data Vault：建模表格及其关联

Synthetic Data Vault，简称 SDV，提供表格数据合成和统计评估能力。文档涵盖单表、序列数据和关联表等方法。它的合成器通过训练学习所提供数据的规律，因此仍然需要一份获准使用的源数据集。SDV 文档。

在 SDV 中，GaussianCopulaSynthesizer 使用经典统计方法学习各列的分布及相互关系；CTGANSynthesizer 使用生成对抗网络，即由生成器与相互竞争的判别器共同训练的模型。两者都接收数据，以及描述数据结构的元数据。它们是表格数据合成器，并非通用聊天模型。Gaussian Copula 文档、CTGAN 文档。

这里的关键限制，是能否保留任务所需的特性。各列分布看起来相似，并不能证明罕见组合、跨表规则或下游模型行为得到保留。应验证应用依赖的关系，包括将子记录关联到父记录的外键。

合成数据生成器怎么选？先看缺了什么

如果缺少的是语言变化，就用模型 API。当可重复的生成和反馈编排值得引入额外依赖时，再加入 Distilabel。测试数据需要可控取值时，选择 Faker。如果表与表之间的统计关系很重要，而且拥有获准用于建模的源数据，可以考虑 SDV。

不要指望购买能力更强的生成器，来解决标注规则不清的问题。这个问题出在所有工具的上游。

用模型输出训练模型，服务商条款怎么规定？

选择教师模型前，先检查输出使用限制。教师模型指生成样例、供另一个模型学习的模型。下面概括了前述三家托管 LLM 服务商的标准条款，并不代表某个具体训练项目已符合要求。

• **OpenAI：**其《服务协议》限制将输出用于开发竞争性 AI 模型，但列明了例外：主要用于数据归类、分类或整理，且不向第三方分发或提供商业使用的模型；以及通过 OpenAI 指定服务进行的模型定制。服务协议。
• **Anthropic：**除非获得 Anthropic 明确批准，其《商业条款》禁止为构建竞争性产品或服务而访问服务，包括训练竞争性 AI 模型。商业条款。
• **Google：**Gemini API《附加条款》禁止使用服务开发竞争性模型；其中的 Google Search Grounding 条款另行禁止使用 Grounded Results 或 Search Suggestions 进行训练。Gemini API 条款。

库的软件许可证、其调用模型的服务条款、模型权重许可证，以及你对源样例拥有的权利，是不同的问题。仅凭拥有输出的所有权，不能解决所有这些问题。

测试数据是否保护隐私，需要单独验证

数据是合成的，不代表隐私就有保障。如果把机密记录复制到未经批准的生成服务中，之后再生成看似虚构的替代记录，也无法撤销之前的信息披露。

Stadler、Oprisanu 和 Troncoso 关于合成数据发布的研究发现，在他们评估的不同模型之间，隐私收益和数据效用各不相同。对实践的启示是：应评估实际发布的数据及其生成过程，而不能把“合成”二字当成匿名性的证明。USENIX 研究论文。

如果已经足以满足软件测试需求，优先采用根据获批的数据结构和规则编写的虚构种子样例。如果必须保留真实统计规律，就应在获准的环境中处理源数据，并评估生成的数据集可能透露哪些信息。

检查直接标识符、复制的段落、罕见组合，以及能否与他人可能已知的信息建立关联。只替换姓名，却保留独特的事件、地点和日期，仍可能让人认出当事人。对于敏感数据的发布，少量人工抽查和重复扫描并不够；隐私评估的强度需要与威胁和预期接收方相匹配。

服务商是否用数据训练模型，与用户是否有权使用输出训练模型，是两个问题。例如，Gemini 的非付费服务条款提醒用户不要提交敏感信息；付费服务的数据使用条款则说明，提示词和回复不会用于改进 Google 的产品。这些条款也将付费服务的数据使用规则适用于欧洲经济区（EEA）、瑞士和英国的非付费使用。Gemini 数据使用条款。

无论服务商承诺不用于训练，还是在本地执行，都不能证明最终数据集可以安全共享。在发布审核完成前，应持续保留其来源记录和访问控制。

合成数据有哪些被夸大的能力？

最大的夸大，是认为多生成一些记录就能解决证据不足。生成数据可以扩大练习覆盖范围、暴露失误，也可能只是把同样的假设大规模复制一遍。

措辞不同，情境可能仍然重复

数据集中的句子各不相同，却仍可能只是在重复少数几类情境。筛选后，应追踪情境覆盖情况：还覆盖哪些业务规则、歧义和失效模式？

在工单示例中，重复的账单投诉无法弥补“账单和账号访问问题同时出现”这类请求的缺失。检查近邻样例，既看通过的样例，也看被拒绝的样例。过于严格的质量筛选，可能悄悄删掉原本想补充的困难案例。

改写并不一定消除偏差

不要以为改写带有偏差的种子样例，就能消除其中的假设。应检查不同语言风格、方言、拼写质量及相关用户群体下的标签选择。除非规则明确支持这种区分，否则不能因为请求语气不满或拼写较差，就把它分到不同的处理路径。

请审核人员比较成对样例，两者仅改变一个与判断无关的属性。如果标签随之改变，就要同时排查种子样例、提示词和筛选器。生成器与评判器可能会相互强化同一种错误。

模型给自己打分，也可能看起来很可信

Zheng 及其同事记录了 LLM 评判器的位置偏差、冗长偏好和自我偏好。模型可能奖励的是措辞或呈现方式，而非你真正想测量的属性。LLM-as-a-judge 研究。

凡是能机械验证答案的地方，都应使用确定性检查。对于主观判断，应以人工决定校准评判器，在可行时隐藏生成器身份，并审核分歧。更换评判器的服务商可以减少一项共同依赖，却不能保证错误彼此独立。

LLM-as-a-judge 指南介绍了如何先检验评估器，再信任它的分数。在合成数据生成流程中，必须先完成这一步，再让评判器决定哪些样例可以作为训练中的标准答案。

模型崩溃是特定风险，不是对所有合成数据的否定

Shumailov 及其同事研究了使用生成数据递归训练的过程，展示了原始分布中较少见的部分如何逐渐消失。这意味着，反复用模型自身的衍生数据替换源证据，需要谨慎。但它并未证明每一次经过审核、面向特定任务的合成数据微调都会失败。Nature 研究论文。

保留获准使用的原始证据，有意识地保留罕见案例，并对照未经改动的基线比较下游行为。不存在一种通用的合成数据与真实数据混合比例，可以替代这种评估。

下一步该怎么做？

现在就可以动手，前提是你能明确指出缺少哪类案例、写出正确行为，并依据稳定规则审核生成的候选样例。从小规模覆盖网格开始，只扩充那些确实能带来有用案例的组合。

先缓一缓微调，如果审核人员对目标标签仍有分歧，或缺少独立的验收集。先解决规则和评估的问题。

使用普通测试数据，如果任务只是填充数据库、测试边界值或检验事务完整性。只有当生成的语言能触发简单数据无法覆盖的行为时，再加入它。

下一次发布前，用同一组未参与训练和调优的案例，对比基线系统与修改后的系统。对于客服工单路由器，应按类别检查错误路由和漏掉的升级处理。只有合成数据改善了预期行为，且没有在其他方面造成不可接受的退步，才值得保留。

合成数据常见问题

订阅通讯，获取构建和评估 AI 系统的实用指南。