Skip to main content
LLM を活用したアプリケーションや AI エージェントは非決定的です。プロンプト、モデル、検索戦略、ツール設定、エージェントのワークフローを変更すると、応答品質、運用コスト、レイテンシー、ユーザー行動にそれぞれ異なる、予測しにくい形で影響します。RAGAS のような評価フレームワークは、個々の応答が品質基準を満たしているかどうかをスコアリングしますが、そのスコアだけでは、その変更がユーザーが本来の目的を達成する助けになっているかどうかまではわかりません。 Kameleoon Feature Experimentation の機能を使うと、生成AIアプリケーションや AI エージェントを支える設定をカスタマイズ、テスト、展開できます。フィーチャー変数は、その設定の一部(プロンプト、モデルパラメータ、検索戦略、ツール定義など)を保持するため、チームはアプリケーションコードの外で管理できます。各バリエーションは候補となる設定を表しており、再デプロイすることなく、より安全に反復、実験、リリースを行えます。 バリエーション間でトラフィックを分割し、複数の種類の指標を使ってその影響を比較します:
  • AI品質指標(正確性、根拠の妥当性、関連性、安全性、コンプライアンスなど)
  • エージェントパフォーマンス指標(ツールの使用成功やタスクの完了など)
  • 運用指標(レイテンシー、トークン消費量、エラー、コストなど)
  • ユーザーおよびビジネス指標(満足度、エスカレーション、コンバージョン、リテンション、収益など)
設定はソースコードではなくフィーチャーフラグの中にあるため、いつでも Kameleoon プラットフォームから直接、バリエーションを追加、編集、ロールバックできます。

評価と実験が解決する課題の違い

評価は、個々のモデルやエージェントの出力が定義された品質基準を満たしているかどうかを判断します。オブザーバビリティツールを使うと、その出力の背後にあるプロンプト、応答、トレース、検索ステップ、ツール呼び出しを確認できます。一方、実験は、基盤となる設定の変更がユーザーやビジネスに測定可能な改善をもたらすかどうかを判断するものであり、評価ともオブザーバビリティとも異なる問いに答えます。 たとえば、LLM ジャッジがあるプロンプトを別のプロンプトより根拠が明確だと評価するとします。Kameleoon の実験は、その同じプロンプトがタスク完了率の向上、エスカレーションの減少、満足度の向上をもたらすか、あるいはレイテンシーやコストに影響するか、つまりチームが責任を負うべき成果にどう影響するかを教えてくれます。 Kameleoon は、LLM のオブザーバビリティや評価のスタックを置き換えるものではありません。RAGAS、LLM ジャッジ、または人によるレビュープロセスから得られた評価スコアを、数値を持つカスタムゴールとして Kameleoon に取り込み、実験がすでに測定している行動指標やビジネスゴールと合わせて追跡することで、モデルレベルの品質シグナルと、統計的に信頼できる実際のユーザー影響の測定とを結び付けられます。 ほとんどの AI 実験では、単一の指標に頼るのではなく、複数の種類の指標を組み合わせます:
  • ユーザーまたはビジネスの成果をプライマリゴールに設定します。
  • AI品質指標をセカンダリゴールまたはガードレールとして追跡します。
  • レイテンシー、コスト、エラー、安全性を運用ガードレールとしてモニタリングします。
  • 自動化されたジャッジのスコアを大規模に信頼する前に、人によるレビュー済みのサンプルと照合して検証します。

仕組み

フィーチャーフラグは各設定(たとえばプロンプト)をフィーチャー変数の値として保存し、テストしたいオプションごとに1つのバリエーションを設けます。訪問者がアプリケーションにアクセスすると、Kameleoon SDK は訪問者にバリエーションを割り当て、対応する値を返します。この値をアプリケーションコードが使って LLM を呼び出したり、エージェントを構成したりします。フィーチャーフラグに紐づけられたゴールは、訪問者が LLM を活用した機能や AI エージェントとやり取りしたとき、たとえばフォローアップの質問をしたり、その助けを借りてタスクを完了したりしたときに、コンバージョンを記録します。十分なトラフィックを収集したら、各バリエーションのコンバージョン率を、追跡している AI 品質指標や運用指標とあわせて比較し、どの設定が最も効果的かを判断します。

前提条件

  • Feature Experimentation 用に設定されたプロジェクトを持つ Kameleoon アカウント。
  • アカウントのクライアント ID とクライアントシークレット。これらの値を確認するには、API認証情報 を参照してください。
  • Kameleoon SDK をインストールできる Python アプリケーション。

Kameleoon でプロンプト実験を設定する

アプリケーションコードに手を加える前に、Kameleoon プラットフォームでフィーチャーフラグ、プロンプトのバリエーション、追跡するゴールを設定します。

フィーチャーフラグを作成する

プロンプトのバリエーションを保持し、実験の展開を制御するフィーチャーフラグを作成します。
  1. Kameleoon アプリで、Features > Flags & Experiments > New feature flag をクリックします。
  2. 名前を入力します (例: LLM prompt test)。フラグを使用するプロジェクトを選択します。
  3. Description フィールドに、フラグが何を制御するかを記録し、チームの他のメンバーがその目的を理解できるようにします。
  4. Validate をクリックします。
詳細については、フィーチャーフラグを作成する を参照してください。

プロンプトをフィーチャー変数に保存する

プロンプトのテキストを保持するフィーチャー変数を追加します。これにより、アプリケーションコードを編集せずに、Kameleoon プラットフォームからプロンプトを変更できます。
  1. フラグのページで、左サイドバーの Set Up > Variables > Add Variable をクリックします。
  2. 変数の TypeString に設定します。
  3. Variable Key を入力します (例: prompt_template)。
  4. Default Value に、アプリケーションが現在使用しているプロンプトを設定します。この値は、実験に含まれていない訪問者に配信されます。
  5. Save をクリックします。
