Kunstig intelligensHafsteinn Runarsson · AI Konsulent15 Sept 2026 · 10 min

RAG i AI: hva det er og hvordan det virker

RAG (retrieval-augmented generation) er en arkitektur som lar en språkmodell hente relevant informasjon før den svarer. I stedet for å stole bare på det modellen lærte under trening, får den et utvalg fra dokumenter, databaser eller andre kunnskapskilder som kontekst. AWS beskriver RAG som en måte å koble en språkmodell til en autoritativ kunnskapsbase uten å trene modellen på nytt.

Kort forklart gjør en RAG-løsning dette:

1. Leser spørsmålet.
2. Finner de mest relevante kildene.
3. Legger utdragene inn i instruksen til språkmodellen.
4. Genererer et svar basert på utdragene.
5. Viser eller lagrer hvilke kilder som ble brukt.

RAG er nyttig når et AI-system må svare ut fra informasjon som er privat, spesialisert eller i stadig endring. Men kvaliteten står og faller på datakildene og søket. En språkmodell blir ikke feilfri bare fordi den bruker RAG.

Slik virker en RAG-løsning

En RAG-løsning består av to løp: først klargjøres kunnskapen, deretter hentes relevant innhold for hvert spørsmål. Selve språkmodellen er bare én del av systemet.

1. Kildene samles og ryddes

Systemet kobles til kilder som håndbøker, produktdokumentasjon, databaser, supportsaker eller interne rutiner. Før innholdet kan brukes, må det ha tydelige eiere, gyldige tilgangsregler og en plan for oppdatering. Gamle og motstridende dokumenter gir gamle og motstridende svar.

Dokumentene deles ofte i mindre tekstbiter, kalt chunks. Bitene må være store nok til å beholde meningen, men små nok til at søket finner akkurat det spørsmålet gjelder. IBM peker på chunk-størrelse som en sentral innstilling: for store biter blir generelle, mens for små biter mister sammenheng.

2. Innholdet gjøres søkbart

Mange RAG-systemer lager embeddings, altså numeriske representasjoner av betydningen i tekst, og lagrer dem i en vektordatabase. Når brukeren stiller et spørsmål, kan systemet finne tekstbiter med lignende betydning selv om de ikke bruker nøyaktig de samme ordene.

Vektorsøk er vanlig, men det trenger ikke stå alene. Et godt oppsett kan kombinere semantisk søk med nøkkelord, metadatafiltre, databasespørringer eller API-kall. Google Cloud beskriver kombinasjonen av semantisk søk, nøkkelordsøk og rerangering som hybrid søk.

3. Spørsmålet brukes til å hente kilder

Brukerens spørsmål omformes til en søkespørring. Systemet kan rette skrivefeil, legge til manglende kontekst fra samtalen og filtrere på for eksempel avdeling, språk, dato eller tilgangsnivå. Deretter hentes et lite sett med relevante utdrag.

Her avgjøres mye av svarkvaliteten. Hvis søket finner feil dokument, kan svaret være tro mot kilden og likevel bomme på spørsmålet. Google Cloud understreker at irrelevante treff kan gi et svar som er godt forankret, men feil eller på siden av temaet.

4. Modellen får spørsmålet og utdragene

De hentede utdragene legges inn i prompten sammen med spørsmålet og klare regler for svaret. En god instruks kan be modellen holde seg til kildene, si fra når grunnlaget er utilstrekkelig, og oppgi referanser til dokumentene den brukte.

Språkmodellen formulerer så et lesbart svar. Etterpå kan systemet kontrollere om svaret faktisk støttes av utdragene, formatere sitater og logge hvilke kilder som ble hentet.

Hva RAG løser

RAG er først og fremst en måte å gi en språkmodell riktig kontekst på riktig tidspunkt. Det løser flere praktiske problemer i samme arkitektur.

• Kunnskapen kan oppdateres uten at modellen trenes på nytt.
• Private eller fagspesifikke kilder kan brukes i et avgrenset system.
• Svar kan kobles til dokumentene de bygger på.
• Utviklere kan endre kilder, filtre og søkelogikk uten å bytte språkmodell.
• Mengden kontekst kan begrenses til det som er relevant for spørsmålet.

