RAG — Retrieval-Augmented Generation forklaret
RAG henter relevant indhold via embeddings-søgning og injicerer det i LLM-konteksten. Alternativ til fine-tuning der er billigere, opdateres dynamisk og reducerer hallucination.
RAG — Retrieval-Augmented Generation — er en arkitektur der kombinerer en LLM med et søgesystem. I stedet for at forvente at modellen har al relevant viden “bagt ind” under træning, henter systemet det relevante indhold dynamisk og injicerer det i prompten som kontekst.
Flowet: bruger stiller et spørgsmål → spørgsmålet konverteres til en embedding-vektor → vektordatabasen søges for semantisk lignende dokumenter → de mest relevante dokumenter injiceres i prompten → LLM’en genererer svar baseret på kombinationen af spørgsmål og hentet kontekst.
Hvorfor RAG frem for fine-tuning
Fine-tuning træner modellen direkte på dine data — men det er dyrt, tidskrævende og producerer en statisk model der ikke kender til data fra efter træningen. RAG løser alle tre problemer.
Dynamisk opdatering
Tilføj et nyt dokument til vektordatabasen og systemet kender til det øjeblikkeligt — ingen gentrænning. Det giver RAG en fundamental opdateringshastighed fine-tuning ikke kan matche.
Kildetransparens
RAG-systemer kan citere de konkrete dokumenter der lå til grund for svaret. Det muliggør verifikation og reducerer blind tillid til output — en afgørende forskel i enterprise-kontekster og redaktionelle workflows.
Lavere hallucination
Når modellen har relevant faktuel kontekst injiceret i prompten, er den langt mindre tilbøjelig til at fabricere information. Modellen instrueres til at basere sit svar på den fremsendte kontekst, ikke på hvad den “husker” fra træning.
Lavere omkostning
Fine-tuning af en stor model koster titusinder af dollars. En vektordatabase og embedding-API’er er brøkdelen — og understøtter dynamisk opdatering som ovenfor.
Vektordatabaser og embeddings i RAG
Kernen i retrieval-steget er embeddings og vektordatabaser. Hvert dokument konverteres til en embedding-vektor og gemmes i en database som Pinecone, Weaviate, Chroma eller pgvector. Ved søgning konverteres spørgsmålet til en vektor og de nærmeste vektorer (cosine similarity eller dot product) hentes.
Kvaliteten af retrieval-steget er afgørende for systemets samlede kvalitet. En perfekt LLM kan ikke generere godt output baseret på dårligt hentet kontekst — “garbage in, garbage out” gælder fuldt ud.
RAG og Googles AI Overviews
Google AI Overviews er i essensen et RAG-system i masseskala: Googles indeks er vektordatabasen, søgealgoritmerne er retrieval-steget og en Gemini-model genererer det opsummerende svar baseret på hentet indhold.
Det er denne arkitektur der giver RAG-systemernes udfordring og mulighed for SEO: dine sider skal retrieves (synlighed i indekset) og de skal være de bedste kandidater til at blive injiceret som kontekst (autoritet, præcision, citérbarhed). Klassisk SEO og AI-synlighed konvergerer i RAG-arkitekturen. → Denne artikel er en del af Sprogmodeller og LLM’er — Hvad de er og hvordan de virker.
Andre artikler i samme emne
- Embeddings — Semantisk mening som matematiske vektorer
- Fine-tuning — Hvornår du bør specialisere en AI-model
- Hallucination i LLM'er — Hvad det er og hvordan du håndterer det
- Kontekstvindue — Hvad context window er og hvad det betyder
- LLM Bias — Skævheder og fejl i AI-sprogmodeller
- RLHF — Reinforcement Learning from Human Feedback
- Tokens og tokenisering — Hvad det er og hvorfor det betyder noget
- Transformer-arkitektur — Den tekniske grund under alle moderne LLM'er
Ofte stillede spørgsmål
- Hvad er RAG (Retrieval-Augmented Generation)?
- RAG er en arkitektur der kombinerer en LLM med et søgesystem. Flowet: bruger stiller et spørgsmål → spørgsmålet konverteres til en embedding-vektor → en vektordatabase søges for semantisk lignende dokumenter → de mest relevante dokumenter injiceres i prompten som kontekst → LLM'en genererer et svar baseret på kombinationen af spørgsmål og hentet kontekst. Resultatet er en model der kan svare baseret på aktuel, verificerbar information fremfor hvad den 'husker' fra træning.
- Hvad er fordelen ved RAG frem for fine-tuning?
- RAG har tre primære fordele over fine-tuning: dynamisk opdatering (tilføj et dokument til vektordatabasen og systemet kender til det øjeblikkeligt uden gentrænning), kildetransparens (RAG-systemer kan citere de konkrete dokumenter der lå til grund for svaret), og lavere hallucination (modellen baserer sit svar på injiceret faktuel kontekst frem for statistiske mønstre fra træning). Fine-tuning koster mere, er statisk og løser ikke hallucinationsproblemet.
- Hvordan er Googles AI Overviews et RAG-system?
- Google AI Overviews fungerer i essensen som RAG i masseskala: Googles søgeindeks er vektordatabasen, søgealgoritmerne er retrieval-steget der finder de mest relevante dokumenter, og en Gemini-model genererer det opsummerende svar baseret på hentet indhold. Det betyder at SEO og AI-synlighed konvergerer i RAG-arkitekturen — dine sider skal både retrieves (indekseres og rangeres) og være de bedste kandidater til at blive injiceret som kontekst (faktuel præcision, autoritet, klar struktur).
- Hvad er chunk-strategien i RAG og hvorfor er den vigtig?
- Chunking er processen at opdele dokumenter i passende stykker inden de embeddes og gemmes i vektordatabasen. For lille chunks (enkeltlinjer) mister man kontekst; for store chunks (hele dokumenter) fortyndes det specifikke indhold og retrieval-præcisionen falder. En typisk effektiv chunk-størrelse er 200-500 tokens med overlap på 20-50 tokens mellem chunks. Valget af chunk-strategi er en af de vigtigste tuning-parametre i et RAG-system — dårlig chunking degraderer output-kvalitet selv med en god LLM og embedding-model.
- Hvornår er RAG bedre end en meget lang prompt med hele dokumentet?
- Med Claudes 200k tokens og Geminis 1M tokens context window kan man i nogle cases sende hele dokumentet som kontekst frem for at bygge et RAG-system. RAG er bedre når: vidensbasen er større end det praktiske context window (f.eks. alle blogindlæg de seneste 5 år), dokumentsamlingen opdateres hyppigt og skal reflekteres uden nyt API-kald, præcis kildeattribution er krævet per svar, og cost per token er en begrænsende faktor ved meget dyre modeller. Direkte kontekst er enklere og foretrækkes for overskulige datasæt.
Placering i ordbogen
- Embeddings — Semantisk mening som matematiske vektorer
- Fine-tuning — Hvornår du bør specialisere en AI-model
- Hallucination i LLM'er — Hvad det er og hvordan du håndterer det
- Kontekstvindue — Hvad context window er og hvad det betyder
- LLM Bias — Skævheder og fejl i AI-sprogmodeller
- RLHF — Reinforcement Learning from Human Feedback
- Tokens og tokenisering — Hvad det er og hvorfor det betyder noget
- Transformer-arkitektur — Den tekniske grund under alle moderne LLM'er