Artificial Analysis Search Index: Search API ベンチマークの方法論

概要

Search API Bench は、エージェント型検索のパラダイムのもとでさまざまな検索プロバイダーを評価します。

このベンチマークはプロバイダーを入れ替える比較です。すべてのサンプルで同じ候補回答モデルとベンチマークタスクを用い、変えるのは検索プロバイダーのみです。

単一の回答モデルで結果を評価することで、各 Search API プロバイダーがもたらす向上分を測定します。

本ページでは、1 つの結果とは固定した候補回答モデルと組み合わせた Search API プロバイダーを指します。これをプロバイダー結果と呼びます。

主要な指標

Artificial Analysis Search Index

公開リーダーボードでは、単一の統合スコアである Artificial Analysis Search Index を主要指標としています。これは各ベンチマークの主要な品質指標を等しい重みで平均した値です。

算出にあたっての注意点:

  • AA-Omniscience からは、Omniscience Index やハルシネーション率ではなく精度を用います。検索プロバイダーと候補モデルというパラダイムでは、精度が最も直接的に比較できるシグナルです。
  • すべての入力は同一の定数(後述)を用いるため、この指数は検索プロバイダーの違いのみを切り出します。

指数の構成要素

評価分野タスク数回答形式採点
DeepSearchQAディープリサーチ型 QA(単一回答・集合回答)900‡自由回答 / 回答の集合回答項目に対する LLM 採点の F1、pass@1
AA-Omniscience事実 QA(正答性 + キャリブレーション)600†自由回答(回答保留も可)LLM 採点による精度、pass@1
BrowseComp難易度の高いウェブ検索 QA200^短い完全一致回答LLM 採点による完全一致回答の精度、pass@1

3 つのベンチマークはいずれも採点に GPT-5.6 Luna(medium)を使用し、それぞれのベンチマーク固有の採点基準を適用します。

‡ DeepSearchQA: 900 行からなる公開評価スプリット全体。

† AA-Omniscience: 非公開の 600 サンプル。6 ドメインにわたり各 100 件ずつ均等に配分。

^ BrowseComp: 1,266 サンプルの評価プールから抽出した、難易度の高い 200 サンプルのサブセット。

定数

以下の値はすべてのプロバイダー結果で固定しているため、比較における唯一の変数は検索プロバイダーです。

  • 候補回答モデル: GPT-5.6 Luna(medium)
  • 推論の強度: Medium
  • 温度: 0.6
  • 最大出力トークン数: 127,999 トークン
  • 採点モデル: GPT-5.6 Luna(medium)。3 つのベンチマークで共通。
  • ターン上限: エージェント 25 ターン(t25)
  • サンプルあたりのツール呼び出し: ターン上限の範囲内で無制限
  • 提示する検索結果: 1 回の検索につき最大 10 件
  • 検索ツール: web_searchweb_fetch
    • web_search — 候補モデルのクエリを対象の Search API プロバイダーに送信し、そのネイティブなレスポンスペイロードを返します。
    • web_fetch — 検索結果から 1 つの URL を取得し、ページの内容(テキストのみ)を返します。
  • 抽出レイヤー: テキストのみを抽出。1 ページあたり 15 秒のタイムアウト。
  • 検索ペイロードの形式: プロバイダーのネイティブ形式。モデルはプロバイダー本来のレスポンスボディを参照します。
  • コンタミネーション・フィルタリング: 有効(詳細は後述)
  • エージェントのワークフロー: 次のいずれか。
    • 検索なしの model_only ベースライン、または
    • Stirrup の検索エージェントループ

ワークフロー

モデルのみのベースライン

model_only のサンプルでは、検索ツールを使わず、ベンチマークのプロンプトで候補モデルをワンショットで直接呼び出します。候補モデルが内部知識や推論だけでどこまで解けるかを推定するものです。

model_only のスコアが高いほど、そのベンチマークサンプルは最新の検索情報なしで回答できることを示します。逆に model_only のスコアが低いほど、検索による向上分が観察しやすくなります。

検索エージェントループ

検索ありのサンプルでは、Artificial Analysis の Stirrup ハーネスが制御する固定のエージェントループを使用します。

ハーネスは web_searchweb_fetch の 2 つのツールを提供します。

対象の検索プロバイダー API が web_search ツールを担い、候補モデルには与えられたタスクを解くために合計 25 ターンと無制限のツール呼び出しが与えられます。

十分な情報を集めたとモデルが判断すると、finish ツールを呼び出して最終回答を提出します。25 ターンをすべて使っても finish を呼び出さなかった場合、回答は提出されず、そのタスクは 0 点となります。

ベンチマークごとの採点器が、非公開の参照データと照らして回答を採点します。

エラー処理

回復可能なエラーは、失敗したツール呼び出しとしてモデルに返され、公開結果にもそのまま残ります。回復可能なエラーには次のものが含まれます。

  • 取得したウェブページのタイムアウトや HTTP エラー
  • web_search が返していない URL をモデルが取得した場合

