LLM プロンプトと AI エージェントの設定を実験する

LLM を活用したアプリケーションや AI エージェントは非決定的です。プロンプト、モデル、検索戦略、ツール設定、エージェントのワークフローを変更すると、応答品質、運用コスト、レイテンシー、ユーザー行動にそれぞれ異なる、予測しにくい形で影響します。RAGAS のような評価フレームワークは、個々の応答が品質基準を満たしているかどうかをスコアリングしますが、そのスコアだけでは、その変更がユーザーが本来の目的を達成する助けになっているかどうかまではわかりません。 Kameleoon Feature Experimentation の機能を使うと、生成AIアプリケーションや AI エージェントを支える設定をカスタマイズ、テスト、展開できます。フィーチャー変数は、その設定の一部(プロンプト、モデルパラメータ、検索戦略、ツール定義など)を保持するため、チームはアプリケーションコードの外で管理できます。各バリエーションは候補となる設定を表しており、再デプロイすることなく、より安全に反復、実験、リリースを行えます。たとえば、AI カスタマーサポートエージェントでは、システムプロンプト、モデル、推論エフォート、検索設定を4つの独立したフィーチャー変数として公開すれば、デプロイのたびに待つことなく、この4つすべての新しい組み合わせを一度にテストできます。バリエーション間でトラフィックを分割し、複数の種類の指標を使ってその影響を比較します:

AI品質指標(正確性、根拠の妥当性、関連性、コンテキストの品質、安全性、コンプライアンスなど)
エージェントパフォーマンス指標(ツールの使用成功やタスクの完了など)
運用指標(レイテンシー、トークン消費量、エラー、コストなど)
ユーザーおよびビジネス指標(満足度、エスカレーション、コンバージョン、リテンション、収益など)

設定はソースコードではなくフィーチャーフラグの中にあるため、いつでも Kameleoon プラットフォームから直接、バリエーションを追加、編集、ロールバックできます。

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

評価は、個々のモデルやエージェントの出力が定義された品質基準を満たしているかどうかを判断します。オブザーバビリティツールを使うと、その出力の背後にあるプロンプト、応答、トレース、検索ステップ、ツール呼び出しを確認できます。一方、実験は、基盤となる設定の変更がユーザーやビジネスに測定可能な改善をもたらすかどうかを判断するものであり、評価ともオブザーバビリティとも異なる問いに答えます。たとえば、LLM ジャッジは、カスタマーサポートエージェントの書き直したシステムプロンプトを、現在のシステムプロンプトより根拠が明確だと評価するかもしれません。Kameleoon の実験は、チームが責任を負うべき問い、つまりその同じ設定が人間へのエスカレーションなしにより多くのチケットを解決するかどうか、そしてそのためにレイテンシーとトークン消費の面でどれだけのコストがかかるかに答えます。 Kameleoon は、LLM のオブザーバビリティや評価のスタックを置き換えるものではありません。RAGAS、LLM ジャッジ、または人によるレビュープロセスから得られた評価スコアを、カスタムゴールとして Kameleoon に取り込み、実験がすでに測定している行動指標やビジネスゴールと合わせて追跡することで、モデルレベルの品質シグナルと、統計的に信頼できる実際のユーザー影響の測定とを結び付けられます。ほとんどの AI 実験では、単一の指標に頼るのではなく、複数の種類の指標を組み合わせます:

ユーザーまたはビジネスの成果をプライマリゴールに設定します。
AI品質指標をセカンダリゴールまたはガードレールとして追跡します。
レイテンシー、コスト、エラー、安全性を運用ガードレールとしてモニタリングします。
自動化されたジャッジのスコアを大規模に信頼する前に、人によるレビュー済みのサンプルと照合して検証します。

仕組み

LLM アプリケーションや AI エージェントを対象とした実験は、Kameleoon 内で5つの段階を経て進みます。

