Autovern for AI

Guardrails og “LLM-as-a-Judge” høres ut som noe bare utviklere trenger å bry seg om. I praksis er det noen av de samme konseptene du bruker når du lærer opp en nyansatt, og de er ofte forskjellen på en AI-løsning du kan tørre å sette i produksjon, og en du må lese over hver gang.

Autovern er det som gjør autopilot mulig

Guardrails er et av de ordene som skaper mer avstand enn forståelse, men analogien er faktisk ganske presis.

Et autovern styrer ikke bilen, bestemmer ikke hvor du skal, og det kjører ikke for deg. Det gjør en ting: det hindrer deg fra å havne utenfor veien. Og det er nettopp derfor du tør å holde farten oppe. Guardrails i AI-sammenheng fungerer på samme måte. Vi lar ikke språkmodellen få fritt spillerom, men gir den noen gitte forutsetninger å jobbe innenfor, og det er de forutsetningene som gjør at vi tør å la den jobbe på egen hånd.

Poenget er verdt å dvele ved, for det er her mange bommer i forventningene sine. En språkmodell som får en åpen oppgave, vil løse den på uendelig mange måter. Det er fantastisk når du idémyldrer rundt en kampanje. Det er et problem når du skal produsere et tilbudsbrev, en avtale eller en kundekommunikasjon som må være riktig hver eneste gang.

Modellen skal velge, ikke dikte

I praksis er guardrails ofte langt mindre skummelt enn ordet antyder. Det handler gjerne bare om enkle ting som maler, tydelige retningslinjer eller en sjekkliste.

Tenk på et dokument med forhåndsskrevet tekst: ferdig formulerte paragrafer, ferdige avsnitt, informasjon som er kvalitetssikret av mennesker en gang for alle. Modellen får ikke i oppgave å generere teksten. Den får i oppgave å velge de riktige paragrafene og avsnittene, og fylle ut helt spesifikke felter.

Det er en fundamentalt annen jobb. Å skrive et avsnitt fra scratch er en åpen oppgave med tusen mulige utfall. Å velge mellom forhåndsgodkjente avsnitt og sette inn riktig data er en lukket oppgave med ett riktig svar. Jo mindre problemområde du gir modellen, jo færre feil får du.

For alle oss som jobber med kunnskapsarbeid er dette gjenkjennelig. Det er ikke veldig ulikt forskjellen mellom å be en fersk konsulent skrive fritt til en kunde, og å gi hen en mal med føringer for hva som kan endres og hva som ikke skal røres.

En modell som passer på modellen

Det andre grepet vi bruker er «LLM-as-a-Judge», altså en språkmodell satt til å kvalitetssikre en annen modell.

Første gang man hører det, klinger det litt bakvendt. Hvis vi ikke kan stole blindt på en språkmodell, hvorfor skulle vi stole på at nummer to fanger opp feilene? Svaret ligger i oppgaven de to får.

Modell nummer en gjør det vanskelige: velger innhold, tolker konteksten, fyller ut feltene. Modell nummer to skal ikke ta avgjørelsen på nytt. Den skal bare verifisere: har modell en holdt seg til malen? Er de forhåndsskrevne formuleringene urørt? Er det bare de feltene som skulle fylles ut, som er endret? Er svaret riktig, ja eller nei?

Det er en betydelig enklere jobb, og det er derfor den fungerer. Dommeren har et lite og godt definert problemområde, og trenger ikke være kreativ i det hele tatt.