Du bygger et RAG-system. Det virker. Svarene er præcise, brugerne er tilfredse, og du ruller ud til flere afdelinger. Så vokser dokumentbasen fra tusind til hundrede tusind sider, og pludselig begynder systemet at svare forkert - uden at nogen opdager det. Modellen lyder lige så selvsikker som før. Den citerer stadig kilder. Men kilderne er forkerte.
Det er ikke en hypotetisk situation. Det er det mønster der rammer 40-60 procent af alle RAG-implementeringer før de når produktion. Og problemet er næsten aldrig sprogmodellen. Det er retrieval.
Når nearest neighbor svigter
Nearest neighbor recall - den metrik der afgør om dit system overhovedet finder de rigtige dokumenter - falder fra 0,95 til 0,71 når man går fra 10.000 til 100 millioner dokumenter. Det er ikke en lille forringelse. Det betyder at systemet overser næsten en tredjedel af de relevante resultater.
EyeLevel.ai har dokumenteret at ren vektorsøgning taber 12 procent præcision allerede ved 100.000 sider. Præcisionstabet starter ved så få som 10.000 sider. Og uden korrekt sharding rammer vektordatabaser en mur ved omkring 50 millioner vektorer.
Det er det lumske ved problemet. Systemet fejler ikke med en fejlmeddelelse. Det returnerer næstbedste resultater, og sprogmodellen bygger troværdige svar oven på dem. For brugeren ser alt normalt ud. For virksomheden hober der sig stille og roligt fejl op i beslutningsgrundlaget.
Fire steder hvor RAG-systemer fejler
Der er fire typiske fejlpunkter når RAG-systemer skaleres. De optræder uafhængigt af hinanden, men i praksis rammer de fleste systemer mindst to af dem samtidig.
- For smal kandidatgenerering. Systemet henter top-10 resultater fra en enkelt retrieval-metode og sender dem direkte til modellen. Med en lille dokumentbase rammer man ofte rigtigt. Med en stor base er chancen for at de 10 bedste resultater faktisk er de rigtige langt lavere
- Fragmenteret retrieval. Søgningen er spredt over flere services - en vektordatabase her, en keyword-søgning der, en metadata-filtrering et tredje sted. Svartiden stiger, og resultater fra forskellige kilder er svære at rangere ensartet
- Dyr reranking uden forudgående filtrering. Cross-encoder reranking er præcis men langsom. Hvis den køres på tusindvis af kandidater i stedet for et filtreret udsnit, eksploderer svartiden
- Prompt engineering som plaster. Når retrieval-kvaliteten falder, forsøger teams at kompensere med bedre prompts. Det virker til en vis grænse, men det løser ikke at modellen aldrig ser de rigtige dokumenter
Arkitekturen der faktisk skalerer
Løsningen er ikke en enkelt teknologi. Det er en pipeline med flere trin, hvor hvert trin balancerer præcision mod hastighed. Princippet er simpelt: start bredt, filtrer hurtigt, ranker dybt, og send kun det bedste til modellen.
Første trin er bred kandidatgenerering. Hybrid retrieval - semantisk søgning kombineret med keyword-baseret BM25 - henter en stor kandidatpulje, typisk top-1000. At kombinere BM25 og vektorsøgning giver 20-30 procent bedre recall end nogen af metoderne alene. GitHub valgte faktisk BM25 over vektorsøgning til dele af deres søgeinfrastruktur, udelukkende fordi det er hurtigere og billigere at køre.
Andet trin er hurtig filtrering. BM25-scoring på cirka 5 millisekunder skærer kandidatpuljen fra 1000 ned til 100. Det er billigt og fjerner den værste støj.
Tredje trin er præcis reranking. En cross-encoder scorer de resterende 100 kandidater på cirka 100 millisekunder og sorterer ned til 5-20 resultater. Det er her vektorsøgning og tensor-baseret retrieval virkelig gør en forskel - late interaction-modeller som ColBERT kan levere markant bedre ranking end ren cosine similarity.
Fjerde trin er kontekstinjektion. Kun de 5-20 bedste resultater sendes til sprogmodellen. Mindre kontekst, bedre svar, lavere cost.
Hybrid retrieval er ikke længere valgfrit
Udbredelsen af hybrid retrieval tredobledes i Q1 2026 ifølge VentureBeat. Det er ikke tilfældigt. Ren vektorsøgning har en grundlæggende svaghed: den er god til semantisk lighed, men dårlig til eksakte matches. Når en bruger søger på et specifikt dokumentnummer, et juridisk begreb eller et produktnavn, er keyword-matching overlegen. Og i en virksomhedskontekst er den slags præcise opslag mindst lige så hyppige som de brede.
RAG-markedet blev vurderet til 16,5 milliarder kroner i 2025 og forventes at ramme 23,5 milliarder kroner i 2026. Væksten drives primært af virksomheder der går fra proof-of-concept til produktion - og opdager at deres retrieval-lag ikke holder.
For virksomheder der allerede har RAG-systemer der bruger jeres egne dokumenter, er spørgsmålet ikke om man skal skifte til hybrid retrieval. Det er hvornår dokumentbasen vokser nok til at det bliver nødvendigt.
Skalering afslører arkitekturgæld
De fleste RAG-fejl i produktion er ikke LLM-fejl. Det er retrieval-fejl der aldrig bliver synlige fordi modellen pakker dem ind i flydende, selvsikkert sprog. Systemet virker perfekt lige indtil det ikke gør - og ingen kan se forskel.
Flertrins-retrieval med hybrid kandidatgenerering, hurtig filtrering og præcis reranking er ikke en luksus for dem med milliarder af dokumenter. Det er den arkitektur der gør forskellen mellem et RAG-system der holder i produktion og et der stille og roligt forgifter beslutninger med selvsikkert forkerte svar.
Jo tidligere man designer sin pipeline til den mængde data man planlægger at ramme - ikke den man har i dag - jo billigere bliver det at nå dertil.