Dette gjør RAG særlig egnet for kunnskapsassistenter og copiloter som må arbeide med virksomhetens egne data. IBM fremhever tilgang til oppdatert domenekunnskap, kildehenvisninger og større kontroll over datakildene som sentrale fordeler.

Hva RAG ikke løser

RAG reduserer noen feilkilder, men innfører også nye. Systemet kan fortsatt hente feil tekst, misforstå et tvetydig spørsmål eller formulere en konklusjon som ikke støttes av kildene. IBM presiserer at RAG kan redusere risikoen for hallusinasjoner, men ikke gjøre modellen feilfri.

Vanlige svakheter er:

• Utdaterte kilder blir hentet fordi oppdateringsløpet ikke virker.
• Dårlig oppdeling gjør at viktig kontekst havner i en annen tekstbit.
• Søket foretrekker språklig likhet fremfor det dokumentet som faktisk er autoritativt.
• For mange utdrag gjør prompten støyete og kostbar.
• Manglende tilgangsfiltre kan vise informasjon brukeren ikke skal se.
• Et velformulert svar kan få større tillit enn kildegrunnlaget fortjener.

Tilgangskontroll må derfor følge hvert søk, ikke bare innloggingen i selve chatten. AWS beskriver hvordan utviklere kan begrense henting av sensitiv informasjon etter autorisasjonsnivå. Kildene, søkeindeksen og loggene må behandles som virksomhetsdata.

RAG sammenlignet med finjustering og vanlig søk

RAG, finjustering og søk løser ulike deler av problemet. Valget blir enklere når du skiller mellom kunnskap, atferd og gjenfinning.

• RAG passer når modellen trenger oppdatert eller privat kunnskap ved svartidspunktet. Kildene kan endres uten ny modelltrening.
• Finjustering passer bedre når modellen skal lære en bestemt stil, struktur eller oppgaveatferd. Det er mindre egnet som lager for fakta som endres ofte.
• Vanlig søk finner dokumenter som brukeren selv må lese. RAG bruker søkeresultatene som grunnlag for et samlet svar.
• Lang kontekst passer når hele kildematerialet er lite nok til å sendes med i hvert spørsmål. RAG blir mer aktuelt når materialet er større, eller når bare noen få utdrag er relevante.

RAG og finjustering kan også kombineres. En finjustert modell kan følge ønsket format, mens RAG tilfører den aktuelle kunnskapen. IBMs sammenligning av RAG og finjustering legger samme skille til grunn: RAG oppdaterer konteksten, mens finjustering endrer modellens parametere.

Ulike typer RAG

De fleste team bør begynne enkelt og legge til mer avansert søkelogikk først når evaluering viser et behov. Navnene varierer mellom leverandører, men disse mønstrene er nyttige å kjenne:

• Enkel RAG gjør ett søk og genererer ett svar. Det passer for avgrensede spørsmål med ryddige kilder.
• Hybrid RAG kombinerer vektorsøk med nøkkelord og metadata. Det er ofte nyttig når eksakte produktnavn, saksnumre eller faguttrykk må bevares.
• RAG med rerangering henter flere kandidater og lar en egen modell sortere de beste utdragene før generering.
• Agentisk RAG kan dele opp et spørsmål, velge mellom flere kilder og søke på nytt hvis første forsøk ikke er godt nok.
• Graph RAG bruker relasjoner mellom personer, selskaper, produkter eller hendelser når et vanlig dokumentsøk ikke fanger sammenhengen.
• Multimodal RAG kan hente fra tekst, bilder, lyd eller video når kunnskapen ikke bare finnes i dokumenttekst.

En oversikt fra Meilisearch beskriver blant annet enkel, agentisk, graph- og multimodal RAG. En lang liste over varianter er likevel ikke et mål i seg selv. Arkitekturen bør følge spørsmålene systemet faktisk skal besvare.

Når RAG passer

RAG passer når gode svar krever et kontrollert kildegrunnlag som modellen ikke kan forventes å ha lært. Før du bygger, bør du kunne peke på både brukerne, spørsmålene og kildene.

Gode utgangspunkt er:

• En intern kunnskapsassistent for rutiner, håndbøker og prosjektinformasjon.
• Kundestøtte som svarer ut fra godkjente produkt- og hjelpedokumenter.
• En copilot som finner og sammenfatter relevant informasjon fra flere systemer.
• Dokumentsøk der brukeren trenger et kort svar med lenker tilbake til originalene.
• En AI-agent som trenger oppdatert kontekst før den foreslår eller utfører en handling.

