HLE

HLE liegt am entgegengesetzten Ende des Suchspektrums von BrowseComp. Die Fragen wurden von Fachexperten so formuliert, dass sie eindeutig, aber äußerst schwierig sind, sodass die Ausgangspunktzahl eines Modells hauptsächlich von seinem vorhandenen Wissen abhängt. Durch das Hinzufügen der Websuche wird daraus eine andere Frage: Wie viel Expertenwissen kann eine Suchkonfiguration bei Bedarf abrufen?

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

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

Da HLE stärker auf Fachwissen als auf Recherchetiefe setzt, fallen die Unterschiede zwischen Suchkonfigurationen hier geringer aus als bei BrowseComp: Viele Fragen werden bei jedem Budget auf dieselbe Weise beantwortet (oder nicht gelöst). Unterschiede zwischen Suchmaschinen mit überlappenden Konfidenzbereichen gelten hier als ungeklärt, nicht als Beleg für Gleichwertigkeit. Die Kosten einer Konfiguration sind ebenso real wie ihre Bewertung, betrachten Sie daher Qualität und Effizienz gemeinsam.

Wir verwenden die reine Textteilmenge des öffentlichen Datensatzes (multimodale Fragen sind ausgeschlossen), daher sind die Bewertungen nicht direkt mit Ranglisten für das vollständige HLE vergleichbar. Die Fragen sind öffentlich, sodass das Auswendiglernen die absoluten Bewertungen im Laufe der Zeit künstlich erhöhen kann; Unterschiede zwischen Suchkonfigurationen bleiben aussagekräftig, da alle Konfigurationen dasselbe Modell verwenden.

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 der Referenz entspricht — dieselbe Bewertung der Antwortäquivalenz, die BrowseComp verwendet. 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.