BrowseComp

BrowseComp-Fragen zielen auf eine einzige, überprüfbare Antwort ab, die sich hinter mehreren Ebenen indirekter Hinweise verbirgt, etwa eine Person, die durch Fragmente ihrer Laufbahn beschrieben wird, oder ein Ereignis, das durch sich überschneidende Bedingungen eingegrenzt wird. Eine einzige Suche führt selten zum Ziel; der Agent muss Hypothesen aufstellen, suchen, verwerfen und die Richtung wechseln. Das macht diesen Test zu unserem präzisesten Werkzeug, um zu messen, welchen Beitrag eine Suchkonfiguration leistet: Dasselbe Modell erzielt mit einem vollen Budget für agentisches Arbeiten ein um ein Mehrfaches höheres Ergebnis als mit einer einzigen Suche vor der Inferenz.

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 Suchen verarbeitet, die Ausführung der Suche als Server-Tool oder als Plugin und die Anzahl der Agentendurchläufe, die in der Schleife zulässig sind. Genau diese Parameter können Sie bereits heute für eine Anfrage festlegen.

Diese Bewertungen vergleichen Suchkonfigurationen, keine Agentenprodukte. Das Modell liest ausschließlich Auszüge aus Suchergebnissen, ohne vollständige Seiten abzurufen und ohne Code-Tools, sodass die absoluten Werte unter denen veröffentlichter Agenten-Ranglisten liegen, die beides erlauben. Vergleichen Sie Konfigurationen statt absoluter Werte.

Überlappende Konfidenzbereiche gelten hier als ungeklärt, nicht als Beweis für Gleichheit. Kosten sollten zusammen mit der Qualität betrachtet werden, wenn eine Konfiguration geringfügig besser und deutlich teurer ist.

Der Datensatz wird verschlüsselt und mit einer Canary-Zeichenfolge versehen ausgeliefert, um ihn aus Trainingskorpora herauszuhalten, aber die Fragen sind öffentlich; die Bewertung hängt von einer mehrstufigen Live-Suche ab, die sich durch Auswendiglernen nur schwer umgehen lässt.

Jede Aufgabe besteht aus einer Frage mit einer kurzen Referenzantwort. Das Modell antwortet in einem festen Format (Erklärung, exakte Antwort, angegebene Konfidenz), und ein Bewertungsmodell beurteilt, ob die extrahierte Antwort semantisch mit der Referenz übereinstimmt. „1988 bis 1996“ stimmt mit „1988–96“ überein; eine andere Entität gilt als falsch. Die Bewertung ist binär ohne Teilpunkte, und fehlgeschlagene oder verweigerte Aufgaben erhalten null Punkte.

reward = judge(extracted_answer ≡ reference_answer)   // ∈ {0, 1}
judge  = gpt-4.1 at temperature 0, strict json_schema 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.