Oprydningsfælden: RAG fejler på data, ikke

Den typiske fejlslutning lyder sådan her: retrieval-laget giver dårlige svar, så vi finjusterer prompten, tilføjer et re-ranking trin, eller skifter embedding-model. Det er symptombehandling, og jeg har selv gjort det, før jeg lærte bedre. Når data først er lagt ind i et vektorrum, er det ekstremt dyrt og teknisk besværligt at rette op på strukturelle fejl i kildematerialet. Man ender med at bygge stadig mere avancerede lag af filtrering og re-ranking oven på et fundament af rod, i stedet for at fjerne roddet, før det når så langt.

Det skyldes en organisatorisk vane. Data engineering bliver ofte betragtet som en teknisk forudsætning, noget der bare skal klares hurtigt, så AI-teamet kan komme i gang med det spændende arbejde. Men i en RAG-arkitektur er datapipelinen ikke en forudsætning, den er selve produktet. Kvaliteten af svarene kan aldrig blive bedre end kvaliteten af det, der blev lagt ind.

Lad mig gøre det konkret. Jeg har arbejdet med en global virksomhed, der havde samlet interne dokumenter, produktblade og supportsvar over mange år, og de ville fodre en RAG-model med hele bunken på én gang. Uden hærdet dataindtagelse sker der tre ting samtidig. For det første kommer dubletter ind, hvor den samme information findes i tre forskellige versioner med tre forskellige formuleringer, og modellen ved ikke, hvilken den skal stole på. For det andet kommer forældede dokumenter ind side om side med aktuelle, uden nogen tidsstempling der fortæller modellen, hvilken version der gælder nu. For det tredje opstår der modstridende tilstande, hvor to kilder direkte siger noget forskelligt om samme emne, og retrieval-laget har ingen mekanisme til at afgøre, hvem der har ret.

Resultatet er ikke, at modellen hallucinerer i den forstand mange tror. Modellen gør faktisk sit arbejde korrekt, den finder og sammensætter det, den får stillet til rådighed. Problemet er, at det, den får stillet til rådighed, er inkonsistent. Man kan ikke bygge pålidelighed oven på et fundament, der allerede er selvmodsigende. Det er derfor pilotprojekter, der ser lovende ud i en kontrolleret demo med et lille, kurateret datasæt, ofte kollapser, når de rammer virksomhedens fulde, rodede datamængde. Jeg har set præcis det kollaps ske i drift, og det er aldrig modellens skyld.

Løsningen er ikke en bedre model. Det er en anden holdning til, hvad der overhovedet får lov at komme ind i systemet. Sådan kører jeg mine egne agenter hos Agent Enterprise: en zero-trust tilgang til dataindtagelse, hvor intet dokument, ingen tekststreng og ingen datakilde bliver godkendt til indeksering uden at have bestået en eksplicit valideringsproces først.

Det indebærer inline skemavalidering, hvor hvert dokument tjekkes mod en defineret struktur, før det overhovedet rører vektordatabasen. Det indebærer flerlags profilering, hvor systemet automatisk opdager dubletter, inkonsistente tidsstempler og modstridende påstande, og enten flagger dem til manuel gennemgang eller afviser dem automatisk efter faste regler. Og det indebærer en klar politik for, hvilken version af sandheden der vinder, når to kilder er uenige, i stedet for at overlade den afgørelse til en model, der gætter i det øjeblik, den genererer et svar.

Det lyder som meget arbejde, og det er det. Men det er arbejde, der kun skal gøres én gang ordentligt, mod at skulle laves om og om igen som brandslukning, hver gang produktionen afslører endnu et hul. Jeg foretrækker det kedelige forarbejde frem for en rollback klokken fire om natten.

En ofte overset konsekvens af oprydningsfælden er, at virksomheder ender med at bygge adgangskontrol og compliance-logik direkte ind i prompten eller i retrieval-forespørgslen. Det er skrøbeligt og svært at auditere. Hvis en medarbejder i økonomiafdelingen ikke må se HR-data, skal den regel håndhæves der, hvor data bliver indekseret og mærket, ikke forsøges filtreret fra ved hvert enkelt kald til modellen.

Når adgangsstyring og datamærkning er indbygget i selve pipelinen, kan man dokumentere præcis, hvilke data der er tilgængelige for hvem, og hvorfor. Det gør compliance til en sporbar, testbar egenskab ved systemet, i stedet for en løs aftale om, at modellen nok respekterer instrukserne i sin prompt. For danske virksomheder, der arbejder med GDPR-følsomme data eller brancheregulerede oplysninger, er den forskel ikke kosmetisk. Det er forskellen på et system, der kan bestå en revision, og et der ikke kan. Min egen regel er enkel: kan jeg ikke fremvise et spor over, hvad systemet gjorde, så er det ikke en medarbejder, men en risiko med god PR, og så ryger det ikke i drift.

Den dybere pointe er en omprioritering af, hvor arbejdet og ressourcerne i et RAG-projekt skal ligge. I stedet for at betragte data engineering som en forudgående, kedelig opgave, der klares hurtigt for at komme til det rigtige AI-arbejde, bør den betragtes som selve kontrolplanet for hele systemet. Det er her, kvalitet, konsistens og sikkerhed reelt bliver håndhævet.

De virksomheder, jeg har set lykkes med at få RAG-pilotprojekter i stabil drift, er typisk dem, der bruger mere tid på dataindtagelsen end på modelvalget. De vælger en kedeligere, men mere driftssikker model, kombineret med en hærdet pipeline, frem for den nyeste model kombineret med rå, urenset data. Det er ikke en overraskende konklusion for nogen, der har arbejdet med data i årevis, men det er en konklusion, mange AI-projekter stadig ikke handler efter. Næste gang et pilotprojekt ser ud til at fejle på grund af modellens svar, er det værd at stille spørgsmålet omvendt: er det modellen, eller er det det, den fik at arbejde med?