Retrieval-Augmented Generation (RAG) Systemer

Hvad bruges RAG-systemer til?

En almindelig sprogmodel som ChatGPT, Claude eller Gemini kender ikke jeres virksomhed. Den ved intet om jeres kontrakter, jeres kvalitetsprocedurer eller manualen til maskinen i produktionshallen. Spørger man alligevel, får man ofte et svar der lyder rigtigt, men ikke har belæg i noget.

Et RAG-system løser præcis det problem. RAG står for Retrieval-Augmented Generation, altså tekstgenerering understøttet af opslag. Systemet slår først op i virksomhedens egne dokumenter og giver derefter de fundne afsnit videre til sprogmodellen, som formulerer svaret ud fra dem. Modellen bliver ikke trænet om. Den får lov at læse, mens den svarer.

Under motorhjelmen foregår det i to faser. Først indekseringen: dokumenterne hentes ind, deles op i mindre bidder (chunks), og hver bid oversættes til en lang talrække, der beskriver bidens betydning (en embedding). Talrækkerne gemmes i en vektordatabase. Dernæst selve søgningen: brugerens spørgsmål oversættes på samme måde, systemet finder de bidder der ligger tættest på spørgsmålet, og sender dem med til sprogmodellen sammen med en instruks om kun at svare ud fra materialet. De fleste opsætninger viser til sidst hvilken fil og hvilket afsnit svaret bygger på.

I danske virksomheder bruges RAG-systemer typisk til intern videnssøgning, hvor medarbejdere kan spørge i almindeligt sprog til personalehåndbøger, ISO- og kvalitetsprocedurer, tekniske vejledninger og gamle projektsager. De bruges til kundeservice, hvor svar skal følge virksomhedens egne handelsbetingelser og produktdata frem for et frit gæt. De bruges til tilbuds- og udbudsarbejde, hvor man skal genfinde formuleringer fra tidligere materiale. Og de bruges i rådgivnings- og revisionsarbejde, hvor man skal finde det rigtige sted i en stor bunke regler og rapporter.

Det er lige så vigtigt at vide, hvad et RAG-system ikke er. Det er ikke en oprydning i jeres filer. Ligger der tre versioner af den samme prisliste på SharePoint, svarer systemet forkert med fuld selvtillid. Det er heller ikke en erstatning for et fagsystem: præcise opslag som "hvad står der på ordre 4471" hører hjemme i ERP-systemet, ikke i en vektorsøgning.

Hvem bruger RAG-systemer?

RAG-systemer er mest udbredt i brancher med meget skriftlig dokumentation og et krav om, at svar kan spores tilbage til en kilde. I Danmark ser man dem hos rådgivende ingeniørvirksomheder og entreprenører, hos advokat- og revisionsfirmaer, i forsikring og finans, i medico og life science, i produktionsvirksomheder med store mængder teknisk dokumentation, og i softwarehuse der bygger løsningen ind i deres eget produkt.

Den offentlige sektor er en tung bruger. Kommuner, regioner og styrelser har store mængder vejledninger, sagsakter og lovtekst, hvor gennemsigtighed og kildehenvisning betyder mere end hastighed. Her er kravene til dokumentation, adgangsstyring og databeskyttelse som regel strammere end i en privat virksomhed af samme størrelse.

Af faggrupper arbejder AI-ingeniører, softwareudviklere, data engineers og løsningsarkitekter direkte i teknikken. Ved siden af dem sidder ofte en fagperson fra forretningen, som ved hvilke dokumenter der gælder, og en dataansvarlig eller DPO, som skal godkende hvad systemet må slå op i. Uden den fagperson bliver løsningen sjældent god, fordi ingen udvikler kan vurdere om et svar om et byggeteknisk krav er rigtigt.

Et særligt dansk mønster er ønsket om at holde materialet i huset eller i det mindste i EU. Derfor kører en del RAG-opsætninger på virksomhedens egne servere med åbne modeller som Llama, Mistral eller Qwen, kørt lokalt med værktøjer som Ollama eller vLLM, og med en vektordatabase som Qdrant, Chroma, pgvector eller OpenSearch ved siden af. Andre vælger en driftet platform som Azure AI Search, AWS Bedrock Knowledge Bases eller Google Vertex AI Search, hvor man til gengæld skal have styr på databehandleraftale og placering af data. Begge veje bruges, og valget handler oftere om jura og drift end om teknik.

Typiske opgaver for en RAG-specialist

Den hyppigste henvendelse handler ikke om at bygge noget nyt. Den lyder: "vi har lavet en pilot, den virkede fint på ti spørgsmål, og nu svarer den forkert". Arbejdet består så i at finde ud af, hvor i kæden viden går tabt.

