Hvad er Retrieval-Augmented Generation (RAG)?

Retrieval-Augmented Generation (RAG) er en metode, hvor en sprogmodel henter relevante oplysninger fra eksterne kilder, før den formulerer et svar. Metoden bruges især, når AI skal svare på aktuelle, interne eller dokumentafhængige spørgsmål, men den gør kun svaret bedre, hvis søgning, datakvalitet og kildekontrol fungerer.

Hvad betyder Retrieval-Augmented Generation?

Retrieval-Augmented Generation betyder, at generativ AI ikke kun bruger det, modellen har lært under træning. Systemet kobler modellen til et søgelag, der finder relevante tekststykker, tabeller eller andre dokumentuddrag, som lægges ind i modellens arbejdsgrundlag for det konkrete svar.

Den oprindelige RAG-idé blev formuleret som en kombination af en generativ model og en ekstern videnkilde. I praksis betyder det, at modellen bevarer sin evne til at formulere tekst, men får mulighed for at bruge information, der kan opdateres uden at træne hele modellen om.

RAG er derfor mest præcist at forstå som en arkitektur for vidensadgang, ikke som en bestemt modeltype. Den kan bygges med forskellige sprogmodeller, søgeteknologier, dokumentformater og kontrolmekanismer, så længe systemet først finder relevant materiale og derefter genererer et svar med det materiale som kontekst.

Hvordan fungerer RAG i praksis?

En almindelig RAG-løsning begynder med, at dokumenter gøres søgbare. Det kan være interne vejledninger, produktdokumentation, tekniske specifikationer, kontraktuddrag, supportartikler eller offentlige kilder. Dokumenterne renses, opdeles i mindre stykker og gemmes i et indeks, så systemet kan finde relevante passager senere.

Når du stiller et spørgsmål, omsætter retrieval-laget spørgsmålet til en søgning. Søgningen kan være traditionel nøgleordssøgning, semantisk søgning med embeddings eller en hybrid løsning, der kombinerer begge dele. De mest relevante tekststykker sendes videre til sprogmodellen, som formulerer et svar ud fra både spørgsmålet og de fundne oplysninger.

En enkel proces kan se sådan ud:

1. Udvælg de kilder, som systemet må bruge.
2. Del indholdet op i tekststykker med passende længde.
3. Opret embeddings eller andre søgbare repræsentationer.
4. Gem materialet i et søgeindeks eller en vektordatabase.
5. Find relevante tekststykker for hvert spørgsmål.
6. Lad sprogmodellen svare med udgangspunkt i de fundne oplysninger.
7. Vis eventuelt kilder, så svaret kan kontrolleres.

Det afgørende er ikke kun, at systemet henter noget. Det afgørende er, om det henter det rigtige, i den rigtige version, med nok kontekst til at modellen kan svare præcist.

Hvilken rolle spiller embeddings og vektordatabaser?

Embeddings er numeriske repræsentationer af tekst, der gør det muligt at finde indhold ud fra betydning og ikke kun ordrette matches. Hvis en bruger spørger om “feriepolitik”, kan systemet finde et dokument, der bruger ord som “fravær”, “årsferie” eller “godkendelse”, hvis betydningen ligger tæt nok på spørgsmålet.

En vektordatabase gemmer disse numeriske repræsentationer og gør dem søgbare. Den kan sammenligne spørgsmålets embedding med embeddings for dokumentstykker og returnere dem, der ligger nærmest. Du kan læse mere om selve begrebet i forklaringen af AI embeddings og den tekniske lagerdel i artiklen om vektordatabaser.

Vektorsøgning er nyttig, når brugere formulerer spørgsmål på andre måder end dokumenterne. Den er dog ikke altid nok alene. Mange systemer kombinerer vektorsøgning med nøgleord, filtre, metadata og semantisk ranking, fordi datoer, produktnumre, navne og præcise termer ofte kræver mere end betydningsmæssig lighed.

Hvornår er RAG bedre end almindelig modelviden?

RAG er især relevant, når svaret afhænger af viden, der er ny, intern, reguleret, detaljeret eller forskellig fra organisation til organisation. En generel sprogmodel kan forklare et begreb, men den kender ikke nødvendigvis din virksomheds seneste proces, dine egne produktdata eller den version af en vejledning, som faktisk gælder.

Metoden passer godt til interne vidensassistenter, supportværktøjer, teknisk dokumentation, sagsbehandling, forskningssøgning og compliance-nære arbejdsgange, hvor brugeren skal kunne spore svaret tilbage til dokumenter. Hvis du bygger en løsning, hvor brugeren stiller spørgsmål til egne filer eller en intern vidensbase, er RAG ofte mere kontrollerbar end at stole på modellens generelle hukommelse.

