generate-synthetic-data

生成合成数据

生成多样、真实的测试输入，覆盖大模型管道的失败空间。

前提条件

生成合成数据之前，先找出管道可能出现故障的地方。询问用户哪些方面容易出问题，查看现有用户反馈，或根据可用的跟踪记录提出假设。维度（步骤 1）必须针对预期故障，而不是随意变化。

核心流程

步骤 1：定义维度

维度是特定于你的应用的变化轴。根据预期的故障点选择维度。

Dimension 1: [Name] — [What it captures]
  Values: [value_a, value_b, value_c, ...]

Dimension 2: [Name] — [What it captures]
  Values: [value_a, value_b, value_c, ...]

Dimension 3: [Name] — [What it captures]
  Values: [value_a, value_b, value_c, ...]

房地产助手示例：

Feature: what task the user wants
  Values: [property search, scheduling, email drafting]

Client Persona: who the user serves
  Values: [first-time buyer, investor, luxury buyer]

Scenario Type: query clarity
  Values: [well-specified, ambiguous, out-of-scope]

先从 3 个维度开始。只有当初始跟踪记录揭示了新轴上的故障模式时，才添加更多维度。

步骤 2：与用户一起拟定 20 个元组

一个元组是由维度值组合而成、用于定义具体测试用例的一组值。向用户展示 20 个拟定的元组，并反复调整，直到用户确认这些元组反映了真实场景。用户的领域知识至关重要——他们知道哪些组合实际存在，哪些不现实。

(Feature: Property Search, Persona: Investor, Scenario: Ambiguous)
(Feature: Scheduling, Persona: First-time Buyer, Scenario: Well-specified)
(Feature: Email Drafting, Persona: Luxury Buyer, Scenario: Out-of-scope)

步骤 3：使用大模型生成更多元组

Generate 10 random combinations of ({dim1}, {dim2}, {dim3})
for a {your application description}.

The dimensions are:
{dim1}: {description}. Possible values: {values}
{dim2}: {description}. Possible values: {values}
{dim3}: {description}. Possible values: {values}

Output each tuple in the format: ({dim1}, {dim2}, {dim3})
Avoid duplicates. Vary values across dimensions.

步骤 4：将每个元组转换为自然语言查询

此步骤使用单独的提示词。单步生成（同时生成元组和查询）会导致措辞重复。

We are generating synthetic user queries for a {your application}.
{Brief description of what it does.}

Given:
{dim1}: {value}
{dim2}: {value}
{dim3}: {value}

Write a realistic query that a user might enter. The query should
reflect the specified persona and scenario characteristics.

Example: "{one of your hand-written examples}"

Now generate a new query.

步骤 5：筛选质量

检查生成的查询。遇到以下情况时，丢弃并重新生成：

• 措辞生硬或不真实
• 内容与元组的意图不符
• 查询之间过于相似

可选：使用大模型按 1～5 分评价真实性，丢弃低于 3 分的查询。

步骤 6：通过管道运行查询

通过完整的大模型管道执行所有查询。捕获完整跟踪记录：输入、所有中间步骤、工具调用、检索到的文档、最终输出。

目标：约 100 条高质量、多样化的跟踪记录。 这是达到饱和状态（新增跟踪记录不再揭示新的故障类别）的大致启发式标准。具体数量取决于系统复杂度。

对真实用户数据进行采样

如果有可用的真实查询，不要随机采样，而要使用分层采样：

1. 找出高差异维度——阅读查询，找出它们的差异之处（长度、主题、复杂度、是否包含约束）。
2. 分配标签——数据集较小时，与用户一起分配；数据集较大时，使用查询嵌入进行 K-means 聚类。
3. 从各组中采样——确保覆盖不同类型的查询，而不仅是最常见的类型。

同时有真实数据和合成数据时，使用合成数据填补代表性不足的查询类型。

反模式

• 无结构的生成。 只提示“给我一些测试查询”，不采用维度／元组结构，会生成泛泛、重复且符合预期路径的示例。
• 单步生成。 在一个提示词中同时生成元组和查询，结果不如分两步生成多样。
• 随意选择维度。 不针对易发生故障的区域选择维度，会浪费测试预算。
• 跳过用户对元组的审查。 如果不先让用户验证元组，就无法判断大模型生成的元组是否真实。
• 无人能判断真实性时使用合成数据。 如果没人能判断合成跟踪记录是否真实，就改用真实数据。
• 对复杂的特定领域内容使用合成数据（法律文件、医疗记录），因为大模型会遗漏结构上的细微差别。
• 对资源匮乏的语言或方言使用合成数据，因为大模型生成的样本不真实。