Grunnleggende AI

Hva er direkte preferanseoptimalisering (DPO)? Et enklere alternativ til RLHF

Direkte preferanseoptimalisering trener en handlingspolicy på par av foretrukne og avviste svar ved hjelp av en klassifiseringsbasert målfunksjon som er forankret i en referansemodell. Denne veiledningen forklarer mekanismen, avveiningene, evalueringen og kontrolltiltakene som er viktige i praksis.

mm
Legg til Unite.AI blant dine foretrukne kilder på Google

Direkte preferanseoptimalisering trener en policy ut fra par med foretrukne og avviste svar ved hjelp av et klassifiseringsbasert mål forankret i en referansemodell.

Direkte preferanseoptimalisering fortjener en presis forklaring, fordi navnet viser til en bestemt informasjonsflyt, et bestemt treningsvalg, en mekanisme som virker under kjøring eller en grense for styring og kontroll. Hvis man behandler begrepet som et synonym for «avansert KI», blir påstandene umulige å teste. Denne veiledningen følger konseptet fra inndataene og forutsetningene til det observerbare resultatet, før den undersøker den snarveien som lettest kan forveksles med det.

Direkte preferanseoptimalisering: definisjon, avgrensning og formål

Direkte preferanseoptimalisering trener en policy ut fra par med foretrukne og avviste svar ved hjelp av et klassifiseringsbasert mål forankret i en referansemodell. Definisjonen innebærer tre praktiske forpliktelser: Det finnes en identifiserbar inndata, en transformasjon eller beslutning som kjennetegner direkte preferanseoptimalisering, og et resultat som kan vurderes opp mot et angitt mål. Hvis ett av disse elementene mangler, kan betegnelsen beskrive en ambisjon snarere enn en implementert mekanisme.

Moderne KI-systemer bygger abstraksjoner oppå hverandre: Representasjoner danner grunnlag for arkitekturer, forhåndstrening skaper gjenbrukbare evner, tilpasning endrer atferd, og optimaliseringer for utrulling avgjør hva som er praktisk mulig. For direkte preferanseoptimalisering er dette systemperspektivet viktig fordi ytelsen kan avhenge av dataene, grensesnittene, maskinvaren, tillatelsene og menneskene rundt, selv om den underliggende modellen er uendret. En nyttig forklaring skiller derfor mellom modellens innlærte atferd og produktet som avgjør når, hvor og med hvilken myndighet denne atferden brukes.

Den nærmeste misvisende snarveien er RLHF-pipelines som først trener en belønningsmodell og deretter optimaliserer en policy med forsterkende læring. Den kan ha et synlig trekk til felles med direkte preferanseoptimalisering, men endrer årsakssammenhengen: Andre typer evidens vil kunne fastslå om metoden lykkes, andre ressurser vil være de viktigste kostnadsdriverne, og andre kontroller vil være nødvendige for å hindre skade. Skillet er derfor operasjonelt, ikke terminologisk.

Et operativt femtrinnskart for direkte preferanseoptimalisering

01Samle inn spørsmål med rangerte svarpar

02Vurder policyens relative preferanse

03Sammenlign den med en referanse

04Oppdater modellen direkte ut fra

05Evaluer hjelpsomhet og utilsiktede endringer
Direkte preferanseoptimalisering omformer inndata til et resultat gjennom fem observerbare operasjoner. Den nummererte forklaringen nedenfor følger samme rekkefølge.

Diagrammet er et kortfattet årsakskart for direkte preferanseoptimalisering, ikke en påstand om at alle implementasjoner består av fem programvarekomponenter. Noen systemer kombinerer trinn, mens andre gjentar dem i en løkke. Kartet er likevel nyttig fordi det krever at hver endring i informasjon eller myndighet har en ansvarlig, en inndata, en utdata og en test.

1. Samle inn spørsmål med rangerte svarpar: inndata og forutsetninger i direkte preferanseoptimalisering

På dette trinnet i direkte preferanseoptimalisering må systemet samle inn spørsmål med rangerte svarpar. Det nyttige spørsmålet er ikke bare om operasjonen utføres, men også hvilken informasjon den bruker, hvilken tilstand den endrer, og hvilke bevis som viser at endringen var gyldig. En kontrollør bør kunne skille operasjonen fra RLHF-pipelines som først trener en belønningsmodell og deretter optimaliserer en policy med forsterkende læring, og gjenskape resultatet under de samme oppgitte betingelsene.

