Retrieval-Augmented Generation (RAG)

RAG deler opgaven i to trin. Først finder et søgetrin de tekststykker, der er relevante for spørgsmålet. Derefter indsættes de i prompten, og modellen skal svare ud fra dem i stedet for ud fra det, der ligger i træningsdata.

Forskellen til generated knowledge er, hvor materialet kommer fra. Der beder du modellen om selv at nedskrive relevante fakta først, og de fakta stammer fra modellens vægte. I RAG kommer teksten udefra og kan versioneres, rettes og udskiftes, uden at modellen røres.

Forskellen til fine-tuning er, hvor viden opbevares. Fine-tuning skriver information ind i parametrene og kræver en ny træningskørsel ved hver opdatering. Med RAG ligger viden i et indeks, hvor et nyt dokument er tilgængeligt i samme øjeblik, det er indekseret.

Selve prompten er ofte triviel, som eksemplet ovenfor viser. Det svære arbejde sker før prompten bygges: chunking, indeksering, søgning og udvælgelse af de få passager, der faktisk skal med.

En sprogmodel forudsiger næste token ud fra hele sekvensen i context window. Når et tal eller et navn står ordret i prompten, kan attention-mekanismen trække direkte på den passage. Uden den skal svaret rekonstrueres fra statistiske spor i vægtene, hvor forkerte men sprogligt nærliggende varianter ligger tæt på det rigtige.

Det forklarer, hvorfor gevinsten er størst på præcise værdier. Beløb, datoer, paragrafnumre og produktkoder er netop den type indhold, hvor parametrisk hukommelse er upålidelig, fordi mange lignende strenge konkurrerer.

Retrieval-trinnet indsnævrer også selve opgaven. Spørgsmålet om resultatet i 2023 er flertydigt på tværs af tusind dokumenter, men entydigt når kun tre relevante afsnit er til stede. Færre konkurrerende kontekster giver en mere koncentreret sandsynlighedsfordeling over mulige fortsættelser.

RAG løser ikke ræsonnement. I eksemplet skal 45 minus 38 beregnes, og hvis fejlen ligger i regnestykket eller i definitionen af resultat, ændrer flere dokumenter ingenting. Hentning erstatter ikke chain-of-thought eller eksplicitte regneregler.

Spørgsmål, der kræver dækning af hele korpus, passer dårligt. Et søgetrin returnerer typisk de k bedste passager, så spørgsmål som hvor mange kontrakter der nævner en bestemt klausul, besvares på et udsnit og ser alligevel autoritativt ud.

Den farligste fejltilstand er stille retrieval-fejl. Henter søgningen de forkerte afsnit, produceres der stadig et flydende svar, ofte med kildehenvisning. Kildeangivelser er selv genereret tekst og kan pege på et dokument, der ikke understøtter påstanden.

Er dokumenterne modstridende eller forældede, flytter RAG blot problemet fra modellen til samlingen. Og er videnmængden lille og stabil nok til at stå i en systemprompt, er retrieval-infrastrukturen ren omkostning.

Store context windows har gjort aggressiv chunking mindre nødvendig. Med Gemini 3.1 Pro eller Claude Opus 5 kan du ofte indsætte hele rapporter i stedet for løsrevne afsnit, hvilket fjerner en klassisk fejlkilde, hvor et chunk klippes midt i en tabel eller mister sin overskrift.

Reasoning-modeller flytter også selve søgningen. Frem for én fast hentning før prompten kan GPT-5.6 Sol eller Claude Opus 5 kalde søgning som værktøj flere gange, læse resultatet og søge igen. RAG bliver da et værktøj i en løkke frem for et forudbestemt pipeline-trin.

Hentning forsvinder ikke af den grund. Omkostning, latenstid og korpusstørrelse gør det stadig urealistisk at sende alt med, og mindre modeller som GPT-5 nano og Gemini 3.7 Flash bliver mærkbart mere upræcise, når relevant tekst drukner i støj.