prompt_template という名前の String 型変数と、プロンプトテキストのデフォルト値のプレースホルダーを示す Variables 設定画面。
詳細については、フィーチャー変数の定義 を参照してください。

プロンプトごとにバリエーションを作成する

テストしたいプロンプトごとに1つのバリエーションを作成し、それぞれで prompt_template 変数に対応するテキストを設定します。
  1. 左サイドバーで Set Up > Variations > Add variation をクリックします。
  2. バリエーションの Name を入力します (例: Detailed summary)。
  3. このバリエーションの prompt_template 変数にプロンプトのテキストを設定します。
  4. Save をクリックします。
  5. テストしたい追加のプロンプトごとに、これらの手順を繰り返します。
Detailed summary という名前のバリエーションで、prompt_template 変数がプロンプトの値に設定されている Variations 設定画面。
詳細については、機能のバリエーションを定義する を参照してください。

エンゲージメントを測定するゴールを紐づける

フィーチャーフラグにゴールを紐づけて、どのプロンプトのバリエーションがより多くのエンゲージメントを生み出すかを Kameleoon が測定できるようにします。Kameleoon は統合されたプラットフォームであるため、他のチームが定義したトランザクションのゴールなど、組織内に既に存在するゴールを紐づけることも、LLM を活用した機能専用のゴールを新たに作成することもできます。
  1. フラグのページで、Set Up メニューの Goals > Add goal をクリックします。
  2. 既存のゴールを選択するか、Create a new goal をクリックして、訪問者が LLM を活用した機能とやり取りしたときに発火するカスタムゴールなどを定義します。
  3. Save をクリックします。
フィーチャーフラグに紐づけられたゴールと、既存のゴールを追加するか新しいゴールを作成するオプションを示す Goals 設定画面。
バックエンドからカスタムゴールを発火させる方法など、ゴールの種類の詳細については、ゴールの作成 を参照してください。

実験を展開する

プロンプトのバリエーション間でトラフィックを分割する実験ルールを作成し、環境を有効化してデータの収集を開始します。
  1. Rollout Planner で、対象としたい環境 (例: Production) を選択します。
  2. Add a rule > Experiment をクリックします。
  3. Variations to serve の下で、各プロンプトのバリエーションを追加し、それぞれの露出率を設定します。たとえば、2つのバリエーションにトラフィックを均等に50%ずつ振り分けます。
  4. テストしたい訪問者 (例: アプリケーションに到達するすべての訪問者) を含むように、ルールのターゲティングを設定します。
  5. 環境の ON/OFF トグルを ON に切り替えます。
  6. Save をクリックします。
すべての訪問者をターゲットとし、トラフィックを2つのバリエーションに50/50で振り分ける実験ルールを示す、Production 環境の Rollout Planner。
詳細については、フィーチャー実験を作成する を参照してください。 ルールを保存すると、Kameleoon は訪問者にバリエーションを割り当て、対応するプロンプトの配信を開始します。後でプロンプトを変更したりバリエーションを追加したりする場合は、Kameleoon プラットフォーム上で直接編集します。これらの変更を適用するために、アプリケーションを再デプロイする必要はありません。

アプリケーションでプロンプトを取得する

Kameleoon の Python SDK をインストールし、訪問者に割り当てられたプロンプトを取得して、訪問者が LLM を活用した機能とやり取りしたときにコンバージョンを追跡します。同じパターンは、Node.js、Java、Go を含む、任意の Kameleoon サーバーサイド SDK にも当てはまります。
  1. SDK を依存関係としてインストールします。
  2. サイトコードと認証情報を使ってクライアントを初期化します。
  3. LLM を呼び出す前に割り当てられたプロンプトを取得し、訪問者が LLM を活用した機能とやり取りしたときにコンバージョンを追跡します。
    LLM にリクエストを送る前に、訪問者の visitor_code を指定して get_prompt_for_visitor() を呼び出し、返された値をプロンプトとして使用します。訪問者が質問を送信したり応答を受け取ったりするなど、LLM を活用した機能とやり取りしたときに track_llm_interaction() を呼び出します。
各訪問者に一意の ID を割り当てるには get_visitor_code() を使用します。データを追跡する前に訪問者の同意が必要なアプリケーションでは set_legal_consent() を使用します。クライアントの初期化と構成に関する完全なリファレンスについては、Python SDK 開発者ガイド を参照してください。

モニタリングと改善

フィーチャーフラグの結果ページを開き、紐づけたゴールに対する各プロンプトのバリエーションのコンバージョン率を比較します。アプリケーションが get_variation()track_conversion() を呼び出すたびに、Kameleoon は露出とコンバージョンを自動的に追跡するため、追加の計測は必要ありません。AI品質指標や運用指標もゴールとして紐づけている場合は、どのバリエーションを展開するか決定する前に、それらをコンバージョン率とあわせて比較します。 詳細については、フィーチャーフラグの全体的な結果を表示する を参照してください。

次のステップ

  • カスタムデータ、クロスデバイス実験、ターゲティング条件などの高度なオプションについては、Python SDK リファレンス を参照してください。
  • 実験を特定のオーディエンスにターゲティングするには、高精度なセグメンテーション条件 を紐づけます。
  • モデルパラメータ、検索設定、ツール定義など、LLM を活用した機能や AI エージェントの他の部分を変数化するには、フィーチャー変数 を確認してください。
  • 評価パイプラインからの AI 品質スコアとビジネス指標など、複数のゴールを同じフラグに紐づけることで、複数の観点から一度に設定を比較できます。詳細については、フィーチャーフラグのゴールを作成する を参照してください。