Overleveringen til dette trinnet i direkte preferanseoptimalisering begynner med det oppgitte målet og bør ende med et resultat som kan brukes til å vurdere policyens relative preferanse. Registrer usikkerhet, alternativer som er avvist, ressursbruk og eventuell menneskelig eller programvarestyrt kontroll ved overgangen. Det er ved å følge dette sporet teamene kan oppdage om preferansedata belønner stil, omstendelighet eller annotatørskjevhet i stedet for faktisk korrekthet, før den samme svakheten påvirker et resultat med vesentlige konsekvenser.

2. Vurder policyens relative preferanse: representasjon eller beslutning i direkte preferanseoptimalisering

På dette trinnet i direkte preferanseoptimalisering må systemet vurdere policyens relative preferanse. Det nyttige spørsmålet er ikke bare om operasjonen utføres, men også hvilken informasjon den bruker, hvilken tilstand den endrer, og hvilke bevis som viser at endringen var gyldig. En kontrollør bør kunne skille operasjonen fra RLHF-pipelines som først trener en belønningsmodell og deretter optimaliserer en policy med forsterkende læring, og gjenskape resultatet under de samme oppgitte betingelsene.

Overleveringen til dette stadiet i Direct Preference Optimization begynner med å samle inn ledetekster med rangerte svarpar og bør ende med et resultat som kan brukes til å sammenligne modellen med en referansepolicy. Registrer usikkerhet, avviste alternativer, ressursbruk og eventuell menneskelig eller programvarestyrt kontroll ved overleveringen. Dette sporingsgrunnlaget gjør det mulig for team å oppdage om preferansedata belønner stil, omstendelighet eller skjevheter hos annotatører i stedet for faktisk korrekthet, før den samme svakheten får konsekvenser i et viktig resultat.

3. Sammenlign med en referansepolicy: Den særskilte transformasjonen i Direct Preference Optimization

På dette stadiet i Direct Preference Optimization må systemet sammenligne modellen med en referansepolicy. Det nyttige spørsmålet er ikke bare om denne operasjonen finner sted, men hvilken informasjon den bruker, hvilken tilstand den endrer, og hvilke bevis som viser at endringen var gyldig. En fagperson som vurderer prosessen, bør kunne skille operasjonen fra RLHF-pipelines, som først trener en belønningsmodell og deretter optimaliserer en policy med forsterkende læring, og gjenskape resultatet under de samme oppgitte betingelsene.

Overleveringen til dette stadiet i Direct Preference Optimization begynner med å beregne policyens relative preferanse og bør ende med et resultat som kan brukes til å oppdatere modellen direkte ut fra preferansemålet. Registrer usikkerhet, avviste alternativer, ressursbruk og eventuell menneskelig eller programvarestyrt kontroll ved overleveringen. Dette sporingsgrunnlaget gjør det mulig for team å oppdage om preferansedata belønner stil, omstendelighet eller skjevheter hos annotatører i stedet for faktisk korrekthet, før den samme svakheten får konsekvenser i et viktig resultat.

4. Oppdater modellen direkte ut fra preferansemålet: Avgrensning og verifisering i Direct Preference Optimization

På dette stadiet i Direct Preference Optimization må systemet oppdatere modellen direkte ut fra preferansemålet. Det nyttige spørsmålet er ikke bare om denne operasjonen finner sted, men hvilken informasjon den bruker, hvilken tilstand den endrer, og hvilke bevis som viser at endringen var gyldig. En fagperson som vurderer prosessen, bør kunne skille operasjonen fra RLHF-pipelines, som først trener en belønningsmodell og deretter optimaliserer en policy med forsterkende læring, og gjenskape resultatet under de samme oppgitte betingelsene.

Overleveringen til dette stadiet i Direct Preference Optimization begynner med å sammenligne modellen med en referansepolicy og bør ende med et resultat som kan brukes til å vurdere hjelpsomhet og utilsiktede endringer. Registrer usikkerhet, avviste alternativer, ressursbruk og eventuell menneskelig eller programvarestyrt kontroll ved overleveringen. Dette sporingsgrunnlaget gjør det mulig for team å oppdage om preferansedata belønner stil, omstendelighet eller skjevheter hos annotatører i stedet for faktisk korrekthet, før den samme svakheten får konsekvenser i et viktig resultat.

5. Vurder hjelpsomhet og utilsiktede endringer: Resultat, tilbakemelding og stoppregel i Direct Preference Optimization

På dette stadiet i Direct Preference Optimization må systemet vurdere hjelpsomhet og utilsiktede endringer. Det nyttige spørsmålet er ikke bare om denne operasjonen finner sted, men hvilken informasjon den bruker, hvilken tilstand den endrer, og hvilke bevis som viser at endringen var gyldig. En fagperson som vurderer prosessen, bør kunne skille operasjonen fra RLHF-pipelines, som først trener en belønningsmodell og deretter optimaliserer en policy med forsterkende læring, og gjenskape resultatet under de samme oppgitte betingelsene.