フィーチャーフラグが設定を保持します。 プロンプトやモデル名など、設定の各部分がフラグ上のフィーチャー変数になります。
各バリエーションが独自の値を設定します。 バリエーションとは、すべての変数に値を持つ、1つの完全な候補設定です。
SDK が各訪問者にバリエーションを割り当てます。 訪問者がアプリケーションにアクセスすると、アプリケーションコードがフラグをリクエストし、割り当てられたバリエーションの値を受け取り、その値を使って LLM を呼び出したり、エージェントを構成したりします。
ゴールが結果を記録します。 アプリケーションは、応答が許容可能な品質またはレイテンシーの閾値を超えた場合にのみ発生するガードレールのコンバージョンを含め、フラグに紐づけられた各ゴールに対してコンバージョンを追跡します。
結果ページがバリエーションを比較します。 十分なトラフィックを収集したら、紐づけたすべてのゴールにわたってバリエーションを比較し、どの設定を展開するかを決定します。

前提条件

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

Kameleoon で AI エージェントの実験を設定する

以降の手順では、次のような具体的な実験を構築します。書き直したシステムプロンプトを、より高性能なモデルおよびより高い推論エフォートと組み合わせることで、カスタマーサポート AI エージェントがより多くのチケットを単独で解決できるようになるか、そしてその際にレイテンシーを許容範囲内に保てるか、という実験です。アプリケーションコードに手を加える前に、Kameleoon プラットフォームでフィーチャーフラグ、バリエーション、追跡用のゴールを設定します。

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

エージェントの設定を保持し、実験の展開を制御するフィーチャーフラグを作成します。

Kameleoon アプリで、Features > Flags & Experiments > New feature flag をクリックします。
名前を入力します。たとえば AI support agent config とし、フラグを使用するプロジェクトを選択します。
Description フィールドに、フラグが何を制御するかを記録します。たとえば「サポートチャットボットのシステムプロンプト、モデル、推論エフォート、検索設定を制御する」のように記載すると、チームの他のメンバーがその目的を理解できます。
Validate をクリックします。
Kameleoon がフラグの名前からフィーチャーキーを生成します。生成されたキーをそのまま使うか、ai_support_agent に編集します。アプリケーションコードはこのキーでフラグを識別し、名前では識別しないため、両者を一致させる必要があります。

新規作成したフラグは OFF 状態で始まります。設定が完了した後、Rollout Planner でフラグをオンにします。詳細については、フィーチャーフラグを作成するを参照してください。

エージェントの設定をフィーチャー変数に保存する

テストしたいエージェントの設定の各部分について、フィーチャー変数を1つずつ追加します。こうしておくと、アプリケーションコードを編集せずに、Kameleoon プラットフォームからそれぞれの値を変更できます。この例では、次の4つの変数をテストします。

変数キー	タイプ	デフォルト値の例
`system_prompt`	String	`You are the support assistant for Kameleoon's help center. Answer only using the article excerpts provided below, and say you'll escalate to a human agent if the answer isn't in them.`
`model`	String	`claude-sonnet-5`
`reasoning_effort`	String	`low`
`retrieval_top_k`	Number	`3`

フラグのページで、左サイドバーの Set Up > Variables > Add Variable をクリックします。
変数の Type を表に合わせて String または Number に設定します。
表にある Variable Key を入力します。たとえば system_prompt です。
Default Value に、アプリケーションが現在本番環境で使用している値を設定します。後で作成する各バリエーションは、これらの値があらかじめ入力された状態で始まるため、正確なデフォルト値を設定しておくと手間が省け、いざというときに立ち返れる動作確認済みの設定にもなります。
Save をクリックします。
表に残っている各変数について、これらの手順を繰り返します。

system_prompt、model、reasoning_effort、retrieval_top_k という4つの変数がそれぞれのデフォルト値とともに表示されている Variables 設定画面。

Kameleoon には Enum タイプもあります。許可する値をカンマ区切りのリストとして入力しておくと、バリエーションを定義するときにドロップダウンから選択できるようになります。決まった値のセットしか受け付けない変数では、この Enum タイプの使用を検討してください。ドロップダウンを使うことで、タイプミスがそのまま LLM プロバイダーに渡ってしまうのを防げます。この例では、model を claude-sonnet-5,claude-opus-5 というリストを持つ Enum として、reasoning_effort を low,medium,high というリストを持つ Enum として定義できます。

詳細については、フィーチャー変数の定義を参照してください。

バリエーションを作成する

配信ルールが配信できるのは Off か、自分で作成したバリエーションのいずれかです。そのため、A/B 比較を行うには、現在の設定用のバリエーションに加えて、テストしたい新しい設定ごとにバリエーションが必要です。この例では、アプリケーションが本番環境ですでに配信している設定をそのまま反映した Baseline と、書き直してより明確にしたプロンプトをより高性能なモデルおよびより高い推論エフォートと組み合わせたチャレンジャーである Grounded, high reasoning の、2つのバリエーションを作成します。

