Hvad RAG faktisk er — og hvorfor det er bedre end fine-tuning
Retrieval-Augmented Generation (RAG) er en arkitektur hvor man kombinerer en LLM med en ekstern videnbank. Konceptet er simpelt: før modellen svarer, søger systemet i en database efter relevant indhold og sender det med i prompten som kontekst.
Fordelen over fine-tuning: du kan opdatere viden uden at retræne noget. Tilføj et nyt produkt, og det er tilgængeligt i botten samme dag. Modellens grund-kapaciteter bliver heller ikke degraderet på opgaver uden for dit domæne.
Ulempen: din infrastruktur bliver mere kompleks. Du skal vedligeholde en vector-database, embedding-pipeline, og søgning. Det er værd at vide før du starter.
Arkitektur — de 6 lag
Et komplet RAG-system består typisk af disse lag:
Lag 1 — Datakilde: dokumenter, FAQ, manualer, produkt-data. Kan være statisk eller dynamisk opdateret.
Lag 2 — Ingestion pipeline: læser dokumenter, splitter dem i chunks, og embedder hver chunk til en vektor. Kører typisk som batch-job eller ved upload.
Lag 3 — Vector database: gemmer embeddings + metadata. Pinecone, Qdrant, Weaviate, pgvector er alle valide.
Lag 4 — Retrieval: når en query kommer ind, embeddes den, og de top-N nærmeste chunks hentes. Ofte kombineret med keyword-search (BM25) for hybrid.
Lag 5 — Reranking: en mindre, præcis model rangerer de top-20 retrieved chunks og giver de bedste 3-5 tilbage. Markant kvalitetsløft.
Lag 6 — Generation: LLM'en får query + retrieved chunks + system prompt og genererer svar.
Valg af komponenter — vores anbefalinger
Embedding-model: OpenAI text-embedding-3-small for de fleste use cases (god kvalitet, billig). For dansk-tungt indhold er Cohere embed-multilingual-v3 ofte bedre. For full open-source er BGE-large eller nomic-embed-text valide valg.
Vector database: hvis I allerede har PostgreSQL, brug pgvector — det holder hele stacken simpel. For større skala (>5M vektorer eller meget høj query-volume): Qdrant self-hostet eller Pinecone managed.
LLM til generation: Gemini Flash eller Claude Haiku for høj-volume use cases. Claude Sonnet eller GPT-5 til komplekse domæner hvor præcision betyder mere end pris.
Reranker: Cohere Rerank eller BGE-reranker — begge tilføjer ~100-300ms latency men forbedrer kvalitet markant.
Chunking — den ofte underprioriterede nøgle
Chunking-strategien er ofte forskellen mellem et RAG-system der virker og et der ikke gør. Tre principper:
Respekter naturlige grænser. Split på afsnit, sektioner, eller logiske enheder — ikke hård word-cap der skærer midt i sætninger. Brug parsere der forstår jeres format (markdown, HTML, PDF med struktur).
Brug overlap. 10-20% overlap mellem nabo-chunks sikrer at en sætning der spænder over to chunks stadig fanger kontekst i begge.
Tilpas chunk-størrelse til indholdstype. Kode: små chunks (50-200 tokens) fordi semantik er tæt. Prosa: medium chunks (300-600 tokens). Tabeller og strukturerede data: hold sammenhørende data i samme chunk.
Eksperimenter. Det vi har set: en god chunking-strategi kan løfte answer accuracy 15-30 procentpoint over en naiv tilgang. Det er virkelig værd at iterere.
Hybrid search og reranking
Ren semantic search misser ofte præcise tekniske termer, produktnumre, eller jura-paragraffer. Keyword search misser parafraserede spørgsmål. Løsningen er hybrid: kør begge, kombiner scores.
For BM25 (keyword) brug Elasticsearch, OpenSearch, eller Tantivy. For pgvector-brugere kan PostgreSQL's built-in full-text search bruges sammen.
Reranking er det andet store kvalitetsløft. Konceptet: din vector search returnerer top-20 kandidater (billigt). En reranker — en mindre cross-encoder model — vurderer hver kandidat mere præcist og returnerer top-5 (lidt dyrere). LLM'en får kun top-5.
Den rate-limit-tunge del af pipeline'n er kun rerank + LLM-kald, så latency er stadig under 1 sek for hele pipeline'n.
Evaluation — uden måling ingen forbedring
De fleste team'er bygger RAG og deployer det uden klare metrics. Det er en fælde. Du skal kunne svare på: "har min ændring til chunking forbedret eller forværret systemet?"
Byg en eval-set: 50-200 reelle spørgsmål med kendte rigtige svar. Kør dem mod systemet og mål:
Retrieval accuracy: blev de rigtige chunks hentet? Brug ground-truth-mapping.
Generation accuracy: er svaret faktuelt korrekt? Brug LLM-as-judge til at score (en separat LLM vurderer hvert svar mod ground truth).
Latency p50/p95: hvor hurtigt svarer systemet.
Kør evals automatisk på hver ændring. Det er den eneste måde at vide om dit nye chunking-trick faktisk virker eller blot er placebo.
Almindelige fælder
1. For store chunks. Modellen bliver overvældet med irrelevant kontekst og misser det vigtige.
2. Ingen metadata-filtering. Hvis dine chunks ikke har metadata (dato, kategori, kilde), kan du ikke filtrere — fx "find kun chunks fra HR-policies", hvilket ofte er nødvendigt.
3. Stale data. Glem ikke at re-embedde når kilderne ændres. Byg en pipeline der enten gør det automatisk eller eskalerer.
4. Embedding-model lock-in. Skift af embedding-model kræver re-embed af alle dokumenter. Vælg klogt fra start, eller byg pipeline'n så det er overkommeligt.
5. Manglende fallback. Hvad sker der hvis retrieval ikke finder noget relevant? Modellen skal vide den ikke skal hallucinere, men sige "jeg har ikke information om det her".