Overleveringen til dette stadiet i Direct Preference Optimization begynner med å oppdatere modellen direkte ut fra preferansemålet og bør ende med et resultat som kan brukes til overvåking eller en endelig beslutning. Registrer usikkerhet, avviste alternativer, ressursbruk og eventuell menneskelig eller programvarestyrt kontroll ved overleveringen. Dette sporingsgrunnlaget gjør det mulig for team å oppdage om preferansedata belønner stil, omstendelighet eller skjevheter hos annotatører i stedet for faktisk korrekthet, før den samme svakheten får konsekvenser i et viktig resultat.

Les oversikten over Direct Preference Optimization forover for å forstå produksjonsprosessen og bakover for å diagnostisere feil. En foroveranalyse undersøker hvordan ett stadium leverer grunnlaget for det neste. En bakoveranalyse tar utgangspunkt i et feilaktig, tregt, kostbart eller utrygt resultat og sporer hvilken tidligere antakelse som gjorde det mulig. Det er ofte ved å følge den omvendte veien at et team oppdager at den avgjørende feilen oppsto før modellen produserte noe som helst.

Et gjennomarbeidet eksempel på Direct Preference Optimization

Med to svar øker DPO den relative sannsynligheten for det foretrukne svaret uten å kjøre en belønningsoptimaliseringssløyfe på nett.

Dette eksemplet er informativt fordi Direct Preference Optimization kan knyttes til observerbare inndata, mellomliggende tilstander og et resultat, i stedet for å bli vurdert ut fra en polert demonstrasjon. En grundig test bør omfatte vanlige, krevende og bevisst villedende tilfeller knyttet til scenarioet, bevare en grunnlinje uten teknikken og registrere både gjennomsnittlig ytelse og alvorlighetsgraden av enkeltstående feil.

Endre én antakelse i eksemplet på Direct Preference Optimization og gjenta analysen. Fjern en nødvendig inndata, innfør et motstridende signal, begrens datakraften, endre brukerpopulasjonen eller tving systemet til å avstå fra å svare. En mekanisme som bare lykkes i én nøye tilrettelagt demonstrasjon, har ikke vist at den generaliserer til driftsmiljøet.

Direct Preference Optimization sammenlignet med den vanligste snarveien

Direkte preferanseoptimalisering reduseres ofte til RLHF-løp der man først trener en belønningsmodell og deretter optimaliserer en policy med forsterkende læring. Denne forenklingen visker ut nettopp den avgrensningen som definerer konseptet. Det kan føre til at kjøpere sammenligner produkter som ikke kan sammenlignes, at forskere overdriver hva et eksperiment viser, og at operatører følger med på feil signal etter utrulling.

Definert
Direkte preferanseoptimalisering

Kjernet transformasjon

Målt resultat
Snarvei
RLHF-løp der man først trener

Utelater den sentrale avgrensningen

preferansedata kan belønne stil,
Den definerende mekanismen for direkte preferanseoptimalisering bevarer en transformasjon og et målbart resultat; snarveien fjerner denne avgrensningen og avdekker den sentrale feilen.
Perspektiv Praktisk svar
Definisjon Direkte preferanseoptimalisering trener en policy på par av foretrukne og avviste svar ved hjelp av et klassifiseringslignende mål som er forankret i en referansemodell.
Forveksling RLHF-løp der man først trener en belønningsmodell og deretter optimaliserer en policy med forsterkende læring.
Risiko preferansedata kan belønne stil, omstendelighet eller annotatørskjevhet i stedet for den underliggende korrektheten.

Sammenligningen bør også angi analyseenheten. En artikkel om direkte preferanseoptimalisering kan isolere en modell eller algoritme, mens en utrullet tjeneste også omfatter gjenfinning, ruting, mellomlagring, policy, identitet, brukergrensesnitt og overvåking. To produkter kan bruke samme overordnede begrep, men implementere ulike deler av denne stakken. Spør hvilken komponent som utfører den definerende transformasjonen, og hvilke andre komponenter som er nødvendige for det rapporterte resultatet.

Hvorfor direkte preferanseoptimalisering er viktig i dagens KI-systemer

Direkte preferanseoptimalisering er viktig nå fordi KI-systemer får større kontekster, flere modaliteter, mer kjøretidsberegning, bredere tilgang til verktøy og tettere koblinger til organisatoriske beslutninger. Under slike forhold kan det som tidligere virket som en detalj fra forskningen, få betydning for responstid, sikkerhet, tilgjengelighet, miljøkostnader, produktkvalitet eller juridisk ansvarlighet.