アプリケーションがフラグを読み取れない場合に備えたハードコードのフォールバックをすでに用意していたとしても、実験の比較対象として Off を使わないでください。Off は、フラグをオフにした状態のアプリケーションを表しており、フラグのフィーチャー変数を一切持ちません。そのため、system_prompt や model を Off の割り当てから読み取ろうとするコードは、何も値を受け取れません。ハードコードのフォールバックもこの問題を解決しません。フォールバックは Kameleoon ではなくソースコード内にあるため、後で勝った設定を昇格させる際にもデプロイが必要になり、フラグの変数が変更された場合にフォールバックを同期させる仕組みもありません。代わりに明示的な Baseline バリエーションを作成してください。そうすれば、現在の設定を、テスト対象のチャレンジャーと並べて、可視化された編集可能な状態に保てます。

バリエーション	`system_prompt`	`model`	`reasoning_effort`	`retrieval_top_k`
Baseline	デフォルト値と同じ	`claude-sonnet-5`	`low`	`3`
Grounded, high reasoning	`You are the support assistant for Kameleoon's help center. Using only the article excerpts provided below, answer the visitor's question and cite the specific article title for each claim you make. If the excerpts don't fully answer the question, say so explicitly and escalate to a human agent instead of guessing.`	`claude-opus-5`	`high`	`5`

左サイドバーで Set Up > Variations > Add variation をクリックします。
Name に、たとえば Baseline を入力し、対応する Variation Key に baseline を入力します。各変数にはデフォルト値があらかじめ入力されているため、4つとも変更せずそのままにします。
Save をクリックします。
Grounded, high reasoning(キー grounded_high_reasoning)という名前の2つ目のバリエーションについて、これらの手順を繰り返し、4つの変数それぞれを、このバリエーション用の表の値に一致するよう編集します。
Save をクリックします。

Baseline をデフォルト値のままにし、Grounded, high reasoning では system_prompt、model、reasoning_effort、retrieval_top_k をそれぞれ上書きした値に設定した、2つのバリエーションを示す Variations 設定画面。

詳細については、機能のバリエーションを定義するを参照してください。

ビジネスへの影響、AI品質、レイテンシーのゴールを紐づける

応答品質だけでなく、チームが責任を負うべき成果全体にわたってバリエーションを比較できるよう、フィーチャーフラグに複数のゴールを紐づけます。Kameleoon は統合されたプラットフォームであるため、組織内にすでに存在するゴールを紐づけることも、LLM を活用した機能専用のゴールを新たに作成することもできます。この例では、AI エージェントにとって重要な指標カテゴリーからそれぞれ1つずつ、合計3つのゴールを紐づけます。

ゴール	指標カテゴリー	タイプ	何に答えるか
`Ticket resolved without escalation`	ユーザーおよびビジネス	Custom goal	エージェントは実際に訪問者の問題を解決したか
`Response groundedness score`	AI品質	Custom goal	許容可能な根拠の妥当性の閾値を下回る応答が増えたか
`Response latency`	運用	Custom goal	許容可能なレイテンシーの閾値を上回る応答が増えたか

訪問者のブラウザではなくアプリケーションが発火させるため、3つとも、バックエンドがトリガーする Custom goals として作成します。各ゴールを作成する際は、Type で Custom goal を選択し、続けてSDK 経由のバックエンドイベントのオプションを選択します。

フラグのページで、Set Up メニューの Goals > Add goal をクリックします。
既存のゴールを選択するか、Create a new goal をクリックして新しいゴールを定義します。Kameleoon は最初に紐づけたゴールを自動的に Primary goal に設定するため、Ticket resolved without escalation を最初に追加します。
Save をクリックします。
Response groundedness score と Response latency についても同じ手順を繰り返します。これらは Kameleoon によって Secondary goals として紐づけられます。

ゴールの区分が意図したものと異なる場合は、そのゴールの横にある3つのドットをクリックして、どのゴールをプライマリにするかを再設定します。

