Hva er RAG for bedriftsdokumenter – hva kan det gjøre?

RAG kan finne utdrag i bedriftens dokumenter og lage svar knyttet til kilder, men det er verken modelltrening, en sannhetsmaskin eller en erstatning for tilgangskontroll.

Mandag morgen spør personalsjefen den interne assistenten hvor lenge data om jobbsøkere skal lagres, og får et overbevisende svar med lenke til bedriftens retningslinjer; det eneste problemet er at versjonen systemet fant, sluttet å gjelde for åtte måneder siden; hva er RAG i en slik situasjon? En slik RAG-løsning for bedriftsdokumenter kan teknisk sett ha gjort alt den ble bedt om: funnet et semantisk lignende utdrag, lagt det inn i modellens kontekst og skrevet et velformulert svar. Den har likevel ikke kontrollert om filen er den nyeste godkjente versjonen dersom versjonsstatusen ikke er pålitelig angitt i indeksen.

Forkortelsen RAG står for retrieval-augmented generation, det vil si generering der eksternt innhold som er hentet inn, legges til når svaret skal lages. Det betyr ikke at bedriftens dokumenter læres inn i modellvektene, og det er heller ikke et eget «intelligenslag» som automatisk vet hvilket dokument som er sant. Det ligner snarere et bibliotek med en svært rask bibliotekar og en dyktig redaktør: Bibliotekaren kan hente feil bind, men redaktøren skriver likevel et overbevisende avsnitt; den opprinnelige RAG-studien skiller uttrykkelig mellom modellens parametriske minne og en ekstern, ikke-parametrisk kilde som hentes inn.

Den praktiske gevinsten er betydelig når grensene beskrives ærlig: Systemet kan finne relevante utdrag i en forvaltet dokumentsamling, sette dem sammen til en kontekst som passer spørsmålet, og lage et utkast med en kildehenvisning som kan kontrolleres. Ansvarsgrensen må også være synlig for brukeren; grensesnittet må ikke gi inntrykk av at en kilde i seg selv er en juridisk godkjenning, og det må være like enkelt å melde fra om feil og uklarheter som å stille et spørsmål. Løsningen kan ikke reparere dokumentasjon av dårlig kvalitet, garantere faktisk riktighet, innføre tilgangsrettigheter på egen hånd eller erstatte en deterministisk arbeidsflyt og menneskelig godkjenning når en feil innebærer juridisk, økonomisk eller sikkerhetsmessig risiko eller risiko for menneskerettighetene. Denne grensen bestemmer både arkitekturen og hva det er meningsfullt å måle i piloten.

Hvorfor en gammel retningslinje kan bli hentet som gjeldende

Hendelsen med den gamle retningslinjen begynner ikke i språkmodellen, men i dokumentforvaltningen: På den delte disken ligger «Persondata_final.docx», «Persondata_final2.docx» og en godkjent PDF, men ingen av filene har en ensartet ikrafttredelsesdato, status eller identifikator for versjonen den erstatter; indeksen ser tre innholdsmessig like kandidater, og det semantiske søket kan rangere det gamle dokumentet høyt fordi formuleringen samsvarer mer presist med spørsmålet. Modellen ser ikke beslutningen fra møtet i organisasjonen dersom den ikke finnes i dataene, og filnavnet «final» er ingen forvaltningsmekanisme.

Konsekvensene er lumske fordi svaret kan se bedre ut enn et vanlig søkeresultat: Det er kort, grammatisk riktig, viser til et ekte dokument og skaper derfor en følelse av at kontrollen allerede er gjort. Kildelenken beviser bare at en bestemt fil er vist eller knyttet til svaret; den beviser ennå ikke at hvert utsagn følger av det siterte utdraget, at utdraget ikke er tatt ut av et avsnitt om unntak, eller at dokumentet har rett til å være autoritativt. NISTs GenAI-profil regner ikke et slikt tillitvekkende uttrykk som tilstrekkelig risikokontroll og understreker styring gjennom hele systemets livssyklus.

Løsningen er publiseringsstatus, versjonskjede og prioriteringsregler, ikke en lengre prompt: I indeksen trenger hvert dokument en eier, start- og sluttdato for gyldighet, status, dokumentet det erstatter, avdeling, konfidensialitetsklasse og frist for gjennomgang; hentefilteret bør som standard utelate utkast og utgåtte versjoner. Hvis kildene står i konflikt, må systemet vise konflikten og avstå fra å late som det finnes ett sikkert svar, mens den ansvarlige eieren må få i oppgave å rydde i dokumentsamlingen. RAG kan synliggjøre kaoset, men kan ikke gjøre kaos om til retningslinjer.

