実験
実験はループのどこに位置するか
システムの挙動を体系的に理解・改善するには、原因と結果を分離する方法が必要です。 実験がそれを提供します。 1 つまたは複数の変数を選び、システムの 2 つのバージョンに同じデータセットを通し、出力を比較します。 結果は、ある変更が本当に役立ったか、どの程度役立ったかを教えてくれます。 どの程度役立ったかを理解するには、実験の出力を評価することも必要です (評価を参照)。 このセクションでは、評価の前段にある体系的な実験の進め方を扱います。
実験の構造
すべての実験には 4 つの構成要素があります。
| 要素 | 内容 |
|---|---|
| ベースライン | 現在の本番システム。他のすべての構成を測定する対照条件です。1 つだけ変数を変える間、これは固定したまま保ちます。 |
| データセット | 両条件に対して通す入力。時系列で比較可能にするため、実験間で同じデータセットを使い続けます。 |
| 変数 | 変更する設定。モデル、プロンプト、コンテキスト、ツールアクセス、エージェントアーキテクチャなど。下記の 変数 を参照してください。 |
| 比較対象の出力 | 各条件のもとでシステムが生成するもの。これらを比較することが、実験を実施する実質的な作業です。 |
一度に変更する変数は 1 つに絞ると役立つことが多いです。 ただし、変数同士は相互作用し、複数を同時に変える必要のある構成もあります。
変数
- モデル。 使っている AI モデル。推論重視のモデル、安価なモデル、速いモデルがあり、それぞれ品質・速度・コストでトレードオフがあります。
- プロンプト。 最もよく動かす変数。プロンプト実験を行う前に問いかけてください。失敗は仕様の問題 (曖昧または不完全なプロンプト) か、汎化の問題 (明確な指示をモデルが一貫して適用できていない) か? 後者は計測する価値があります。
- コンテキスト。 プロンプトに含める情報。取得したドキュメント、会話履歴、ユーザーメタデータなど。
- ツールアクセス。 ツールの追加・削除により、システムが取りうる経路が変わります。
- エージェントアーキテクチャ。 シングルエージェント vs マルチエージェント、どのフレームワークか、タスクをどう分解するか。 最も影響範囲の大きな選択で、最も分離が難しい変数です。
実験の使い方
中心となる流れは、変数を 1 つ選んで仮説を立て、両方の条件をデータセットに対して実行し、出力を比較し、何かを学び、それを繰り返すことです。
典型的な試みには次のようなものがあります。
- 新しいモデルが出た。システムの性能を向上させるだろうか?
- プロンプトを変更したら、システムの出力品質は向上するだろうか?
- 新しいエージェントの構成は、マルチエージェント構成より良い結果を生むだろうか?
定性的なところから始めましょう。 同じ入力、両条件、トレースを並べて比較します。 これがアプリにとっての「良い」が何かを学ぶ方法です。 実出力を定期的に読まなければ、メトリクスは誤読しやすいものです。
スコアは比較を具体的にしてくれます。 勝率、勝ちが入力全体に分散しているか集中しているか、コストやレイテンシーのトレードオフなど。 品質・価格・速度は同方向に動くことはまれです。 実験はそれらの綱引きを抽象論ではなく、自分たちのデータで見せてくれます。
どこから始めるか
インフラを整える前に、小さく手動の比較から始めましょう。 トレースを並べた数件の例から、最初の 1 時間で学べることは、セットアップに 1 週間かけて学べることよりも多いはずです。
- 20〜30 件の実例を集めます。本番トレースから引いてくるか、現実的な例を考えます。 全経路を網羅する必要はなく、アプリケーションが扱う現実の一断面で十分です。
- 設定を変更し、両方のバージョンを実行します。それ以外はすべて同一に保ちます。
- トレースを並べて読みます。評価器はまだ不要です。ただ読んでください。 何が違うか? どちらが実際に良く、なぜそうなのか? 失敗の種類に注目してください。プロンプトが不明瞭なのか、明確な指示をモデルが一貫して適用していないのか。 この区別が、次にどんな修正を試すべきかを教えてくれます。
- 直感が育ったら評価器を追加します。何度か手動で見比べた後で、何を探すべきかが分かるはずです。 それをコード化します。そこからスケールできます。
次のステップ
実験が改善につながったかを判断するには、結果を評価する必要があります。 次のセクションで 評価手法 について学んでください。
リリース前に一貫したテストを行うため、実験をリリースプロセスに統合します。
Last edited
