Hva er en språkmodell (LLM), og hvordan lager den svar?

Hvor kommer svaret fra?

Tenk deg at en medarbeider spør: «Kan jeg bestille hotell før tjenestereisen er godkjent?» En chatbot svarer raskt, på godt norsk og med en forklaring som høres rimelig ut. Men hvor kom svaret fra? Har den lest bedriftens reiseregler, eller finner den på basert på det den kan fra før?

Medarbeideren forventer riktig svar. Assistenten må derfor bruke bedriftens egne regler og vise hvor svaret kommer fra.

Mønstre i språk

LLM står for large language model, eller stor språkmodell. Modellen trenes på store mengder tekst og lærer mønstre i hvordan ord og begreper brukes sammen. Det gjør den i stand til å forklare, oversette og oppsummere tekst.

Teksten deles opp i tokens: små enheter som kan være ord, deler av ord eller tegn. Når modellen lager et svar, beregner den mulige fortsettelser ut fra det den har fått som kontekst, og bygger svaret videre token for token. Konteksten kan inneholde spørsmålet, instrukser, samtalehistorikk og dokumentutdrag.

Svaret blir altså til mens modellen skriver. Den kan formulere seg godt også når den mangler informasjon eller trekker feil konklusjon.

Tilgang til bedriftens dokumenter

Når jeg avklarer en slik løsning med en kunde, skiller jeg mellom tre ting: det modellen har lært under trening, det brukeren skriver, og det applikasjonen henter fra bedriftens egne kilder. Det er sistnevnte vi må designe på en gjennomtenkt måte dersom assistenten skal bruke gjeldende reiseregler.

At du kan chatte med en modell, betyr ikke at den automatisk ser bedriftens dokumenter eller søker på nettet. Applikasjonen bestemmer hvilke opplysninger og verktøy som er tilgjengelige.

Medarbeideren bør kunne åpne reisereglene fra svaret og kunne se avsnittet assistenten har brukt. Dokumentets dato og versjon bør også være tilgjengelig, så det går an å kontrollere at regelen fortsatt gjelder.

RAG: søk i kildene før svaret skrives

RAG er forkortelsen for retrieval-augmented generation. Prinsippet er at løsningen først søker etter relevant materiale og deretter gir funnene til modellen som grunnlag for svaret. Bedriftens dokumenter trenger dermed ikke læres inn i modellen for hver oppdatering.

For hotellspørsmålet kan søket hente avsnittene om forhåndsgodkjenning og bestilling, uten å inkludere andre dokumenter der søkescoren er dårligere. Modellen får utdragene sammen med spørsmålet og kan forklare regelen med en lenke til dokumentet.

Det kan også være fornuftig å diskutere hvem som skal få se hvilke dokumenter, hvordan gamle versjoner håndteres, og hvem som holder kildene oppdatert. En god formulering hjelper lite dersom dokumentet bak den er utdatert.

Når modellen finner på et svar

En hallusinasjon er et svar som presenterer feil eller oppdiktet innhold som om det var riktig. Modellen kan for eksempel finne på en godkjenningsfrist som ikke står i reglene. Dette kan skje både med og uten internettilgang.

Selv med riktige dokumenter foran seg kan modellen misforstå et unntak eller blande to regler. Den kan også lenke til et dokument som ikke støtter konklusjonen. Vi må derfor teste om svarene faktisk følger kildene.

Tilpassede regler kan redusere hallusinasjoner drastisk, men god testing kreves alltid for å sikre at vi har bygget et robust system som kun svarer ut fra kildedokumentene.

Når kildene ikke strekker til

Vi kan sette en terskel som filtrerer bort svake søketreff. Men relevansscoren sier hvor godt treffet passer til søkefrasen. Det betyr ikke nødvendigvis at svaret alltid er sant for spørsmålet som stilles.

Terskelen må derfor prøves ut på bedriftens egne spørsmål. Settes den for lavt, slipper vi gjennom irrelevant materiale. Settes den for høyt, kan assistenten avvise spørsmål den kunne ha hjulpet med. Vi må også undersøke om materialet faktisk besvarer spørsmålet, og om kildene er gyldige og tilgjengelige for brukeren.

Når søket ikke gir gode nok treff, kan programvaren stoppe og gi en fast beskjed om at den mangler grunnlag. Brukeren kan bli bedt om å presisere spørsmålet eller kontakte en medarbeider.

Hva betaler dere for?

I en skreddersydd løsning er utviklingsarbeidet én kostnad, og løpende bruk av modell, søk, lagring og drift en annen. Mer dokumenttekst og lengre svar kan gi mer modellbruk. Derfor bør vi teste kostnaden med oppgaver som ligner deres hverdag, og avtale grenser og oppfølging.

I EPMs kundeprosjekter ligger leverandørtjenestene på kundens egne kontoer. Dere betaler leverandøren direkte, uten påslag fra EPM. Utvikling og avtalt oppfølging prises separat. Før vi velger teknologi, går vi gjennom forventet bruk og hva det vil koste å holde løsningen i drift.