I en slik situasjon må svargrensesnittet vise mer enn dokumentnavnet: Det bør også vise versjon, gyldighetsstatus, utdrag og en advarsel om konflikten. Loggen må bevare hvilke kandidater som ble funnet, og hvorfor én ble valgt, slik at feilen kan gjenskapes etter at indeksen er endret. Hvis systemet senere begynner å gi et annet svar, må teamet kunne avgjøre om det var dokumentet, oppdelingen i utdrag, søkekonfigurasjonen eller modellen som endret seg; uten slik sporbarhet blir en kvalitetshendelse til gjetning om «KI-atferd» i stedet for en systemfeil som kan rettes.

Hva er RAG, og hvordan fungerer det med bedriftsdokumenter?

En RAG-pipeline begynner med datainnhenting, ikke med et chattevindu: Filer hentes fra bestemte lagringssteder, og tekst, tabeller og tilgjengelig struktur trekkes ut, mens skannede dokumenter krever optisk tegngjenkjenning, OCR. Deretter deles innholdet i meningsfulle utdrag, og for hvert av dem beholdes en lenke til dokumentet, siden, avsnittet og metadataene for forvaltning. Microsofts veiledning beskriver oppdeling i utdrag som et valg som påvirker nytten av søket: Et for lite utdrag mister tanken, et for stort gir mye støy, mens blind deling etter et fast antall tegn kan skjære gjennom en tabell eller en unntaksbestemmelse.

I indekseringsfasen får utdragene en representasjon som egner seg for søk, vanligvis ved at søkeord kombineres med semantisk sammenligning av numeriske vektorer. Når brukeren stiller et spørsmål, kan systemet gjøre det om til flere søk, bruke filtre for avdeling, dato og tilgang, hente kandidater og rangere dem på nytt. Først da går de valgte utdragene inn i modellens kontekstvindu sammen med oppgaven: å svare ut fra det tilgjengelige bevisgrunnlaget, vise til kildene og si fra dersom grunnlaget ikke er tilstrekkelig; på dette tidspunktet blir ingenting «lært for alltid»; konteksten gjelder denne ene forespørselen.

Det siste trinnet er generering, der en forhåndstrent språkmodell gjør utdragene om til et forståelig svar; derfor kan den også omformulere klønete, koble sammen kilder som ikke hører sammen, eller legge til en troverdig detalj fra sin generelle kunnskap. Resultatet må bevare forbindelsen mellom utdrag og påstand, ikke bare vise en dekorativ kildeliste nederst i svaret. Hvis spørsmålet ber om en handling, for eksempel å endre en pris i CRM-systemet, bør modellen ikke få utføre den fritt: En strukturert verktøyforespørsel kontrolleres av programkoden, rettighetene og et godkjenningssteg. Hentingen hjelper med å finne grunnlaget; den gir ingen tillatelse til å handle.

I praksis fungerer hybridsøk godt: En nøyaktig produktkode eller et nummer på en retningslinje søkes som nøkkelord, mens meningen i spørsmålet sammenlignes semantisk. Deretter velger en ny rangering utdragene som best besvarer hele spørsmålet. Denne rekkefølgen må testes med ekte forkortelser, feilstavede koder, bøyningsformer og flerspråklige dokumenter, fordi spørsmålet i en demonstrasjon som regel er for ryddig. Hvis det nødvendige utdraget ikke finnes blant kandidatene, kan ikke den genererende modellen hente det tilbake med veltalenhet; derfor må søkefeilen rettes før prompten omformuleres.

Hvilke dokumentoppgaver passer RAG til?

