SFT, RL en On-Policy Distillation door een distributionele lens

Het verschil tussen SFT, RL en On-Policy Distillation zit niet primair in de loss-functie, maar in de distributie van staten waarop je traint. Dat is de centrale stelling van een technische blog van nrehiew die post-training herpositioneert als "distributional shaping". Een taalmodel is een kansverdeling over sequenties. SFT trekt die verdeling richting een externe dataset. RL verschuift de verdeling via eigen rollouts richting hogere reward. OPD zit ertussenin: de student genereert zelf trajecten, maar krijgt daarbij een teacher-signaal om de eigen outputdistributie bij te sturen.

Dit is geen volledig formele theorie, maar een architecturaal zeer bruikbare lens voor wie post-training, agent-tuning of domeinspecifieke modeladaptatie ontwerpt. En voor de Nederlandse publieke sector, waar steeds meer organisaties eigen modellen fine-tunen op gevoelige data, is dit inzicht direct operationeel relevant.

SFT: krachtig maar risicovol

Supervised Fine-Tuning traint op een vaste externe target-distributie. De dataset bestaat al vóór training, human-written of synthetic. Cross-entropy trekt het model naar die dataset toe, ongeacht hoe ver die afligt van de oorspronkelijke modeldistributie. Daardoor heeft SFT een natuurlijk failure mode: catastrophic forgetting.

Dat betekent niet dat SFT slecht is. SFT is juist zeer geschikt voor cold-start gedrag: instructievolging, outputformaten, domeinconventies, tool-calling syntax, compliance templates, juridische formats of code-editing conventies. Maar SFT is grofmazig. Elk token krijgt trainingsdruk, ook tokens die niet taak-kritisch zijn. De blog noemt dat "uniform, aggressive token-level gradients": stijlwoorden, tussenstappen en toevallige artefacten worden net zo hard geleerd als de relevante redenering of actie.

Voor enterprise AI betekent dit: SFT is geschikt om een model "taal en vorm" te leren, maar gevaarlijk als je daarmee diep capability-gedrag probeert te forceren zonder retentie-evaluatie. Je loopt risico op degradatie van algemene redeneercapaciteit, codekwaliteit, robuustheid of security awareness. Dit is exact het patroon dat we zagen in de Oracle Poisoning-analyse: modellen verliezen kennis niet omdat ze slecht getraind zijn, maar omdat de training geen onderscheid maakt tussen kritische en incidentele tokens.

RL: minder imitatie, meer lokaal bijsturen

RL werkt fundamenteel anders. Het model genereert zelf samples, een rewardfunctie beoordeelt die samples, en policy gradient verhoogt de kans op gedrag met hogere verwachte reward. Daardoor komt de trainingsdruk alleen uit gebieden die het model zelf bezoekt. De auteur stelt dat dit verklaart waarom RL vaak minder forgetting veroorzaakt: RL duwt het model niet naar een willekeurige externe dataset, maar zoekt een nabijgelegen taakoplossende policy.

Dit is vooral overtuigend bij RLVR, Reinforcement Learning with Verifiable Rewards. Bij wiskunde, code, unit tests, formele validatie of security challenges is de reward relatief betrouwbaar. Bij RLHF is dit minder schoon, omdat een reward model of LLM judge bias, voorkeuren en stijlverwarring introduceert. De blog maakt terecht onderscheid tussen verifieerbare rewards en subjectieve feedbacksignalen.

Voor de DjimIT-context is dit belangrijk: waar je objectieve validators hebt, tests, policy checks, schema-validatie, linting, static analysis, exploit-detectie, RAG-grounding checks, OWASP/NIST compliance gates, is RLVR of RL-achtig trainen strategisch aantrekkelijker dan pure SFT. Dit sluit direct aan op de controlled learn loop-architectuur die we eerder beschreven: niet trainen op ideale demonstraties, maar op gecontroleerde runtime states met harde validators.

OPD: de interessante middenvorm

On-Policy Distillation gebruikt student-generated data, maar de update komt van een teacher-distributie. De student leert dus niet alleen van een externe dataset, maar van advies op zijn eigen staten. Dat lijkt op RL omdat het on-policy is, maar lijkt op SFT omdat er een teacher-signaal is. De blog beschrijft OPD als reverse-KL-achtig: de student wordt richting de teacher-distributie getrokken op de states die de student zelf produceert.

