Hvad er DPO (Direct Preference Optimization)?

DPO (Direct Preference Optimization) er en metode til at finjustere sprogmodeller ud fra præferencepar, hvor én modelrespons foretrækkes frem for en anden. Metoden bruges efter grundtræning og gør det muligt at lære præferencer direkte uden et separat belønningsmodeltrin og uden klassisk reinforcement learning i selve optimeringen.

Hvad betyder DPO i korte træk?

DPO betyder Direct Preference Optimization. Metoden bruges især i post-træning af store sprogmodeller, hvor målet er at gøre modellen bedre til at vælge den type svar, som mennesker eller et defineret evalueringssystem foretrækker. I stedet for kun at vise modellen et godt facitsvar arbejder DPO med sammenligninger: et input, et foretrukket svar og et fravalgt svar.

Den praktiske ide er enkel: modellen skal øge den relative sandsynlighed for det foretrukne svar og mindske sandsynligheden for det fravalgte svar. Det sker i forhold til en referencemodel, så den finjusterede model ikke uden kontrol bevæger sig for langt væk fra sit udgangspunkt. Derfor omtales DPO ofte som en direkte metode til præferenceoptimering.

DPO er ikke en selvstændig sprogmodel, en brugerfunktion eller en sikkerhedsgaranti. Det er en træningsmetode. Den er relevant, når du arbejder med modeludvikling, finjustering, evaluering af svaradfærd eller vurdering af, hvordan en model kan tilpasses bestemte kvalitetskriterier efter den almindelige træning.

Hvor passer DPO ind i træning af sprogmodeller?

DPO hører hjemme efter den store grundtræning, hvor en sprogmodel lærer generelle mønstre i tekst. I mange moderne træningsforløb kommer der derefter en fase med instruktionstilpasning eller finjustering af sprogmodeller. Her lærer modellen at besvare opgaver på en mere brugbar måde.

Præferenceoptimering kommer typisk senere i forløbet. Når modellen allerede kan give brugbare svar, kan udviklere indsamle flere mulige svar på samme opgave og lade mennesker, eksperter eller et kontrolleret evalueringssystem markere, hvilket svar der er bedst efter en bestemt rubrik. DPO bruger disse valg som træningssignal.

Det betyder, at DPO ikke erstatter hele modeltræningen. Metoden kan heller ikke kompensere for alle mangler i en svag grundmodel eller i et dårligt datagrundlag. Den bruges til at justere en model, der allerede kan producere svar, så dens svarfordeling flyttes i retning af foretrukne mønstre.

Hvordan adskiller DPO sig fra RLHF?

RLHF står for reinforcement learning from human feedback. I klassiske RLHF-forløb indsamles præferencer mellem modelsvar, hvorefter der trænes en belønningsmodel. Den model forsøger at forudsige, hvilke svar mennesker vil foretrække. Derefter bruges en reinforcement learning-metode, ofte PPO i ældre beskrivelser, til at optimere sprogmodellen mod den lærte belønning.

DPO angriber samme overordnede problem fra en mere direkte vinkel. I stedet for først at træne en særskilt belønningsmodel og derefter optimere modellen gennem en separat reinforcement learning-løkke, omskriver DPO præferenceproblemet, så sprogmodellen selv kan opdateres direkte ud fra præferenceparrene.

Forskellen kan opsummeres sådan:

Forholdet mellem DPO og reinforcement learning er derfor lidt paradoksalt: DPO er afledt af den samme type præferenceproblem, men undgår den klassiske reinforcement learning-optimering i selve træningsløkken.

Hvilke data kræver DPO?

DPO kræver præferencedata. Et typisk datapunkt består af en opgavebeskrivelse, et foretrukket svar og et fravalgt svar. Det foretrukne svar kaldes ofte chosen i tekniske værktøjer, mens det fravalgte svar kaldes rejected. Begge svar skal høre til samme opgave, ellers lærer modellen af en uklar sammenligning.

