Kihagyás

Agent Training from First Principles — SFT, RL, Environment Design

A Core Loop

Minden agent-training rendszer ugyanarra az alapstruktúrára épül:

prompt → model action → environment → reward → gradient update

A framework-ek (TRL, Unsloth, PRIME-RL, verl, OpenRLHF) ezt a loop-ot skálázzák — batching, rollout generation, distributed inference, reward computation, clipping — de a koncepcionális mag ugyanaz.

Agent = Policy + Environment

Egy nyelvi modell akkor válik agent-té, amikor a kimenete nem prose, hanem végrehajtható akció. Az environment definiálja: - Milyen akciók validak - Mi történik az akciók végrehajtásakor - Hogyan mérjük a sikert (reward)

Példa (text-to-diagram agent): - Observation: user kérés ("rajzolj egy CI pipeline-t") - Action: JSON akciók (create_shape, connect) - Environment: Python Canvas, ami validálja és rendereli az akciókat - Reward: JSON validity + layout minőség + szemantikus coverage

SFT vs RL Felosztás

Fázis Mit csinál Miért kell
Teacher trajectories Erősebb modell (Gemini) generál példa akciókat Cold start probléma megoldása
SFT A diák modell utánozza a tanár trajectory-kat Megtanítja az action language-t (valid JSON, séma)
RL A modell saját rollout-jait pontozza a környezet, és a jobbak felé mozdul Optimalizál a reward függvény szerint

Aranyszabály: "SFT buys you syntax. RL buys you optimization."

SFT nélkül a modell a valid akciótéren kívül marad, és minden rollout null reward-ot kap → RL használhatatlan. SFT után a modell be tud lépni a valid tartományba, ahol az RL már értelmes gradienst kap.

Miért RL az SFT után?

  • A tanár trajectory-k statikusak — azt mutatják, amit a tanár csinált
  • SFT azt mondja: "legyen ez a válasz valószínűbb"
  • RL azt mondja: "legyenek a magas reward-ú válaszok valószínűbbek"
  • RL tud javítani a tanár által nem demonstrált megoldások felé is

Environment Design > Algorithm Selection

A cikk legfontosabb állítása: az environment minősége bottleneck-eli az RL agent minőségét, nem az algoritmus választása.

Jó environment tulajdonságai: 1. Partial credit: ne csak 0/1 legyen a reward — a malformed JSON is kapjon többet mint a teljesen invalid, a valid-de-hiányos többet mint a malformed 2. Szétválasztja a szintaxist és szemantikát: a validitás szükséges, de nem elégséges 3. Nehezen kijátszható: ha a modell megtalálja a reward hacking lehetőségét, ki is fogja használni 4. Log-olható: minden rollout inspectable legyen (prompt, completion, parse errors, canvas state, reward komponensek)

Gyakori Hibamódok

  • Soha nem kap reward-ot → a valid régió elérhetetlen → SFT kell, egyszerűbb action space, partial reward
  • Triviális outputokat tanul → a reward túlértékeli a validitást a feladatteljesítéssel szemben
  • Valid JSON, de ignorálja a promptot → a reward túl szintaktikus → szemantikus scoring kell
  • Túltanulja a tanár stílusát → túl szűk SFT adat → több tanár modell, diverzebb trajectory-k
  • Instabil RL futás → túl agresszív update → alacsonyabb LR, clipping, KL penalty
  • A reward nő, de a humán minőség nem → reward hacking → inspect, bontsd fel a reward-ot, negatív tesztek

GRPO (Group Relative Policy Optimization)

A legegyszerűbb online RL módszer: 1. Vegyünk G darab completion-t ugyanarra a promptra 2. Pontozzuk őket az environment-tel: r₁, r₂, ..., r_G 3. Számoljunk group-relative advantage-et: Aᵢ = (rᵢ - mean(r)) / (std(r) + ε) 4. Növeld a jobbak valószínűségét, csökkentsd a rosszabbakét

A valós implementációk (PPO, GRPO) hozzáadnak clipping-et, KL penalty-t, reference model-t, token masking-et.

Pipeline Összefoglaló

1. Environment definiálása (action schema, validator, reward)
2. Prompt-ok generálása (seed + synthetic)
3. Teacher trajectory-k generálása (erősebb modell → validál → validak megtartása)
4. SFT a diák modellen
5. RL (GRPO/PPO) az environment reward alapján
6. Eval holdout prompt-okon
7. Iteráció: reward javítása, nehezebb prompt-ok, új teacher trace-ek

Relevancia a Mi Rendszerünkre

A jelenlegi pipeline-unk (összefoglalók, wiki, Nuclear Pulse) implicit SFT-szerűen működik (template-ek, strukturált formátum). Egy explicit environment + reward komponens (outcome grader) beépítése a pipeline végére javíthatná a minőséget:

  • Reward komponensek: forrás-validitás, dátum-pontosság, strukturális teljesség, topic mapping helyesség
  • Outcome grading: a summary után automatikus ellenőrzés, csak valid output kerüljön a topic fájlba
  • Log-olás: minden feldolgozás inspectable legyen a hibák javításához
Vissza a tetejére