LLM評価の実践：ユーザーより先にAI機能をテストする方法 - Toolsify AI Blog

AI機能が初めてチームを困らせる瞬間は、ベンチマークの失敗には見えません。サポートbotが誤った返金ポリシーを自信満々に適用する、コードアシスタントが触ってはいけないファイルを変更する、営業copilotが空のCRM項目を見て顧客情報を作り出す。デモは問題なく、プロンプトレビューも通ったのに、実ユーザーが未テストの入力を見つけます。

LLM evals はそのためにあります。ランキング競争ではなく、プロダクト上の期待を再現可能なテスト、回帰ゲート、人間レビューのループに変える仕組みです。

LLM評価が通常のQAと違う理由

通常のQAは、既知の入力に期待出力が返るかを確認します。LLMプロダクトでは、許容できる答えが複数あります。だからこそ、ルーブリックはリスクに合わせる必要があります。事実整合性、網羅性、トーン、拒否、ツール選択、権限、安全な停止を評価します。これは AIエージェントには能力より信頼性が必要という記事の考え方と同じです。

プロンプト調整の前にゴールデンデータセットを作る

ゴールデンデータセットは、現実的な入力、期待される振る舞い、採点メモ、メタデータを持つケース集です。最初は50から200件で十分です。サポートなら怒ったチケット、多言語、情報不足、エスカレーションが必要なケース。開発者向けツールなら小さなバグ、曖昧なリファクタ、失敗テスト、権限境界を入れます。

タスク種別、リスク、必要な根拠、許可されたアクション、合否理由も保存します。Hamel Husain の LLM evalsに関する実践記事は、抽象的なベンチマークよりもプロダクト固有の例と人間の判断を重視する点で参考になります。

プロンプトとモデルをプロダクト実験として比較する

同じデータセットで本番プロンプト、候補プロンプト、候補モデルを実行します。平均点だけでなく、タスク、言語、リスク、ユーザーセグメントで結果を見ます。ChainForge は複数プロンプトと出力の比較に向き、Vellum はプロンプト管理、評価、デプロイのワークフローを提供し、DeepEval はLLMアプリケーション向けのオープンソーステストフレームワークです。

各runではプロンプト版、モデル名、検索設定、ツールschema、temperature、システム指示を保存します。これは LLMでソフトウェアを書く実践ワークフローのようなマルチモデル運用では特に重要です。

CI/CDに回帰ゲートを入れる

ゴールデンデータセットの一部をsmoke evalsとしてCI/CDに入れます。危険なポリシー回答、壊れたJSON、禁止ツール呼び出し、重大な幻覚、必須エスカレーションを含めます。プロンプト、モデル設定、retrieval、ツールschema、ルーティングを変えるPRはこれを実行すべきです。

まずは決定的なチェックから始めます。schemaの妥当性、必要な引用、禁止アクション、拒否、単純なツール選択です。その後、トーンや有用性にはrubricやLLM-as-judgeを追加します。エージェントでは MCP本番統合と Operator型Web自動化のように、ツール呼び出しを記録し、エラーを分類し、schemaをバージョン管理し、失敗経路をテストします。

人間レビューで失敗をテストに変える

eval setは古くなります。出力、苦情、エスカレーション、near missを定期的に確認し、欠落文脈、誤ったツール、根拠のない主張、不適切なトーン、危険な行動、古いソース、過剰拒否、拒否不足などに分類します。代表的な例をゴールデンデータセットに追加します。

PMやドメイン専門家も重要です。エージェントの運用ダッシュボードがあるなら、eval failureをそこにつなげます。Agent運用ファネル設計はその見方に近いです。

ゲーム世界型のオープン評価が役立つとき

多くのチームはゴールデンデータセットと回帰ゲートから始めるべきです。オープン環境は、長期計画、予期せぬ状態からの復帰、多数のツール操作が本当のリスクである場合に役立ちます。Factorio Learning Environment はFactorioを使い、計画、資源収集、建設、適応を評価する例です。FAQ botには重すぎますが、ブラウザagent、coding agent、運用copilotには有用な場合があります。

良いLLM evalsはAI機能を完璧にはしません。ただし、ユーザーが見つける前にトレードオフを見える化します。成熟したチームは、重要な失敗を知り、回帰を早く見つけ、判断と責任が必要な場所に人間を残します。