De beste kandidatene er spørsmål der svaret allerede finnes i mange forvaltede dokumenter, men der det tar for lang tid for et menneske å lete det frem: interne rutiner, produktmanualer, tekniske instrukser, kvalitetsdokumentasjon, forklaringer til kontraktsmaler og kunnskapsbasen i kundestøtten. Her er ikke oppgaven til RAG å finne på en ny beslutning, men å finne riktig avsnitt, sette sammen noen utdrag som stemmer overens, og lage et utkast. Et godt spørsmål er «Hvilken veiledning beskriver denne feilen, og hvilke kontrolltrinn står der?», ikke «Hvordan bør bedriften håndtere enhver krisesituasjon?»; et søkelag for dokumenter er også nyttig før et menneske begynner arbeidet: Prosjektlederen kan finne leveringsvilkår i kontrakter, innkjøperen omtale av krav, og servicemedarbeideren tidligere løsninger på lignende utstyr. I slike tilfeller må svaret åpne riktig sted i kilden, slik at brukeren kan kontrollere sammenhengen, og systemet må logge spørsmålet, utdragene som ble funnet, og versjonen som ble brukt. Det gjør RAG til et verktøy for navigasjon og utkast, ikke en anonym dommer hvis beslutningsspor senere ikke kan gjenskapes.

Dårlige kandidater er oppgaver uten et stabilt dokumentgrunnlag, oppgaver som krever nøyaktig aritmetikk eller håndheving av regler, og oppgaver der én feil automatisk fører til en irreversibel handling. Lønnsberegning, tildeling av tilgang, gjennomføring av betaling og kontroll av en juridisk frist styres av kode og etterprøvbare forretningsregler; RAG kan finne en forklaring på prosedyren, men kan ikke erstatte beregningsmotoren eller fullmaktskjeden. Hvis det egentlige målet er å koble sammen systemer og flytte data på en forutsigbar måte, bør du vurdere automatisering av forretningsprosesser, ikke gjøre et generert svar til den sentrale bryteren i prosessen.

Egnetheten avgjøres også av hvem som har ansvaret: Hver dokumentsamling trenger en person som godkjenner kildene, løser konflikter og bestemmer hva som skal fjernes fra indeksen, mens hvert bruksområde trenger et team som gjennomgår feilene og endrer testsettet. Hvis ingen tar dette arbeidet, blir piloten etter noen måneder et speil av gamle dokumenter, selv om selve modellen ikke har endret seg; en teknisk enkel, men forvaltet støtteveiledning er derfor et bedre første prosjekt enn å koble til hele bedriftsdisken på én kveld.

Hva RAG kan gjøre med dokumenter i arbeidshverdagen

RAG kan redusere tiden en medarbeider bruker på å gjette riktig mappe og riktige nøkkelord, fordi semantisk søk kan finne et utdrag selv når ordene i spørsmålet ikke samsvarer med terminologien i dokumentet. Det kan kombinere flere kilder som stemmer overens, forklare en komplisert veiledning i enklere språk, lage et utkast til e-post eller rapport og vise hvilke sider hver vesentlig påstand kommer fra. OpenAIs filsøk og Microsofts søkearkitektur er konkrete eksempler på verktøy, men produktvalget fjerner ikke behovet for å definere dokumentstatus, filtre og kvalitetskontroller. Systemet kan også avdekke dokumentasjonsproblemer som vanlig mappevisning skjuler: To motstridende instrukser blir funnet for samme spørsmål, vanlige spørsmål mangler kilde, eller én avdeling dominerer søkeresultatene fordi filene der er bedre strukturert. Slike tilfeller er verdifulle bare dersom de ikke skjules bak ett velformulert svar; en kilde som ikke blir funnet, og en konflikt må bli målbare hendelser som dokumenteieren ser. Da blir RAG-loggen også en arbeidsliste for kunnskapsforvaltning, ikke bare en graf over modellytelse.

En annen reell mulighet er å tilpasse presentasjonen til rolle og kontekst: Teknikeren får en detaljert veiledning med koder, mens kunderådgiveren får en kortere forklaring dersom begge har rett til å se de samme kildene. Det er presentasjonen som er forskjellig, ikke sannheten, og hver rolle må beholde samme kildestatus og samme forbud mot å finne på det som mangler. Arbeidet vårt med KI-løsninger for bedrifter begynner med grensene for dette bruksområdet og risikoen, ikke med en modelldemonstrasjon, fordi en god prototype viser en konkret arbeidsgevinst på dine egne dokumenter og samtidig avdekker hvilke spørsmål systemet må besvare med «jeg vet ikke».