Kvaliteten af disse par er afgørende. Hvis det foretrukne svar kun er lidt bedre, hvis vurderingskriteriet skifter mellem eksempler, eller hvis fravalgte svar er kunstigt dårlige, kan modellen lære et skævt signal. DPO er følsom over for, hvad datamærkningen faktisk belønner.

Tre datapunkter bør kontrolleres før træning:

• Om hvert svarpar vurderes efter samme kriterier, for eksempel hjælpsomhed, korrekthed, korthed, sikkerhed eller domænefaglig præcision.
• Om de fravalgte svar er realistiske alternativer og ikke kun lette negative eksempler.
• Om datakilden er passende for den modeladfærd, du vil ændre, så træningen ikke optimerer mod et andet formål end det ønskede.

Præferencer kan komme fra mennesker, eksperter, brugertests eller kontrollerede AI-baserede evalueringsprocesser. Når de kommer fra AI-systemer, bliver datadokumentationen særlig væsentlig, fordi modellen ellers kan lære en anden models blinde vinkler eller stilpræferencer uden tydelig menneskelig kontrol.

Hvad sker der teknisk under DPO-træning?

Teknisk sammenligner DPO sandsynlighederne for det foretrukne og det fravalgte svar. Modellen justeres, så det foretrukne svar bliver mere sandsynligt relativt til det fravalgte. Samtidig sammenlignes den opdaterede model med en referencemodel, som normalt er modellen før DPO-træningen.

Det centrale er ikke, at modellen lærer en absolut karakter for hvert svar. Den lærer en forskel mellem to svar på samme input. Hvis det foretrukne svar allerede er meget mere sandsynligt end det fravalgte, er træningssignalet anderledes, end hvis modellen før træning foretrak det forkerte svar.

DPO-paperet viser, at denne direkte optimering kan forstås som en omskrivning af et klassisk RLHF-mål under en præferencemodel. I praksis betyder det, at udvikleren kan træne på præferencepar med en lossfunktion, som minder mere om superviseret optimering end om et fuldt reinforcement learning-system.

Den tekniske gevinst er ikke, at alle problemer forsvinder. Gevinsten er, at træningsforløbet bliver kortere og mere direkte: færre modeller skal trænes separat, færre mellemtrin skal kalibreres, og der er mindre behov for at sample nye svar i en løbende belønningsløkke under selve finjusteringen.

Hvad betyder referencemodel og beta?

Referencemodellen er det udgangspunkt, den DPO-trænede model holdes op imod. Den kan for eksempel være en superviseret finjusteret model før præferenceoptimeringen. Rollen er at give et anker, så modellen ikke blot presser sandsynlighederne voldsomt i retning af præferencedataene.

Beta er en styringsparameter i DPO-lossen. Den påvirker, hvor stærkt præferencesignalet vægtes i forhold til afstanden fra referencemodellen. En forkert valgt beta kan give en model, der enten ændrer sig for lidt eller bliver for aggressivt optimeret mod præferenceparrene.

En praktisk måde at forstå det på er, at referencemodellen beskytter mod ukontrolleret afdrift, mens beta bestemmer hvor hårdt modellen skubbes. Begge dele gør DPO til mere end en simpel regel om at øge sandsynligheden for valgte svar. Metoden forsøger at balancere præferenceindlæring med bevaring af modelens oprindelige sproglige evner.

Hvornår giver DPO praktisk mening?

DPO giver mest mening, når du allerede har en model, der kan løse opgaven rimeligt, men hvor svarstilen, prioriteringen eller kvaliteten skal justeres. Det kan være i domæner, hvor der findes tydelige kvalitetskriterier, men hvor det er dyrt eller svært at skrive perfekte facitsvar til alle tænkelige tilfælde.

