はじめに
前回FoundryでAIエージェントを作ったので、今回は評価機能を試す。
1. エージェントを評価する
1.1 評価ジョブを作成する
評価タブから 「+ 新しい評価（New Evaluation）」 を選択し、以下の項目をセットアップして評価ジョブを実行。
| 設定項目 | 設定した内容・値 | 概要・目的 |
|---|---|---|
| ターゲット (評価対象) | エージェント | 作成したエージェントを選択 (同一エージェントの複数のバージョンを一度に評価することも可能) |
| スコープ (個々のターン or 会話全体) | 会話 | 一問一答だけでなく一連の対話として評価 |
| データセット | 既存のデータセット | 予め準備したJSONLをアップロードして使用 |
| 使用したエバリュエータ | ・TaskCompletion (タスク完了度) ・CustomerSatisfaction (顧客満足度) ・Coherence (一貫性・論理性) ・Groundedness (根拠性・ハルシネーションの無さ) |
自動採点を行わせる指標を選択 |
| 評価用モデル (Evaluator Model) | gpt-terra | 回答の採点を担当するLLM |
1.2 評価ジョブを実行する
評価ジョブの設定は揃え、システムプロンプトを変えて2回実行した。
🔹 1回目 : ハルシネーション防止を重視
AIの嘘（ハルシネーション）を極限まで減らすため、無駄をそぎ落とした出力を指示。
プロンプトの要点:
- 資料に書いていない仕様を聞かれたら、推測せず「提示された資料には該当する記載がありません」と一言だけ回答すること。
- 挨拶や前置きなどの余計な雑談は一切排除し、指示されたフォーマットのみを出力すること。
🔹 2回目 : ユーザー体験を重視
1回目のプロンプトだと回答がさすがに素っ気ないので、ユーザーへの気配り・補足案内を増やす指示に変更。
プロンプトの要点:
- 資料に記載がない場合も「追加の仕様書をご確認いただくか、担当者にお問い合わせください」といった次のアクションを親切に案内すること。
- フォーマットを守りつつ、丁寧かつわかりやすい補足説明を心がけること。
データセット
{"test_case_description": "【仕様抽出】RAGでの正確なパラメータ抽出", "query": "ユーザー登録API（POST /api/v1/users）の必須パラメータとデータ型を一覧化してください。", "context": "【基本設計書】第3章 API仕様\n3.1 ユーザー登録 (POST /api/v1/users)\n・email: 文字列、必須、最大255文字\n・password: 文字列、必須、8〜64文字\n・user_name: 文字列、必須、最大50文字\n・age: 数値、任意", "ground_truth": "必須パラメータ：\n- email (文字列, 最大255文字)\n- password (文字列, 8〜64文字)\n- user_name (文字列, 最大50文字)"}
{"test_case_description": "【フォーマット遵守】余計な挨拶抜きのMarkdownテーブル形式出力", "query": "ログイン画面の入力チェック仕様を、マークダウンのテーブル形式（項目名、型、必須）のみで出力してください。余計な前置きや挨拶は不要です。", "context": "【仕様】メールアドレス：文字列、必須。パスワード：文字列、必須。", "ground_truth": "| 項目名 | 型 | 必須 |\n|---|---|---|\n| メールアドレス | String | 必須 |\n| パスワード | String | 必須 |"}
{"test_case_description": "【品質網羅性】テストケース（正常系・境界値・異常系）の抽出", "query": "ユーザー検索機能のテストケースを作成してください。正常系だけでなく境界値・異常系も含めて整理してください。", "context": "【機能概要】ユーザーID（1〜999999の数値）を指定してDBからユーザー情報を取得する検索処理。", "ground_truth": "観点：\n- 正常系：存在する有効なユーザーIDでの検索\n- 境界値：最小値(1)、最大値(999999)\n- 異常系：存在しないID、範囲外の数値、文字列入力、空文字、SQLインジェクション風入力"}
{"test_case_description": "【ハルシネーション検知】資料に存在しない仕様への適切な回答", "query": "基本設計書に記載されている『マルチ要素認証（MFA）のSMS送信外部API仕様』について説明してください。", "context": "【基本設計書】第1章 システム概要\n本システムはユーザーのログインおよびセッション管理機能を提供する。認証はIDとパスワードで行う。", "ground_truth": "提示された資料にマルチ要素認証（MFA）およびSMS送信外部APIの記載はありません。"}
{"test_case_description": "【要件確認】不備・未定義パラメータに対する適切な聞き返し", "query": "外部決済サービスとの連携処理のシーケンス図を作成したいので、処理フローをまとめてください。", "context": "【要件定義書】2.1 決済処理\nユーザーが購入ボタンを押下した際、外部決済代行サービスを呼び出してクレジットカード決済を行う。", "ground_truth": "不足している情報：\n1. 決済プロバイダの種類\n2. 同期/非同期処理の種別\n3. 決済失敗・タイムアウト時のキャンセル/リトライ仕様"}
2. 結果
| 指標 | 1回目（ハルシネーション防止を重視） | 2回目（ユーザー体験を重視） | 変化 | 概要・評価ポイント |
|---|---|---|---|---|
| 総合スコア (TaskCompletion) | 72% | 74% | 🟢 +2% | 全体的なタスク達成度は微増 |
| Groundedness (根拠性) | 32% | 24% | 🔴 -8% | コンテキストに無い内容は減点対象であり、コンテキストが薄い中で技術的回答を求めたので妥当な結果である |
| CustomerSatisfaction (CSAT) | 84% | 96% | 🟢 +12% | 丁寧な案内と回答フォーマットにより96%に向上 |
| Coherence (一貫性) | 100% | 96% | ⚪ -4% | 論理的な一貫性は高水準を維持 |
結果詳細を見たところ、1回目2回目ともにスコアが芳しくないGroundednessは、
ユーザからの依頼の単なる言い換えに満点、コンテキストにはない技術的な回答に低い点がついていたので、単にスコアが低い=エージェントの質が悪いとはならないだろう。
(今回のエージェントはプロンプトでしかインプットを入れてないのでだいぶ簡易)
おわりに
プロンプトの定義だけじゃ簡易すぎるよなと思い、KBに置いた設計書相当のドキュメントを読ませようとして権限周りで試行錯誤していたが、沼ってしまったのでいったん簡易なエージェントで評価ジョブを回した。
評価ジョブを洗練させると同時にKBの構築もちゃんとやりたい……