Response groundedness score と Response latency は数値を持ちません。アプリケーションは、ある応答が許容可能な閾値(応答が遅すぎるか、根拠が不十分すぎるか)を超えたかどうかを判断し、超えた場合にのみそのゴールのコンバージョンを発生させます。Kameleoon はその後、各ゴールのコンバージョン率をバリエーションごとに報告し、どれだけの割合の応答がその閾値を超えたかを示します。

フィーチャーフラグに紐づけられた3つのゴール、Ticket resolved without escalation、Response groundedness score、Response latency を示す Goals 設定画面。

バックエンドからカスタムゴールを発火させる方法など、ゴールの種類の詳細については、ゴールの作成を参照してください。

実験を展開する

2つのバリエーション間でトラフィックを分割する Experiment ルールを追加し、フラグをオンにしてデータの収集を開始します。Add a rule メニューは、ルールを目的別にグループ化しています。Feature testing には、トラフィックを分割してバリエーション間の統計的に有意な比較を測定する Experiment ルールが含まれます。一方、Feature delivery には、比較を行わずに単一のバリエーションを徐々に、または特定のセグメントに向けてリリースする Progressive delivery と Targeted delivery が含まれます。A/B テストには Experiment ルールが必要です。

Rollout Planner で、対象としたい環境を選択します。たとえば Production です。
Add a rule をクリックし、Feature testing の下で Experiment を選択します。
Variations to serve の下で、Baseline を Control に設定し、Grounded, high reasoning を Treatment として追加します。Kameleoon はすべてのトリートメントの結果をコントロールと比較して測定するため、コントロールにはすでに本番環境で実行している設定を指定する必要があります。
2つのバリエーション間でトラフィック配分を設定します。たとえば、それぞれ50%ずつです。
テストしたい訪問者を含むよう、ルールのターゲティングを設定します。たとえば、サポート会話を開始したすべての訪問者です。
Then, for everyone else in production, serve のドロップダウンで Baseline を選択します。ルールのターゲティング対象外となった訪問者には、現在の検証済みの設定が配信され、アプリケーションはこれらの訪問者に対しても完全な変数セットを取得できます。
フラグの ON/OFF トグルを ON に切り替えます。
Save をクリックします。

Production 環境の Rollout Planner。Feature testing の下に Experiment ルールがあり、Baseline が Control に設定され、Grounded, high reasoning が Treatment として追加され、トラフィックが50/50で分割されている様子を示しています。

詳細については、フィーチャー実験を作成するを参照してください。ルールを保存すると、Kameleoon は訪問者に設定を割り当て、対応する変数の配信を開始します。後で値を変更したりバリエーションを追加したりする場合は、Kameleoon プラットフォーム上で直接編集します。これらの変更を適用するために、アプリケーションを再デプロイする必要はありません。

アプリケーションで設定を取得する

Kameleoon の Python SDK をインストールし、訪問者に割り当てられた設定を取得して、訪問者のチケットが進行するのに合わせて各ゴールのコンバージョンを追跡します。同じパターンは、Node.js、Java、Go を含む、任意の Kameleoon サーバーサイド SDK にも当てはまります。Kameleoon が提供するのは設定値だけであるため、同じパターンは OpenAI Agents SDK、Claude Agent SDK、LangChain などの任意のエージェントフレームワークでも機能します。エージェントのコードの大半は Python または TypeScript で実行されるため、アプリケーションに合わせていずれかを選択してください。

SDK を依存関係としてインストールします。
pip install kameleoon-client-python

サイトコードと認証情報を使ってクライアントを初期化します。environment には、Experiment ルールを保持している Rollout Planner の環境と同じ値を設定します。異なる値を設定すると、SDK が別の環境のルールを評価してしまいます。

from kameleoon import KameleoonClientConfig, KameleoonClientFactory

SITE_CODE = "a8st4f59bj"
FEATURE_KEY = "ai_support_agent"
TASK_GOAL_ID = 12345      # "Ticket resolved without escalation"
QUALITY_GOAL_ID = 12346   # "Response groundedness score"
LATENCY_GOAL_ID = 12347   # "Response latency"

configuration = KameleoonClientConfig(
    client_id="your-client-id",
    client_secret="your-client-secret",
    environment="production",
)
kameleoon_client = KameleoonClientFactory.create(SITE_CODE, configuration)

if not await kameleoon_client.wait_init_async():
    # SDK の初期化に失敗しました。本番環境の設定にフォールバックします。
    ...