Metoden er især relevant, når vurdering er lettere end produktion. En ekspert kan ofte hurtigere vælge det bedste af to svar end selv at skrive et fuldt ideelt svar fra bunden. Det er en af grundene til, at præferencebaserede metoder bruges i alignment og post-træning af store sprogmodeller.

DPO kan også være relevant i mindre, afgrænsede modelprojekter, hvor udviklere arbejder med åbne modeller og værktøjer som TRL. Her kan DPOTrainer og tilsvarende biblioteker gøre metoden praktisk tilgængelig, men den kræver stadig GPU-ressourcer, modeladgang, datasæt og evalueringsarbejde. Det er ikke en indstilling, man blot slår til i en færdig chatbot.

Hvilke begrænsninger har DPO?

DPO er enklere end mange RLHF-forløb, men metoden har klare begrænsninger. Den lærer kun af de præferencer, den får. Hvis præferenceparrene belønner lange, selvsikre eller overfladisk pæne svar frem for korrekte svar, kan modellen bevæge sig i den retning. Et præferencesignal er ikke automatisk det samme som sandhed eller faglig kvalitet.

Derudover kan DPO overtilpasse sig datasættet. Hvis træningen fortsætter for længe, eller hvis datasættet er smalt, kan modellen miste variation, blive for ensartet i svarformen eller nedprioritere nyttige alternativer. Nyere forskning i robuste DPO-varianter udspringer netop af behovet for at håndtere støj, usikre præferencer og overtilpasning.

DPO bør derfor vurderes som et præcist værktøj til en bestemt træningsopgave, ikke som en generel løsning på alignment. Hvis modellen skal bruges i faglige, sikkerhedsmæssige eller beslutningsstøttende sammenhænge, kræver det stadig separate tests for faktuel korrekthed, sikkerhed, bias, databeskyttelse og misbrug.

Hvordan hænger DPO sammen med sikkerhed og hallucinationer?

DPO kan bruges til at gøre bestemte svarmønstre mere sandsynlige, men metoden fjerner ikke i sig selv AI-hallucinationer. Hvis præferencedataene belønner svar, der lyder overbevisende uden at være kontrollerede, kan træningen endda forstærke en uønsket tendens.

For sikkerhed handler DPO derfor om, hvilke præferencer der formuleres og testes. Hvis et datasæt systematisk foretrækker svar, der afviser farlige instruktioner, forklarer usikkerhed eller beder om nødvendige oplysninger, kan metoden hjælpe med at skubbe modellen i den retning. Hvis datasættet er uklart, bliver sikkerhedssignalet uklart.

I organisationer bør DPO ses sammen med AI-governance. Det indebærer dokumentation af datakilder, evalueringsrubrikker, modelversioner, testresultater og kendte begrænsninger. Selve træningsmetoden kan ikke erstatte ansvarlige processer omkring modellen.

Hvordan vurderer du om en DPO-træning er lykkedes?

En DPO-træning er ikke lykkedes alene, fordi loss-kurven falder. Den bør vurderes på uafhængige tests, der afspejler den adfærd, modellen faktisk skal have. Hvis træningen for eksempel sigter mod mere præcise tekniske svar, bør evalueringssættet indeholde tekniske opgaver, tydelige fejltilfælde og sammenligninger med modellen før DPO.

Et solidt evalueringsdesign skelner mellem flere kvaliteter. Hjælpsomhed, korrekthed, sikkerhed, korthed og evnen til at udtrykke usikkerhed kan trække i forskellige retninger. En model kan blive bedre på én dimension og dårligere på en anden. Derfor er enkeltstående vinderprocenter sjældent nok.

En praktisk evaluering bør mindst omfatte:

• Blind parvis sammenligning mellem basisversionen og den DPO-trænede version.
• Faktatjek på eksempler, hvor modellen tidligere kunne give forkerte eller for sikre svar.
• Test af afvisninger, grænsetilfælde og brugssituationer uden for træningsdatasættet.
• Kontrol af om svarene er blevet unødigt lange, ensformige eller mindre nyttige.

