Retrieval-Augmented Generation (RAG) er en metode, hvor en sprogmodel henter relevante oplysninger fra eksterne kilder, før den svarer. Formålet er at gøre svar mere aktuelle, kontrollerbare og knyttet til dokumenter, databaser eller videnbaser, som modellen ikke nødvendigvis har lært under træning.
Retrieval-Augmented Generation (RAG) gør en sprogmodel mere nyttig ved at hente relevante kilder, før den svarer. Metoden giver overblik over arkitektur, dataforberedelse, embeddings, adgangskontrol, sikkerhed, kvalitetstjek, drift og forskellen på RAG, fine-tuning og lang kontekst.
Hvad betyder Retrieval-Augmented Generation i praksis?
Retrieval-Augmented Generation betyder, at generativ AI udvides med et søgelag. I stedet for at bede modellen svare ud fra sin indlærte viden alene, søger systemet først efter relevant materiale og sender udvalgte tekststykker videre som grundlag for svaret.
Retrieval-delen handler om at finde information. Augmented betyder, at modelinputtet beriges med det fundne materiale. Generation er den del, hvor sprogmodellen formulerer et samlet svar. RAG er derfor ikke en bestemt model, men en arkitektur, der forbinder søgning, dataforberedelse og tekstgenerering.
Metoden bruges især, når en organisation vil lade en AI-assistent svare på interne politikker, produkthåndbøger, teknisk dokumentation, supportartikler, kundeaftaler eller andre kilder, som ofte ændrer sig. Den kan også bruges med offentlige kilder, hvis systemet skal svare på et emne, hvor kildematerialet skal kunne kontrolleres.
Hvordan fungerer en RAG-arkitektur trin for trin?
En typisk RAG-arkitektur begynder med, at relevante dokumenter indsamles og gøres søgbare. Dokumenterne opdeles ofte i mindre tekststykker, fordi en model sjældent kan bruge hele dokumenter effektivt på én gang. Hvert tekststykke får metadata som kilde, dato, adgangsniveau, dokumenttype og eventuelt ejer.
Når en bruger stiller et spørgsmål, omsættes spørgsmålet til en søgeforespørgsel. Systemet finder derefter de mest relevante tekststykker i et indeks, prioriterer dem og sender et begrænset udvalg videre til sprogmodellen. Modellen får samtidig en instruks om at basere svaret på det udvalgte materiale.
Det sidste trin er svar og kontrol. Et godt RAG-system returnerer ikke kun en flydende formulering, men kan også vise, hvilke kilder der ligger bag svaret. I mere modne løsninger logges både søgning, valgte kilder, brugerens adgangsrettigheder og svarets kvalitet, så systemet kan testes og forbedres.
Hvilke data kan bruges i et RAG-system?
RAG kan bygges på mange typer tekstlige kilder: PDF’er, websider, vidensbaseartikler, e-mails, tickets, regneark, manualer, kontraktudkast, API-dokumentation og interne retningslinjer. Det afgørende er ikke filformatet alene, men om indholdet kan udtrækkes, opdeles, indekseres og vedligeholdes på en kontrolleret måde.
Datakvalitet har stor betydning. Et system, der indekserer forældede, dublerede eller modstridende dokumenter, kan give svage svar, selv hvis sprogmodellen er stærk. Derfor bør dokumenter have tydelig version, dato, ejer, emne og adgangsniveau. Der bør også være en proces for at fjerne gamle kilder fra indekset.
RAG er mest nyttig, når kilderne har en konkret funktion. En supportassistent kan søge i produktvejledninger og kendte fejl. En intern HR-assistent kan søge i personalehåndbog og politikker. En udviklerassistent kan søge i kodebase, tekniske beslutninger og dokumentation. Jo klarere kildesamling, jo lettere bliver systemet at evaluere.
Hvorfor er embeddings og søgeindeks centrale?
RAG bygger ofte på AI-embeddings, som omsætter tekst til numeriske repræsentationer. Formålet er at gøre det muligt at finde tekststykker, der betyder noget lignende som brugerens spørgsmål, selv når ordene ikke er identiske. Det kaldes semantisk søgning.
Embeddings gemmes typisk i en vektordatabase eller et søgeindeks, hvor systemet hurtigt kan finde de nærmeste tekststykker. I praksis kombineres vektorsøgning ofte med traditionel nøgleordssøgning, filtrering på metadata og en ekstra rangering, der vælger de mest brugbare kilder.
Indeksdesignet påvirker svaret direkte. Hvis tekststykkerne er for korte, mangler modellen sammenhæng. Hvis de er for lange, kan relevante passager drukne i støj. Hvis metadata mangler, kan systemet vælge en gammel version eller et dokument, brugeren ikke burde have adgang til. Retrieval er derfor en faglig opgave, ikke kun en teknisk integration.
Hvordan adskiller RAG sig fra fine-tuning?
RAG og fine-tuning af sprogmodeller løser forskellige problemer. RAG giver modellen adgang til eksterne kilder ved svartidspunktet. Fine-tuning ændrer modellens adfærd eller mønstergenkendelse gennem ekstra træning. De to metoder kan kombineres, men de bør ikke forveksles.
| Metode | Bedst til | Typisk begrænsning |
|---|---|---|
| RAG | Aktuelle, kildebaserede svar på dokumenter og videnbaser | Kræver stærk datakvalitet, søgning og adgangsstyring |
| Fine-tuning | Stil, format, klassifikation eller domænespecifik adfærd | Opdaterer ikke automatisk viden fra nye dokumenter |
| Lang kontekst | Analyse af udvalgte dokumenter i samme samtale | Kan blive dyrt, langsomt og vanskeligt at styre ved store samlinger |
Hvis problemet er, at modellen skal svare på opdaterede dokumenter, er RAG ofte mere naturligt end fine-tuning. Hvis problemet er, at modellen konsekvent skal klassificere sager i et bestemt format eller følge en særlig sproglig stil, kan fine-tuning eller systematisk eksempeldesign være mere relevant.
Hvornår er RAG mere relevant end en længere kontekst?
Store sprogmodeller kan håndtere mere tekst end tidligere, men længere kontekst erstatter ikke nødvendigvis RAG. Når datamængden er stor, skiftende eller adgangsbegrænset, er det sjældent hensigtsmæssigt at sende alt materiale med til modellen. RAG forsøger i stedet at finde det mest relevante udsnit.
Lang kontekst er nyttig, når du allerede ved, hvilke dokumenter der skal analyseres. RAG er mere relevant, når systemet selv skal finde de rigtige kilder blandt mange mulige dokumenter. Det gælder især i organisationer, hvor viden er spredt på tværs af mapper, vidensbaser, supporthistorik og teknisk dokumentation.
RAG kan også reducere omkostninger og svartid, fordi modellen kun får udvalgte tekststykker. Det kræver dog, at søgelaget faktisk finder de rigtige kilder. En længere kontekst med de forkerte dokumenter giver ikke et bedre svar end en kortere kontekst med præcist materiale.
Hvad gør RAG ved hallucinationer og faktuelle fejl?
RAG kan mindske risikoen for AI-hallucinationer, fordi modellen får konkrete kilder at svare ud fra. Det betyder dog ikke, at hallucinationer forsvinder. Modellen kan stadig misforstå et dokument, blande flere kilder forkert sammen eller formulere en konklusion, som kilderne ikke understøtter.
Fejl kan også opstå før modellen svarer. Hvis retrieval-laget finder et irrelevant dokument, hvis en gammel version ligger højere end den nye, eller hvis et tekststykke mangler den nødvendige kontekst, kan svaret blive forkert. RAG flytter derfor en del af kvalitetsarbejdet fra modelvalg til data, søgning og evaluering.
En praktisk regel er, at RAG bør behandles som et kontrollerbart beslutningsstøttesystem, ikke som en garanti for sandhed. Kildespor, testspørgsmål, manuelle stikprøver og klare svargrænser er nødvendige, hvis systemet skal bruges i arbejdsprocesser, hvor fejl har reel betydning.
Hvordan vurderer du kvaliteten af retrieval?
Kvaliteten af RAG bør måles på to niveauer: om systemet finder de rigtige kilder, og om modellen bruger dem korrekt. Det første niveau handler om retrieval. Her kan du teste, om de mest relevante dokumenter bliver fundet, om nyere versioner prioriteres, og om metadatafiltre virker.
Det andet niveau handler om svaret. Her bør du undersøge, om svaret faktisk bygger på de hentede kilder, om usikkerhed formuleres tydeligt, og om kilderne dækker hele konklusionen. Et svar kan være sprogligt overbevisende og stadig være dårligt, hvis retrieval-laget kun har fundet halvdelen af materialet.
- Lav et testsæt med realistiske spørgsmål, kendte facits og forventede kilder.
- Mål om de rigtige tekststykker ligger blandt de øverste søgeresultater.
- Test både enkle spørgsmål, flertydige spørgsmål og spørgsmål, hvor systemet bør afvise at svare sikkert.
- Log ændringer i indeks, rangering og datakilder, så fejl kan spores tilbage.
Evaluering bør gentages, når datakilder, modeller, embeddings eller rangering ændres. Små tekniske justeringer kan flytte, hvilke tekststykker systemet vælger, og dermed ændre svarene mærkbart.
Hvilke sikkerheds- og adgangskrav skal med?
RAG kan give en sprogmodel adgang til dokumenter, som normalt er beskyttet af rettigheder, roller eller fortrolighed. Derfor skal adgangskontrol være en del af arkitekturen fra begyndelsen. Systemet bør kun hente kilder, som den konkrete bruger har ret til at se.
En almindelig fejl er at bygge et samlet indeks over alle dokumenter og først tænke rettigheder ind bagefter. Det kan skabe risiko for, at svar afslører oplysninger fra dokumenter, brugeren ikke selv kan åbne. Metadata om adgangsniveau, afdeling, kunde, projekt og dokumentstatus bør derfor følge hvert tekststykke.
Sikkerhed handler også om logning og dataminimering. Spørgsmål, hentede kilder og svar kan indeholde personoplysninger eller forretningskritisk information. En RAG-løsning bør have klare regler for lagring, sletning, overvågning og brug af leverandører, især hvis den anvendes i regulerede eller kundevendte miljøer.
Hvordan bør kilder og citater håndteres?
Kildehenvisninger er en af de mest praktiske fordele ved RAG. Når systemet kan vise, hvilke dokumenter der er brugt, bliver svaret lettere at kontrollere. Kilder bør dog ikke kun vises som pynt. De skal pege på konkrete dokumenter eller passager, som faktisk understøtter svaret.
Hvis et system viser kilder, bør det også kunne håndtere uenighed mellem kilder. En nyere politik kan afløse en ældre. En produktside kan være mere opdateret end en PDF. En intern instruks kan gælde én afdeling, men ikke en anden. RAG-systemet skal kunne prioritere efter dato, status og relevans.
Her hænger RAG tæt sammen med grounding af AI-modeller. Grounding betyder, at modellens svar bindes til et konkret grundlag. I en god løsning er det tydeligt, om svaret bygger på dokumenter, generel modelviden eller en forsigtig fortolkning af flere kilder.
Hvilke fejl opstår typisk i RAG-projekter?
Den første fejl er at behandle RAG som et lag, der kan lægges oven på ustruktureret dokumentkaos. Hvis dokumenterne er uklare, forældede eller modstridende, vil systemet afspejle den uklarhed. RAG gør viden mere tilgængelig, men det rydder ikke automatisk op i kildematerialet.
Den anden fejl er at optimere på modelsvaret uden at måle retrieval. Mange problemer skyldes ikke, at modellen formulerer sig dårligt, men at den får de forkerte tekststykker. Derfor bør fejl analyseres baglæns: Var spørgsmålet forstået korrekt, fandt søgningen de rigtige kilder, og brugte modellen dem loyalt?
Den tredje fejl er at overse drift. Kilder ændrer sig, adgangsrettigheder flyttes, nye dokumenttyper kommer til, og brugere stiller spørgsmål på andre måder end testpersoner. Et RAG-system skal have ejerskab, overvågning og en fast proces for opdatering, ellers bliver kvaliteten gradvist svagere.
Hvordan kommer du fra prototype til stabil drift?
En stabil RAG-løsning begynder med en afgrænset brugssituation. Vælg et område, hvor kilderne er kendte, hvor svarene kan kontrolleres, og hvor fejl kan håndteres. Det kan for eksempel være intern support, teknisk dokumentation, standardiserede kundespørgsmål eller søgning i produktviden.
Derefter bør du bygge en enkel dataproces: udvælg kilder, rens dokumenter, opdel dem i tekststykker, tilføj metadata, opret indeks og lav et testsæt. Før løsningen bruges bredt, bør den testes på spørgsmål, der kræver præcise kilder, og spørgsmål, hvor systemet ikke bør give et skråsikkert svar.
Når løsningen går i drift, skal den have vedligeholdelse. Nye dokumenter skal indekseres, gamle versioner skal fjernes, adgangsregler skal kontrolleres, og fejlrapporter skal føre til forbedringer i datagrundlag eller søgning. RAG er dermed både en AI-arkitektur og en løbende vidensforvaltningsopgave.
Hvilke kilder ligger til grund?
Artiklen bygger på den oprindelige RAG-beskrivelse i Lewis et al.s forskningsartikel om Retrieval-Augmented Generation, Microsofts tekniske gennemgang af RAG med Azure AI Search, Google Clouds forklaring af RAG som kombination af informationssøgning og sprogmodeller samt AWS’ dokumentation for Knowledge Bases for Amazon Bedrock.