Hvordan opsættes lokal RAG?

Lokal RAG opsættes ved at køre sprogmodel, embeddings, dokumentindeks og retrieval i et kontrolleret lokalt miljø. Målet er at lade en AI-model svare ud fra egne dokumenter uden at sende hele vidensgrundlaget til en ekstern tjeneste.

Hvad betyder lokal RAG i praksis?

RAG står for retrieval-augmented generation. I den oprindelige forskningsbeskrivelse kombineres en generativ sprogmodel med en ekstern, søgbar hukommelse, så modellen kan trække relevant viden ind, når et svar skal dannes. I en lokal opsætning ligger denne søgning og ofte også modelkørslen på egne maskiner eller i et kontrolleret internt miljø.

Det adskiller sig fra almindelig chat med en stor sprogmodel, fordi modellen ikke kun svarer ud fra sin træning. Den får først udvalgte tekstpassager fra dine dokumenter, og svaret skal bygge på den fundne kontekst. Det er beslægtet med grounding af AI-modeller, hvor formålet er at gøre svaret mere forankret i kontrollerbare kilder.

Lokal RAG er ikke det samme som fuld offline-sikkerhed. Hvis du bruger en cloudmodel, et eksternt embedding-API eller en hostet vektordatabase, forlader dele af databehandlingen stadig det lokale miljø. Første afklaring er derfor, hvad der faktisk skal være lokalt: dokumenter, indeks, embeddings, sprogmodel, brugerlogning eller hele kæden.

Hvilke komponenter skal være på plads?

En brugbar lokal RAG-løsning består normalt af fem tekniske lag. Først skal dokumenterne indlæses fra mapper, PDF-filer, tekstfiler, intraneteksport eller databaser. Derefter skal de opdeles i mindre tekststykker, så søgningen kan finde præcise passager i stedet for hele dokumenter.

Næste lag er embeddings. En embeddingmodel omdanner tekststykker til talvektorer, som kan sammenlignes matematisk. Hvis du vil have en kort begrebsforklaring, er AI embeddings det centrale mellemled mellem rå tekst og semantisk søgning.

Det fjerde lag er en vektorbaseret søgestruktur, ofte kaldet en vector store eller vektordatabase. Det femte lag er selve svarlaget, hvor en lokal eller kontrolleret sprogmodel modtager brugerens spørgsmål og de hentede tekststykker. En orkestreringsdel binder lagene sammen, så hvert spørgsmål bliver til søgning, kontekstvalg og svar.

Hvordan vælger du lokal model og embeddingmodel?

Modelvalget bør starte med opgaven, ikke med den største model. En intern vidensassistent, der skal svare kort på procedurer, kan ofte køre på en mindre model end en løsning, der skal skrive lange tekniske forklaringer. Lokal modelkørsel kræver desuden nok RAM, VRAM eller CPU-tid til, at svartiderne bliver acceptable.

Værktøjer som Ollama dokumenterer lokal modelkørsel på macOS, Windows og Linux samt et lokalt API på maskinen. Det gør teknikken tilgængelig, men modellen er kun ét led. Den skal kobles sammen med en embeddingmodel, der passer til sprog, fagområde og dokumenttype.

Ollamas dokumentation for embeddings beskriver, at tekst bliver til numeriske vektorer til semantisk søgning, retrieval og RAG. Den samme embeddingmodel bør bruges, når du både opbygger indekset og søger i det. Hvis du skifter embeddingmodel, skal indekset normalt bygges igen, ellers sammenligner du nye forespørgsler med gamle vektorer fra et andet rum.

For danske dokumenter bør du teste med danske spørgsmål og danske kildetekster. En model, der virker fint på engelske tekniske dokumenter, kan hente svagere passager i kontrakter, instrukser eller undervisningsmateriale på dansk. Sprog, forkortelser, tabeller og fagspecifikke termer betyder mere for kvaliteten end modelnavnet alene.

