用途
该技能用于为 LLM 流水线评估生成多样化、贴近真实的合成测试输入，目标是覆盖流水线可能失败的场景空间。它适合在引导评估数据集时使用，也适合在真实用户数据不足、需要补充覆盖时使用。
前置准备
在生成合成数据之前，需要先识别流水线可能在哪里失败。可以询问用户已知的易失败区域、查看现有用户反馈，或从可用轨迹中形成假设。第一步定义的维度必须针对预期失败点，而不是任意变化。
核心流程
第一步：定义维度
维度是特定于应用的变异轴，应根据预期失败点来选择。
格式示例：
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（用户想要的任务）：[property search, scheduling, email drafting]
- Client Persona（用户服务的对象）：[first-time buyer, investor, luxury buyer]
- Scenario Type（查询清晰度）：[well-specified, ambiguous, out-of-scope]
建议从 3 个维度开始。只有当初始轨迹揭示出新的失败轴时才增加维度。
第二步：与用户一起草拟 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)
第三步：用 LLM 生成更多元组
使用如下提示词生成 10 个随机组合：
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.
第四步：将每个元组转换为自然语言查询
此步骤使用单独的提示词。单步生成（元组与查询一起生成）会产生重复的措辞。
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.
第五步：质量过滤
审查生成的查询。出现以下情况时丢弃并重新生成：
- 措辞生硬或不真实
- 内容与元组意图不符
- 查询之间过于相似
可选：使用 LLM 按 1-5 分评估真实度，低于 3 分丢弃。
第六步：将查询跑通流水线
将所有查询通过完整的 LLM 流水线执行。捕获完整轨迹：输入、所有中间步骤、工具调用、检索到的文档、最终输出。
目标：约 100 条高质量、多样化的轨迹。这是一个粗略的经验值，用于达到饱和（即新轨迹不再揭示新的失败类别）。具体数量取决于系统复杂度。
采样真实用户数据
当有真实查询可用时，不要随机采样，而应使用分层采样：
- 识别高方差维度——通读查询，找出它们在长度、主题、复杂度、是否含约束等方面的差异。
- 分配标签——小数据集与用户一起完成；大数据集使用查询嵌入上的 K-means 聚类。
- 从每组中采样——确保覆盖各类查询，而不仅仅是最常见的类型。
当真实数据和合成数据都可用时，用合成数据填补覆盖不足的查询类型。
反模式
- 无结构生成。在没有维度/元组结构的情况下提示“给我测试查询”，会产生通用、重复、只走顺利路径的示例。
- 单步生成。在一个提示词中同时生成元组和查询，多样性不如两步分离。
- 任意维度。不针对易失败区域的维度会浪费测试预算。
- 跳过用户对元组的审查。没有用户先验证元组，就无法判断 LLM 生成的元组是否真实。
- 无人能判断真实度时使用合成数据。如果没有人能判断合成轨迹是否真实，应改用真实数据。
- 复杂领域特定内容（法律文件、医疗记录）使用合成数据，LLM 会遗漏结构性细微差别。
- 低资源语言或方言使用合成数据，LLM 生成的样本不真实。