評価の評価: AIエージェントのパフォーマンスをどう測るか
サマリー
AIエージェントの評価方法についての考察を提供する記事です。従来の合格/不合格の評価方法の限界を指摘し、情報理論に基づく新たなアプローチを提案しています。エージェントの能力を詳細に理解するための地図を作成することの重要性が強調されています。
本文
エディターノート: AIに関する最も興味深い質問のいくつかは、情報理論の専門家によって提起されています。最近、私たちは、現代のAIシステムが機能するために必要なメタデータ、コンテキスト、キュレーションされた知識を表現するためのポータブルで相互運用可能な形式を定義するOpen Knowledge Formatに関するブログを公開しました。このブログは多くの関心を集めたため、私たちは新しい「Frontier and Center」シリーズの一環として、同様の内容をお届けすることにしました。今日は、Google Data CloudのフロンティアAIチームの2人のメンバーから、エージェントがそのコンテキストに基づいて質問に効果的に答えられるかどうかを体系的に評価するという繰り返しの課題についてお話しします。
試験の合格点は、試験が伝える最も興味深くないことです。これは学生が基準をクリアしたことを示すだけであり、彼らの失敗がどれほど狭いものであったか、合格がどれほど容易であったか、次に何を教えるべきかについては全く不明です。しかし、私たちはまさにこのようにAIエージェントを評価しています。固定されたベンチマークを実行し、スコアを計算し、進捗を宣言します。このプロセスでは、エージェントに合格/不合格の試験を与えていることになりますが、実際に必要なのはエージェントの能力の地図です。データエージェントにとって、この地図はデータの発見において非常に重要です。実際のユーザーは質問を不完全に表現し、どのデータセットを取得するかを推測することはエージェントにとって大きな課題です。評価における興味深い質問は「エージェントは合格できるか？」ではなく、「質問がどれだけ曖昧になるとエージェントが壊れるか？」です。試験はそれに簡単には答えられませんが、地図は答えられます。
今日は、私たちがエージェントのパフォーマンスをよりよく理解するために、ベンチマークに詳細とニュアンス（すなわち忠実度）を追加するために活用している情報理論に基づくアプローチを共有します。途中で、追加された忠実度は、新たに出現する評価ケースの質に関する深い問題を明らかにしました。
データの取得に関して、評価ケースはしばしば難易度の層に分けられます。これは有機的に発生することもあれば、質問を「簡単」または「難しい」と分類するラベルを人間や機械が適用することもあります。このような感情に基づくラベリングは、テストケースをラベル付けする唯一の方法ではありませんが、その不完全さにもかかわらず頻繁に使用されています。
手作業で評価ケースをすべて評価するアプローチは、スケールで実現不可能です。私たちが必要としているのは、評価ケースの難易度を調整できる厳密なアプローチです。私たちは、Discovery Benchと呼ばれるメタベンチマークを反復しています。これは、各ケースの「簡単」と「難しい」のバリエーションを生成することによって評価ケースを調整するフレームワークです。これにより、エージェントがそれらのケースで成功するためにどれだけ近いか、または遠いかを監査できます。
入力クエリの難易度を調整するためのレバーは、情報理論と機械学習の両方に存在する信頼できる概念である「驚き」によって提供されます。私たちのケースでは、クエリの驚きは、クエリに基づいて正しいデータセットについて残る不確実性を表します。私たちのアプローチの背後にある考え方はシンプルです。評価クエリの用語やフレーズは、コーパス内の他のすべてからターゲットを鋭く区別する場合に高い情報力を持ちます。したがって、情報力の異なる用語を追加または削除することで、評価ケースの難易度を調整できます。
私たちのアプローチの核心は、反復的な驚きに基づくクエリの洗練（iSQR）と呼ばれるループであり、エージェントがクエリに成功して答え始めることができる場所をテストするために、情報力の高いまたは低いケースを生成します。Discovery Benchの難易度ダイヤルが明らかにするのは、単一のフレーズベンチマークが構造的に示すことができないことです。私たちは、F1エージェントをKramaBenchに対して実行し、全ての曖昧さのレベルを通じて曲線を描きました。高い曖昧さで0.34、中立で0.76、中程度で0.81、低いで0.78です。
ここからすぐに2つの発見が得られます（どちらも従来の評価では見えませんでした）。まず、崖です。このクエリは中立的な表現でF1 = 1.00の完璧なスコアを持っていますが、高い曖昧さでは0.00です。これは上記の衛星48445のケースです。区別するトークン「TLE」を削除すると、エージェントはテーブルを完全に失います。同じクエリ、同じエージェント、同じ真実の基盤ですが、1つのノッチ曖昧になると崖から落ちます。静的なベンチマークは中立的な表現をテストし、「解決済み」とスタンプを押し、平坦な地面を報告しますが、実際には崖が存在します。合格/不合格は特に誤解を招くものであり、地形が平坦であると伝えたのではなく、崖を見逃しました。
次に、スイートスポットです。Discovery Agentの場合、中程度の曖昧さが中立を上回り、低い曖昧さは時々それを下回りました。より具体的であることは、評価されるシステムにとって単調に良いわけではありません。これは、エージェントを改善するための具体的な失敗モードに向かって、どこを登るべきかを示すグレード付きのアクショナブルな信号です。地図はエージェントが失敗したことを示すだけでなく、どこで、なぜ失敗したのかを示しました。私たちの仮説は、曖昧さが少なく、コンテキストが多い（用語を通じての操縦）ことが一般的に取得を改善するはずですが、特定のDiscovery Agentにおいては、特異な「スイートスポット」がその実装におけるトレードオフを意味深く強調しました。
私たちだけではありません。分野はメタベンチマーキングに向かって収束しており、エージェントを挑戦し評価する方法をより制御しています。増加する研究は、標準化テストの背後にある潜在能力モデルである項目応答理論を使用して、難易度をラベルではなく測定された量として扱っています。私たちは、評価を行う際に、生成者自体を評価する必要があります。私たちは、同じ曖昧さのスイープを2つの方法で構築しました。純粋なLLMの推測からの操縦用語と、TF-IDFの驚きに基づく用語です。これらは激しく対立しました。高い曖昧さで、LLM構築のスイープはエージェントをF1 ≈ 0.34で評価しましたが、基盤となるスイープは約0.85でした。どちらかの地図がひどく歪んでいます。基盤となるものは、予測可能に、より堅牢です。驚きは、自由に動くLLMが欠けている足場を提供します。
私たちは、測定することなくエージェントを最適化することに何年も費やしてきました。より良いモデルがこれを悪化させるという苦い皮肉があります。エージェントが粗いベンチマークをクリアすると、スコアは上部近くで飽和し、試験はエージェントが改善できる場所を強調する能力を失います。したがって、行動を促す呼びかけは不快であり、過去のものです。評価を評価してください。真実の基盤を読み、難易度を測定された量として扱い、スイープし、プロットし、システムが壊れるビット幅を見つけてください。「合格したか？」だけでなく、「どれだけ近かったか、合格はどれほど難しかったか、そして少し曖昧な質問がそれを崖から落とすか？」という質問をしてください。評価が信号を生み出すように構築してください。単なる判決ではなく。ここには真剣に向き合うべき緊張があります。エントロピーとしての難易度は、エントロピーを推定するモデルが信頼できる限りです。測定可能な代理を強化しすぎるリスクがありますが、それはエージェントではなくルーラーを最適化することになります。それは合格/不合格に戻る理由ではなく、評価者を評価するのと同じ厳密さを保つ理由です。評価者を評価する人を問わなくなる瞬間、私たちの地図は再び役に立たなくなります。
試験の合格点は、試験が伝える最も興味深くないことです。これは学生が基準をクリアしたことを示すだけであり、彼らの失敗がどれほど狭いものであったか、合格がどれほど容易であったか、次に何を教えるべきかについては全く不明です。しかし、私たちはまさにこのようにAIエージェントを評価しています。固定されたベンチマークを実行し、スコアを計算し、進捗を宣言します。このプロセスでは、エージェントに合格/不合格の試験を与えていることになりますが、実際に必要なのはエージェントの能力の地図です。データエージェントにとって、この地図はデータの発見において非常に重要です。実際のユーザーは質問を不完全に表現し、どのデータセットを取得するかを推測することはエージェントにとって大きな課題です。評価における興味深い質問は「エージェントは合格できるか？」ではなく、「質問がどれだけ曖昧になるとエージェントが壊れるか？」です。試験はそれに簡単には答えられませんが、地図は答えられます。
今日は、私たちがエージェントのパフォーマンスをよりよく理解するために、ベンチマークに詳細とニュアンス（すなわち忠実度）を追加するために活用している情報理論に基づくアプローチを共有します。途中で、追加された忠実度は、新たに出現する評価ケースの質に関する深い問題を明らかにしました。
データの取得に関して、評価ケースはしばしば難易度の層に分けられます。これは有機的に発生することもあれば、質問を「簡単」または「難しい」と分類するラベルを人間や機械が適用することもあります。このような感情に基づくラベリングは、テストケースをラベル付けする唯一の方法ではありませんが、その不完全さにもかかわらず頻繁に使用されています。
手作業で評価ケースをすべて評価するアプローチは、スケールで実現不可能です。私たちが必要としているのは、評価ケースの難易度を調整できる厳密なアプローチです。私たちは、Discovery Benchと呼ばれるメタベンチマークを反復しています。これは、各ケースの「簡単」と「難しい」のバリエーションを生成することによって評価ケースを調整するフレームワークです。これにより、エージェントがそれらのケースで成功するためにどれだけ近いか、または遠いかを監査できます。
入力クエリの難易度を調整するためのレバーは、情報理論と機械学習の両方に存在する信頼できる概念である「驚き」によって提供されます。私たちのケースでは、クエリの驚きは、クエリに基づいて正しいデータセットについて残る不確実性を表します。私たちのアプローチの背後にある考え方はシンプルです。評価クエリの用語やフレーズは、コーパス内の他のすべてからターゲットを鋭く区別する場合に高い情報力を持ちます。したがって、情報力の異なる用語を追加または削除することで、評価ケースの難易度を調整できます。
私たちのアプローチの核心は、反復的な驚きに基づくクエリの洗練（iSQR）と呼ばれるループであり、エージェントがクエリに成功して答え始めることができる場所をテストするために、情報力の高いまたは低いケースを生成します。Discovery Benchの難易度ダイヤルが明らかにするのは、単一のフレーズベンチマークが構造的に示すことができないことです。私たちは、F1エージェントをKramaBenchに対して実行し、全ての曖昧さのレベルを通じて曲線を描きました。高い曖昧さで0.34、中立で0.76、中程度で0.81、低いで0.78です。
ここからすぐに2つの発見が得られます（どちらも従来の評価では見えませんでした）。まず、崖です。このクエリは中立的な表現でF1 = 1.00の完璧なスコアを持っていますが、高い曖昧さでは0.00です。これは上記の衛星48445のケースです。区別するトークン「TLE」を削除すると、エージェントはテーブルを完全に失います。同じクエリ、同じエージェント、同じ真実の基盤ですが、1つのノッチ曖昧になると崖から落ちます。静的なベンチマークは中立的な表現をテストし、「解決済み」とスタンプを押し、平坦な地面を報告しますが、実際には崖が存在します。合格/不合格は特に誤解を招くものであり、地形が平坦であると伝えたのではなく、崖を見逃しました。
次に、スイートスポットです。Discovery Agentの場合、中程度の曖昧さが中立を上回り、低い曖昧さは時々それを下回りました。より具体的であることは、評価されるシステムにとって単調に良いわけではありません。これは、エージェントを改善するための具体的な失敗モードに向かって、どこを登るべきかを示すグレード付きのアクショナブルな信号です。地図はエージェントが失敗したことを示すだけでなく、どこで、なぜ失敗したのかを示しました。私たちの仮説は、曖昧さが少なく、コンテキストが多い（用語を通じての操縦）ことが一般的に取得を改善するはずですが、特定のDiscovery Agentにおいては、特異な「スイートスポット」がその実装におけるトレードオフを意味深く強調しました。
私たちだけではありません。分野はメタベンチマーキングに向かって収束しており、エージェントを挑戦し評価する方法をより制御しています。増加する研究は、標準化テストの背後にある潜在能力モデルである項目応答理論を使用して、難易度をラベルではなく測定された量として扱っています。私たちは、評価を行う際に、生成者自体を評価する必要があります。私たちは、同じ曖昧さのスイープを2つの方法で構築しました。純粋なLLMの推測からの操縦用語と、TF-IDFの驚きに基づく用語です。これらは激しく対立しました。高い曖昧さで、LLM構築のスイープはエージェントをF1 ≈ 0.34で評価しましたが、基盤となるスイープは約0.85でした。どちらかの地図がひどく歪んでいます。基盤となるものは、予測可能に、より堅牢です。驚きは、自由に動くLLMが欠けている足場を提供します。
私たちは、測定することなくエージェントを最適化することに何年も費やしてきました。より良いモデルがこれを悪化させるという苦い皮肉があります。エージェントが粗いベンチマークをクリアすると、スコアは上部近くで飽和し、試験はエージェントが改善できる場所を強調する能力を失います。したがって、行動を促す呼びかけは不快であり、過去のものです。評価を評価してください。真実の基盤を読み、難易度を測定された量として扱い、スイープし、プロットし、システムが壊れるビット幅を見つけてください。「合格したか？」だけでなく、「どれだけ近かったか、合格はどれほど難しかったか、そして少し曖昧な質問がそれを崖から落とすか？」という質問をしてください。評価が信号を生み出すように構築してください。単なる判決ではなく。ここには真剣に向き合うべき緊張があります。エントロピーとしての難易度は、エントロピーを推定するモデルが信頼できる限りです。測定可能な代理を強化しすぎるリスクがありますが、それはエージェントではなくルーラーを最適化することになります。それは合格/不合格に戻る理由ではなく、評価者を評価するのと同じ厳密さを保つ理由です。評価者を評価する人を問わなくなる瞬間、私たちの地図は再び役に立たなくなります。