RAG er mindre oplagt, hvis opgaven primært handler om kreativ formulering, generel ideudvikling eller data, der allerede findes stabilt i modellens træningsgrundlag. Her kan retrieval-laget give unødig kompleksitet, længere svartider og flere mulige fejlkilder.

Hvad kan RAG ikke løse alene?

RAG kan reducere nogle fejlkilder, men det fjerner ikke risikoen for upræcise svar. Hvis systemet henter forkerte, forældede eller for korte tekststykker, kan modellen skrive et overbevisende svar på et svagt grundlag. Hvis kilderne modsiger hinanden, kan modellen også sammenblande information på en måde, der virker mere sikker, end den er.

RAG løser heller ikke adgangsstyring af sig selv. Hvis en bruger ikke må se et dokument i den oprindelige datakilde, må retrieval-laget heller ikke hente det ind i svaret. Det kræver klare rettigheder, filtrering på bruger- eller rolleniveau og logning af, hvilke kilder der blev brugt.

Et andet forbehold er kontekstlængde. Modellen kan kun arbejde med en begrænset mængde materiale ad gangen. Hvis retrieval-laget sender for mange passager med, kan svaret blive rodet. Hvis det sender for få, kan centrale forbehold mangle. Det er derfor nødvendigt at teste både søgning, rangering og svarformulering.

Hvordan adskiller RAG sig fra fine-tuning?

RAG og fine-tuning løser forskellige problemer. RAG giver modellen adgang til eksterne oplysninger ved svartidspunktet. Fine-tuning ændrer derimod modellens adfærd eller specialiserer den på bestemte eksempler. Du kan bruge fine-tuning til tone, format, klassifikation eller gentagne opgavemønstre, mens RAG typisk bruges til faktuel og opdaterbar viden.

I mange praktiske løsninger er RAG første valg, hvis problemet er viden, der ændrer sig. Fine-tuning kan komme senere, hvis systemet skal lære en stabil arbejdsform. Se også den særskilte forklaring af fine-tuning af sprogmodeller.

Hvilke datakilder egner sig bedst?

De bedste datakilder til RAG er kilder, der er autoritative, ajourførte, tekstligt klare og afgrænset til det område, brugeren spørger om. Interne politikker, produktoplysninger, tekniske manualer, standardprocedurer og godkendte vidensartikler fungerer ofte bedre end lange ustrukturerede mapper med dubletter og uklare versioner.

Før du lægger data i et RAG-system, bør du vurdere:

• om kilden er den gældende version
• hvem der ejer indholdet
• hvilke brugere der må se det
• om dokumenterne har metadata som dato, afdeling, produkt eller version
• om indholdet kan deles i meningsfulde tekststykker

Hvis datagrundlaget er svagt, hjælper en avanceret model kun begrænset. En RAG-løsning bliver typisk bedre af færre, bedre kuraterede kilder end af et stort indeks med uklare kopier, forældede dokumenter og modsatrettede instruktioner.

Hvordan vurderer du kvaliteten af en RAG-løsning?

Kvaliteten skal vurderes i flere led. Først skal retrieval-laget finde de rigtige kilder. Derefter skal rangeringen placere de vigtigste tekststykker højt. Til sidst skal modellen bruge materialet korrekt og undlade at udfylde huller med usikre antagelser.

En praktisk test bør derfor ikke kun spørge, om svaret lyder rigtigt. Den bør også kontrollere, om de viste kilder faktisk understøtter svaret, om relevante dokumenter blev overset, og om svaret skelner mellem dokumenteret information og usikker fortolkning.

Et lille evalueringssæt kan være nok til at afsløre de første problemer. Vælg spørgsmål, som dækker almindelige opgaver, vanskelige grænsetilfælde, forældede dokumenter, enslydende begreber og spørgsmål, hvor systemet bør svare, at der mangler grundlag. Den type test siger mere end en enkelt demonstration med et let spørgsmål.

Hvilke sikkerheds- og datarisici følger med RAG?

RAG flytter en del af AI-risikoen fra modellen til datalaget. Det kan være en fordel, fordi kilder kan styres og opdateres, men det betyder også, at dokumentadgang, dataklassifikation og kildehygiejne bliver centrale kontrolpunkter.

En organisation bør især kontrollere tre områder. For det første skal fortrolige dokumenter kun kunne hentes af brugere med adgang. For det andet skal systemet kunne håndtere skadelige eller manipulerende dokumenter, hvis brugere kan uploade materiale. For det tredje skal output kunne efterprøves, så en fejl kan spores til enten retrieval, kildeindhold eller modellens formulering.