Fejlsøgning af selve opslaget er kerneopgaven. Hentes de forkerte afsnit, hjælper det ikke at skifte sprogmodel. Specialisten ser på hvordan dokumenterne er delt op, om bidderne skærer midt i en tabel eller en paragraf, om der bruges ren betydningssøgning hvor der burde være hybrid søgning med både nøgleord og betydning, og om der mangler et ekstra sorteringstrin (reranking), der vurderer de fundne afsnit en gang til, før de sendes videre.

Dokumentbehandlingen fylder mere, end folk regner med. Scannede PDF'er uden tekstlag, tegninger, tabeller, regneark, gamle Word-filer og mailtråde skal læses ind på en måde, hvor indholdet holder sammen. Dubletter og forældede versioner skal luges ud eller markeres, så systemet ved hvilken version der gælder nu.

Dansk sprog er sin egen opgave. Mange embedding-modeller er trænet med hovedvægt på engelsk og rammer skævt på dansk fagsprog, sammensatte ord og forkortelser. Her afprøver specialisten flersprogede modeller mod virksomhedens eget materiale i stedet for at stole på en generel rangliste.

Adgangsstyring er en klassisk anledning til at hente hjælp udefra. Et RAG-system må kun vise den enkelte medarbejder det, vedkommende i forvejen har lov at se. Det kræver, at rettighederne fra SharePoint, filshares eller fagsystemet følger med ind i indekset og bruges ved hvert opslag. Personalesager og lønfiler, der pludselig dukker op i et svar, er en af de dyreste fejl i den her slags projekter.

Evaluering er den opgave, der adskiller en hobbyopsætning fra en driftsløsning. Specialisten bygger et testsæt af rigtige spørgsmål med kendte, korrekte svar og måler systematisk to ting: om det rigtige afsnit blev fundet, og om svaret faktisk har belæg i det fundne. Uden det testsæt kan ingen sige, om en ændring gjorde løsningen bedre eller værre.

Dertil kommer drift og økonomi: svartider, forbrug af tokens, caching, og hvordan indekset opdateres når et dokument rettes. Migreringer går typisk fra pilot til drift, fra ren vektorsøgning til hybrid søgning, eller fra en cloud-tjeneste til lokal drift på egne servere af hensyn til databeskyttelse.

Endelig er der dokumentationsdelen. Virksomheder hyrer hjælp til at beskrive hvor data ligger, hvad der logges, hvilket retsgrundlag der er for behandlingen, og hvordan løsningen forholder sig til AI-forordningen. Datatilsynet og Digitaliseringsstyrelsen driver en regulatorisk sandkasse for AI, hvor virksomheder og myndigheder kan få vejledning om GDPR og risikoklassifikation, før løsningen sættes i drift.

Hvordan lærer man RAG-systemer?

Der findes ingen officiel certificering i RAG. Feltet er ungt, og de fleste dygtige folk har lært det ved at bygge, måle og rette.

Grundlaget er to ting, der ligger før sprogmodellerne: almindelig informationssøgning og almindelig softwareudvikling. Forstår man hvorfor nøgleordssøgning virker godt til varenumre og dårligt til omskrevne spørgsmål, har man allerede fat i halvdelen. Python er det sprog, næsten alt materiale bruger.

Af skriftlige kilder er leverandørernes egen dokumentation den mest holdbare. Microsoft Learns beskrivelse af RAG i Azure AI Search gennemgår mønsteret grundigt, også for dem der ikke bruger Azure. LangChain og LlamaIndex har hver deres dokumentation med kørende eksempler, og Hugging Face har materiale om embedding-modeller og om hvordan man vurderer dem på sit eget sprog.

Af kurser er DeepLearning.AI's kursus om Retrieval Augmented Generation det mest anerkendte samlede forløb, og det dækker både arkitektur, drift og evaluering. Der findes tilsvarende forløb på Coursera og Udemy, men kvaliteten svinger meget, og et kursus kan ikke stå alene. I Danmark rådgiver Alexandra Instituttet som GTS-institut virksomheder om RAG-løsninger, herunder evaluering, og det kan være en vej ind for en virksomhed, der vil have hjælp og læring på samme tid.

Den praktiske vej er stadig den bedste: byg en lille løsning på jeres egne dokumenter, skriv tredive rigtige spørgsmål ned med det svar der burde komme, og mål hvor mange systemet rammer. Ret så én ting ad gangen. Det er den øvelse, der gør forskellen mellem en demo og noget, kolleger tør bruge.

Vær ærlig om tidshorisonten. At koble en model til en mappe med filer kan læres på en dag. At få et RAG-system til at svare pålideligt på virkeligt rodet virksomhedsmateriale er et håndværk, der bygges over måneder, og det kommer af at måle, ikke af at læse.