De verrassende observatie: OPD-studenten konden vergelijkbaar of beter presteren dan hun teachers, zelfs wanneer de teacher via SFT was getraind en zelf meer forgetting vertoonde. In het experiment rond minimal code editing scoorde de OPD-student met SFT-teacher beter op Pass@1 dan de SFT-teacher én had hij minder degradatie op LiveCodeBench.

De implicatie is fundamenteel: de teacher is niet het enige dat telt. De state distribution van de student is mogelijk belangrijker. OPD laat het model leren op eigen fouten, eigen prefixes en eigen gedragspaden. Daardoor wordt het leersignaal relevanter dan klassieke distillatie op teacher-generated trajectories.

Waarom dit relevant is voor agentic AI

Voor agent-systemen is deze blog belangrijker dan hij op het eerste gezicht lijkt. Veel organisaties proberen agentgedrag te verbeteren met SFT op voorbeeldtrajecten: "zo moet een goede agent plannen, tools gebruiken, valideren en rapporteren." Dat is nuttig, maar fragiel. De agent ziet dan vooral ideale demonstraties, niet de rommelige states waarin hij zelf terechtkomt, exact het probleem dat de agentic AI security survey identificeerde als "distributional mismatch between training and deployment."

De OPD-lens suggereert een betere aanpak. Laat de agent eerst zelf taken uitvoeren in een gecontroleerde sandbox. Verzamel zijn eigen tussenstappen, fouten, tool-keuzes, hallucination states en recovery paths. Laat vervolgens een sterkere teacher, validator of policy-engine feedback geven op die eigen states. Train of tune daarna op die on-policy states.

Dat is wezenlijk anders dan "maak een dataset met perfecte voorbeelden". Het is meer vergelijkbaar met security testing: je hardent niet alleen tegen bekende CVE's, maar tegen het gedrag dat jouw systeem daadwerkelijk vertoont onder druk.

Belangrijkste technische inzicht

De blog draait om één load-bearing insight: on-policy data fungeert als impliciete regularisatie. SFT kan het model naar een ver weg liggende distributie trekken. RL en OPD blijven dichter bij de huidige policy, omdat de training plaatsvindt op states die het model zelf bezoekt. Daardoor bewegen ze naar een "nabije taakoplossende policy" in plaats van naar een willekeurige target-distributie.

Dit sluit aan bij recent onderzoek. Een paper uit mei 2026 stelt expliciet dat post-training beter begrepen kan worden als state-distribution shaping: SFT traint op fixed dataset states, terwijl RL en OPD trainen op states induced by the current learner. Dat paper rapporteert ook dat OPD van een gedegradeerde SFT-teacher beter kan scoren dan de teacher zelf op GSM8K, TruthfulQA en MMLU.

Daarnaast laat recenter werk over de geometrie van OPD zien dat OPD niet simpelweg "tussen SFT en RL" zit, maar een eigen updategeometrie heeft: minder brede parameterupdates dan SFT, minder strak geconstrained dan RLVR, en met snelle subspace locking in een lage-dimensionale updatebaan.

Kritische kanttekeningen

De blog is sterk als conceptuele synthese, maar je moet hem niet lezen als definitief bewijs.

Ten eerste is het experiment beperkt. Minimal code editing is relevant, maar smal. Het is een goede test voor generalisatie en forgetting, maar geen volledige benchmark voor reasoning, tool-use, safety, legal-domain behavior of enterprise compliance.

Ten tweede is OPD gevoelig voor teacher-bias. De blog benoemt dit zelf. Bij OPSD, On-Policy Self Distillation, kunnen stijl- of pivot tokens zoals "wait" of "alright" meer KL veroorzaken dan inhoudelijk belangrijke math tokens. Dat kan leiden tot verkeerde updateprioriteiten en zelfs collapse, tenzij je clipping of trust-region mechanismen gebruikt.

Ten derde blijft rewardkwaliteit cruciaal. RLVR werkt goed wanneer de reward klopt. Maar bij LLM-as-judge, voorkeursscores of subjectieve kwaliteit kom je snel in RLHF-problemen: proxy gaming, bias amplification, style over substance en overoptimalisatie op verkeerde signalen.