RAG passer dårlig hvis kildene mangler eiere, tilgangsregler eller en pålitelig oppdateringsprosess. Det er heller ikke nødvendig når oppgaven kan løses med et enkelt databasesøk, et fast regelsett eller vanlig fulltekstsøk.

Slik planlegger du en RAG-løsning

En RAG-løsning bør bygges rundt målbare spørsmål, ikke rundt en bestemt modell eller vektordatabase. Start med en liten, representativ testmengde og gjør feilene synlige.

1. Velg én tydelig arbeidsflyt og én brukergruppe.
2. Samle ekte spørsmål brukerne trenger svar på.
3. Bestem hvilke kilder som er autoritative for hvert tema.
4. Avklar hvem som kan lese hva, også i søkeindeksen.
5. Lag en første løsning med enkel henting og tydelige kildehenvisninger.
6. Evaluer både om riktig innhold ble hentet, og om svaret støttes av innholdet.
7. Test hva systemet gjør når kildene mangler, er uenige eller er utdaterte.
8. Overvåk søk uten treff, svake kilder, svartid og kostnad etter lansering.

Målene bør skille mellom søket og språkmodellen. Hvis riktig dokument aldri blir hentet, hjelper det lite å endre prompten. Hvis dokumentet blir hentet, men svaret likevel er feil, ligger problemet senere i kjeden.

Hvordan måler du kvaliteten?

God RAG-kvalitet betyr at systemet finner riktig grunnlag og svarer innenfor det grunnlaget. En generell vurdering av om svaret «høres bra ut» er ikke nok.

Test minst disse delene hver for seg:

• Treffkvalitet: Kom de riktige utdragene med blant de første treffene?
• Kildedekning: Fantes informasjonen i kunnskapsbasen?
• Forankring: Kan hvert viktig utsagn spores til de hentede utdragene?
• Fullstendighet: Besvarer svaret hele spørsmålet?
• Avståelse: Lar systemet være å gjette når kildene ikke gir svar?
• Tilgang: Får brukeren bare treff fra innhold vedkommende har lov til å lese?
• Aktualitet: Bruker systemet siste gyldige versjon av dokumentet?

Google Cloud beskriver en tilsvarende evalueringsmodell med egne mål for blant annet hentede tekstbiter, forankring, sikkerhet og svarkvalitet. Poenget er å etablere en grunnlinje og forbedre søk, kildeoppsett, chunking og spørsmål systematisk.

Fjerner RAG hallusinasjoner?

Nei. RAG kan gi modellen bedre kilder og gjøre svar lettere å kontrollere, men den kan fortsatt trekke en feil slutning eller bruke et irrelevant utdrag. Krev kildehenvisninger, test avståelse og mål om svaret faktisk støttes av kildene.

Trenger RAG alltid en vektordatabase?

Nei. En vektordatabase er nyttig for semantisk søk i mye ustrukturert tekst, men RAG kan også hente fra nøkkelordsøk, SQL, kunnskapsgrafer eller API-er. Mange løsninger kombinerer flere metoder.

Kan RAG bruke private data?

Ja, men bare innenfor et gjennomtenkt sikkerhetsoppsett. Tilgangsregler må brukes under selve hentingen, slik at modellen aldri får utdrag brukeren ikke har rett til å se. Det må også finnes kontroll på logging, lagring og sletting.

Hva er forskjellen på RAG og en AI-agent?

RAG gir et AI-system relevant kunnskap. En AI-agent kan i tillegg velge handlinger og bruke verktøy, for eksempel å slå opp en ordre eller oppdatere en sak. En agent kan bruke RAG som én av flere kunnskapskilder.

Neste steg

En god første avklaring er enkel: Hvilke spørsmål skal systemet besvare, hvilke kilder avgjør hva som er riktig, og hvem har tilgang til dem? Hvis de tre svarene er uklare, bør datagrunnlaget ryddes før teknologien velges.

Daia bygger AI-agenter og copiloter for produksjon. Omfang, pris, timing, tilgang, eierskap og overlevering avtales for hvert oppdrag. Start en samtale hvis dere vil vurdere om RAG passer for egne data og arbeidsflyter.