DeepSearchQA

Eine einzelne Tatsache zu finden und jede Tatsache zu finden, sind unterschiedliche Suchprobleme. Eine einzige glückliche Suchanfrage kann eine BrowseComp-Antwort liefern; eine DeepSearchQA-Antwort muss über mehrere Suchvorgänge hinweg zusammengestellt werden, wobei der Agent verfolgt, was er gefunden hat und was noch fehlt. Dieser Druck zur vollständigen Abdeckung beansprucht einen anderen Teil des Suchsystems: Ergebnisbreite und Deduplizierung sind ebenso wichtig wie das Ranking.

Wir führen den Test mit einem unveränderten Modell durch, weil sich so die Variablen isolieren lassen, die OpenRouter-Nutzer tatsächlich steuern können. Dazu gehören die Suchmaschine, die die Suchvorgänge verarbeitet, die Ausführung der Suche als Server-Tool oder Plugin sowie die Anzahl der zulässigen Agentenschritte in der Schleife. Genau diese Parameter können Sie bereits heute für eine Anfrage festlegen.

Diese Bewertungen vergleichen Suchkonfigurationen, nicht Agentenprodukte. Das Modell liest ausschließlich Auszüge aus Suchergebnissen, ohne vollständige Seiten abzurufen oder Code-Tools zu nutzen, sodass die absoluten Werte unter denen veröffentlichter Agentenranglisten liegen, die beides erlauben. Vergleichen Sie Konfigurationen statt reiner Zahlenwerte.

Die Alles-oder-nichts-Bewertung macht diese Testsuite streng: Ein fehlendes Listenelement wird genauso bewertet wie das Fehlen aller Elemente, sodass die Bewertungen niedrig ausfallen und kleine Unterschiede zwischen Suchmaschinen stark durch Zufallsschwankungen beeinflusst werden. Überlappende Konfidenzintervalle gelten hier als ungeklärt, nicht als Beweis für Gleichheit. Die Kosten einer Konfiguration sind ebenso real wie ihre Bewertung, betrachten Sie daher Qualität und Effizienz gemeinsam.

Die Fragen sind öffentlich, was bedeutet, dass Auswendiglernen die absoluten Bewertungen im Laufe der Zeit erhöhen kann; Unterschiede zwischen Suchkonfigurationen bleiben aussagekräftig, weil jede Konfiguration dasselbe Modell verwendet.

Jede Aufgabe besteht aus einer Frage mit einer Referenzliste der erwarteten Antwortbestandteile. Ein Bewertungsmodell prüft die Antwort auf jeden erwarteten Bestandteil und markiert außerdem überzählige Antworten – Bestandteile, die in der Antwort behauptet werden, aber nicht in der Referenz enthalten sind. Eine Aufgabe ist nur dann korrekt, wenn das Bewertungsmodell jeden erwarteten Bestandteil und keine überzähligen Antworten findet. Die Bewertung ist binär ohne Teilpunkte, und fehlgeschlagene oder verweigerte Aufgaben erhalten null Punkte.

reward = all_expected_parts_found ∧ no_excessive_answers   // ∈ {0, 1}
judge  = gemini-2.5-flash, strict json_schema completeness verdict
empty or refused answers skip the judge and score 0

Eine Suchkonfiguration besteht aus einem Modell, einer Suchmaschine, einem Anfrageformat und einem maximalen Suchbudget. Die Bewertungen werden nach der Anzahl der Fragen in jedem verifizierten Durchlauf gewichtet; kleine Smoke-Tests werden ausgeschlossen.

Die Durchläufe werden auf Kepler, dem Harness für Leistungsvergleiche von OpenRouter, gegen Produktionsendpunkte ausgeführt. Servertool-Konfigurationen legen ein anfragebezogenes Budget für Tool-Aufrufe fest, und zwar für das Websuch-Servertool. Plugin-Konfigurationen führen vor der Inferenz eine einzelne Suche nach der Frage durch, und zwar mit dem Websuch-Plugin. Die Suchmaschinen verwenden dieselben Standardkonfigurationen wie bei der Verarbeitung von Produktionsdatenverkehr.

Jeder Durchlauf speichert das genaue Modell, die Engine, das Anfrageformat, das Suchbudget, die Kosten und die verfügbare Zeittelemetrie. Fehlende Konfigurationen bleiben in der Vergleichstabelle fehlend, und absent or zero telemetry is not treated as free or instantaneous performance.