エヌビディアのジェンスン・フアン最高経営責任者(CEO)は、AIインテリジェンスを「デジタル労働力」と称えているが、このような見解を持つテックリーダーは彼だけではない。 マイクロソフトのサティア・ナデラCEOもまた、知的身体技術がビジネスのあり方を根本的に変えると考えている。
これらのインテリジェンスが外部ツールやAPIと相互作用できるようになったことで、その応用シーンは大きく広がった。 しかし、AIインテリジェンスは完璧とは言い難く、潜在的な相互作用が複雑であるため、実世界のアプリケーションにおける性能を評価することは困難であった。
この課題に対処するため、Hugging Faceはエージェント・インテリジェンス・ボディ・ランキングを導入しました。 GalileoのTool Selection Quality (TSQ)メトリクスを使用し、Leaderboardはツールベースのインタラクションを扱う際の様々な大規模言語モデル(LLM)のパフォーマンスを評価し、開発者に明確なリファレンスを提供します。
- ハグ顔エージェント 知的ボディランキング
Hugging Faceは、"AIインテリジェンスは実際のビジネス環境でどの程度のパフォーマンスを発揮するのか?"という中心的な疑問に答えるためにこのランキングを作成した。 学術的なベンチマークは重要だが、それらは技術的な能力に焦点を当てているのに対し、Hugging Faceは、どのモデルが実際に様々な実世界のユースケースに適用できるかをより重視している。
ハグ・フェイス・エージェント インテリジェント・ボディ・アセスメント・リーダーボードのユニークな特徴
現在主流の評価フレームワークは、通常、特定のドメインに焦点を当てている。 例えば、BFCLは数学、エンターテイメント、教育などのアカデミックなドメインを得意とし、τ-benchは小売業や航空会社などの業界特有のシナリオに焦点を当て、xLAMは21のデータ生成ドメインをカバーし、ToolACEは390のドメインにわたるAPIインタラクションに焦点を当てている。 Hugging Faceのリーダーボードは、より広範なドメインと実世界のユースケースをカバーするように設計された包括的な評価フレームワークに、これらのデータセットを組み合わせた点でユニークです。
विविधベンチマークとテストシナリオを統合することで、Hugging Faceのリーダーボードはモデルの技術的能力の評価を提供するだけでなく、モデルがエッジケースとセキュリティの考慮事項をどのように扱うかについての実用的な洞察を提供することに重点を置いています。 Hugging Faceはまた、費用対効果、実装ガイドライン、ビジネスへの影響など、AIインテリジェンスの導入を検討している組織にとって重要な複数の要素に対する洞察も提供します。 このランキングにより、Hugging Faceは、企業チームが現実世界のアプリケーションの制約を考慮しながら、彼らの特定のニーズを最もよく満たすAIインテリジェンスモデルをより正確に突き止める手助けをしたいと考えています。
新しい大規模言語モデル(LLM)のリリース頻度を考慮し、Hugging Faceは、急速に進化するモデリング技術に対応できるよう、リーダーボードのベンチマークを毎月更新する予定です。
主な調査結果
Hugging Faceが17の主要な大規模言語モデル(LLM)を詳細に分析した結果、AIインテリジェンスが実世界のタスクにアプローチする方法における興味深いパターンが明らかになりました。 Hugging Faceは、単純なAPIコールから複雑なマルチツールインタラクションに及ぶ次元を評価し、14の異なるベンチマークにわたってプライベートモデルとオープンソースモデルの両方で包括的なストレステストを実施しました。

大規模言語モデリング(LLM)ランキング
Hugging Faceの評価結果は、モデルの性能に関する従来の認識を覆すものであり、AIインテリジェンスを構築するチームにとって貴重な実用的参考資料となる。