I det daglige arbeidet oppstår den største gevinsten når mennesket ser hva systemet har gjort, og hva som fortsatt må kontrolleres. I svarutkastet kan påstander med mangelfullt grunnlag fremheves, relaterte dokumenter foreslås og feil versjon rapporteres med én handling; slik tilbakemelding er mer verdifull enn et enkelt tommelikon. Rettelsen må knyttes til spørsmålet, utdraget og feiltypen, slik at teamet kan skille en kilde som ikke ble funnet, fra klønete språk eller en feil forretningsregel og velge riktig tiltak.

Hva RAG ikke kan gjøre, uansett hvor overbevisende svaret er

RAG kan ikke garantere sannhet, fordi en feil kan oppstå før, under eller etter genereringen: Kilden kan inneholde et feilaktig faktum, hentingen kan velge et irrelevant utdrag, konteksten kan miste et unntak, eller modellen kan koble sammen riktige avsnitt på feil måte. En henvisning reduserer risikoen for blind tillit bare når brukeren kan åpne det nøyaktige stedet og kontrollere at påstanden faktisk følger av det. En lenke til en ekte PDF er likevel ikke et kvalitetsstempel, på samme måte som litteraturlisten i en mangelfull rapport ikke gjør konklusjonen riktig.

RAG kan heller ikke innføre tilgangskontroll på egen hånd: Hvis søkelaget ikke filtrerer dokumentene etter en bekreftet brukeridentitet og dokumentets tillatelser før hentingen, kan modellen få et utdrag brukeren ikke har lov til å se. En senere instruks i prompten om å «ikke røpe hemmelig informasjon» reparerer ikke denne arkitekturfeilen. Microsofts veiledning for tilgang på dokumentnivå legger opp til at tillatelsesdata og sikkerhetsfiltre finnes i selve søkeforløpet. En skjult knapp i brukergrensesnittet er ingen beskyttelse dersom forespørselen kan utløses på en annen måte.

RAG gjør heller ikke upålitelig innhold trygt: Et dokument, en nettside eller en e-post kan inneholde en instruks som forsøker å omskrive systemets atferd — promptinjeksjon — og OWASP fremhever dette som en egen risiko som ikke løses fullstendig av et enkelt forbud i systemprompten. Eksternt innhold må derfor behandles som data, ikke kommandoer, verktøykall må være snevert tillatt og validert, og en handling med høy risiko må fortsatt styres av en deterministisk regel og godkjennes av et menneske; modellen kan foreslå; systemet tildeler fullmakten.

Listen over grenser må også omfatte tilgjengelighet og driftskontinuitet: Hvis søkeindeksen ikke kan nås, later ikke et sikkert system som det fortsatt har tilgang til bedriftens kilder, men går tydelig over i en feiltilstand eller en begrenset modus. Ellers kan ikke brukeren skille et kildebasert svar fra modellens frie improvisasjon; det må også finnes kostnads- og forespørselsgrenser, nødstopp og mulighet til å gjenopprette den forrige konfigurasjonen. Et RAG-produkt er en kjede av flere tjenester, og enhver stille feil kan endre betydningen i svaret selv om chattevinduet fortsetter å virke.

Er dokumentene klare for indeksering? OCR, metadata og versjonskontroll

Hvor mange filer som ligger i dokumentmappen, sier ingenting om dokumentene er klare: En skannet kontrakt med en skjev side, en tabell uten lesbar overskrift, en PDF med feil tekstrekkefølge eller et foto med lav kontrast kan se forståelig ut for et menneske, men miste et siffer, sammenhengen mellom kolonner eller en avsnittsgrense i OCR-uttrekket. Microsofts beskrivelse av begrensningene ved OCR knytter uttrykkelig resultatet til skannekvalitet, oppløsning, kontrast, lys, rotasjon og egenskaper ved teksten. Representative dokumenter må derfor kontrolleres etter uttrekk ved å sammenligne tekst, tabeller, sidereferanser og vesentlige felt med originalen, i stedet for å stole på at filen ble «behandlet uten feil».

Metadata gir utdraget organisatorisk kontekst: Dokumenttype, avdeling, produkt, språk, eier, godkjenner, konfidensialitet, ikrafttredelsestidspunkt og versjonsstatus gjør det mulig å avgrense søket før semantisk likhet vurderes. Uten slike data sammenligner søket setninger, men vet ikke at lagerinstruksen bare gjelder Litauen, eller at et kontraktsvedlegg er erstattet av et nyere. De viktigste feltene bør hentes fra et pålitelig system eller kontrolleres av et menneske; en generert gjetning om dokumentstatus må ikke bli filteret som bestemmer det neste svaret.