Hvordan forberedes dokumenterne til søgning?

Dokumentforberedelsen afgør ofte mere end selve sprogmodellen. RAG kan ikke hente viden, som ikke er i indekset, og den kan heller ikke rette op på kildedata, der er forældede, duplikerede eller uklart strukturerede. Start derfor med et afgrænset datasæt, hvor du kender dokumentejer, opdateringsrytme og adgangsniveau.

PDF-filer, eksport fra vidensbaser og tekstudtræk fra intranet kræver typisk rensning. Sidehoveder, menuer, gentagne fodnoter og automatisk genererede navigationstekster kan forstyrre søgningen, fordi de får samme vægt som indholdet. Hvis dokumenter indeholder tabeller, bør du kontrollere, om tekstudtrækket bevarer relationen mellem kolonner og rækker.

Chunking er næste beslutning. For korte chunks kan miste den kontekst, som forklarer en regel. For lange chunks kan gøre retrieval upræcis, fordi ét tekststykke handler om flere emner. En praktisk start er at teste flere chunk-størrelser med 20-40 spørgsmål, hvor du på forhånd ved, hvilke dokumentafsnit der burde blive fundet.

• Brug metadata som dokumenttitel, dato, afdeling og adgangsniveau, så søgningen kan filtreres.
• Fjern uaktuelle versioner, eller markér dem tydeligt, så retrieval ikke blander gamle og nye regler.
• Gem kildehenvisninger på chunk-niveau, så brugeren kan se, hvor svaret kommer fra.

Hvordan oprettes en lokal vektordatabase?

En vektordatabase lagrer tekststykkernes embeddings sammen med metadata og kildeoplysninger. I en simpel prototype kan den være filbaseret eller køre i hukommelsen. I en mere stabil løsning bør den have vedvarende lagring, adgangskontrol, backup og en klar plan for genopbygning af indeks.

LangChains RAG-dokumentation viser blandt andet lokale eller procesnære varianter med Chroma, Milvus og Qdrant. Det centrale valg er ikke kun værktøjsnavnet, men om databasen kan håndtere mængden af dokumenter, opdateringsfrekvensen, adgangsreglerne og de svartider, som brugerne forventer.

Hvis emnet er nyt, kan en begrebsartikel om vektordatabaser hjælpe med at skelne mellem almindelige databaser, fuldtekstsøgning og semantisk søgning. RAG kan også kombinere teknikker, hvor keyword-søgning og vektorsøgning bruges sammen, hvis dokumenterne har mange koder, navne eller præcise betegnelser.

En lokal database bør versioneres sammen med dokumentgrundlaget. Når dokumenter opdateres, bør du kunne se, hvilket indeks der ligger bag et bestemt svar. Det er især relevant i organisationer, hvor procedurer, politikker eller tekniske vejledninger ændres løbende.

Hvordan forbindes retrieval og svarmodel?

Forbindelsen mellem retrieval og svarmodel er den del, brugeren oplever som selve AI-systemet. Når brugeren stiller et spørgsmål, skal systemet omsætte spørgsmålet til en søgning, hente relevante tekststykker, sortere eller genrangere dem og give sprogmodellen en begrænset kontekst at svare ud fra.

LangChain beskriver RAG som to hovedprocesser: indeksering og retrieval med generation ved kørselstid. LlamaIndex beskriver tilsvarende trin som loading, indexing, storing, querying og evaluation. Begge beskrivelser peger på samme praktiske pointe: RAG bør bygges som en kæde med målbare mellemtrin, ikke som én uigennemsigtig modelkald.

En god kæde kan returnere kilder, sige fra ved manglende grundlag og undgå at blande hentede fakta med uunderbyggede formuleringer. Brugeren bør kunne se, om svaret bygger på ét dokument, flere dokumenter eller ingen brugbare fund. Det er en praktisk kvalitetsgrænse, ikke kun en teknisk detalje.