エージェントのインテリジェント・ボディ・ランキングの主な結果
ツール呼び出しの複雑さ
ツール呼び出しの複雑さは、単純なAPIコールをはるかに超える。 実際には、AIインテリジェンスはツールの使用において多くの複雑なシナリオや課題に直面し、的確な判断を下す必要がある:
シーン認識
知的機関がユーザーからの問い合わせを受け取ると、その最初のタスクは、ツール起動が必要かどうかを判断することである。 時には、必要な情報が対話履歴に既に存在し、ツール起動が冗長になることがある。 また、利用可能なツールがユーザーの問題を解決するのに十分でなかったり、タスク自体と無関係であったりすることもある。 このような場合、インテリジェンスは、不適切なツールの使用を強制するのではなく、その限界を認識し、ユーザーに対して誠実である必要がある。
ツール選択ダイナミクス
道具の選択は、単純な「イエス」か「ノー」かの二者択一の問題ではなく、精度と想起を伴う。 理想を言えば、知的な身体はすべての必要な道具を正確に識別できる一方で、無関係な道具の選択を避けることができるはずである。 しかし、現実はもっと複雑であることが多い。 知的体は、必要な道具を1つだけ正確に識別しても、他の道具を省いたり(リコールが不十分)、適切な道具を選択しても、不必要な道具を誤って選択したりする(精度が不十分)。 これらのシナリオはどちらも最適ではないが、程度の差こそあれ、選択の偏りを表している。
パラメタリゼーション
たとえインテリジェント・ボディが適切なツールを選択できたとしても、パラメータ処理に新たな課題が生じる可能性がある。 インテリジェント・ボディは、次のことをしなければならない:
- 必要なパラメータをすべて指定し、名前が正しく付けられていることを確認する。
- オプション・パラメータの適切な取り扱い。
- パラメータ値の精度を確認する。
- ツール固有の仕様に従ってパラメータをフォーマットする。
逐次意思決定
多段階のタスクでは、知能はより高度な意思決定能力を発揮する必要がある:
- ツールコールの最適な順序を決定する。
- ツール呼び出し間の相互依存を処理する。
- 複数のオペレーション間のコンテクストの一貫性を維持する。
- 地域的な成功や失敗に対応する柔軟性。
上記のような複雑さは、道具選択の質を単純な指標として見るべきではないことを十分に示している。 むしろ、現実のシナリオの中で複雑な意思決定を行う知能の能力を総合的に評価するものと考えるべきである。
方法論
Hugging Faceの評価プロセスは、AIインテリジェンスを包括的かつ公平に評価する体系的な方法論に従っている:
- モデル選択: Hugging Faceは、プロプライエタリなものからオープンソース実装まで、多様な主要言語モデルを厳選しました。 この選択戦略は、現在の技術状況の包括的なビューを提供することを目的としています。
- スマートボディの構成: Hugging Faceは、各モデルを標準化されたシステムキューを持つインテリジェンスとして構成し、一貫したツールセットへのアクセスを許可します。 この標準化されたコンフィギュレーションにより、パフォーマンスのばらつきは、キュー・エンジニアリングのような外部要因に影響されることなく、モデル自身が本来持っている能力を忠実に反映したものとなる。
- 指標の定義 Hugging Faceは、工具選択の正しさとパラメータ使用の有効性に焦点を当て、中核となる評価指標として工具選択品質(TSQ)を確立しています。 TSQメトリクスは、実世界の性能要件を念頭に設計されています。
- データセットのキュレーション Hugging Faceは、既存の成熟したベンチマークデータセットから戦略的にサンプリングすることで、バランスの取れたマルチドメインのデータセットを構築する。 このデータセットは、評価の包括性を確保するために、基本的な関数呼び出しから複雑な複数ラウンドの相互作用に至るまで、インテリジェンスの能力を包括的にテストする。
- 採点システム: 最終的なパフォーマンス・スコアは、すべてのデータセットについて等しい重みの平均を計算することによって導き出される。 このアプローチにより、バランスの取れた評価が保証され、単一の能力が全体的な評価結果を支配することが回避されるため、インテリジェンスの総合的なパフォーマンスがより客観的に反映されます。
この構造化された評価方法を通じて、ハギング・フェイスは、実世界での配備決定を直接導くことができる洞察を提供することを目指している。
ハギング・フェイスはエージェント・インテリジェンスのパフォーマンスをどのように測定するのか?
評価の枠組み
上述したように、ツール起動の評価には、さまざまな異なるシナリオにおける信頼性の高い測定が必要です。 Hugging Faceは、ツール選択の正確さとパラメータ使用の有効性を見て、知能のツール呼び出しパフォーマンスを評価するためにツール選択品質メトリックを開発しました。 この評価フレームワークは、タスクを完了するためにインテリジェンスがツールを適切に使用しているかどうかを判断し、ツールの使用が不必要な状況を特定するために設計されています。
評価プロセスにおいて、ハギング・フェイスはツール選択の決定を評価するためにGPT-4oとChainPollモデルを使用した。 各インタラクションについて、ハギング・フェイスは複数の独立した判定を収集し、最終的なスコアは肯定的な評価の割合を表します。 各判定には、評価プロセスの透明性を確保するための詳細な説明が含まれています。
以下のコード例は、TSQメトリクスを使用して、データセット上での大規模言語モデル(LLM)のツール呼び出しパフォーマンスを評価する方法を示しています:
import promptquality as pq
import pandas as pd
file_path = "path/to/your/dataset.parquet" # 替换为你的数据集文件路径
project_name = "agent-leaderboard-evaluation" # 替换为你的项目名称
run_name = "tool-selection-quality-run" # 替换为你的运行名称
model = "gpt-4o" # 你想要评估的模型名称
tools = [...] # 你的工具列表
llm_handler = pq.LLMHandler() # 初始化 LLMHandler
df = pd.read_parquet(file_path, engine="fastparquet")
chainpoll_tool_selection_scorer = pq.CustomizedChainPollScorer(
scorer_name=pq.CustomizedScorerName.tool_selection_quality,
model_alias=pq.Models.gpt_4o,
)
evaluate_handler = pq.GalileoPromptCallback(
project_name=project_name,
run_name=run_name,
scorers=[chainpoll_tool_selection_scorer],
)
llm = llm_handler.get_llm(model, temperature=0.0, max_tokens=4000)
system_msg ={
"role":"system",
"content":'Your job is to use the given tools to answer the query of human. If there is no relevant tool then reply with "I cannot answer the question with given tools". If tool is available but sufficient information is not available, then ask human to get the same. You can call as many tools as you want. Use multiple tools if needed. If the tools need to be called in a sequence then just call the first tool.',
}
outputs = []
for row in df.itertuples():
chain = llm.bind_tools(tools)
outputs.append(
chain.invoke(
[system_msg,*row.conversation],
config=dict(callbacks=[evaluate_handler])
)
)
evaluate_handler.finish()
なぜハギング・フェイスは、ツールコールの評価にラージ・ランゲージ・モデル(LLM)を採用したのでしょうか?
大規模言語モデル(LLM)に基づく評価手法は、様々な複雑なシナリオの包括的な評価を可能にする。 このアプローチは、ツールを使用する前にユーザーからより多くの情報が必要かどうかを判断するために、コンテキスト情報が不十分な状況をインテリジェント体が適切に処理したかどうかを効果的に検証することができる。 マルチツール適用シナリオでは、この方法は、インテリジェントボディが必要なツールをすべて識別し、正しい順序でそれらを呼び出すかどうかをチェックすることができる。 長いコンテキストのダイアログでは、このメソッドは、インテリジェントボディがダイアログ履歴の以前の関連情報を完全に考慮することを保証する。 ツールがない、または適用できない場合でも、評価メソッドは、インテリジェントボディがツールの起動を正しく回避し、不適切なアクションを回避しているかどうかを判定する。
TSQの指標に優れるためには、AIインテリジェンスが高度な能力を発揮する必要がある。必要なときに適切なツールを選択する、正確なパラメータを提供する、複数のツールを効率的に調整する、ツールの使用が不要なシナリオを特定する、などである。 例えば、必要な情報がすでに対話履歴に存在する場合や、適切なツールがない場合は、ツールを使用しないことが望ましい。
データセットのコンテンツ構成の評価
Hugging Faceの評価フレームワークは、BFCL(Berkeley, Inc. 関数呼び出し Leaderboard(バークレー関数コール・リーダーボード)、τ-bench(Tauベンチマーク)、Xlam、およびToolACE。 各データセットは、特定の側面における知能の能力をテストすることを目的として設計されている。 これらの評価次元を理解することは、モデル評価と実用的なアプリケーション開発の両方にとって極めて重要である。
単発容量
- 基本的な工具の使用 シナリオ:ツール文書、プロセスパラメータを理解し、基本的なファンクションコールを実行する知能体の能力を評価することに重点を置く。 この次元では、直接対話における知的体の応答フォーマットとエラー処理能力を調べることに重点を置いています。 この能力は、リマインダーの設定や基本情報の取得[xlam_single_tool_single_call]など、実世界のアプリケーションにおける単純な自動タスクに不可欠です。
- ツール選択 シナリオ:複数のツールオプションから正しいツールを選択するモデルの能力を評価する。 この次元では、モデルがツールのドキュメントを理解し、ツールの適合性について理性的に判断できる程度を調べます。 多目的知能を構築する実世界のアプリケーションシナリオでは、この能力は非常に重要です[xlam_multiple_tool_single_call]。
- 並列実行 シナリオ:複数のツールを同時にプログラムするモデルの能力を調べる。 この次元は、実世界のアプリケーションで効率を向上させるために重要である[xlam_multiple_tool_multiple_call]。
- 工具の再利用 シナリオ: バッチ操作とパラメータ変動を効率的に処理するインテリジェンスの能力を評価する。 この側面は、実際のアプリケーションにおけるバッチ処理シナリオにとって特に重要である[xlam_single_tool_multiple_call]。
エラー処理とエッジケース
- 関連性テスト シナリオ:利用可能なツールがユーザーニーズに合致しない場合に、ツールの限界を特定し、合理的に伝達するテストモデルの能力。 この能力は、ユーザーエクスペリエンスとシステムの信頼性を確保するための基礎となる [BFCL_v3_irrelevance]。
- 紛失した工具の取り扱い シナリオ:必要なツールが利用できない場合、その制限をユーザーに通知し、代替手段を提供する機能 [xlam_tool_miss、BFCL_v3_multi_turn_miss_func]を含め、モデルがどの程度エレガントに処理できるかを検証する。
コンテキスト管理
- 長い文脈 シナリオ:長期的な対話において、文脈の一貫性を維持し、複雑な指示を理解するモデルの能力を評価する。 この能力は、複雑なワークフローや長い対話 [tau_long_context、BFCL_v3_multi_turn_long_context] を処理するために重要である。
重層的相互作用
- 基本的な対話 シナリオ: インテリジェンスが複数ラウンドの対話において、会話的な関数呼び出しを行い、コンテキストを維持する能力をテストする。 この基本的な能力は、対話型アプリケーションの開発に不可欠である[BFCL_v3_multi_turn_base_single_func_call, toolace_single_func_call]。
- 複雑な相互作用 シナリオ:複数の課題を組み合わせて、複雑なシナリオにおける知能の総合的な頑健性と問題解決能力を総合的にテストする[BFCL_v3_multi_turn_base_multi_func_call、BFCL_v3_multi_turn_composite]。
パラメーター管理
- 欠落パラメータ シナリオ: 情報が不完全な場合にモデルがどのように対処するか、また、必要なパラメータを収集するためにユー ザとどのように効果的に相互作用するかを検証する[BFCL_v3_multi_turn_miss_param]。
ハギング・フェイスは、コミュニティによる研究とアプリケーション開発を促進するため、データセットをオープンソース化している。 エージェント・リーダーボード データ集合
AIエンジニアへの実践的な影響
ハギング・フェイスの評価結果は、AIエンジニアがAIインテリジェンスを開発する際に多くの貴重な洞察を与えてくれる。 堅牢で効率的なインテリジェント・ボディ・システムを構築する際には、以下の重要な要素を考慮する必要がある:
モデルの選択とパフォーマンス
複雑なワークフローを処理する必要があるアプリケーションでは、複合タスクのスコアが 0.85 を超える高性能モデルを選択することが重要です。 ほとんどのモデルは基本的なツール呼び出しタスクに対応できますが、並列処理を扱う場合は、総合的な性能指標だけに頼るのではなく、特定のタスクにおけるモデルの実行スコアに注目することがより重要です。
コンテキストとエラー管理
長いコンテキストのシナリオでうまく機能しないモデルの場合、効果的なコンテキストの要約戦略を実装することが極めて重要である。 無関係性検出やパラメータ処理に欠点のあるモデルが選択された場合、ロバストなエラー処理メカニズムを構築しなければならない。 パラメータ収集に追加的なサポートが必要なモデルについては、必要なパラメータ情報を提供するようユーザーをガイドする構造化されたワークフローを考慮することができる。
安全性と信頼性
システムの安全性と信頼性を確保するためには、ツールの厳格なアクセス制御を実施することが重要であり、特に、無関係な操作の検出において十分な性能を発揮しないモデルについては、そのようなツールのアクセス制御を実施することが重要である。 性能の安定性が不十分なモデルについては、検証レイヤーを追加してシステム全体の信頼性を向上させることを検討する。 また、特にパラメータが欠落した場合の処理に苦慮しているモデルについては、適切に構築されたエラーリカバリーシステムを持つことが極めて重要である。
システム性能の最適化
システムワークフローアーキテクチャを設計する際には、並列実行やロングコンテキストシナリオを処理するモデルごとの能力の違いを十分に考慮する必要がある。 バッチ処理戦略を実装する場合、モデルのツール再利用能力を評価することが重要である。
AIモデル開発の現状
現在、プロプライエタリ・モデルが全体的な能力ではまだリードしているが、オープンソース・モデルの性能は急速に向上している。 単純な道具の相互作用タスクでは、どのタイプのモデルもより洗練されてきている。 しかし、複雑な複数ラウンドの相互作用や長いコンテキストのシナリオでは、モデルはまだ多くの課題に直面しています。
異なる次元におけるモデル性能のばらつきは、特定のユースケース要件に基づいてモデルを選択することの重要性を浮き彫りにしています。 開発者は、モデルの一般的な性能指標だけに注目するのではなく、ターゲットとするアプリケーションシナリオにおけるモデルの実際の性能を深く評価する必要があります。
Hugging Faceは、このエージェント・インテリジェンスのリストが開発者にとって貴重な参考資料となることを願っている。
モデル性能の概要
推論モデル
ハギング・フェイスの分析で興味深い現象は、推論モデルの性能である。 しかし o1 歌で応える o3-ミニ 関数呼び出し能力の統合では、それぞれ0.876と0.847という高いスコアを達成し、良い結果を残したが、Hugging Faceは他の推論モデルでいくつかの課題に直面した。 具体的にはディープシークV3 歌で応える ディープシーク R1 モデルは、汎用的な機能という点では素晴らしいパフォーマンスを発揮するが、現在のバージョンでは関数呼び出しのサポートが限られているため、ハギング・フェイスのリーダーボードからは除外された。
強調しなければならないのは、この先 ディープシークV3 歌で応える ディープシーク R1 ランキングからの除外は、これらのモデルの優れた性能を否定するものではなく、公表されているモデルの限界を十分に理解した上での慎重な判断である。 ランキングの ディープシーク V3と ディープシーク R1 Hugging Faceの公式ディスカッションで、開発者はこれらのモデルの現在のバージョンはまだ関数コールをサポートしていないことを明らかにした。 Hugging Faceは、回避策を考案したり、誤解を招く可能性のあるパフォーマンス指標を提示したりするのではなく、関数コールをネイティブにサポートする将来のリリースを待つことを選択した。
このケースподчеркивает 関数呼び出しは特殊な機能で、すべての高性能言語モデルがデフォルトで備えているわけではありません。 推論に優れたモデルであっても、構造化関数呼び出しのために特別に設計され、訓練されていなければ、構造化関数呼び出しをネイティブにサポートしないことがあります。 そのため、特定のユースケースに対してモデルを徹底的に評価することで、最適な選択が可能になります。
エリート・レベルのパフォーマンス (>= 0.9)
ジェミニ-2.0-フラッシュ このモデルは、0.938という優れた平均スコアでランキングをリードし続けている。 このモデルは、すべての評価カテゴリーにわたって優れた安定性と一貫性を示しており、特に複合シナリオ(0.95)と無関係性検出(0.98)に強みを発揮している。 100万人当たりの トークン 0.15ドル/0.6ドルの価格設定。ジェミニ-2.0-フラッシュ 性能とコストパフォーマンスのバランスが魅力。
それに続くのは GPT-4oこのモデルは0.900という高いスコアを達成し、マルチツール処理(0.99)や並列実行(0.98)といった複雑なタスクでも高いパフォーマンスを示した。 しかし GPT-4o 価格は100万トークンあたり2.5ドル/10ドルとかなり高いが、その優れた性能は依然としてоправдываетの方が高い。
高性能バンド(0.85~0.9)
高性能セグメントには、いくつかの強力なモデルが集中している。 ジェミニ1.5フラッシュ 特に無相関の検出(0.98)と単一関数のパフォーマンス(0.99)において、0.895という優れたマークが維持されている。 ジェミニ-1.5-プロ 100万トークンあたり1.25ドル/5ドルという高い価格設定にもかかわらず、0.885という高いスコアを達成し、複合タスク(0.93)と単一ツール実行(0.99)で大きな強みを発揮した。
o1 このモデルは、100万トークンあたり15ドル/60ドルという高価格にもかかわらず、0.876というスコアと業界をリードするロング・コンテキスト処理能力(0.98)で、市場での地位を証明している。 新興モデル o3-ミニ 0.847と競争力があり、単一関数呼び出し(0.975)と無関係性検出(0.97)に優れ、100万トークンあたり1.1ドル/4.4ドルという価格設定でバランスの取れた選択肢を提供している。
ミディアム・ティア容量(0.8~0.85)
GPT-4o-ミニ は0.832の効率的な性能を維持し、並列ツール使用(0.99)とツール選択において特に優れた性能を発揮する。 しかし、このモデルは、長いコンテキストのシナリオでは比較的性能が低い(0.51)。
オープンソースのモデリング陣営ではミストラル-スモール-2501 0.832というスコアでリードするこのモデルは、前バージョンと比較して、長いコンテキストの処理(0.92)とツールの選択能力(0.99)の両方で大幅な改善を示している。 クウェン-72b スコアは0.817で、無関係性検出(0.99)でプライベートモデルに匹敵し、強力なロングコンテクスト処理(0.92)を示している。 ミストラル-ラージ 道具の選択(0.97)では良いパフォーマンスを見せたが、タスクの統合(0.76)では課題を残した。
クロード・ソネ は0.801のスコアを達成し、機器による欠失検出(0.92)と単一機能処理(0.955)に優れていた。
ベースレイヤーモデル (<0.8)
ベースティアのモデルは、主に特定の領域で優れた成績を収めたモデルで構成されているが、全体的なスコアは比較的低かった。 クロード俳句 スコアは0.765と、よりバランスの取れたパフォーマンスを提供し、価格は100万トークンあたり0.8ドル/4ドルで、優れた費用対効果を示している。
オープンソースモデル ラマ70B は0.774のポテンシャルを示し、特にマルチツールのシナリオ(0.99)において顕著である。 一方 ミストラル-小 (0.750), ミストラル-8b (0.689)となる。 ミストラル・ネモ (0.661)など、より小さなスケールのモデルは、基本的なタスクシナリオにおいて効率的な選択肢をユーザーに提供する。
これらのデータセットは、言語モデリングツールの呼び出し能力を総合的に評価するフレームワークを構築するために不可欠である。
コメント Hugging Faceが発表したAgent Intelligent Body Rankingは、現在のビッグ・ランゲージ・モデル・アプリケーションの核となるペインポイント、つまりツールをいかに効率的に使うかを的確に捉えている。 長い間、業界はモデル自体の能力に注目してきたが、真の意味でモデルが実装され、実際の問題を解決するためには、ツール呼び出しの能力が鍵となる。 このランキングの登場は、開発者が特定のアプリケーションシナリオに最も適したモデルを選択するための貴重な参考情報を提供することは間違いない。 評価方法からデータセットの構築、最終的なパフォーマンス分析に至るまで、Hugging Faceの報告書は、その厳格で綿密なプロフェッショナリズムを示すとともに、AIアプリケーションの実装を促進するための積極的な取り組みを反映している。 特に、このランキングがモデルの絶対的な性能に焦点を当てるだけでなく、実世界のアプリケーションにおいて極めて重要な要素である、長い文脈処理やマルチツールの呼び出しといった、さまざまなシナリオにおけるモデルの性能を分析している点は高く評価できる。 さらに、Hugging Faceは評価データセットを惜しみなくオープンソース化しており、ツール呼び出し能力の分野におけるコミュニティの研究開発をさらに促進することは間違いない。 全体として、これは非常にタイムリーで価値のある試みである。