生成AIアプリケーションの評価

アプリケーションの評価では、モデル単体の出来だけでなく、検索 ()、エージェント、ワークフローを含めたアプリケーション全体が目的を果たしているかを確かめます。 AIF-C01では、RAGやエージェントの評価の方法と、業務目標と結び付いた指標が問われます。

概要

同じモデルでも、検索で渡す文書、ツールの選び方、手順の組み立てによって結果は大きく変わります。そのため、モデルの評価に加えて、アプリケーションの部品ごとと全体の両方を評価します。

評価の対象	確かめること
モデル	回答が正確で、役に立ち、安全か
	必要な文書を取り出せたか、回答が文書に基づいているか
エージェント	目標を達成したか、正しいツールを正しい引数で呼んだか
ワークフロー	各段の結果がつながり、最後まで処理できたか
業務	利用者と事業にとって価値があったか

試験では、「どの部分の問題か」を切り分け、それに合う評価の方法と指標を選びます。

の出力には唯一の正解がないため、別のを審査役 (ジャッジ) にして、決めた観点で採点させる方法が使われます。

観点	内容
利点	より速く安く、大量の出力を同じ基準で採点できます。
採点の観点の例	正確さ、網羅性、有用性、根拠との一致、有害さ
注意点	審査役のモデルにも偏りがあります。一部を人間が確かめて、採点の妥当性を確認します。

⚠️ 頻出: やは参照の文章との語句の重なりを測ります。意味の正しさや有用性を大量に採点したいなら、を使います。

Point

の問題は、「検索で必要な文書を取れていない」のか「文書はあるのに回答が正しくない」のかで対策が変わります。のRAGの評価では、2種類の評価を選べます。

評価の種類	対象	分かること
検索のみ (retrieve only)	取り出した文書	質問に関係する文書を、取りこぼしなく取り出せたか
検索と生成 (retrieve and generate)	取り出した文書と生成した回答	回答が正確で、文書に忠実で、質問に答えているか

結果	疑う箇所	対策の例
関係する文書が取れていない	検索	の分け方、、、
文書はあるが回答が根拠と違う	生成	の指示、モデルの選択、根拠の確認 ()

だけでなく、外部で作ったRAGの結果を持ち込んで評価することもできます。

評価の種類	主な指標
検索のみ	文脈の関連性 (取り出した文書が質問に関係するか)、文脈の網羅性 (正解の情報をどれだけ覆っているか。正解のデータが必要)
検索と生成	正確さ、網羅性、有用性、忠実性 (取り出した文書にない内容を加えていないか)、引用の正確さと網羅性、有害性

のは、本番の回答をその場で検査して遮る機能です。公開前に評価用のデータセットで構成を比べるのは、RAGの評価です。

は、エージェントの実行の記録 (セッション、トレース) を、の手法を使って自動で採点します。判断の過程を追跡して見せるのは Observability、品質を採点するのはEvaluationsです。

評価の種類	使う場面
オンライン評価	本番の通信から一部のセッションを抜き出して継続して採点し、品質の傾向を見ます。
評価	指定したトレースだけを採点します。報告された問題の調査、修正の確認、開発中のテストに使います。
バッチ評価	多数のセッションをまとめて採点し、変更の前後を比べます。

用意された評価器に加えて、独自の評価器も作れます。独自の評価器には、審査役のモデルへの指示と採点の基準を自分で決めるLLM-as-a-judgeの評価器と、関数で決まった規則を確かめるコードによる評価器があります。

⚠️ 頻出: モデルの指標が良くても、タスク完了率や満足度が上がらなければ、アプリケーションとしては目的を果たしていません。

段階	すること
公開前	評価用のデータセットで、モデル、、エージェントを比べます。
公開時	一部の利用者で新旧を比べます。
公開後	本番の記録を継続して評価し、利用者の反応を集めます。
改善	評価の結果から、、検索、ツールの説明などを直します。

(ヒューマンインザループ) は、自動評価の結果の確認や、安全性のような判断の難しい観点に使います。

問題文のキーワード	選ぶ方法
で必要な文書を取り出せているか確かめたい	RAGの評価 (検索のみ)
RAGの回答が文書に忠実か確かめたい	RAGの評価 (検索と生成)
意味の正しさや有用性を大量に採点したい
エージェントが目標を達成し、正しいツールを選んだか確かめたい	エージェントの評価 ()
自動化の効果を事業側へ示したい	、インタラクションあたりの費用
審査役のモデルの採点が妥当か確かめたい	一部を人間が評価して比べる