Lokale systemer bør også styre, hvor meget hentet tekst modellen må få. For lidt kontekst giver tynde svar. For meget kontekst kan gøre svaret langsommere og øge risikoen for, at modellen vælger en mindre relevant passage. Start med få, tydelige tekststykker og udvid først, når testspørgsmål viser behovet.

Hvordan testes kvaliteten før brug?

Kvalitetstest bør ske før systemet får rigtige brugere. Lav et testsæt med realistiske spørgsmål, forventede kilder og kendte afvisninger. Et godt testsæt indeholder både lette opslagsspørgsmål, sammensatte spørgsmål, spørgsmål med forældede dokumenter og spørgsmål, hvor svaret ikke findes i datagrundlaget.

Du bør teste mindst tre ting hver for sig. Først om retrieval finder de rigtige tekststykker. Dernæst om modellen svarer loyalt ud fra de fundne kilder. Til sidst om svaret er brugbart for en læser, der ikke allerede kender dokumenterne. Hvis svaret er forkert, skal du kunne se, om fejlen ligger i dokumentudtræk, chunking, embeddings, søgning eller formulering.

En enkel evalueringsproces kan se sådan ud:

1. Skriv 20-40 realistiske spørgsmål fra brugernes arbejdsopgaver.
2. Angiv hvilke dokumenter eller afsnit der bør være relevante for hvert spørgsmål.
3. Kør spørgsmålene gennem systemet og gem hentede tekststykker, svar og kildehenvisninger.
4. Marker fejltyper: forkert kilde, manglende kilde, forkert konklusion, uklart svar eller korrekt afvisning.
5. Ret først datagrundlag og retrieval, før du skifter sprogmodel.

Hvilke data- og sikkerhedsforhold skal afklares?

Lokal RAG kan give bedre kontrol over data, men den fjerner ikke sikkerhedsarbejdet. Dokumenterne kan indeholde personoplysninger, forretningshemmeligheder eller interne beslutninger, som ikke alle brugere må se. Hvis en bruger kan stille spørgsmål til hele indekset, kan systemet indirekte afsløre indhold, som brugeren ikke burde have adgang til.

Adgangsstyring bør derfor ligge både før og under retrieval. Det er ikke nok, at dokumentmappen er beskyttet på filniveau, hvis vektordatabasen senere søger på tværs af alle chunks uden brugerfilter. Metadata om rettigheder, afdeling og dokumenttype bør bruges aktivt, så hver bruger kun søger i det tilladte grundlag.

OWASP beskriver blandt andet risici som manipulerede input, usikker håndtering af modeloutput, følsom informationslækage og for stor autonomi i LLM-applikationer. For RAG betyder det, at hentede dokumenter skal behandles som data, ikke som instruktioner. Eksterne eller brugeruploadede dokumenter bør ikke kunne styre systemets regler.

• Log kun det nødvendige, og undgå at gemme følsomme spørgsmål længere end formålet kræver.
• Skeln mellem dokumenter, brugere og systemregler i hele kæden.
• Test om systemet kan lokkes til at afsløre kilder uden for brugerens adgang.
• Begræns eventuelle handlinger, så RAG-systemet ikke automatisk ændrer data uden særskilt kontrol.

Hvornår er lokal RAG bedre end cloudbaseret RAG?

Lokal RAG giver mest mening, når data ikke bør sendes til eksterne API’er, når dokumentgrundlaget skal holdes tæt på eksisterende systemer, eller når organisationen vil kunne inspicere hele kæden. Den kan også være relevant i undervisning, udvikling og prototyper, hvor man vil forstå mekanikken uden at være bundet til én cloudleverandør.

Cloudbaseret RAG kan til gengæld give lettere skalering, stærkere driftsværktøjer og adgang til store modeller uden lokal hardware. Valget handler derfor om kontrol, kapacitet, compliance, økonomi og vedligeholdelse. Lokal drift er ikke automatisk billigere, hvis hardware, opdateringer, overvågning og fejlsøgning bliver omfattende.

