Such-APIs für KI-Agenten: Qualität schlägt reine Abfragegeschwindigkeit

Ein Benchmark, der die Latenzfrage neu stellt

33 Punkte ohne Suchzugriff, 65 bis 75 Punkte mit: Diese Spanne misst Artificial Analysis für dasselbe Antwortmodell. Der Sprung kommt nicht von einem besseren Modell. Er entsteht, weil der Agent überhaupt suchen darf. Brauchbare Treffer können außerdem den Tokenverbrauch des Antwortmodells senken. Damit beeinflusst der Suchanbieter Qualität, Kosten und Tempo des gesamten Agentenlaufs.

Search API Bench vergleicht Suchanbieter in einem agentischen Aufbau. Jede Probe nutzt dieselbe Benchmarkaufgabe und dasselbe Antwortmodell; nur der Suchanbieter wechselt. Als Antwortmodell dient GPT-5.6 Luna auf mittlerer Stufe. Unterschiede lassen sich dadurch nicht bequem auf ein anderes Modell, einen anderen Prompt oder eine andere Aufgabenstellung schieben.

Gemessen wird der ganze Lauf

Der Gesamtindex ist das gleich gewichtete Mittel der primären Qualitätsmetrik aus drei Benchmarks: DeepSearchQA steuert 900 Aufgaben bei, AA-Omniscience 600 und BrowseComp 200. Der Agent läuft auf Stirrup und darf pro Aufgabe wiederholt suchen und Webseiten abrufen.

Das verändert die Latenzfrage grundlegend. Nicht die Antwortzeit eines einzelnen Endpunkts entscheidet über den produktiven Nutzen, sondern die Dauer bis zu einer belastbaren Antwort einschließlich zusätzlicher Suchen, Seitenabrufe und Modellarbeit. Eine etwas langsamere API kann den gesamten Lauf verkürzen, wenn ihre Treffer früh die benötigten Belege liefern.

Tempo allein täuscht.

Eine schnelle API mit schwachen Resultaten schickt den Agenten dagegen in weitere Schleifen und vergrößert den Kontext. Genau diese Folgekosten fehlen in fast jedem Endpunkt-Datenblatt.

Qualität und Kosten laufen in dieselbe Richtung

Parallel, Exa und Firecrawl erreichen 75, 74 und 73 Punkte. Wichtiger als diese Momentaufnahme ist der Zusammenhang dahinter: Wenn der Agent früh brauchbare Resultate erhält, benötigt das Antwortmodell weniger Tokens. Suchqualität und Gesamtkosten sind in diesem Aufbau daher keine Gegensätze.

Das trifft die übliche Beschaffungslogik an einer empfindlichen Stelle. Wer Such-APIs nur nach Millisekunden pro Anfrage und Preis pro tausend Abfragen sortiert, optimiert eine Teilgröße. Der Suchpreis ist lediglich ein Posten; schwache Treffer erhöhen zusätzlich die Kosten des Antwortmodells.

Ich halte diesen Aufbau für ehrlicher als einen isolierten Latenzcheck. Die Zahlen bleiben allerdings an feste Bedingungen gebunden: ein Antwortmodell, ein Agentengerüst und drei Aufgabensets. Mit einem anderen Modell oder einem engeren Schrittbudget können die Abstände anders ausfallen. Die Rangfolge ist kein Naturgesetz.

Eine Auswahlszene aus der Praxis

Angenommen, ein Plattformteam prüft Parallel, Exa und Firecrawl für einen Rechercheagenten. Eine Testfrage ist nach acht Sekunden beantwortet, verbraucht aber mehrere Suchrunden und viel Modellkontext; eine andere dauert pro Abruf länger, liefert jedoch nach wenigen Schritten eine belegte Antwort. Wer nur die Endpunktlatenz betrachtet, wählt womöglich den teureren Lauf.

Für den Vergleich erhält jeder Anbieter denselben Aufgabensatz, während Antwortmodell, Prompt, Agentengerüst und Schrittbudget konstant bleiben. Pro Lauf werden drei Werte protokolliert: erreichte Qualität, verbrauchte Tokens und Wanduhrzeit bis zur fertigen Antwort. Vorab festgelegte Sollwerte und Abbruchschwellen verhindern, dass einzelne Ausreißer die Auswahl verzerren.

Bei auffälligen Läufen sollte das Plattformteam anschließend prüfen, wo die Mehrkosten entstanden sind: durch unpassende Treffer, wiederholte Seitenabrufe oder lange Modellantworten. So wird aus einer Rangliste ein Diagnosewerkzeug. Wie stark solche Entscheidungen am Gesamtsystem hängen, zeigt sich auch bei der Bewertung von Agenten-Benchmarks und in den Deep Dives zu Agenten-Werkzeugen.

Takeaways

Endpunktlatenz und Abfragepreis reichen als Leitgrößen für Agentensysteme nicht aus. Die tatsächliche Rechnung entsteht aus Trefferqualität, Folgeschritten und Tokenverbrauch des Antwortmodells. Search API Bench macht diese Kette sichtbar, indem der Suchanbieter als Variable wechselt.

Die Mindestregel für die nächste Evaluierung ist schlicht: Kein Anbieterwechsel allein auf Basis von Endpunktlatenz oder Abfragepreis. Wer die Tokenkosten des Antwortmodells nicht mitmisst, weiß nicht, was der Wechsel tatsächlich kostet.