RAG forklart: Slik gir du AI oppdatert kunnskap

Problemet: språkmodeller lever i fortiden

Alle store språkmodeller har en «cutoff-dato» — et tidspunkt der treningen stoppet. GPT-4 vet ikke hva som skjedde i går. Claude vet ikke om den nyeste loven Stortinget vedtok. Og selv om modellen vet noe fra treningen, kan den ikke sitere kilden din — bedriftens interne dokumenter, din produktkatalog, eller din juridiske fagbase.

Dette er ikke et bug du kan fikse med en bedre prompt. Det er en strukturell egenskap ved how language models work. Løsningen er RAG: i stedet for å be modellen huske svaret, lar du den slå opp svaret i din egen kunnskapsbase — akkurat som en menneskelig ekspert ville gjort.

Hva er RAG — den grunnleggende idéen

RAG, eller Retrieval-Augmented Generation, kombinerer to systemer: et søkesystem som finner relevante dokumenter, og et generativt LLM som formulerer et svar basert på de fundne dokumentene. I stedet for å stille modellen spørsmålet direkte, forbereder RAG-pipeline-n en kontekstuell prompt: «Her er de 5 mest relevante dokumentene fra kunnskapsbasen. Basert på disse, svar på følgende spørsmål:»

• Steg 1 — Indeksering: Dokumenter deles opp i biter (chunks) og konverteres til embedding-vektorer som lagres i en vektordatabase.
• Steg 2 — Retrieval: Brukerens spørsmål konverteres til en embedding-vektor, og de mest semantisk lignende chunks hentes ut via cosine similarity-søk.
• Steg 3 — Augmentation: De hentede chunks legges inn i prompten som kontekst.
• Steg 4 — Generation: LLM genererer svar basert på den augmenterte prompten, med kildehenvisning til de faktiske dokumentene.

Embeddings og vektordatabaser: teknologien under panseret

Kjernen i RAG er embedding-teknologi. En embedding-modell (f.eks. OpenAI text-embedding-3-large eller det norske NB-BERT) konverterer et tekststykke til en numerisk vektor — typisk 1536 eller 3072 tall. Semantisk like tekster får vektorer som er «nær» hverandre i dette høydimensjonale rommet.

En vektordatabase er optimalisert for å finne de nærmeste vektorene til et gitt søkepunkt, ekstremt raskt — selv med millioner av dokumenter. Dette skiller seg fra tradisjonell fulltekstsøk (som BM25/Elasticsearch) som søker på nøkkelord. Semantisk søk forstår mening, ikke bare ord.

Chunking-strategi: ofte oversett, alltid kritisk

Hvordan du deler dokumenter i chunks er kanskje den viktigste designbeslutningen i et RAG-system. For store chunks gir mer kontekst, men lavere presisjon i retrieval. For små chunks gir høy presisjon, men fragmentert kontekst til LLM. Vanlige strategier:

• Fast-size chunking: Del på fast antall tokens (f.eks. 512). Enkelt, men kan kutte midt i setninger. Bruk overlapp (50–100 tokens) for å bevare sammenheng.
• Semantisk chunking: Del på avsnitt eller temagrenser. Bevarer logisk sammenheng bedre, men variabel størrelse.
• Hierarchical chunking (Parent-Child): Lagre både store og små chunks. Søk på små for presisjon, men send store til LLM for kontekst.
• Late chunking: Ny teknikk der hele dokumentet embeddes, men chunks ekstraheres ettersom — gir bedre kontekstuell forståelse.

Hybrid søk og re-ranking

Rent vektorsøk er ikke alltid best. En hybrid tilnærming kombinerer semantisk søk (vektorer) med nøkkelord-søk (BM25) for å fange opp eksakte termer som produktnavn, lover og fagbegreper. Etter at kandidat-chunks er hentet, bruker man gjerne en re-ranker (f.eks. Cohere Rerank eller cross-encoder modeller) som scorer relevans mer nøyaktig enn cosine similarity alene.

"RAG er ikke én teknologi, men et arkitekturmønster. Den faktiske ytelsen avhenger 80 % av datakvalitet og chunking-strategi — ikke av LLM-valget."

RAG i tall

Ytelsesdata fra reelle RAG-implementasjoner:

Norske brukstilfeller: hvem bruker RAG?

NAV har implementert RAG-baserte chatbots som kan svare på spørsmål om ytelser og regelverket — basert på oppdatert lovtekst og NAV-interne retningslinjer. Svarene er kildehenvist til faktiske paragrafer, noe som reduserer risikoen for feil informasjon drastisk.

Advokatfirmaer som Wiersholm og Thommessen bruker RAG for juridisk research — modellen søker i rettspraksis-databaser og fagartikler og genererer analyser med kildehenvisning. Videre bruker DNB og Nordea RAG for intern kunnskapshåndtering: ansatte kan spørre systemet om bankens produkter, prosedyrer og compliance-regler i stedet for å søke manuelt i hundrevis av interne dokumenter.

Kom i gang med RAG selv

Det enkleste utgangspunktet for norske utviklere er LangChain eller LlamaIndex kombinert med OpenAI embeddings og en lokal vektordatabase som Chroma (for utvikling) eller pgvector på Postgres (for produksjon). For norskspråklig innhold gir NB-BERT fra Nasjonalbiblioteket bedre embedding-kvalitet enn engelske modeller.

For bedrifter uten intern utviklerkapasitet finnes managed RAG-tjenester: Azure AI Search med OpenAI-integrasjon, AWS Bedrock Knowledge Bases og Vertex AI Search på Google Cloud. Disse håndterer indeksering, chunking og retrieval som managed service — mot en høyere kostnad per spørring.