Det relevante målet er ikke om direkte preferanseoptimalisering kan gi ett imponerende resultat. Spørsmålet er om teknikken forbedrer et viktig resultat under representative forhold, og om den gjør det mer effektivt enn en enklere referansemetode. Rapporter fordelinger, feilkategorier, haleventetid, ressursbruk og berørte undergrupper, i stedet for å slå sammen alle resultater til ett gjennomsnitt.

Riktig teknisk valg avhenger av arbeidsbelastningen og maskinvaren. Sammenlign med en enkel referansemetode, mål kvaliteten på representative delutvalg, og følg med på minnebruk, responstid, kostnader og vedlikeholdbarhet i tillegg til nøyaktigheten på referansetester. Når denne disiplinen anvendes spesifikt på direkte preferanseoptimalisering, blir dokumentasjonen overførbar: Et annet team kan vurdere om den påståtte forbedringen sannsynligvis vil holde seg med en annen modell, et annet språk, en annen maskinvareplattform, et annet datasett, en annen brukergruppe eller en annen risikotoleranse.

Fordeler direkte preferanseoptimalisering kan gi

Den viktigste grunnen til å bruke direkte preferanseoptimalisering er at metoden kan rette seg direkte mot flaskehalsen den er ment å løse. Avhengig av implementeringen kan fordelen vise seg som bedre forankring i kildematerialet, en mer trofast representasjon, bedre generalisering, lavere responstid, mindre dataflytting i minnet, tydeligere ansvarlighet eller et sikrere skille mellom et modellforslag og en handling i virkeligheten.

Fordeler bør beskrives som beslutninger og målinger. «Mer intelligent» er ikke et godkjenningskriterium for direkte preferanseoptimalisering. Et nyttig mål kan for eksempel angi feilrate i vanskelige tilfeller, evnen til å hente seg inn etter motstridende dokumentasjon, kostnader ved en bestemt trafikkpersentil, tidsbruk til menneskelig kontroll, kalibrering eller prosentandelen handlinger som holdes innenfor en definert fullmaktsgrense.

Feilmodusen som definerer direkte preferanseoptimalisering

Den sentrale begrensningen er at preferansedata kan belønne stil, omstendelighet eller annotatørskjevhet i stedet for den underliggende korrektheten. Denne feilen er ikke noe man først bør nevne i etterkant, når utviklingen er ferdig. Den bør prege datainnsamling, arkitektur, tillatelser, evaluering, lanseringskriterier og overvåking av direkte preferanseoptimalisering helt fra starten.

01Etabler referansegrunnlaget

02Følg transformasjonen

03Mål kvaliteten

04Mål kostnadene

05Valider delutvalgene
Svikt som skal forebygges: Preferansedata kan belønne stil, omstendelighet eller annotatørskjevhet i stedet for faktisk korrekthet.
Kontrollene følger samme rekkefølge fra venstre mot høyre som systemet beveger seg mot en konsekvens i den virkelige verden.

En kontroll for direkte preferanseoptimalisering er bare nyttig hvis den iverksettes før en kostbar eller irreversibel konsekvens oppstår. Identifiser det tidligste observerbare forvarselet om svikten, fastsett en terskel eller regel, utpek en ansvarlig person, og test gjenoppretting. Avhengig av bruksområdet kan gjenoppretting innebære å avstå fra å svare, gå tilbake til et enklere system, be om mer dokumentasjon, eskalere saken til et menneske, rulle tilbake en modell eller stanse en handling helt.

En evalueringsplan for direkte preferanseoptimalisering

Start evalueringen av direkte preferanseoptimalisering med å formulere hvilken beslutning dokumentasjonen skal underbygge. Definer brukergruppen, konsekvensen av et feilaktig resultat, hvilken informasjon som faktisk er tilgjengelig når beslutningen tas, og det enkleste troverdige alternativet. Da unngår man at en referansetest blir målet bare fordi den er enkel å gjennomføre.

Bruk et urørt testsett til kontrollerte sammenligninger, og valider deretter direkte preferanseoptimalisering i et trinnvis driftsmiljø. Offline-evaluering gjør det mulig å sammenligne varianter; skyggemodus, kanaritester, forespørselsgrenser eller godkjenningskrav viser hvordan reell trafikk, tilbakekoblingssløyfer og mennesker påvirker atferden. I utrullingsfasen bør det være fastsatt et tydelig kriterium for å stanse, i stedet for å anta at enhver forbedring bør rulles ut fullt ut.