Hvis modellen kun forbedres på samme datasætstype, som den er trænet på, er resultatet svagt. Hvis den derimod forbedrer relevante kvalitetsmål på holdout-data og samtidig bevarer generel evne, er der stærkere grundlag for at betragte træningen som vellykket.

Hvad bør en organisation kontrollere før brug af DPO?

Før DPO bruges i en organisation, bør formålet være klart. Det er ikke nok at skrive, at modellen skal være bedre. Der skal være en konkret præference: mere præcis, mere forsigtig, bedre til at følge en bestemt svarstruktur, bedre til at afvise bestemte opgaver eller bedre til at skelne mellem sikre og usikre udsagn.

Dernæst skal datagrundlaget kunne forklares. Hvem har valgt de foretrukne svar? Hvilke kriterier blev brugt? Hvor kommer de fravalgte svar fra? Er der persondata, ophavsretligt materiale eller følsomt indhold i træningsdataene? Den type spørgsmål hører til den praktiske risikovurdering, før modellen trænes eller tages i brug.

Til sidst bør du kontrollere, om DPO overhovedet er den rigtige metode. Nogle problemer løses bedre med bedre retrieval, bedre evaluering, almindelig finjustering, datarensning eller systemdesign. DPO er mest relevant, når forskellen mellem gode og dårlige svar faktisk kan udtrykkes som pålidelige præferencepar.

Hvordan kan DPO forklares uden matematik?

En enkel forklaring er, at DPO lærer modellen at foretrække det svar, mennesker eller et evalueringssystem har valgt, uden først at bygge en separat dommermodel. Den ser to svar på samme opgave og justerer sig selv, så det valgte svar bliver mere sandsynligt næste gang.

Det svarer ikke til at give modellen en facitliste. Det svarer mere til at vise den gentagne valg mellem bedre og dårligere svar. Over mange eksempler lærer modellen, hvilke mønstre der typisk kendetegner de foretrukne svar. Det kan være faglig præcision, mere passende tone, færre løse antagelser eller bedre håndtering af usikkerhed.

Den dokumenterbare unikke vinkel ved DPO er, at metoden bevarer forbindelsen til RLHF-målet, men flytter optimeringen ind i en direkte præferenceloss. Derfor blev DPO hurtigt vigtig i open source-miljøer og forskningsarbejde: den gør en central del af alignment-arbejdet enklere at eksperimentere med, uden at påstå at alignment dermed er løst.

Hvordan hænger DPO sammen med modelstørrelse og praktiske ressourcer?

DPO bruges ofte om store sprogmodeller, men metoden er ikke defineret af et bestemt antal parametre. En større model kan have flere sproglige evner at bevare eller justere, men den kræver også mere beregning, mere hukommelse og mere omhyggelig evaluering. Derfor hænger DPO tæt sammen med den praktiske modeløkonomi bag træningen.

Hvis du arbejder med parameterstørrelser i sprogmodeller, er pointen, at DPO ikke gør en stor model billig at træne fra bunden. Den kan gøre en post-træningsfase enklere end et fuldt RLHF-setup, men den kræver stadig adgang til modelvægte, træningskode, accelereret hardware og målinger af kvalitet efter træningen.

I praksis vælger mange teams derfor en afgrænset træningsopgave, en realistisk modelstørrelse og et smalt evalueringssæt først. Det giver bedre kontrol med, om præferenceoptimeringen faktisk ændrer den ønskede adfærd, før metoden bruges på større datasæt eller dyrere modelversioner.

Hvilke kilder ligger til grund?

Denne forklaring bygger især på DPO-paperet fra Rafailov m.fl., Hugging Face TRL-dokumentationen om DPOTrainer, NeurIPS-paperet om InstructGPT og RLHF samt Anthropic-paperet om Constitutional AI og AI-feedback.