CoreWeave, NVIDIA und You.com steigern die BrowseComp-Genauigkeit in drei Wochen auf 45,45 Prozent

Was der Sprint gebracht hat

Anfang September haben die drei Unternehmen ein Open-Weight-Modell für agentische Websuche per Post-Training optimiert. Der Workflow kombinierte webbasierte Suchdaten, Supervised Fine-Tuning (SFT), Reinforcement Learning (RL) und verwaltete RL Rollouts. Laut CoreWeave lag das Endergebnis bei 45,45 Prozent Genauigkeit auf BrowseComp, gegenüber 36,97 Prozent bei der ursprünglichen Baseline. Das entspricht einer relativen Verbesserung von 22,94 Prozent.

Die durchschnittliche Zahl der Tool-Aufrufe sank von rund 168 auf 115 pro Aufgabe, eine Reduktion um 31,55 Prozent. CoreWeave beschreibt die Fehler des Basismodells anhand von drei Mustern: Death Loops, bei denen es wiederholt nach denselben Informationen suchte; schwache Tool-Nutzung, bei der es aus Ergebnissen keinen Nutzen zog; und Second-Guessing, bei dem es die richtige Antwort fand, an ihr zweifelte und dann falsch antwortete.

Als anschauliches Beispiel nennt das Unternehmen einen BrowseComp-Durchlauf, bei dem anhand von Hinweisen zu einem CEO ein Automodell identifiziert werden sollte. Im berichteten Vergleich benötigte das Basismodell 313 Tool-Aufrufe und fand nie heraus, wer der CEO war. Der optimierte Agent kam mit 7 Tool-Aufrufen ans Ziel.

Daten und Trainingsstrategie von You.com

You.com argumentierte, offene Datensätze veralteten schnell und stützten sich stark auf Wikipedia, während echte Fragen im echten Web stattfänden. Das Unternehmen erstellte mehrstufige Frage-Antwort-Paare, die auf objektiven Fakten echter Webseiten beruhen. Das Team zog Stichproben aus dem mittleren Popularitätsbereich, ließ den spamlastigen Long Tail und den boilerplate-lastigen Kopf aus und folgte 1-Hop-Links, um Seiteninhalte aus seinem Index zu holen.

Anschließend wurde nach Schwierigkeit gefiltert. Jede Frage wurde achtmal mit Nemotron 3.5 Lightning über die Such-APIs von You.com ausgeführt, wobei ein LLM-Judge jeden Versuch bewertete. Die Fragen wurden in Kategorien von zu leicht (8/8) bis zu schwer (0/8) eingeteilt. Die Überlegung dahinter, so der Beitrag: Wenn ein Modell eine Frage manchmal löst, ist sie trainierbar; löst es sie nie, lohnt sich das Rechenbudget noch nicht.

Das Team nutzte 4.932 SFT-Traces, die mit You.com Search und NeMo Automodel erzeugt wurden, gefolgt von 1.480 RL-Aufgaben, trainiert mit Group Relative Policy Optimization (GRPO) und einem binären Belohnungssignal. CoreWeave zufolge lief der gesamte Job auf seiner Infrastruktur in etwa 9 Stunden. You.com berichtet außerdem, dass die Abstimmung seiner Such-Endpunkte auf Konsistenz im Post-Training die Leistung bereits vor dem eigentlichen Training um etwa 4 Prozent verbesserte.

Hot-Load: schnellere Gewichtsupdates für RL Rollouts

CoreWeave sieht das zentrale Infrastrukturproblem im Inferenztakt. In einer RL-Schleife werden Rollouts erzeugt, bewertet und zum Update der Policy genutzt, und die neuen Gewichte müssen die Serving-Replikate erreichen, bevor der nächste Zyklus beginnt. Bei einem herkömmlichen Rolling Redeploy startet jedes Replikat neu, lädt den vollständigen Checkpoint aus dem Objektspeicher herunter und wartet, bis die Engine initialisiert ist. In dieser Zeit ist das Replikat nicht verfügbar, und unfertige Anfragen können verloren gehen.

CoreWeave RL Rollouts ersetzt dies durch direkte Gewichtsupdates im laufenden Betrieb, genannt Hot-Load. Der Trainer veröffentlicht einen Checkpoint und ruft die Hot-Load-API auf, während frühere Rollouts noch laufen. Die Control Plane von CoreWeave koordiniert das Update, während NVIDIA Dynamo, NVIDIA ModelExpress und vLLM es innerhalb jedes Replikats ausführen. Das Replikat pausiert das Serving, behält aber laufende Anfragen und den Cache im Speicher und setzt dann mit den neuen Gewichten fort. Für streng On-Policy-Training kann der Trainer einen Reset des Prompt-Caches anfordern und warten, bis alle Replikate ihr Update abgeschlossen haben.

• Delta Weight Sync veröffentlicht ein komprimiertes Delta gegenüber einem Baseline-Checkpoint. In den Tests mit Nemotron 3.5 Lightning betrugen die Deltas grob 0,14 Prozent, 0,95 Prozent der Größe des vollständigen BF16-Checkpoints.
• Ein Replikat rekonstruiert den Checkpoint lokal, die übrigen erhalten die Gewichte über GPU-zu-GPU-Transfers über das InfiniBand-Netzwerk von CoreWeave oder über NVIDIA NVLink.
• In einem Benchmark mit vier Replikaten auf den NVIDIA-GB300-NVL72-Systemen von CoreWeave war das schnellste Delta-Hot-Load etwa 15-mal schneller als der durchschnittliche Cold-Start-Redeploy.

Rollout-Antworten liefern zudem Token-IDs und Logprobs pro Token zurück, sowie Expert-Routing-Daten für unterstützte Mixture-of-Experts-Deployments, sofern aktiviert.

Was das für Teams bedeutet, die Suchagenten bauen

Für Teams, die Suchagenten entwickeln, bedeutet das Ergebnis laut CoreWeave: mehr korrekt beantwortete Fragen bei weniger Tool-Aufrufen. Für Teams, die RL-Post-Training betreiben, können schnellere Updates nach Angaben des Unternehmens die Wartezeit zwischen den Runden verkürzen und die GPUs über einen größeren Teil des Zyklus produktiv halten. Es schränkt jedoch ein, dass die Wirkung davon abhängt, wie viel Zeit eines Workflows auf das Laden von Gewichten entfällt.

Die Unternehmen präsentieren das Vorhaben als wiederholbares Muster und nicht als Einzelfall. Ihre Empfehlungen: mit einer starken Suche beginnen, Fragen aus dem echten Web aufbauen und gegen die eigene Evaluation dekontaminieren, vor dem Training nach Schwierigkeit filtern, dann SFT auf den eigenen Traces ausführen und anschließend GRPO mit einer binären Judge-Belohnung.