RAG kan også give en falsk følelse af sikkerhed, hvis alle svar vises med kilder, men kilderne kun delvist understøtter konklusionen. Det er her, grounding bliver et selvstændigt kvalitetsbegreb. En gennemgang af grounding af AI-modeller forklarer, hvorfor kildegrundlag og svar ikke automatisk er det samme.

Hvordan bruges RAG i danske organisationer?

I danske organisationer er RAG især relevant i miljøer med mange interne dokumenter, faglige vejledninger og hyppige opdateringer. Det kan være kundeservice, HR, IT-support, produktteams, offentlige sagsgange, uddannelsesmiljøer og faglige videnscentre, hvor brugeren har brug for et svar med sporbarhed til en kilde.

Den praktiske værdi ligger ofte i at forkorte vejen fra spørgsmål til relevant dokumentation. En medarbejder kan spørge i almindeligt sprog og få et svar, der peger på relevante afsnit. Det kan spare tid, men det bør ikke erstatte faglig kontrol i beslutninger med stor økonomisk, juridisk eller personlig betydning.

Hvis RAG bruges sammen med personoplysninger, fortrolige dokumenter eller regulerede arbejdsgange, skal adgangen designes ud fra de eksisterende rettigheder i organisationen. Det er ikke nok at lægge dokumenterne i en søgbar base. Systemet skal også vide, hvem der må få hvilke svar.

Hvad er forskellen på klassisk RAG og agentisk retrieval?

Klassisk RAG bruger typisk én søgning eller et fast sæt søgetrin før svaret. Agentisk retrieval giver systemet mere frihed til at planlægge flere søgninger, opdele et komplekst spørgsmål, sammenholde resultater og returnere mere strukturerede svar. Det kan være nyttigt, når spørgsmålene er lange, uklare eller kræver flere kilder.

Agentisk retrieval er dog ikke automatisk bedre. Flere søgetrin kan give bedre dækning, men også flere beslutninger, der skal logges og testes. Hvis opgaven er enkel, kan klassisk RAG være lettere at styre, hurtigere at svare med og nemmere at fejlfinde.

Valget bør afhænge af brugerens opgave. Hvis en chatbot mest skal finde ét relevant afsnit i en intern vejledning, kan klassisk RAG være tilstrækkeligt. Hvis brugeren spørger på tværs af mange datakilder og forventer et begrundet svar med flere mellemtrin, kan agentisk retrieval give mere værdi.

Hvordan kommer man i gang uden at overbygge løsningen?

Den mest robuste start er at vælge et lille område, hvor kilderne er kendte, brugerne har et konkret informationsbehov, og svarene kan kontrolleres. Det kan være en intern FAQ, en produktmanual eller en afgrænset dokumentpakke. Formålet er at teste hele kæden, før systemet udvides.

En enkel startplan kan være:

1. Vælg én brugergruppe og én opgavetype.
2. Udpeg de autoritative dokumenter.
3. Rens dubletter og gamle versioner væk.
4. Lav et lille sæt testspørgsmål med kendte svar.
5. Mål om systemet henter de rigtige kilder.
6. Juster chunking, metadata, søgning og svarformat.
7. Udvid først, når fejltyperne er forstået.

Hvis målet er en praktisk chatbot med egne dokumenter, er RAG ofte en del af løsningen, men ikke hele løsningen. Artiklen om at bygge en AI-chatbot med egne data dækker flere af de valg, der ligger rundt om retrieval-laget.

Hvad er den vigtigste praktiske konklusion?

RAG er nyttigt, når AI skal svare med udgangspunkt i konkrete kilder frem for generel modelviden. Metoden er særlig stærk, når kilderne er opdaterbare, kontrollerbare og knyttet til en bestemt organisation eller et bestemt fagområde.

Den største fejl er at behandle RAG som en garanti for korrekte svar. En god RAG-løsning kræver kildevalg, søgekvalitet, adgangsfiltre, evaluering og tydelige svargrænser. Hvis et spørgsmål ikke understøttes af de hentede kilder, bør systemet kunne sige det i stedet for at formulere et sikkert klingende svar.

Den bedste tommelfingerregel er at starte med datagrundlaget. Hvis du kan definere, hvilke kilder der er autoritative, hvem der må se dem, og hvilke testspørgsmål systemet skal klare, har du et langt bedre udgangspunkt end ved først at vælge model og først senere rydde op i kilderne.

Hvilke kilder ligger til grund?

Den tekniske definition bygger især på den oprindelige forskningsartikel Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. Den praktiske proces er sammenholdt med Microsofts RAG-overblik for Azure AI Search, AWS-dokumentationen for Bedrock Knowledge Bases og Google Clouds RAG Engine-dokumentation. Risikoperspektivet er holdt op mod NISTs profil for generativ AI-risikostyring.