A CoreWeave, az NVIDIA és a You.com hatékonyabb keresőügynököt tanított

Valós webes adatokkal tanították a modellt

A három vállalat szeptember elején dolgozott együtt egy olyan nyílt súlyú modellen, amelyet ügynökalapú webes keresésre utóképeztek. A You.com a webgráfból építette fel a tanítási adatokat, mert megítélésük szerint a nyílt adathalmazok gyorsan elavulnak, és túlzottan a Wikipédiára támaszkodnak.

A csapat valódi weboldalakon található, objektív tényekre épülő, többfordulós kérdés-válasz párokat hozott létre. A források kiválasztásakor a közepes népszerűségű oldalakat célozták, majd egylépéses hivatkozásokat követtek az indexükben. Ezután minden kérdést nyolcszor futtattak le a Nemotron 3.5 Lightning modellen, saját keresési API-ikkal, és egy nyelvi modell értékelése alapján nehézségi kategóriákba sorolták őket.

A tanítás 4932, You.com Search és NeMo Automodel segítségével létrehozott felügyelt finomhangolási nyommal indult. Ezt 1480, csoportos relatív szabályoptimalizálással, vagyis GRPO-val és bináris jutalmazással tanított RL-feladat követte.

A gyorsabb súlyfrissítés csökkentette a várakozást

A megerősítéses tanulási ciklusban a rendszer először mintavételezéseket, úgynevezett rolloutokat generál, majd kiértékeli őket, frissíti a modellt, és megismétli a folyamatot. A CoreWeave és az NVIDIA az új modellverziók következtetési példányokra juttatásának gyorsítására összpontosított.

A hagyományos újratelepítéskor minden példány újraindul, letölti a teljes ellenőrzőpontot az objektumtárolóból, majd megvárja a kiszolgáló motor inicializálását. A CoreWeave RL Rollouts ehelyett helyben végzett súlyfrissítést, Hot-Loadot használ. A vezérlősík összehangolja a frissítést, miközben a NVIDIA Dynamo, a NVIDIA ModelExpress és a vLLM az egyes példányokon kezeli a betöltést.

A frissülő példány ideiglenesen szünetelteti a kiszolgálást, de memóriában megtartja a folyamatban lévő kéréseket és a gyorsítótárat. A betöltés után ezek a kérések az új súlyokkal folytatódnak, az új kérések pedig a szünet alatt várakoznak. A delta-súlyszinkronizálás a teljes modell helyett tömörített különbséget továbbít. A Nemotron 3.5 Lightning tesztjeiben ez a teljes BF16 ellenőrzőpont méretének 0,14 és 0,95 százaléka között volt.

Nagyobb pontosság, kevesebb keresés

A kiinduló modell a BrowseComp teszten 36,97 százalékos pontosságot ért el, és feladatonként átlagosan 168 eszközhívást végzett. A beszámoló szerint a fő hibák közé tartozott ugyanazon információ ismételt keresése, a keresési eredmények gyenge használata, valamint az, amikor a modell megtalálta a helyes választ, majd megkérdőjelezte azt.

A You.com Search és a közös optimalizálási folyamat után a pontosság 45,45 százalékra nőtt, az átlagos eszközhívások száma pedig körülbelül 115-re csökkent. Ez 31,55 százalékos visszaesés a hívások számában, a kiinduló eredményhez képest pedig 22,94 százalékos relatív javulást jelent.

Egy bemutatott feladatban az alapmodell 313 eszközhívással sem azonosította a keresett vezérigazgatót, miközben 1,3 millió karakternek megfelelő haszontalan keresési eredményt dolgozott fel. Az optimalizált ügynök hét hívásból oldotta meg ugyanezt a feladatot.

A módszer a fejlesztési ciklus gyorsítását célozza

A forrás szerint a négy NVIDIA HGX B200 GPU-n végzett SFT körülbelül egy órát, az RL-futás körülbelül nyolc órát vett igénybe, a teljes folyamat pedig nagyjából kilenc óra alatt zajlott le. A You.com keresési végpontjainak utóképezéshez igazított finomhangolása már a tanítás előtt körülbelül 4 százalékkal javította a teljesítményt.

A bemutatott munkafolyamat a valós webes adatokra, a nehézség szerinti szűrésre, a saját keresési nyomokon végzett SFT-re, majd a GRPO-ra épül. A CoreWeave szerint a Hot-Load és a delta-szinkronizálás rövidítheti a frissítések közötti várakozást, így az RL-ciklusban több idő maradhat a hasznos számításra. Ennek hatása attól függ, hogy a teljes munkafolyamat mekkora részét teszi ki a súlyok betöltése.