LLM を呼び出す前に割り当てられた設定を取得し、訪問者のチケットが進行するのに合わせて各ゴールのコンバージョンを追跡します。

from anthropic import AsyncAnthropic

judge_client = AsyncAnthropic()

# フラグのデフォルト値を反映したもの。SDK が Kameleoon に到達できない場合に使用します。
FALLBACK_CONFIG = {
    "system_prompt": "You are the support assistant for Kameleoon's help center. ...",
    "model": "claude-sonnet-5",
    "reasoning_effort": "low",
    "retrieval_top_k": 3,
}

# 応答がこの値を超えるとレイテンシーのガードレールに違反します。
LATENCY_THRESHOLD_MS = 5000
# 応答がこの値を下回ると根拠の妥当性のガードレールに違反します。
QUALITY_THRESHOLD = 0.7


def get_agent_config_for_visitor(visitor_code: str) -> dict:
    try:
        variation = kameleoon_client.get_variation(visitor_code, FEATURE_KEY)
    # これらの例外クラスは Kameleoon SDK に同梱されています。
    except (FeatureNotFound, FeatureEnvironmentDisabled, VisitorCodeInvalid):
        # 訪問者が実験の対象外なので、動作確認済みの設定を配信します。
        return FALLBACK_CONFIG

    variables = variation.variables
    if not variables:
        return FALLBACK_CONFIG

    return {
        "system_prompt": variables["system_prompt"].value,
        "model": variables["model"].value,
        "reasoning_effort": variables["reasoning_effort"].value,
        "retrieval_top_k": int(variables["retrieval_top_k"].value),
    }


def track_ticket_resolved(visitor_code: str) -> None:
    kameleoon_client.track_conversion(visitor_code, TASK_GOAL_ID)


# LLM-as-a-judge: `response` に含まれる事実の主張を抽出し、
# `retrieved_context` がそれを裏付けている割合をスコアリングします。
async def score_response_groundedness(retrieved_context: str, response: str) -> float:
    judge_prompt = (
        "List the factual claims in RESPONSE. For each claim, check "
        "whether CONTEXT supports it. Return only a number from 0 to 1: "
        "the fraction of RESPONSE claims that CONTEXT supports.\n\n"
        f"CONTEXT:\n{retrieved_context}\n\nRESPONSE:\n{response}"
    )
    judge_reply = await judge_client.messages.create(
        model="claude-opus-5",
        max_tokens=10,
        messages=[{"role": "user", "content": judge_prompt}],
    )
    return float(judge_reply.content[0].text)


def track_quality_score(visitor_code: str, score: float) -> None:
    if score < QUALITY_THRESHOLD:
        kameleoon_client.track_conversion(visitor_code, QUALITY_GOAL_ID)


def track_response_latency(visitor_code: str, latency_ms: float) -> None:
    if latency_ms > LATENCY_THRESHOLD_MS:
        kameleoon_client.track_conversion(visitor_code, LATENCY_GOAL_ID)

LLM にリクエストを送る前に、訪問者の visitor_code を指定して get_agent_config_for_visitor() を呼び出し、返された値を使ってリクエスト、つまりシステムプロンプト、モデル、推論エフォート、取得するドキュメント数を組み立てます。エージェントが人間へのエスカレーションなしに訪問者の問題を解決したときは track_ticket_resolved() を呼び出します。エージェントが応答した後、取得したドキュメントと生成された応答を指定して score_response_groundedness() を呼び出し、返されたスコアを track_quality_score() に渡します。各 LLM 呼び出しの後、応答時間をミリ秒単位で指定して track_response_latency() を呼び出します。track_quality_score() と track_response_latency() はどちらも、値が閾値を超えた場合にのみコンバージョンを追跡するため、両方のガードレールの範囲内にとどまる応答はどちらのゴールも発生させません。 score_response_groundedness() は、LLM-as-a-judge の最小限の例です。応答の主張を取得したコンテキストと比較し、それを裏付けている割合を返すようモデルに求めます。RAGAS の Factual Correctness 指標も同じ基本的な考え方をスコアリングしており、自作のジャッジプロンプトの代わりに、この指標やチームがすでに使用している他の評価フレームワークに置き換えることができます。 Kameleoon はその後、各ゴールのコンバージョン率をバリエーションごとに報告し、生のスコアやミリ秒の値そのものを追跡するのではなく、品質またはレイテンシーのガードレールに違反した応答の割合を示します。