Oppdatering er også en del av produktet, ikke en engangsimport: Teamet må vite hvor raskt en godkjent endring når indeksen, hvordan et tilbaketrukket utdrag slettes, hva som skjer når filadressen endres, og om systemet fortsetter å vise den gamle versjonen etter en feil. Microsofts veiledning for indeksering skiller mellom trinnvise oppdateringer og ny indeksering, så hver kilde trenger en dokumentert metode for synkronisering og feilkontroll; før et RAG-prosjekt er det verdt å få orden på én autoritativ dokumentflyt; ellers gjør rask henting bare konsekvensene av uklar styring raskere.

Før den første indekseringen er det nyttig med et utvalg som viser hvor klare dokumentene er: Velg ulike filtyper, aldre, språk, tabeller, skanninger og tilgangsklasser, og kontroller deretter uttrekt tekst, grensene mellom utdrag, metadata og kildelenke for hver av dem. Feilandelen bør ikke gjøres om til ett gjennomsnittstall, fordi kostnaden ved et manglende komma i en instruks og et manglende beløp i en kontrakt er forskjellig. Utvalget gir et grunnlag for å bestemme hvilke formater som kan godtas automatisk, hvilke som trenger menneskelig kontroll, og hvilke som foreløpig ikke bør indekseres; dette arbeidet gir ofte større kvalitetsforbedring enn å velge en annen språkmodell.

Tilgangsrettigheter, personvern og valg av driftsmiljø

En sikker arkitektur begynner med identitet: Hvem spør, hvilken organisasjon og avdeling tilhører personen, hvilke dokumentklasser kan vedkommende se, og blir disse rettighetene kontrollert ved hver henteforespørsel? Tillatelsesfilteret må virke før utdrag når modellens kontekst, mens loggene bør unngå unødvendige kopier av hele spørsmål, svar og sensitive utdrag. Grensetilfeller må også testes: En ansatt bytter rolle, et dokument blir begrenset, tilgang trekkes tilbake, eller én kunde forsøker å finne innholdet til en annen. «Chatten krever innlogging» er ikke et tilstrekkelig akseptansekriterium.

Det finnes ikke noe ærlig, universelt svar på spørsmålet «Blir dataene mine brukt til å trene modellen?» uten å navngi leverandør, produkt, konto og innstillinger. Materialet til OpenAI om bedriftsprodukter og API-et opplyser at data fra de aktuelle bedriftsproduktene som standard ikke brukes til å trene modeller, mens dokumentasjonen om datakontroll for API-et beskriver lagring, overvåking av misbruk og unntak for endepunkter separat. Anthropic skiller på samme måte mellom behandling i kommersielle produkter, uttrykkelig samtykke til forbedring og vilkår for lagring; kontrakten og det tekniske designet må derfor kontrollere den konkrete tjenesten i stedet for å stole på uttrykket «API for bedrifter».

Drift i en EU-region eller på egen infrastruktur kan bidra til å oppfylle bestemte krav til datalokasjon, kontroll eller integrasjon, men viser ikke i seg selv at løsningen er sikker eller i samsvar med GDPR. Behandlingsformål og rettslig grunnlag, dataminimering, lagringstid, underleverandører, sletting, hendelseshåndtering og tilgangsrevisjon må fortsatt defineres; prinsippene i GDPR gjelder hele kjeden, ikke bare landet der modellserveren står. Noen ganger er riktig beslutning å la bestemte dokumenter stå helt utenfor RAG eller å fjerne felt som ikke trengs for svaret, før dokumentene indekseres.

Trusselmodellen må teste mer enn en nysgjerrig ansatt: Den må også dekke feil gruppesynkronisering, en delt lenke, en administratorrolle, en lagret hurtigbuffer og et dokument med en skadelig instruks. Testbrukerne bør dekke hver rolle og hver forbudte rollekombinasjon og prøve direkte spørsmål, synonymer og indirekte forespørsler om oppsummering. Resultatet må ikke røpe et utdrag, dokumentnavnet eller en fortrolig detalj som kan utledes av svaret. Testen må gjentas etter at rettigheter endres, fordi gårsdagens sikre filter kan ligge igjen i hurtigbufferen; disse kontrollene er akseptansekriterier, ikke pynt til en senere sikkerhetsgjennomgang.

