Beslutningsguide
Retrieval-Augmented Generation — RAG — betyder kort: find relevante stykker af jeres materiale, send dem med ind i prompten, og lad modellen svare ud fra det. Det er den dominerende måde at få et LLM til at tale om jeres produkter, politikker eller tickets uden at træne en ny model.
Det er også blevet en catch-all for ethvert AI-ønske. Resultatet er prototyper der hallucinerer høfligt på dårlige PDF'er, eller projekter der skulle have været bedre søgning og metadata. Vi bygger RAG-systemer i produktion — og vi siger nej når forudsætningerne mangler.
TL;DR
De vigtigste pointer
- RAG er rigtigt når svar skal baseres på jeres korpus, og korpuset kan chunkes, opdateres og citeres.
- Hvis problemet er "find den rigtige side", så start med søgning og information architecture — ikke et chat-UI.
- Datakvalitet og adgangskontrol afgør mere end modelvalget. Forkerte rettigheder i retrieval er et sikkerhedsproblem.
- Evaluering (træfsikre spørgsmål I kan score) er del af produktet — ikke en eftertanke.
- Agenter der "gør ting" er et andet produkt end RAG der "svarer med kilder". Bland dem ikke i v1 uden grund.
Hvad RAG faktisk løser
Et LLM ved ikke hvad der står i jeres handbook, jeres tickets eller jeres produktkatalog — medmindre I giver det konteksten. Finetuning kan lære stil og smalle opgaver, men er et tungt og langsomt svar på "svar ud fra dokument X der ændrede sig i går". RAG er bygget til netop det: frisk retrieval + generering.
Det typiske vindende use case er intern eller kundevendt Q&A over et afgrænset korpus: politikker, runbooks, produkt docs, kontrakt-skabeloner, support-artikler. Brugeren stiller et spørgsmål, systemet henter passager, modellen formulerer et svar og — vigtigt — kan pege på kilderne.
Det typiske tabende use case er "chat med hele virksomheden" uden ejerskab af dokumenterne, uden chunks der giver mening, og uden nogen der vil måle om svarene er forkerte. Så får I et demo-wow og et produktions-nej.
RAG vs. alternativerne
RAG
Hent relevant kontekst, generér svar — korpus kan opdateres løbende.
- God til Q&A over dokumenter og tickets
- Kilder kan vises til brugeren
- Nyt indhold indekseres uden gen-træning
- Kræver chunking, embeddings, retrieval-kvalitet
- Dårlig retrieval ⇒ selvsikkert forkerte svar
Andre veje
Søgning, finetuning, structured extraction — eller bare et bedre UI på dataene.
- Klassisk søgning: når brugeren skal finde, ikke få et essay
- Finetuning: stil, klassifikation, smalle formater — ikke daglige doc-updates
- Structured LLM-kald: når output er JSON til et system, ikke prosa til et menneske
- Agenter/værktøjskald: når der skal handles (opret ticket, hent ordre) — oven på pålidelig retrieval
- Ingen AI: når en filtrérbar tabel eller et godt FAQ-træ løser opgaven
Hvornår er RAG det rigtige?
Venstre er situationen — højre er det vi typisk anbefaler.
Jeres situation
Support eller medarbejdere stiller de samme doc-spørgsmål igen og igen
Vores anbefaling
RAG over et kurateret korpus med synlige kilder. Start med ét domæne (fx HR eller produkt).
Jeres situation
Brugeren skal finde en side eller fil, ikke have et genereret svar
Vores anbefaling
Forbedr søgning, metadata og IA først. Chat kan komme bagefter.
Jeres situation
I vil have AI til at oprette ordrer, ændre data eller køre workflows
Vores anbefaling
Agent med værktøjskald og stramme guards — RAG alene er det forkerte abstraktion.
Jeres situation
Dokumenterne er rodede PDF'er uden ejer, og ingen vil rydde op
Vores anbefaling
Stop. Invester i indhold og ejerskab før embeddings. Ellers køber I hallucinationer.
Jeres situation
Data er følsomt og rollebaseret (kun egen afdeling, egne kunder)
Vores anbefaling
RAG med retrieval der respekterer samme ACL som kildesystemet — ellers byg ikke.
Jeres situation
I er i tvivl om værdien
Vores anbefaling
Lav et evaluerings-sæt på 30–50 rigtige spørgsmål og en golden answer. Prototypér retrieval før I bygger chat-UI.
Før I bygger et RAG-system
Hvis de her punkter ikke er på plads, er projektet ikke et modelproblem — det er et data- og procesproblem.
- Der findes et afgrænset korpus med en navngiven ejer (ikke "hele Drive").
- Vi kan liste 30 spørgsmål brugere faktisk stiller, med acceptable svar.
- Adgangsregler er kendte: hvem må se hvilke dokumenter.
- Vi har aftalt hvordan nyt indhold kommer ind (pipeline, ikke manuel upload ad hoc for evigt).
- Vi ved hvordan vi måler fejl: forkerte svar, manglende retrieval, forældet kilde.
- Vi har besluttet om v1 er intern (lavere risiko) eller kundevendt (højere krav til cite og tone).
Produktion er mere end embeddings
I produktion skal I genindeksere når dokumenter ændrer sig, håndtere sletning (GDPR), versionere prompts, rate-limite kald, og logge både retrieval og svar til senere analyse. "Vi smed PDF'erne i en vector database" er en spike — ikke et system.
Modelvalg betyder noget for latency og omkostning, men skifter sjældent et dårligt korpus til et godt. Omvendt kan et stramt korpus og gode citations få en mindre model til at føles mere pålidelig end en større model på rodede data.
Hvis I også har brug for handlinger — opret sag, hent ordrestatus, book møde — så er det et agent-lag med værktøjer, ikke mere RAG. Retrieval kan stadig fodre agenten med kontekst; men rettigheder, side effects og bekræftelser hører hjemme i værktøjslaget.
Spørgsmål vi får igen og igen
Er RAG ikke forældet nu hvor modeller har længere context windows?
Længere context hjælper, men erstatter ikke retrieval når korpuset er stort, ændrer sig ofte, eller er rettighedsstyret. At proppe "det hele" ind i prompten skalerer dårligt på pris, latency og støj. RAG (eller hybrid search + rerank) forbliver det pragmatiske valg for de fleste virksomheds-korpusser.
Skal vi fine-tune i stedet?
Finetuning er stærkt til format, klassifikation og stil. Det er et tungt svar på dokument-Q&A der ændrer sig. Mange teams får mest ud af god RAG først, og finetuner kun hvis et smalt trin stadig fejler efter retrieval er i orden.
Hvilken vector database skal vi bruge?
Den I kan drifte. Postgres med pgvector er et stærkt default når I allerede kører Postgres. Dedikerede vektordatabaser giver mening ved meget store korpusser eller særlige query-mønstre. Valget er sekundært i forhold til chunking, metadata og evaluering.
Hvordan undgår vi at modellen opdigter svar?
I fjerner det ikke helt — I styrer det. Kræv citations, straff manglende retrieval ("jeg fandt ikke noget" er et gyldigt svar), hold temperaturen nede, og mål hallucinerede claims mod kilderne i jeres eval-sæt. UX der viser kilder gør det også lettere for brugeren at stole rigtigt.
Kan vi starte med ChatGPT / custom GPT på vores filer?
Som spike til at lære spørgsmålene: ja. Som produktionssystem for følsomme eller kunde-vendte data: kun med åbne øjne for dataflows, rettigheder og manglende kontrol. Når I har bevis for værdi, flyt til et setup I ejer — med logging, ACL og en indeks-pipeline.
Overvejer I RAG på jeres data?
Lad os sortere hype fra et projekt der kan gå i drift.
Vi hjælper med at afgøre om svaret er RAG, bedre søgning, et agent-lag — eller at vente indtil korpuset er klar.