generate-synthetic-data

合成データを生成する

LLM パイプラインで発生しうる失敗を網羅する、多様で現実的なテスト入力を生成します。

前提条件

合成データを生成する前に、パイプラインが失敗しやすい箇所を特定してください。失敗しやすい領域についてユーザーに尋ねたり、既存のユーザーフィードバックを確認したり、利用可能なトレースから仮説を立てたりします。ディメンション（ステップ 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：LLM を使ってタプルを追加生成する

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：品質を確認する

生成されたクエリを確認します。次の場合は破棄して再生成してください。

• 表現が不自然、または現実的ではない
• 内容がタプルの意図に合っていない
• クエリ同士が似すぎている

任意：LLM を使って現実性を 1〜5 の尺度で評価し、3 未満のものを破棄します。

ステップ 6：クエリをパイプラインに通す

すべてのクエリを完全な LLM パイプラインに通します。入力、すべての中間ステップ、ツール呼び出し、取得したドキュメント、最終出力を含む完全なトレースを記録します。

目標：約 100 件の高品質で多様なトレース。 これは、新しいトレースから新たな失敗カテゴリが見つからなくなる飽和状態に達するための、大まかな目安です。必要な件数はシステムの複雑さによって異なります。

実際のユーザーデータのサンプリング

実際のクエリを利用できる場合は、ランダムにサンプリングしないでください。層化サンプリングを使います。

1. 分散の大きいディメンションを特定する — クエリを読み、長さ、トピック、複雑さ、制約の有無など、違いが見られる点を探します。
2. ラベルを割り当てる — 小規模なデータセットではユーザーと一緒に、大規模なデータセットではクエリの埋め込みに対する K-means クラスタリングを使います。
3. 各グループからサンプリングする — 最も一般的なクエリだけでなく、さまざまな種類のクエリを網羅できます。

実データと合成データの両方を利用できる場合は、合成データを使って、十分に代表されていないクエリの種類を補います。

アンチパターン

• 構造化されていない生成。 ディメンション／タプルの構造を使わずに「テスト用クエリを生成して」と指示すると、一般的で反復的な、正常系の例ばかりが生成されます。
• 単一ステップでの生成。 1 つのプロンプトでタプルとクエリを生成すると、2 つのステップに分ける場合よりも多様性が低くなります。
• 任意のディメンション。 失敗しやすい領域を対象にしていないディメンションは、テスト予算の無駄になります。
• タプルに対するユーザー確認を省くこと。 事前にユーザーがタプルを検証しないと、LLM が生成したタプルが現実的かどうか判断できません。
• 現実性を判断できる人がいない状況での合成データの使用。 合成トレースが現実的かどうかを判断できる人がいない場合は、代わりに実データを使います。
• ドメイン固有で複雑な内容（法的書類、医療記録など）に対する合成データの使用。 LLM では構造上の微妙な違いを見落とす可能性があります。
• リソースの少ない言語や方言に対する合成データの使用。 LLM が生成するサンプルが不自然になる可能性があります。