RAG-arkitektur for danske virksomheder: hvornår, hvorfor og de 5 typiske fælder

Hver fjerde dag står en ny kunde foran os og siger "vi vil have en RAG-chatbot på vores dokumenter". Halvdelen af dem har allerede prøvet og fejlet. Det er ikke fordi RAG ikke virker — det er fordi de fleste implementerer det forkert. Her er hvad der reelt skiller succes fra fiasko.

Hvad RAG faktisk er — uden buzzwords

Retrieval-Augmented Generation kombinerer to ting: en AI-model (typisk Claude, GPT eller Gemini) og en søgning i jeres egne dokumenter. I stedet for at lade AI'en svare ud fra sin generelle viden, giver vi den relevante kontekst fra jeres data først.

Et typisk RAG-flow:

1. Brugeren stiller et spørgsmål
2. Vi laver en søgning i jeres dokumenter (oftest via vector search)
3. Vi finder de 3-10 mest relevante uddrag
4. Vi sender uddragene + brugerens spørgsmål til AI-modellen
5. Modellen svarer baseret på den specifikke kontekst

Resultatet: AI'en kan besvare spørgsmål om jeres specifikke produkter, kontrakter eller processer — uden at hallucinere generelle svar.

Hvornår RAG giver mening

• Kundeservice hvor svar findes i jeres dokumentation, FAQ eller produktbeskrivelser
• Intern viden der ligger spredt i Confluence, Notion, Google Drive
• Juridisk eller compliance med store kontrakt- eller regelsæt
• Teknisk support over brugermanualer og produktdata

Hvornår RAG IKKE giver mening

• Når svar kræver beregninger eller logik (brug agent + tools i stedet)
• Når data ændrer sig minut-for-minut (RAG er optimeret til statisk-ish data)
• Når brugerens spørgsmål typisk er meget abstrakte (svært at retrieve relevant kontekst)
• Når I kun har 20-50 dokumenter total — så bare put dem direkte i prompt'en

De 5 fælder vi ser igen og igen

1. Forkert chunking

Når I splitter dokumenter op i chunks, taber I ofte sammenhæng. En FAQ-side delt på "100 ord ad gangen" kan splitte spørgsmål fra svar. Sigte efter semantisk chunking — split på naturlige grænser (afsnit, sektioner, h-tags) og overvej overlap på 10-20%.

2. Generisk embedding-model

Mange bruger OpenAI's ada-002 til alt. Til dansk kontekst er text-embedding-3-large eller specifikke multilingual modeller markant bedre. Forskellen kan være 15-30% bedre retrieval på samme data.

3. Ingen re-ranking

Vector search returnerer "ligner-noget"-resultater. Tilføj en re-ranking-fase (fx Cohere Rerank eller en mindre LLM) der vurderer "er det her reelt relevant for spørgsmålet?". Det fanger irrelevante top-5-resultater.

4. Manglende citations

Hvis AI'en svarer "iflg. afsnit 4.2 i jeres kontrakt..." og linker til kilden, bygges tillid. Hvis svaret bare er en flyderum-tekst, har brugeren ingen måde at verificere. Vi tvinger altid citations i system-prompten.

5. Ingen evaluation

De fleste sætter RAG i produktion uden at måle hvor ofte den giver forkerte svar. Byg et eval-set af 50-100 typiske spørgsmål med forventede svar. Kør evals månedligt.

Vores anbefalede stack i 2026

• Vector DB: Supabase + pgvector for SMV-projekter. Pinecone eller Weaviate hvis enterprise-skala
• Embeddings: OpenAI text-embedding-3-large eller Cohere embed-multilingual-v3
• LLM: Claude Sonnet 4.6 for kvalitet, Haiku 4 for volumen
• Re-rank: Cohere Rerank 3 eller en lille Claude Haiku-call
• Orkestrering: Direkte API-kald eller LangChain hvis komplekst

Hvad det koster i praksis

For en typisk SMV med 5.000 dokumenter og 500 forespørgsler/dag:

• Vector DB (Supabase): inkl. i deres pro-plan ~ 250 kr/md
• Embeddings (engangs): ~ 50 kr
• LLM-kald: ~ 1.500-3.000 kr/md (Claude Sonnet)
• Total: 2.000-3.500 kr/md i kørselsomkostninger

Implementering: 3-6 uger fra start til produktion afhængigt af kompleksitet.