Megerősítéses tanulás (RL) központi szerepet kap a nyelvi modellek igazításában: az AI-asszisztenseknél megszokott reinforcement learning with human feedback (RLHF) mellett megjelent a reinforcement learning with verifiable rewards (RLVR) mint munkafolyamat a következtetési és ügynökfeladatokhoz. Az ipari alkalmazásokban az RL akkor válik gyakorlattá, amikor szervezetek speciális, domain-specifikus ügynököket igényelnek, és szeretnék a siker kritériumait közvetlenül tanítási jelekké alakítani.
Frontvonalbeli kutatások is kimutatták, hogy az RL javíthat általános képességeket: OpenAI nagy léptékű RL-sel tréningezte az o-sorozat modelljeit, a DeepSeek-R1 pedig azt szemléltette, hogy a group relative policy optimization (GRPO) és a verifiable rewards hogyan javítják a matematika-, kód- és következtetési viselkedést. NVIDIA Nemotron 3 Super esetében post-traininget hajtottak végre multi-environment RL-lel 21 NVIDIA NeMo Gym verifiers és 37 dataset kombinációja fölött, nagyjából 1,2 millió environment rollout generálása mellett.
A NeMo/Nemotron ökoszisztéma (például Nemotron, NVIDIA NeMo RL, NVIDIA NeMo Gym) nyílt modelleket, post-training recepteket és környezeti infrastruktúrát kínál, amelyek integrálhatók további eszközökkel: OpenRLHF, PrimeIntellect, SGLang, Unsloth, veRL vagy vLLM.
Miért fontos az RL az ügynököknél?
Sok szervezet igényel specializált ügynököket biztonsági triage-ra, tudományos felfedezésre, CLI automatizálásra, ügyféltámogatásra, adatanalízisre vagy belső eszközhasználatra. Nyílt modellek (például Nemotron) testreszabásával ez gyakorlatiá válik: a csapatok növelhetik a pontosságot és sebességet, miközben megtartják az adatok, szellemi tulajdon és telepítés feletti kontrollt.
Promptolás, RAG és külső eszközök sok esetben elegendők, de ha az ügynök ismételten hibás tool-hívásokat hajt végre, többlépéses munkafolyamatokban megbukik, helytelen formátumban ad eredményt vagy rossz stratégiát választ, akkor szükség van egy tanítási jelre — ezt adja az RL. Az ügynöki rendszerekben a jutalom tipikusan egy verifierből származik: olyan kódból vagy mechanizmusból, amely tesztekkel, eszközvégrehajtással, sémavalidációval, szimulátorokkal, reward modellel vagy LLM-as-judge/emberi preferencia címkékkel pontozza az eredményeket vagy pályákat.
Melyik módszert mikor használjuk? (RAG, prompting, SFT, DPO, RLVR, RLHF)
Ne az algoritmussal kezdj: "Melyik algoritmust válasszam?" — hanem azzal, hogy "Milyen viselkedést akarok növelni, és hogyan mérem?"
Egyszerű döntési mátrix a gyakori problémákra:
- A modell hiányos domain-tényekkel küzd: RAG vagy adatbefecskendezés.
- A modell nem követ egy formátumot: promptolás, majd SFT.
- A modellnek példákat kell utánoznia: SFT (LoRA vagy QLoRA hatékony adaptációhoz).
- Van preferált és elutasított kimenet: DPO.
- A sikert algoritmikusan ellenőrizni lehet: RLVR GRPO-val.
- Árnyalt emberi preferenciákra van szükség: RLHF vagy reward modeling.
- Az ügynök hosszú távú munkafolyamatokban többszörös tool-hívásokat és állapotfrissítéseket használ: környezet-alapú RL pálya-szintű jutalmakkal.
Általános útvonal verifikálható eszközhasználatnál és ügynök-munkafolyamatoknál: szükség esetén SFT → GRPO RLVR-rel → kiértékelés → hibák vizsgálata → ismétlés.
GRPO mint gyakorlati alapérték RLVR-hez
Az RLVR munkafolyamatoknál a group relative policy optimization (GRPO) gyakran jó kiindulópont: több kimenetet generál promptonként, ezeket a verifier pontozza, majd a modellt a csoporton belüli relatív teljesítmény alapján frissíti. Összehasonlítva a PPO-stílusú RLHF-fel, a GRPO kevesebb bonyolult összetevőt igényel és jól működik szabályalapú jutalmakkal, ezért sok ügynökös példa alapértelmezett megközelítése.
Megjelennek újabb variánsok is: a dynamic sampling policy optimization (DAPO) dinamikus mintavételt és aszimmetrikus clippinget ad a GRPO-hoz, míg a group sequence policy optimization (GSPO) sorozatszinten optimalizál a token-szintű helyett, ami stabilizálja a tréninget, különösen Mixture-of-Experts modelleknél. A továbbiakban a cikk gyakorlati RLVR munkafolyamatra koncentrál GRPO-val és környezeti értékeléssel.
A minimális RL-forduló hét eleme
Egy LLM/ügynök RL-tréning futás hét komponensből áll:
- Policy model: a tanított modell.
- Task: a modell bemenete.
- Action: modell-kimenet, tool-hívás, kódpatch, parancs vagy többlépéses pálya.
- Environment: a rendszer, amely végrehajtja az akciót és visszajelzést ad.
- Verifier: a siker pontozásáért felelős jel.
- Rolloutok: a jelenlegi modellből mintavételezett próbálkozások.
- Policy update: a tanítási lépés, amely növeli a jobb kimenetek valószínűségét.
Mindig kezdjen kiértékeléssel a tréning előtt: fusson le baseline a holdout feladatkészleten, vizsgálja a hibákat, és profilozza a verifiert vagy jutalomfüggvényt. Az RL akkor működik jól, ha a modell időnként el tudja érni a kívánt viselkedést, de nem megbízhatóan. Ha a jutalom hibás, az RL a rossz viselkedést optimalizálja.
Adat, környezet és jutalom tervezése
- Task és tréningadat: SFT-hez bemenet-kimenet példák szükségesek; RLVR-hez olyan taskok és environment logika kell, ahol a verifiert és eszközöket használva pontozni lehet a kimeneteket.
- Szintetikus adatgenerálás: hasznos, ha a valós példák ritkák — generálhatók task variánsok, edge-case-ek és eszköz-hívási forgatókönyvek, majd validálás után használhatók. NVIDIA NeMo Data Designer segíthet strukturált feladatadatokat létrehozni, NeMo Gym pedig lefuttatni azokat környezeteken keresztül.
- Agentikus RL környezetek: hosszú futamidejű vagy többlépéses ügynökök esetén szükség van környezetre, amely definiálja a datasetet, az agent harness-t, a verifiert és az állapotot. NeMo Gym skálázható, reprodukálható módon köti össze az ügynököket, modelleket, külső rendszereket, eszközöket és verifiert.
Jutalom- és verifier-tervezés: kezdje egyszerűvel. Sok projekt túlkomplikálja a jutalmazást; RLVR-nél egy bináris jutalom (+1 ha a verifier átmegy, 0 különben) jó kiindulás. Később adjon köztes jeleket csak akkor, ha valódi előrehaladást mérnek (például egy kódoló ügynöknél +0.1 a megfelelő eszköz kiválasztásáért, +0.4 argumentum-megfelelésért, +1.0 a feladat teljesítéséért, -1.0 veszélyes akcióért). Jó jutalomfüggvény:
- a valódi feladatot méri;
- nehéz kijátszani;
- láthatóan hibázik, ha rossz.
Fusson át 50–100 modellkimeneten a jutalomfüggvénnyel előzetesen; ha a pontozás nem egyezik a szakértői ítélettel, javítsa a verifiert.
Számítási költségek és ajánlások
Az RL-költség két munkaterhelésből áll: rollout és tréning. Mindkettőt befolyásolja batchméret, modellméret és szekvenciahossz. A rollout költség skálázódik a tool-hívások számával, beszélgetési fordulókkal és környezeti lépésekkel. VLLM javítja a rollout latenciát, NeMo Gym az eszközhívások szervezését. Tréning oldalon Megatron és NeMo Automodel növeli a throughputot; NeMo RL a fentiekre építve hatékony kört hoz létre.
GPU-igény a munkaterheléstől függ: adapter-alapú ~1B–8B kísérletek elindíthatók egy modern GPU-n vagy kis több-GPU csomón; nagyobb modellek, teljes fine-tuning, hosszú kontextus vagy sok rollout több GPU-t igényelnek. Számítás szűkössége esetén először csökkentse a modellméretet, max tokeneket, generálások számát és a párhuzamos környezetek számát.
Kezdetben használjon kisebb modelleket: ezek gyorsabban segítik a data-, verifier- és environment-hibák megtalálását. Komplex feladatoknál nagyobb modellre lehet szükség, hogy a jutalmi görbe vagy a holdout értékelés érdemi javulást mutasson.
Gyakorlati első RL-futtatás: egy ellenőrizhető, kis GRPO-jobbal
Példa: workplace assistant ügynök, amely helyes JSON tool-hívásokat generál természetes nyelvi kérésekből.
- Kezdje a NeMo RL getting-started példával, majd lépjen a multi-step Workplace Assistant tutorialra, amely a Nemotron Nano 9B v2 modellt GRPO-val tanítja eszközhívásokra projektmenedzsment munkafolyamatokban.
Lépések röviden:
- Válasszon egy viselkedést (pl. adott NL kérésre helyes JSON tool-hívás létrehozása).
- Futtasson baseline értékelést és osztályozza a hibákat (formátum, rossz eszköz, téves argumentumok, unsafe akciók).
- Döntse el, kell-e SFT (ha ritkán követi a formátumot, először SFT; ha néha jó, de ingadozó, lépjen RLVR-re).
- Építse meg a verifiert/jutalomfüggvényt egyszerűen; ellenőrizze azt mintákon, és javítsa, ha nem egyezik a szakértői ítélettel. Például egy egyszerű jutalomfüggvény JSON-validitás, expected_tool és argumentum-megfelelés alapján pontoz.
- Futtasson egy kis GRPO-jobbot (példa konfiguráció):
- modell: nvidia/Nemotron-Nano-9B-v2
- algoritmus: grpo
- adapter: lora
- num_generations_per_prompt: 8
- reward: tool_call_verifier
- eval_interval: 10
- held_out_eval: tool_call_eval
- Kövesse a megfelelő metrikákat: ne csak a training rewardot; mérje a validation rewardot, sikerarányt, érvénytelen kimeneteket, unsafe akciókat, késleltetést és költséget.
- Vizsgálja a hibákat checkpointonként, keresse a reward-hackelést, formátumregressziót vagy a biztonság romlását, és csak akkor promótáljon, ha a hangolt modell a holdouton megveri az alapvonalat.
Folyamatos fejlesztés hosszú életű ügynököknél
Egy hosszú futamidejű ügynök folyamatosan fejlődjön úgy, mint egy szoftver rendszer:
- Logolja a valós pályákat: promptok, eszköz-hívások, megfigyelések, kimenetek, hibák, emberi beavatkozások, végső kimenetek.
- Minden éles hibát alakítson regressziós tesztté vagy environment tasktá.
- Csoportosítsa a hibamódokat (formátum, rossz eszközválasztás, rossz tervezés, unsafe akciók, visszakeresési hibák, kitalált API-k stb.).
- Először a legkönnyebb javítást válassza (prompt vagy eszközváltás), SFT ismétlődő formátum/problémákra, DPO preferencia-lényegre, RLVR/GRPO, ha verifikálható a siker.
- Mindig tartson fenn egy fix, a tréningen kívüli eval készletet, és csak akkor promóciózzon, ha a viselkedés javult minden releváns metrikában.
- Verziózza a hangolt modelleket/adaptereket visszagörgethetőség és összehasonlíthatóság érdekében.
A cél: egy ügynök-flywheel, ahol éles hibákból evalok lesznek, evalokból environmentek, environmentek jutalmakat generálnak, a jutalmak javítják a modellt, és az új modell tesztelve kerül élesbe.
Következtetés — hogyan kezdjen hozzá?
A legrövidebb út egy hasznos RL-futtatáshoz: tiszta feladat, megbízható verifier, kis alapmodell és egy holdout eval, amely megmutatja, hogy a modell valóban javult. NVIDIA NeMo és Nemotron eszközök — Nemotron modellek, NeMo RL, NeMo Gym és NeMo Data Designer — receptet és infrastruktúrát adnak ahhoz, hogy a fejlesztők a feladatspecifikus adatkészítéstől a tréningen ésértékelésen át a finomhangolásig anélkül haladjanak, hogy a teljes RL-stacket nulláról kéne újraépíteniük.