Ten vierde is OPD operationeel complexer dan SFT. Je hebt rollouts, teacher-inference, logprob access of black-box approximaties, clipping, evaluatieharnassen en regressietests nodig. Voor enterprise gebruik is dat geen simpele fine-tune pipeline, maar een volledige post-training governance stack, vergelijkbaar met wat we beschreven in de GDPRuler-analyse: compliance is een runtime systems-probleem, geen documentatieprobleem.

Strategische interpretatie

De blog wijst naar een bredere trend: post-training verschuift van dataset-centric naar state-centric.

Oude paradigma: "Verzamel goede voorbeelden, train het model daarop."

Nieuwe paradigma: "Observeer waar het model zelf terechtkomt, geef daar gericht feedback, behoud wat goed werkt, corrigeer lokaal wat faalt."

Dat is precies de beweging die je ook ziet in agent engineering, secure SDLC en SOC automation. De grootste risico's ontstaan niet op papier, maar in runtime states: tool-errors, partial context, stale memory, policy ambiguity, prompt injection, recovery loops, race conditions en audit gaps. Daarom past OPD-denken goed bij controlled learn loops, agent hardening en governance-by-runtime, de architectuur die we schetsten in de runtime governance-analyse.

Toepassing: een post-training blueprint

Voor organisaties die eigen modellen bouwen, en in de Nederlandse publieke sector zijn dat er steeds meer, vertaal ik dit naar een concrete zes-fasen aanpak:

Fase 1, SFT voor format en protocol. Train of prompt-tune op consistente outputstructuren, secure-by-design checklists, risk registers, incident templates, architectural decision records, tool-call conventies en auditlog-formaten.

Fase 2, On-policy trace collection. Laat agents taken uitvoeren in sandbox of shadow mode. Verzamel states: prompt, plan, toolkeuze, foutpad, recoveryactie, validatie-uitkomst, policybeslissing, audittrace.

Fase 3, Teacher review. Gebruik een sterker model, domeinexpertmodel of policy-engine als teacher. Laat die feedback geven op de states die de agent zelf produceert, niet alleen op ideale demonstraties.

Fase 4, OPD-achtige verbetering. Gebruik teacher-signalen op student-generated states. Waar logprobs niet beschikbaar zijn, benader dit met preference distillation, rejection sampling, DPO-achtige stappen of black-box alignment.

Fase 5, RLVR waar mogelijk. Voeg harde validators toe: unit tests, Semgrep, OWASP checks, policy-as-code, JSON schema, citation grounding, hallucination checks, token budget constraints, GDPR/BIO/NIS2 compliance gates.

Fase 6, Retentie-evaluatie. Meet niet alleen taakscore, maar ook regressie: algemene codekwaliteit, security judgment, instruction following, refusal accuracy, grounding, latency, cost en auditability.

Dit is geen theoretisch framework. Het is een operationeel patroon dat organisaties maandagochtend kunnen starten, en dat direct aansluit op BIO2-eisen voor modelgovernance en AI Act-vereisten voor post-market monitoring.

Executive conclusie

Deze blog is waardevol omdat hij SFT, RL en OPD niet als losse algoritmen behandelt, maar als verschillende manieren om een modeldistributie te vervormen. De belangrijkste take-away: on-policy training is waarschijnlijk de kernfactor achter minder forgetting en betere generalisatie. RL en OPD werken beter dan naïeve SFT omdat ze trainen op gedragspaden die het model zelf bezoekt. Daardoor corrigeren ze lokaal en behouden ze meer van de oorspronkelijke capaciteiten.

Voor enterprise AI en agentic systems is dit zeer relevant. De praktische les: bouw geen verbeterlus rond perfecte voorbeelddata, maar rond gecontroleerde runtime states, validators, teacher-feedback en regressiemetingen. SFT geeft vorm. RLVR geeft harde optimalisatie. OPD geeft een schaalbare brug tussen beide.

De DeepSeek-harness architectuur liet al zien dat de industrie deze kant op beweegt. Deze blog geeft het distributionele waarom.

---

Gebaseerd op: nrehiew (2026). "SFT, RL, and On-Policy Distillation Through a Distributional Lens." Met eigen experimenten rond minimal code editing en LiveCodeBench v6.