No products added!
Store sprogmodeller kan skrive imponerende dansk, opsummere komplekse emner og hjælpe med idéudvikling på få sekunder. Men når spørgsmålet handler om noget, der skal være korrekt, opdateret og forankret i en bestemt kilde, opstår den klassiske udfordring: modellen kan komme til at “lyde sikker” uden faktisk at have belæg.
Retrieval-Augmented Generation, forkortet RAG, er en enkel idé med stor effekt: Lad modellen hente viden i relevante dokumenter, mens den skriver svaret. Så får man kombinationen af sproglig styrke og dokumenteret indhold, i stedet for gæt baseret på træningsdata.
RAG i én sætning, og hvorfor det føles som et gennembrud
RAG er en metode, hvor en sprogmodel først slår noget op i en ekstern vidensbase og derefter formulerer et svar med udgangspunkt i det fundne materiale.
Det lyder beskedent, men ændrer dynamikken i mange AI-løsninger. I stedet for at spørge en model: “Hvad ved du?”, spørger man i praksis: “Hvad kan du finde i vores kilder, og hvordan kan du forklare det klart?”. Det giver en mere kontrollerbar AI, især når svar skal kunne forklares, dokumenteres eller auditeres.
Og ja, RAG handler også om at reducere hallucinationer. Når modellen får konkrete tekstbidder at støtte sig til, bliver det sværere at opfinde paragraffer, produktdetaljer eller interne processer.
To typer “hukommelse”: det modellen har lært, og det den kan slå op
En sprogmodel har en form for indbygget viden fra træningen. Den er stærk til mønstre i sprog, generelle begreber og typiske forklaringer. Men den viden er ikke nødvendigvis aktuel, og den er sjældent specifik for din organisation.
RAG supplerer med en ekstern hukommelse: dokumenter, databaser, intranet-sider, PDF’er, politikker, manualer eller offentlige kilder. Her ligger det, man reelt vil have modellen til at bruge.
Det er et vigtigt skifte i tankegang: man opdaterer ikke nødvendigvis modellen, når noget ændrer sig. Man opdaterer kilderne og indekset, så retrieval-delen finder de nye passager næste gang.
En enkelt sætning kan opsummere gevinsten: RAG gør det muligt at bygge svar på noget, der kan genfindes.
Hvad der sker, når du stiller et spørgsmål i et RAG-system
Når en bruger stiller et spørgsmål, sker der typisk to ting, før der kommer et svar tilbage.
Først omsættes spørgsmålet til et “søgesignal”. I mange løsninger betyder det, at man laver en embedding (en numerisk repræsentation af betydning), som kan matches mod embeddings for tekststykker i vidensbasen. Alternativt, eller som supplement, bruges klassisk søgning med nøgleord.
Så hentes de mest relevante tekstpassager. De passager bliver sendt med ind i prompten til sprogmodellen, som får en meget konkret opgave: Svar med udgangspunkt i de vedlagte kilder.
Den praktiske konsekvens er, at man kan styre både indhold og tone. Indhold via kilderne, tone via prompt og retningslinjer.
Kernekomponenterne i en RAG-løsning
En RAG-løsning kan se avanceret ud udefra, men den kan forstås som et samspil mellem få byggesten. Tabellen her er en nyttig mental model, når man skal vurdere muligheder, risici og indsats.
| Komponent | Hvad den gør | Typiske designvalg |
|---|---|---|
| Vidensgrundlag (dokumenter/data) | Kilden til “sandheden” i svarene | Offentlige kilder, interne politikker, produktmanualer, kontraktbiblioteker, tickets, FAQ |
| Chunking og struktur | Deler lange dokumenter i mindre bidder, der kan findes igen | Størrelse pr. tekstbid, overlap, metadata (dato, afdeling, version) |
| Indeks (ofte vektorindeks) | Gør tekstbidder søgbare via semantisk lighed | FAISS/Qdrant/Pinecone eller søgemotor + vektorudvidelse |
| Retriever | Finder relevante bidder ud fra spørgsmålet | Dense, sparse (BM25) eller hybrid retrieval |
| Reranking (valgfrit, men effektivt) | Sorterer de fundne bidder bedre | Cross-encoder/reranker for højere præcision |
| Generator (LLM) | Skriver svaret baseret på spørgsmålet + fundne bidder | Modelvalg, prompt, svarformat, kildeangivelser |
| Kontrol og sikkerhed | Begrænser fejl, datalæk og uønskede svar | Adgangsstyring, logning, filtrering, policies, evaltests |
Når man ser det sådan, bliver RAG også et samarbejde mellem faglighed og teknik: Man skal både have styr på kilder, kvalitet og ejerskab, og på søgning, performance og governance.
Danske eksempler: hvor RAG hurtigt bliver værdifuldt
Dansk er et mindre sprogområde, og meget viden ligger i dokumenter, der ikke er “almindeligt kendte” for en generel model. Derfor passer RAG godt til danske behov, både i virksomheder og i det offentlige.
Når man først har indekseret solide kilder, åbner der sig mange anvendelser:
- Intern HR og personalehåndbog
- Kundeservice med produkt- og leveringsvilkår
- Juridisk førstehjælp med interne kontraktskabeloner
- IT-support baseret på runbooks og kendte fejl
- Projektkontor med metoder, skabeloner og beslutningsnotater
- Uddannelsesmiljøer med pensum, vejledninger og interne regler
En dansk kundeservice-case er let at se for sig: En kunde spørger om retur, reklamation eller garanti. Uden RAG risikerer man upræcise svar, fordi regler og vilkår varierer efter produktkategori, købstype og virksomhedens egne betingelser. Med RAG kan assistenten hente de relevante afsnit fra virksomhedens handelsbetingelser og formulere et svar, der følger samme ordlyd og praksis.
Et andet stærkt eksempel er kommunikation af komplekse regler: En intern assistent, der kan forklare personaleprocedurer eller compliance-krav i klart dansk, men altid med rod i de interne dokumenter, der gælder lige nu.
Hvad RAG giver dig, som en “almindelig” chatbot sjældent kan love
En standard chatbot uden retrieval kan være glimrende til kreative opgaver og generelle forklaringer. Men når svaret skal være efterprøveligt, begynder kravene at ændre sig.
RAG hjælper især på tre fronter: aktualitet, sporbarhed og domænesprog. Du kan opdatere vidensbasen, uden at genoptræne modellen. Du kan i mange opsætninger få kildehenvisninger, så brugeren kan tjekke belæg. Og du kan gøre det muligt at bruge præcis terminologi fra danske dokumenter, hvad enten det er interne processer eller offentlige tekster.
Det betyder ikke, at RAG automatisk giver perfekte svar. Det betyder, at du kan bygge et system, hvor kvalitet kan måles og forbedres systematisk.
Designvalg der afgør, om RAG føles skarpt eller sløvt
To RAG-løsninger kan ligne hinanden på en tegning, men opføre sig helt forskelligt i praksis. Forskellen ligger ofte i detaljerne.
Chunking er et klassisk eksempel. Hvis man deler dokumenter i for store bidder, bliver retrieval upræcist og man får “for meget støj” med ind i prompten. Hvis man deler for småt, mister man sammenhæng, og modellen får svært ved at formulere et korrekt svar med de rigtige forbehold.
Retrieval-metoden betyder også meget på dansk. Nøgleordssøgning kan være stærk i juridiske tekster, hvor konkrete begreber og paragraftegn går igen. Semantisk vektorsøgning kan være bedre, når brugere formulerer sig frit, bruger synonymer eller taler i hverdagssprog. Mange ender med hybrid søgning, fordi det giver robusthed.
Så er der spørgsmålet om kildevisning. I praksis kan et RAG-svar blive markant mere troværdigt, hvis det ledsages af 2-4 korte kildestykker eller links, brugeren kan klikke på. Det gør også intern godkendelse lettere, når løsningen skal ud til flere afdelinger.
Kvalitet, ansvarlighed og data: det voksne lag i RAG
Når RAG bruges på interne dokumenter, opstår der hurtigt reelle spørgsmål: Hvem må se hvad? Hvordan sikrer man, at fortrolige oplysninger ikke bliver en del af svaret? Hvilke logs gemmes, og hvor længe?
Her giver RAG faktisk en mulighed, der ofte er nemmere end ren finjustering: man kan lægge adgangsstyring på vidensbasen og filtrere retrieval efter brugerens rettigheder. Så kan samme assistent give forskellige svar, fordi den kun må hente fra de kilder, den pågældende bruger må læse.
Et andet vigtigt element er evalueringspraksis. Mange fejl i RAG handler ikke om “dårlig AI”, men om svage kilder, uklare dokumentversioner eller retrieval, der finder det forkerte afsnit. Når man måler på:
- om de hentede passager er relevante
- om svaret kun bruger det, der står i passagerne
- om svarformat og forbehold følger retningslinjer
…så bliver forbedringerne konkrete. Det er også her, mange fagteams får en reel rolle: de kan kuratere kilder, definere godkendte formuleringer og opsætte testspørgsmål.
En praktisk måde at komme i gang på, uden at gøre det unødigt tungt
Den bedste start er ofte en afgrænset use case med tydelige kilder og klare succeskriterier. Det giver læring hurtigt, og man kan udvide derfra.
En enkel plan kan se sådan ud:
- Afgrænsning af use case: Vælg én opgave, hvor korrekthed betyder noget, og hvor kilderne kan samles i en lille, kontrolleret vidensbase.
- Kildehygiejne og ejerskab: Beslut hvem der “ejer” dokumenterne, hvem der godkender ændringer, og hvordan versioner håndteres.
- Chunking med intention: Del dokumenter, så hvert tekststykke giver mening alene, men stadig har nok kontekst til at være brugbart.
- Retrieval og testspørgsmål: Byg en spørgebank fra virkelige henvendelser og mål, om systemet henter de rigtige passager.
- Svarpolitik: Fastlæg om assistenten må svare, hvornår den skal sige “jeg ved det ikke”, og om den skal vise kilder.
- Drift og opdatering: Planlæg hvordan nye dokumenter indekseres, og hvordan man opdager, når svar begynder at glide i kvalitet.
For mange teams giver det også mening at kompetenceudvikle parallelt. Når medarbejdere lærer at formulere krav til kilder, teste svar og arbejde ansvarligt med AI, bliver RAG ikke et “IT-projekt”, men et fælles kvalitetsløft. Det er netop den slags praksisnære forløb, et kursusakademi som Nordisk Business Academy typisk tager udgangspunkt i: konkrete cases, målbar effekt og en tilgang, hvor AI hænger sammen med faglighed og arbejdsprocesser.
RAG er i den forstand mindre magi og mere håndværk. Og det er gode nyheder, for håndværk kan læres, forbedres og skaleres.