致命的なエラーは成功するまで再試行し、致命的なエラーを含む結果は公開しません。致命的なエラーには次のものが含まれます。

  • Search API プロバイダー側のエラー(429、5xx、タイムアウトなど)

費用

費用は実験全体の総額として報告し、次のように内訳を示します。

  • 候補回答モデルの費用。入力、キャッシュ、推論、出力のすべてのトークンを含みます。
  • Search API プロバイダーの費用。
    • 注: model_only ベースラインには Search API プロバイダーの費用は発生しません。

レイテンシ

レイテンシは複数の観点から報告します。

  • タスクあたりのモデル時間。 タスクあたりの候補モデルの入力・思考・出力トークンにかかる、推定エンドツーエンド時間の平均。
  • タスクあたりの検索時間。 タスクあたりに web_search で費やした実測時間の平均。
  • タスクあたりの時間。 タスクあたりのモデル時間と検索時間の合計。
  • 検索クエリあたりの時間。 ベンチマーク全体を通じた、個々の web_search リクエストの平均レイテンシ。

1 回の呼び出しが速いプロバイダーでも、モデルがより頻繁に検索する場合は合計時間が長くなることがあります。

コンタミネーション・フィルタリング

コンタミネーション・フィルタリングは、ベンチマークの流出やその出典となりうるもの、および既知のものを取り除きます。

フィルタリングは、候補モデルが出力を目にする前に両方の検索ツールの内部で適用されます。web_search の結果は URL・タイトル・スニペットで、web_fetch のページテキストは抽出後にそれぞれ検査されます。該当した項目はプロバイダーの結果リストから除外されますが、レスポンスの構造は変わりません。

例:

  • 既知の出典の所在。 ベンチマークが元々公開されている URL やデータセット。
  • データセット本文の付随シグナル。 元データに含まれる既知のカナリア文字列。

検索プロバイダー API の設定

各プロバイダーは max_results=10(またはそれに相当する設定)で固定しています。以下に挙げるものを除き、設定はすべてプロバイダーの既定値のままです。

プロバイダー結果ドキュメントベンチマークでのリクエスト設定
BraveBrave Web Search APIq=agent query, result_filter=web
Tavily basicTavily Search APIsearch_depth=basic
You.comYou.com Search APIsafesearch=moderate
FirecrawlFirecrawl Search APIscrape_format=none
Exa fastExa Search APItype=fast, contents={"highlights": True}
Exa autoExa Search APItype=auto, contents={"highlights": True}
Parallel turboParallel Search APImode=turbo
Parallel basicParallel Search APImode=basic
Parallel advancedParallel Search APImode=advanced
Keenable proKeenable Search APImode=pro
Keenable realtimeKeenable Search APImode=realtime

ベンチマークの範囲

DeepSearchQA

単一回答と集合回答の行を含む、ディープリサーチ型の QA ベンチマーク。

  • 出典: Google DeepSearchQA。Hugging Face論文
  • サンプル範囲: 900 行からなる公開 eval スプリット全体。
  • 主要指標: F1。

BrowseComp

難易度の高いウェブ検索 QA ベンチマーク。

  • 出典: OpenAI BrowseCompSimple Evals とともに配布されています。論文
  • サンプル範囲: 200 サンプルの n200 判定パネル。選定方法は「指数の構成要素」に記載のとおりです。
  • 主要指標: 精度。

AA-Omniscience

正答性とキャリブレーションに焦点を当てた、非公開の事実 QA ベンチマーク。

  • 出典: AA-Omniscience。公開参照データセット: AA-Omniscience-Public論文
  • サンプル範囲: 非公開の 600 サンプル。6 ドメインにわたり各 100 行ずつ均等に配分。
  • 主要指標: 精度。

Omniscience Index やハルシネーション率ではなく精度を用います。AA-Omniscience は、パラメトリックな知識と、十分な文脈がないときに回答を控える能力を測るために設計されています。

検索ツールが文脈を供給する状況では、モデルは常に回答する傾向があります。そのため精度は、プロバイダーからの検索文脈が与えられたときにモデルがどれだけ正確に回答するか、という問いへの手がかりになります。

結果の読み方

Search API Bench は複数の観点からの比較です。

  1. 検索によって model_only より回答は改善したか。
  2. 品質を最も高めたプロバイダーはどこか。
  3. その改善にいくらかかったか。
  4. どれだけレイテンシが増えたか。
  5. その向上は複数のベンチマークにわたって安定しているか、それとも特定のタスク群に限られるか。

あるタスクにとって最良のプロバイダーが、必ずしも最高スコアのプロバイダーとは限りません。特定のユースケースに適した検索プロバイダーは、次の観点で評価してください。

  • ベースラインからの品質向上。
  • ベースラインからの費用増加。
  • ベースラインからのレイテンシ増加。