Artificial Analysis Search Index: Methodik des Search-API-Benchmarks
Überblick
Search API Bench bewertet Suchanbieter in einem agentischen Suchszenario.
Der Benchmark ist ein Vergleich mit Anbieterwechsel. Jede Stichprobe verwendet dasselbe Kandidaten-Antwortmodell und dieselbe Benchmark-Aufgabe und variiert allein den Suchanbieter.
Wir werten die Ergebnisse mit einem einzigen Antwortmodell aus, wodurch wir den Zugewinn messen können, den jeder Search-API-Anbieter liefert.
Auf dieser Seite bezeichnet ein Ergebnis stets einen Search-API-Anbieter in Kombination mit dem festen Kandidaten-Antwortmodell. Wir nennen dies ein Anbieterergebnis.
Zentrale Kennzahlen
Artificial Analysis Search Index
Die öffentliche Bestenliste wird von einem einzigen kombinierten Wert angeführt, dem Artificial Analysis Search Index. Er ist der gleichgewichtete Mittelwert der primären Qualitätskennzahl jedes Benchmarks:
Hinweise zur Berechnung:
- AA-Omniscience steuert die Genauigkeit bei, nicht seinen Omniscience Index oder seine Halluzinationsrate. Die Genauigkeit ist das unmittelbar vergleichbarste Signal, wenn ein Suchanbieter mit dem Kandidatenmodell kombiniert wird.
- Alle Eingaben verwenden dieselben Konstanten (siehe unten), sodass der Index den Suchanbieter isoliert.
Bestandteile des Index
| Evaluation | Bereich | Aufgaben | Antworttyp | Bewertung |
|---|---|---|---|---|
| DeepSearchQA | Deep-Research-QA (Einzel- und Mengenantworten) | 900‡ | Offene Antwort / Antwortmenge | LLM-bewerteter F1 über Antwortelemente, pass@1 |
| AA-Omniscience | Faktenwissen-QA (Korrektheit + Kalibrierung) | 600† | Offene Antwort (Enthaltung zulässig) | LLM-bewertete Genauigkeit, pass@1 |
| BrowseComp | Schwierige Websuche-QA | 200^ | Kurze exakte Antwort | LLM-bewertete Genauigkeit exakter Antworten, pass@1 |
Alle drei Benchmarks verwenden GPT-5.6 Luna (medium) für die Bewertung, jeweils mit ihren benchmarkspezifischen Bewertungsrastern.
‡ DeepSearchQA: der vollständige öffentliche Eval-Split mit 900 Zeilen.
† AA-Omniscience: 600 private, zurückgehaltene Stichproben, ausgewogen mit je 100 pro Domäne über 6 Domänen.
^ BrowseComp: eine schwierige Teilmenge aus 200 Stichproben, gezogen aus dem Evaluationspool mit 1.266 Stichproben.
Konstanten
Jeder der folgenden Werte wird über alle Anbieterergebnisse hinweg konstant gehalten, sodass der Suchanbieter im Vergleich die einzige Variable ist.
- Kandidaten-Antwortmodell: GPT-5.6 Luna (medium)
- Reasoning-Aufwand: Medium
- Temperatur: 0,6
- Maximale Ausgabe-Token: 127.999 Token
- Bewertungsmodell: GPT-5.6 Luna (medium), für alle drei Benchmarks gleich
- Zugbudget: 25 Agentenzüge (t25)
- Tool-Aufrufe pro Stichprobe: Unbegrenzt innerhalb des Zugbudgets
- Angezeigte Suchergebnisse: Bis zu 10 Ergebnisse pro Suche
- Such-Tools:
web_searchundweb_fetchweb_search– Sendet die Anfrage des Kandidatenmodells an den jeweiligen Search-API-Anbieter und gibt dessen native Antwort-Payload zurück.web_fetch– Ruft eine URL aus einem Suchergebnis ab und gibt den Seiteninhalt zurück (nur Text).
- Extraktionsschicht: Reiner Textextraktor mit einem Timeout von 15 Sekunden pro Seite
- Format der Such-Payload: Anbieternativ; das Modell sieht den ursprünglichen Antwortkörper des Anbieters
- Kontaminationsfilterung: Aktiviert, wie unten beschrieben
- Agenten-Workflow: Entweder:
model_only-Baseline ohne Suche oder- Stirrup-Suchagentenschleife
Workflow
Baseline ohne Suche
Die model_only-Stichprobe ruft das Kandidatenmodell einmal direkt mit dem Benchmark-Prompt und ohne Such-Tools auf. Sie schätzt ab, wie viel das Kandidatenmodell allein aus internem Wissen oder Reasoning lösen kann.
Ein hoher model_only-Wert zeigt an, dass eine Benchmark-Stichprobe ohne frische Suchinformationen beantwortbar ist, während ein niedrigerer model_only-Wert den Zugewinn durch Suche leichter erkennbar macht.
Suchagentenschleife
Suchstichproben verwenden eine feste Agentenschleife, orchestriert vom Stirrup-Harness von Artificial Analysis.
Das Harness stellt zwei Tools bereit: web_search und web_fetch.
Der getestete Search-API-Anbieter betreibt das web_search-Tool, und das Kandidatenmodell hat insgesamt 25 Züge mit unbegrenzten Tool-Aufrufen, um die Aufgabe zu lösen.
Wenn das Modell genügend Informationen gesammelt zu haben glaubt, ruft es ein finish-Tool auf, um seine endgültige Antwort abzugeben. Verbraucht das Modell alle 25 Züge, ohne finish aufzurufen, wird keine Antwort abgegeben und die Aufgabe wird mit null bewertet.
Ein benchmarkspezifisches Bewertungsmodell bewertet die Antwort anhand verborgener Referenzdaten.
Fehlerbehandlung
Behebbare Fehler gelangen als fehlgeschlagener Tool-Aufruf zurück an das Modell und verbleiben in den veröffentlichten Ergebnissen. Zu den behebbaren Fehlern zählen:
- Timeouts oder HTTP-Fehler bei abgerufenen Webseiten
- Das Modell ruft eine URL ab, die
web_searchnicht zurückgegeben hat
Fatale Fehler werden bis zum Erfolg wiederholt, sodass kein veröffentlichtes Ergebnis einen enthält. Zu den fatalen Fehlern zählen:
- Fehler des Search-API-Anbieters (z. B. 429, 5xx und Timeouts)
Kosten
Die Kosten werden als Gesamtkosten des Experiments ausgewiesen und aufgeteilt in:
- Kosten des Kandidaten-Antwortmodells, einschließlich aller Eingabe-, Cache-, Reasoning- und Ausgabe-Token.
- Kosten des Search-API-Anbieters.
- Hinweis: Die
model_only-Baseline verursacht keine Kosten beim Search-API-Anbieter.
- Hinweis: Die
Latenz
Die Latenz wird auf mehrere Arten ausgewiesen:
- Modellzeit pro Aufgabe. Durchschnittliche abgeleitete Ende-zu-Ende-Zeit für Eingabe-, Denk- und Ausgabe-Token des Kandidatenmodells pro Aufgabe.
- Suchzeit pro Aufgabe. Durchschnittlich gemessene Zeit, die pro Aufgabe in
web_searchverbracht wird. - Zeit pro Aufgabe. Summe aus Modellzeit pro Aufgabe und Suchzeit pro Aufgabe.
- Zeit pro Suchanfrage. Durchschnittliche Latenz je einzelner
web_search-Anfrage über den gesamten Benchmark hinweg.
Ein Anbieter kann pro Aufruf schnell sein und trotzdem mehr Gesamtzeit beisteuern, wenn das Modell häufiger gegen ihn sucht.
Kontaminationsfilterung
Die Kontaminationsfilterung entfernt bekannte und mögliche Benchmark-Leaks sowie deren Quellen.
Die Filterung greift in beiden Such-Tools, bevor das Kandidatenmodell irgendeine Ausgabe sieht: web_search-Ergebnisse werden anhand von URL, Titel und Snippet geprüft, und der Seitentext von web_fetch wird nach der Extraktion geprüft. Markierte Einträge werden aus der Ergebnisliste des Anbieters entfernt, ohne die Struktur der Antwort zu verändern.
Zum Beispiel:
- Bekannte Quellorte. Ursprünglich gehostete Benchmark-URLs und -Datensätze.
- Begleitsignale im Datensatztext. Bekannte Canary-Strings im Ausgangsmaterial.
Einstellungen der Such-Anbieter-APIs
Jeder Anbieter verwendet fest max_results=10 (oder das Äquivalent des Anbieters). Alle Einstellungen bleiben auf den Standardwerten des Anbieters, mit Ausnahme der unten aufgeführten.
| Anbieterergebnis | Dokumentation | Anfrageeinstellungen im Benchmark |
|---|---|---|
| Brave web | Brave Web Search API | q=agent query, result_filter=web |
| Brave LLM context | Brave LLM Context API | q=agent query, api=llm_context |
| Exa instant | Exa Search API | type=instant, contents={"highlights": True} |
| Exa fast | Exa Search API | type=fast, contents={"highlights": True} |
| Exa auto | Exa Search API | type=auto, contents={"highlights": True} |
| Firecrawl | Firecrawl Search API | scrape_format=none |
| Keenable pro | Keenable Search API | mode=pro |
| Keenable realtime | Keenable Search API | mode=realtime |
| Parallel turbo | Parallel Search API | mode=turbo |
| Parallel fast | Parallel Search API | mode=fast |
| Parallel basic | Parallel Search API | mode=basic |
| Parallel advanced | Parallel Search API | mode=advanced |
| Perplexity low | Perplexity Search API | search_context_size=low |
| Perplexity medium | Perplexity Search API | search_context_size=medium |
| Perplexity high | Perplexity Search API | search_context_size=high |
| Tavily basic | Tavily Search API | search_depth=basic |
| TinyFish web | TinyFish Search API | domain_type=web |
| You.com snippets | You.com Search API | safesearch=moderate |
| You.com highlights | You.com Search API | safesearch=moderate, extraction={"extraction_mode": "highlights"} |
Umfang der Benchmarks
DeepSearchQA
Ein QA-Benchmark im Stil der Deep Research, mit Zeilen für Einzel- und Mengenantworten.
- Quelle: Google DeepSearchQA. Hugging Face. Paper.
- Stichprobenumfang: vollständiger öffentlicher
eval-Split mit 900 Zeilen. - Hauptkennzahl: F1.
BrowseComp
Ein schwieriger QA-Benchmark für die Websuche.
- Quelle: OpenAI BrowseComp, veröffentlicht mit Simple Evals. Paper.
- Stichprobenumfang: das Entscheidungspanel
n200mit 200 Stichproben, ausgewählt wie unter „Bestandteile des Index“ beschrieben. - Hauptkennzahl: Genauigkeit.
AA-Omniscience
Ein privater, zurückgehaltener QA-Benchmark zum Faktenwissen mit Fokus auf Korrektheit und Kalibrierung.
- Quelle: AA-Omniscience. Öffentlicher Referenzdatensatz: AA-Omniscience-Public. Paper.
- Stichprobenumfang: 600 private Stichproben, ausgewogen mit je 100 Zeilen pro Domäne über 6 Domänen.
- Hauptkennzahl: Genauigkeit.
Wir verwenden die Genauigkeit statt des Omniscience Index oder der Halluzinationsrate. AA-Omniscience wurde entwickelt, um parametrisches Wissen und die Fähigkeit zur Enthaltung ohne ausreichenden Kontext zu prüfen.
Steht ein Such-Tool zur Kontextbeschaffung bereit, antwortet ein Modell tendenziell immer. Die Genauigkeit beantwortet daher die Frage: Wie genau antwortet das Modell, wenn ein Anbieter den Suchkontext liefert?
Ergebnisse interpretieren
Search API Bench ist ein Vergleich mit mehreren Zielgrößen:
- Hat die Suche die Antwort gegenüber
model_onlyverbessert? - Welcher Anbieter hat die Qualität am stärksten verbessert?
- Wie viel hat diese Verbesserung gekostet?
- Wie viel Latenz kam dadurch hinzu?
- Sind die Zugewinne über die Benchmarks hinweg robust oder auf eine einzelne Aufgabenfamilie beschränkt?
Der stärkste Anbieter für eine bestimmte Aufgabe muss nicht derjenige mit der höchsten Punktzahl sein. Ein für einen konkreten Anwendungsfall geeigneter Suchanbieter sollte bewertet werden nach:
- Qualitätszugewinn gegenüber der Baseline.
- Kostenanstieg gegenüber der Baseline.
- Latenzanstieg gegenüber der Baseline.