訪問者が実験の対象外になるケースには、必ず対処してください。プロンプトやモデルが欠けた状態で組み立てた LLM 呼び出しは、リクエスト時に失敗します。ルックアップが例外を発生させたり None を返したりするままにせず、完全なフォールバック設定を返すようにしてください。

各訪問者に一意の ID を割り当てるには get_visitor_code() を使用します。データを追跡する前に訪問者の同意が必要なアプリケーションでは set_legal_consent() を使用します。クライアントの初期化と構成に関する完全なリファレンスについては、Python SDK 開発者ガイドを参照してください。

モニタリングと改善

フィーチャーフラグの結果ページを開き、紐づけた3つのゴールすべてにわたって Baseline と Grounded, high reasoning を比較します。アプリケーションが get_variation() と track_conversion() を呼び出すたびに、Kameleoon は露出とコンバージョンを自動的に追跡するため、追加の計測は必要ありません。 3つのゴールは、個別にではなくまとめて読み取ってください。この例のチャレンジャーは、より大規模なモデルをより高い推論エフォートで実行し、より多くのドキュメントを取得するため、会話あたりのコストが高くなり、レイテンシーのガードレールに違反しやすくなります。Ticket resolved without escalation の向上がこの代償に見合うのは、Response latency と Response groundedness score のコンバージョン発生率が、Baseline よりもチャレンジャーで高くならない場合に限られます。プライマリゴールが改善していても、ガードレールのコンバージョン率が許容できる範囲を超えて上昇している場合は、Baseline の配信を続け、チャレンジャーを見直してください。

パフォーマンスが低下したチャレンジャーを見つけるために、結果ページを自分で監視し続ける必要はありません。実験ルールにロールバック条件を追加すると、たとえば Response groundedness score が定義したしきい値を超えたときにルールを無効化するよう設定でき、条件が満たされた時点で Kameleoon がルールを自動的に無効化し、すべての訪問者に Baseline の配信を再開します。詳細については、機能の自動ロールバックを参照してください。

チャレンジャーが勝った場合は、それを昇格させます。各変数の Default Value を、勝った設定の値に更新して新しい動作確認済みのベースラインとし、その後、実験ルールを終了するか、次の仮説のためにそのバリエーションを再利用します。詳細については、フィーチャーフラグの全体的な結果を表示するを参照してください。

次のステップ

カスタムデータ、クロスデバイス実験、ターゲティング条件などの高度なオプションについては、Python SDK リファレンスを参照してください。
実験を特定のオーディエンス、たとえば特定のプロダクト領域のタグが付いたチケットのみにターゲティングするには、高精度なセグメンテーション条件を紐づけます。
レイテンシーと並んでトークンコストのゴールを追加し、会話あたりに消費したトークン数を数値のカスタムゴールとして追跡すると、Sonnet 構成と Opus 構成の差を直接コストとして把握できます。詳細については、ゴールの作成を参照してください。
retrieval_top_k を増やすことで、エージェントが取得するドキュメントの関連性が実際に向上するかどうかを確認するために、コンテキストの関連性を測るゴールを追加します。根拠が明確な回答であっても、参照元のドキュメントが誤っている場合があるためです。詳細については、ゴールの作成を参照してください。
各応答の後にサムズアップ/サムズダウンのコントロールを表示するなど、直接的なユーザーフィードバックのゴールを追加すると、この例がすでに追跡している行動シグナルと合わせて訪問者の満足度を捉えられます。詳細については、ゴールの作成を参照してください。
temperature、ツール定義、リトライ時のフォールバックモデルなど、エージェントの設定の他の部分をテストするには、変数を追加します。詳細については、フィーチャー変数の定義を参照してください。
大規模に信頼する前に、Response groundedness score の閾値を、自動スコアのサンプルを人によるレビューと比較して検証します。詳細については、フィーチャーフラグのゴールを作成するを参照してください。

ホーム

はじめに

実験

アセット

実験アナリティクス

Webパーソナライゼーション

レコメンデーションとマーチャンダイジング

製品ターゲティングと社会的証明

アカウントとチーム管理

プロジェクト管理

AIアシスト

AI機会検出

AI予測ターゲティング

FAQ

LLM プロンプトと AI エージェントの設定を実験する

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

仕組み

前提条件