Slik måler du henting, kildegrunnlag og riktighet

Ett samlet mål for «nøyaktighet» i et RAG-system er som én gjennomsnittskarakter for et sykehus: Tallet kan se godt ut mens en kritisk feilklasse forblir skjult. Mål først hentingen separat — om det nødvendige utdraget kom blant et definert antall topptreff, og om irrelevante utdrag skjøv det ut. Mål deretter hvor relevant konteksten er for spørsmålet, om svaret har grunnlag i utdragene som ble gitt, faktisk riktighet mot en godkjent fasit, om hver kildehenvisning støtter den konkrete påstanden, og systemets evne til å avstå fra å svare når en kilde mangler eller kildene står i konflikt.

Microsofts dokumentasjon om RAG-evaluatorer deler opp disse dimensjonene, og forskningsarbeidet ARES skiller på lignende måte mellom kontekstrelevans, svarforankring og svarrelevans. I et praktisk testsett trenger hvert reelle spørsmål derfor mer enn det «riktige svaret»: Det trenger også en obligatorisk kilde, tillatte formuleringer, forbudte påstander, en rolle, dokumentversjon og forventet atferd når bevisgrunnlaget ikke er tilstrekkelig. Noen eksempler bør komme fra vanlige spørsmål, andre fra kostbare unntak og bevisste feller.

Akseptanseterskelen må fastsettes for hver dimensjon og risikoklasse før resultatene blir kjent; ellers velger teamet etter demonstrasjonen det målet som ser best ut. Målingene i piloten bør også bevare fordelingen av feil etter dokumenttype, avdeling, språk og spørsmålstype, fordi det samlede gjennomsnittet kan skjule at håndbøker fungerer godt mens kontraktstabeller fungerer dårlig. En automatisk modellevaluator gjør det mulig å skalere testingen, men et utvalg må gjennomgås av et menneske, og kritiske svar må sammenlignes med en autoritativ kilde, ikke med selvsikkerheten til en annen modell.

Etter lansering bør de samme dimensjonene måles på et kontrollert utvalg fra produksjonen og med logger som ivaretar personvernet. En endring i dokumentkorpuset, algoritmen for oppdeling, embeddingmodellen, omrangeringen eller den genererende modellen kan forbedre én gruppe spørsmål og svekke en annen; derfor trenger hver versjon en regresjonstest og en sammenlignbar grunnlinje med uendrede evalueringsregler for hele testsettet. Et varsel bør ikke bare utløses når den samlede poengsummen faller, men også når det oppstår en kritisk feil, som et utdrag uten tillatelse eller et oppdiktet svar der systemet skulle ha avstått.

RAG, søk, lang kontekst, finjustering og agenter

Vanlig fulltekstsøk er bedre når brukeren kjenner det nøyaktige navnet, koden eller uttrykket og trenger et dokument i stedet for et sammensatt svar. Det er rimeligere, mer forutsigbart og enklere å revidere; semantisk søk hjelper med synonymer og vage spørsmål, men generering bør bare legges til når en oppsummering skaper reell verdi. RAG er ikke obligatorisk i ethvert søkeverktøy for bedrifter: Noen ganger er riktig produkt en god søkeside med filtre, forhåndsvisning av utdrag og versjonsstatus, fordi brukeren selv kan trekke konklusjonen fra hele dokumentet.

Å legge et helt dokument i et langt kontekstvindu kan være enkelt for en liten og stabil mengde materiale, men i et stort korpus øker det kostnaden, støyen og risikoen for at et viktig avsnitt forsvinner blant irrelevant innhold. Finjustering av modellen kan på sin side forsterke et format, en stil eller en bestemt oppgaveatferd, men er ingen praktisk måte å lagre priser, retningslinjer og instrukser som endres ofte, fordi oppdatering og kildehenvisning blir mindre gjennomsiktig. RAG lar dokumentsamlingen endres uavhengig av treningen av modellvektene, men denne fleksibiliteten krever forvaltning av indeksen, versjonene og kvaliteten på hentingen.

