RAG
RAG og videnssystemer
Vi bygger RAG-systemer der lader sprogmodeller svare på baggrund af jeres egne dokumenter — med citater, kvalitets-evaluering og en arkitektur der kan vedligeholdes.
Retrieval-først, model bagefter
Sådan bygger vi RAG der overlever produktion
- Vector + keyword + re-ranker
- Hybrid
- Hvert svar peger tilbage til kilden
- Cite
- Permissions filtreres ved query-time
- ACL
- Kvalitets-pipeline kører ved hver ændring
- Eval
Sådan bygger vi RAG
Retrieval-først — ikke prompt-først.
RAG-systemer er den mest praktiske AI-arkitektur lige nu — det er der hvor sprogmodeller faktisk leverer på de løfter de gerne vil leve op til. Forudsætningen er at retrieval-laget gør sit arbejde: hvis modellen får dårlige dokumenter ind, får brugeren et selvsikkert, men forkert svar. De fleste RAG-systemer der ikke fungerer, fejler ikke i modellen — de fejler i hentningen. Det er der vi bruger vores tid.
Vi bygger RAG over jeres egne data: dokumentation, kontrakter, sager, supportartikler, intern wiki. Tekst chunkes intelligent (ikke bare på tegn-grænser), embeddes med en model passende til jeres sprog (vi har god erfaring med multilingvale modeller for dansk), og indekseres i en vector store — typisk pgvector hvis I allerede har Postgres, ellers Pinecone eller Qdrant. Retrieval kombineres med klassisk søgning (BM25) for at fange det semantiske indhold ikke nødvendigvis dækker.
Lige så vigtig som arkitekturen er evalueringen. Vi sætter en evaluations-pipeline op fra dag ét: en samling af spørgsmål med kendte gode svar, kørt regelmæssigt mod systemet, så I kan måle hvornår en ændring forbedrer eller forværrer kvaliteten. Uden den slags måling bliver RAG til en demo der nogle gange virker.
Hvad I får leveret
Et RAG-system der overlever produktion.
Hybrid retrieval, citater, adgangskontrol og en evaluerings-pipeline der måler kvalitet over tid.
Intelligent chunking og embedding
Vi chunker efter struktur — afsnit, sektioner, tabeller — ikke efter blinde tegn-grænser. Chunks får metadata (kilde, titel, dato, forfatter) så retrieval kan filtrere efter kontekst. Embeddings genereres med modeller der kan dansk og engelsk lige godt.
Hybrid retrieval (vector + keyword)
Vector search fanger semantisk lighed; BM25/keyword search fanger eksakte termer (produktnavne, paragraf-numre, fejlkoder). Vi kombinerer begge med en re-ranker så de bedste 5–10 chunks går videre til modellen.
Citater og kildehenvisninger
Modellen instrueres til altid at citere hvilket dokument og hvilket afsnit svaret kommer fra. Brugeren kan klikke sig tilbage til kilden og verificere — afgørende når svarene bruges i sager, support eller juridiske kontekster.
Vector store: pgvector, Pinecone eller Qdrant
pgvector hvis I allerede har Postgres (ingen ekstra system at drifte). Pinecone hvis I vil have en fuld managed service. Qdrant hvis I selv vil hoste og have rich filtering. Vi vælger ud fra jeres datavolumen og drifts-tolerance.
Indekserings-pipeline med versionering
Når dokumenter ændrer sig, re-indekseres kun det berørte indhold. Vi versionerer indekset så I kan teste en ny embedding-model på et sekundært indeks før I skifter — uden at tage systemet ned.
Evaluering, monitorering og kvalitetsmål
Et evalueringsdatasæt med kendte gode svar kørt i CI ved hver ændring i prompts, retriever eller model. Plus produktions-monitorering: tomme retrieves, lave confidence-scores og brugerklager logges så I kan finde kvalitets-huller før de bliver et mønster.
Inden I går i gang
Det her bør I overveje først.
RAG eller fine-tuning?
RAG er næsten altid det rigtige startpunkt. Det er hurtigere at bygge, lettere at opdatere når dokumenter ændrer sig, og giver verificerbare citater. Fine-tuning bliver først interessant når I har et stort, stabilt korpus af eksempler på god output-form — og selv da bruger man det typisk sammen med RAG, ikke i stedet for.
Datakvalitet er forudsætningen
Et RAG-system over rodet, modstridende eller forældet data bliver et selvsikkert lyver. Vi bruger gerne tid i discovery på at se på en stikprøve af jeres dokumenter — og hvis kvaliteten kræver oprydning, siger vi det før vi starter, ikke efter pilot-fasen.
Adgangskontrol pr. dokument
Hvis ikke alle brugere må se alle dokumenter, skal retrieval respektere det. Vi indekserer permissions sammen med dokumentet og filtrerer ved query-time — så modellen aldrig ser et dokument den anmodende bruger ikke selv må se. Det er ikke en eftertanke, det er et arkitektur-valg fra dag ét.
Sprog og dansk-specifikke modeller
De fleste embedding-modeller er trænet primært på engelsk. For dansk bruger vi multilingvale modeller (E5-multilingual, BGE-M3) der har vist gode resultater på skandinaviske sprog. Vi tester på jeres faktiske data i discovery — det er den eneste pålidelige måde at vide om en model er god nok.
FAQ
Det folk plejer at spørge om.
Hvor lang tid tager det at bygge et RAG-system?
En fokuseret prototype over et afgrænset korpus (1.000–10.000 dokumenter, ét sprog, én use-case) er typisk i drift på 4–6 uger. Et produktions-RAG med adgangskontrol, hybrid retrieval, evaluerings-pipeline og UI er typisk 8–14 uger. Vi anbefaler altid at starte med en prototype så I tidligt kan se om kvaliteten er der hvor den skal være.
Hvilken vector database skal vi vælge?
pgvector hvis I allerede har Postgres — det er den enkleste vej og skalerer fint til millioner af chunks. Pinecone eller Qdrant Cloud hvis I vil have managed service og høj skala. Selv-hostet Qdrant eller Weaviate hvis I har strikse data-residency-krav. Vi vælger sammen i discovery efter jeres datavolumen, drifts-team og compliance.
Kan I bruge OpenAI eller skal det være open source?
Begge dele virker. OpenAI (eller Azure OpenAI for EU-residency) giver state-of-the-art modeller og enkel drift. Open source via vLLM eller Bedrock giver mere kontrol og kan være billigere på høj volumen. Embeddings og generation kan være forskellige modeller — vi vælger pr. lag baseret på kvalitet og pris.
Hvordan ved vi om RAG-systemet er godt nok?
Vi bygger et evalueringsdatasæt sammen med jer i discovery: 50–200 spørgsmål med kendte gode svar fra en domæneekspert. Det datasæt køres mod systemet ved hver ændring og giver et målbart kvalitets-tal. Plus produktions-monitorering: tomme retrieves, lav confidence og bruger-feedback logges. Hvis tallene falder, ved vi det inden brugerne klager.
Hvad med GDPR og persondata i dokumenterne?
Vi indekserer ikke følsomme data uden eksplicit beslutning. Hvor det er nødvendigt, redakterer vi PII før embedding (navne, CPR, kontonumre erstattes med pladsholdere). Adgangskontrol sikrer at modellen kun ser dokumenter den anmodende bruger må se. Til særligt følsomme korpus kører vi modeller selv-hostet i EU.
Klar til at starte?
Lad os tage en uforpligtende snak.
Vi vender tilbage indenfor en arbejdsdag med konkret input — ikke et standardtilbud.