For mindre teams kan en hybrid løsning være mere realistisk. Dokumenter og vektordatabase kan ligge lokalt, mens en ekstern model bruges til svar. Det er dog kun delvist lokal RAG, fordi spørgsmål og hentede tekststykker sendes ud af miljøet. Den skelnen bør være tydelig, før løsningen beskrives som lokal.

Hvilke fejl opstår typisk i en lokal opsætning?

Den mest almindelige fejl er at fokusere på modelnavnet, før datagrundlaget er ryddet op. En stærk sprogmodel kan stadig svare dårligt, hvis indekset er fyldt med dubletter, gamle versioner eller tekstudtræk uden struktur. Den næstmest almindelige fejl er at teste med for få spørgsmål, så systemet ser stabilt ud i en demo, men fejler i almindelig brug.

En anden fejl er at blande dokumenter med forskelligt adgangsniveau i samme indeks uden filtrering. Det kan gøre den tekniske prototype hurtig, men senere svær at gøre sikker. Hvis rettigheder ikke indgår fra begyndelsen, skal store dele af kæden ofte bygges om.

Der opstår også fejl, når chunks ikke har kildehenvisninger. Uden dokumenttitel, side, dato eller afsnits-ID kan brugeren ikke kontrollere svaret. RAG bør give et bedre grundlag for efterprøvning end almindelig chat, men det kræver, at kildeoplysninger bevares hele vejen fra dokumentudtræk til svar.

Hvordan kan opsætningen vedligeholdes over tid?

RAG er ikke færdigt, når første indeks er bygget. Dokumenter ændrer sig, brugere stiller nye spørgsmål, og modeller eller embeddingmodeller bliver udskiftet. Vedligeholdelsen bør derfor have faste rutiner for opdatering, genindeksering, test og tilbagerulning.

Når nye dokumenter tilføjes, bør systemet kunne skelne mellem fuld genopbygning og inkrementel opdatering. Fuld genopbygning er ofte enklere og renere i små datasæt. Inkrementel opdatering kan være nødvendig i større systemer, men kræver bedre kontrol med sletninger, ændringer og versioner.

Brugerfeedback bør kategoriseres. Et dårligt svar kan skyldes manglende dokument, forkert retrieval, tvetydigt spørgsmål, svag modelinstruktion eller en bruger, der forventer rådgivning uden kildedækning. Hvis alle fejl bare registreres som modelproblemer, bliver løsningen dyrere uden nødvendigvis at blive bedre.

Hvordan ser en realistisk startproces ud?

En realistisk startproces er lille, målbar og afgrænset. Vælg ét dokumentområde, eksempelvis interne vejledninger, tekniske produktnoter eller undervisningsmateriale. Definér, hvem der må bruge systemet, hvilke spørgsmål det skal kunne besvare, og hvilke spørgsmål det skal afvise.

Dernæst bygger du en minimal kæde: dokumentudtræk, chunking, lokal embeddingmodel, lokal vektordatabase, lokal eller kontrolleret svarmodel og kildevisning. Først når den kæde virker på kendte testspørgsmål, bør du udvide datamængden eller give adgang til flere brugere.

Hvis du vil arbejde videre med den lokale side af teknikken, hænger emnet tæt sammen med lokal AI. Lokal RAG er en praktisk arkitektur oven på lokal AI, men den kræver sit eget arbejde med dokumentkvalitet, retrieval, sikkerhed og evaluering.

Hvilke kilder ligger til grund?

Artiklen bygger på den oprindelige RAG-beskrivelse i Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, praktiske pipelinebeskrivelser i LangChains RAG-dokumentation og LlamaIndex’ introduktion til RAG. Lokale embeddings er kontrolleret mod Ollamas embedding-dokumentation, og sikkerhedsforbehold er holdt op mod OWASP Top 10 for LLM Applications.