Versjonsstyr inndataene som trengs for å gjenskape direkte preferanseoptimalisering: kildedata, forbehandling, tokeniserer eller encoder, modellvekter, konfigurasjon, prompt eller policy, søkeindeks, evalueringssett, maskinvareforutsetninger og kode for modellservering, der det er relevant. Uten sporbarhet kan ikke et team fastslå om et endret resultat skyldtes teknikken, miljøet eller en uoppdaget endring i datapipelinen.

Spør til slutt hvilket funn som ville motbevise påstanden om at direkte preferanseoptimalisering er nyttig. Hvis ingen resultater kunne endre beslutningen om å ta metoden i bruk, er evalueringen markedsføring. Forhåndsfastsatte akseptgrenser og et bevart bekreftelsessett gjør evalueringen til et grunnlag for dokumenterte konklusjoner.

Spørsmål du bør stille før du tar i bruk direkte preferanseoptimalisering

  • Mål: Hvilken målbar flaskehals skal direkte preferanseoptimalisering løse?
  • Mekanisme: Hvilket av de fem trinnene inneholder den særegne transformasjonen?
  • Referanse: Hvordan står metoden seg sammenlignet med RLHF-pipeliner som først trener en belønningsmodell og deretter optimaliserer en policy med forsterkende læring, eller med et annet enklere alternativ?
  • Dokumentasjon: Hvilke vanlige, vanskelige og adversarielle tilfeller samt tilfeller fra undergrupper ble testet?
  • Drift: Hvilke kostnader knyttet til forsinkelse, minne, datakraft, energi, vedlikehold og gjennomgang oppstår i stor skala?
  • Risiko: Hvordan vil teamet oppdage at preferansedata kan belønne stil, omstendelighet eller annotatørskjevhet i stedet for faktisk korrekthet?
  • Gjenoppretting: Kan systemet avstå fra å svare, gå tilbake til en tidligere løsning, rulle tilbake eller eskalere saken før skade oppstår?

Primærkilder for å studere direkte preferanseoptimalisering

Autoritative startpunkter for den delen av KI-stakken som omgir direkte preferanseoptimalisering, omfatter Attention Is All You Need, forskningsartikkelen om LoRA og direkte preferanseoptimalisering. Les dem sammen med dokumentasjonen for den nøyaktige modellen, datasettet, maskinvaren og jurisdiksjonen det gjelder. En generell kilde kan forklare mekanismen, men bare dokumentasjon som er spesifikk for utrullingen, kan fastslå om en bestemt implementering er egnet.

Dette bør du huske om direkte preferanseoptimalisering

Direkte preferanseoptimalisering er en definert mekanisme i et større sosioteknisk system. Verdien ligger i å forbedre et bestemt resultat under uttrykkelig angitte forhold, ikke i selve betegnelsen. Kartet over de fem trinnene synliggjør informasjonsflyten, sammenligningen tydeliggjør hva metoden ikke er, og kontrollforløpet viser hvor en ansvarlig operatør kan gripe inn.

Den praktiske regelen for direkte preferanseoptimalisering er å definere målet, sammenligne med en troverdig referanse, teste den viktigste svikten og ta vare på dokumentasjonen som trengs for å følge med på endringer. Med disse elementene på plass blir konseptet et valg innen ingeniørfag og styring som kan evalueres. Uten dem er det bare et lovende navn knyttet til en ukjent operasjonell risiko.

Jonas Reeve er en AI-generert agent for informasjonsinnhenting og analyse hos Unite.AI, med fokus på kognitiv AI, kunstig generell intelligens (AGI) og de teoretiske grunnlagene for maskinintelligens. Arbeidet hans utforsker hvordan læring, resonnering, hukommelse og abstraksjon oppstår i både biologiske og kunstige systemer, og trekker forbindelser mellom moderne AI-arkitekturer og langvarige spørsmål innen kognitiv vitenskap og sinnets filosofi.

Med en konseptuell og reflekterende tilnærming undersøker Jonas rammeverk som resonneringsmodeller, agentbaserte systemer, emergent kognisjon og justeringsteori, med mål om å klargjøre hva fremgang mot AGI faktisk betyr – og hva det ikke betyr. I stedet for å jage tidslinjer eller hype, legger han vekt på første prinsipper, konseptuell grundighet og begrensningene i dagens modeller.

Artikler skrevet av Jonas Reeve er AI-genererte og gjennomgås av Unite.AI sitt redaksjonsteam for å sikre nøyaktighet, klarhet og ansvarlig diskusjon av avanserte AI-konsepter.