自分を欺かずにLLMプロンプトをA/Bテストする方法

かつて、私はサポートアシスタントを構築し、それが成功作になると確信していました。30件のテストケースを実行したところ、新しいプロンプトの方がスコアが高かったため、そのままリリースしました。

しかし6時間後、サポートのキューは苦情で埋め尽くされました。その日の夜、変更をロールバックせざるを得ませんでした。

高かったスコアは偽物でした。30件の例では、真の改善と単なる運を区別するには不十分です。その数値は、ただのノイズに過ぎませんでした。

以下に、そのような間違いを犯さずにプロンプトをテストする方法を紹介します。

  • 小規模なテストでは、大きな変化しか捉えられません。わずかな改善を見つけたい場合は、より多くの例が必要です。極めて小さな変化を見つけるには、1,000件以上の例が必要になることもあります。

  • 両方のバージョンに同じ質問を使用してください。バージョンAに一連の質問を与え、バージョンBに別の質問を与えるようなことはしないでください。質問には難易度の差があります。もしバージョンBに簡単な質問が割り当てられた場合、たとえ性能が悪くても、結果は良く見えてしまいます。両方のバージョンに対して、全く同じ質問セットを実行してください。

  • 平均だけでなく、範囲（レンジ）に注目してください。平均値だけでは、改善の幅がどれほど大きいのかは分かりません。起こりうる最小の改善幅と最大の改善幅の範囲を報告するようにしてください。もしその範囲にゼロが含まれる場合は、リリースすべきではありません。

  • 適切なスコアリング手法を選択してください。 • 絶対的な品質にはチェックリストを使用する。 • トーンや役立ちやすさといった曖昧な品質には、サイドバイサイド（並列）比較を使用する。

  • 複数のバージョンがある場合はバンディットを使用してください。3つ以上のバージョンがあり、ユーザーの不満を最小限に抑えたい場合は、バンディットが有効です。学習が進むにつれて、より優れたバージョンに多くのトラフィックを割り当てます。これにより、ユーザーが何週間も悪い回答を見続ける事態を防げます。

以下の罠を避けてください：

  • 範囲を確認せずに平均値を比較すること。
  • バージョンごとに異なる質問セットを使用すること。
  • テストの途中でスコアラーを変更すること。
  • 数値が良くなった瞬間にテストを止めること。
  • 同時にあまりにも多くの指標を監視すること。これは、偽の勝利（偶然の成功）を見逃す可能性を高めます。
  • 人間の判断と比較して検証する前に、スコアラーを信頼してしまうこと。

難しいのはテストを実行することではありません。結果が本物であるかどうかを見極めることこそが、難しいのです。

Source: https://dev.to/kartik-nvjk/how-i-ab-test-llm-prompts-without-fooling-myself-528f

Optional learning community: https://t.me/GyaanSetuAi