Automatisering utfører forhåndsdefinerte trinn, mens en KI-agent kan velge verktøy og neste trinn; denne friheten krever derfor strengere grenser for fullmakt, validering og stopp. RAG kan gi en agent informasjon, men ikke rettigheter: Selv om modellen finner retningslinjene for ferie, kan den ikke godkjenne et fravær eller endre lønnssystemet på egen hånd. Et strukturert funksjonskall er bare et forslag til programmet, som kontrollerer skjemaet, identiteten, den tillatte handlingen, beløpet eller andre grenser og nødvendig menneskelig godkjenning. Sammenligning av teknologi begynner med risikoen i prosessen, ikke med et ønske om å bruke den nyeste betegnelsen.

Valget kan uttrykkes som en enkel test: Hvis du må finne og åpne en fil, begynn med søk. Hvis du må oppsummere noen få kilder som endres, med henvisninger, bør du vurdere RAG. Hvis du må opprettholde et stabilt format eller en bestemt klassifiseringsatferd, kan finjustering passe. Hvis du må utføre en forutsigbar rekke handlinger, bør du bygge automatisering. Legg bare til en agent når neste trinn ikke kan programmeres på en trygg måte, og gevinsten veier opp for den ekstra risikoen. Tilnærmingene kan kombineres, men hvert lag må ha sin egen oppgave, måling og stoppgrense; ellers forsvinner årsaken til en feil bak ordet «KI».

Slik bygger du en avgrenset pilot med reelle spørsmål

En pilot begynner med én dokumentsamling, én brukergruppe og én beslutningsgrense, for eksempel håndbøker for teknisk støtte der systemet bare finner kilder og lager et svarutkast. Før utviklingen samler teamet reelle spørsmål fra søkelogger, e-poster og intervjuer med ansatte, legger til de riktige kildene og tar bevisst med tilfeller som ikke kan besvares, er utdaterte, står i konflikt eller krever en tilgang brukeren ikke har. For hvert tilfelle defineres hva som er akseptabelt: Det nødvendige utdraget blir funnet, påstanden har grunnlag i kilden, henvisningen leder til riktig sted, svaret er faktisk riktig, og systemet unngår trygt å finne på det som mangler.

Tersklene må fastsettes før demonstrasjonen og deles inn etter risiko: Et utkast som kan rettes, kan være akseptabelt for et vanlig informasjonsspørsmål, mens et spørsmål om persondata, kontrakt, sikkerhet eller betaling krever strengere kontroll og menneskelig godkjenning. Piloten bør også måle svartid, kostnad per forespørsel, om tilgangsfiltrene virker, forsinkelsen i oppdatering av indeksen og hvor ofte en medarbeider åpner kilden eller retter svaret. Hvis systemet bare forbedrer demonstrasjonseksemplene, men ikke holder mål på et tidligere skjult testsett, er det ikke dokumentert et produktresultat; det eneste som er dokumentert, er at teamet kan forberede en demonstrasjon.

Utviklingen av våre KI-løsninger for bedrifter starter fra 3 500 € og tar vanligvis 3–8 uker, mens en fungerende pilot på dine egne data kan leveres på 2–3 uker. Disse tallene beskriver tjenestens startpris og generelle tidsplan, ikke et fast tilbud for et ukjent omfang. Når piloten er ferdig, bør resultatet være mer enn et chattevindu: Det bør omfatte et versjonert dokumentkorpus, testspørsmål, separate kvalitetsmålinger, en feillogg, tilgangskontroller og en beslutning om hva løsningen ikke skal gjøre. Senere integrasjonskrav bør registreres like tydelig som i ethvert annet digitalt prosjekt, etter prinsippet som er beskrevet i artikkelen om de ti feilene bedrifter gjør når de bestiller nettside: Akseptansekriterier og eiere må defineres før full innføring, ikke etter det første imponerende skjermbildet.

Piloten bør bare videreføres dersom den når de forhåndsdefinerte tersklene på en usett del av testsettet, håndterer spørsmål uten tillatelse eller svargrunnlag på en trygg måte og gir en målbar gevinst i menneskelig arbeid. Hvis hentingen systematisk ikke finner riktig kilde, må dokumentene, metadataene og indeksen rettes først; hvis kilden er riktig, men genereringen forvrenger den, må konteksten, prompten eller modellen endres. Hvis feilen bare oppstår i beslutninger med høy risiko, bør de beslutningene overlates til et deterministisk system og et menneske. En stanset pilot er ikke en fiasko — den er et rimelig bevis på at grensene ved RAG betyr mer enn demonstrasjonseffekten i akkurat denne prosessen.