RAG, knowledge graphs eller strukturerede mapper: hvordan skal AI have adgang til jeres dokumenter?

Der findes tre forsvarlige måder at give en AI adgang til virksomhedens dokumenter: vector RAG, knowledge graphs og et struktureret mappetræ, som agenten selv finder rundt i. RAG henter efter lighed. En knowledge graph henter efter relation. Mappetræet lader agenten læse, ligesom en kollega, der har fået arkivet forklaret. For de fleste mindre virksomheder er den tredje den rigtige.

Hvad de tre tilgange er

Tre forskellige bud på, hvordan en AI skal finde frem til noget.

Vector RAG (retrieve-augment-generate) er den, de fleste har hørt om. Dokumenterne hakkes i stykker, hvert stykke oversættes til en talrække, en vektor, af en embedding-model, vektorerne lægges i en database, og når nogen spørger om noget, hentes de stykker, hvis vektorer ligger tættest på spørgsmålets. Modellen ser kun de stykker. Det er lighedssøgning i sprogligt tøj.

Knowledge graphs går den modsatte vej. I stedet for geometrisk nærhed trækker man entiteter ud, altså personer, virksomheder, produkter og begreber, sammen med relationerne mellem dem, og gemmer det som en graf, man kan bevæge sig rundt i. Microsofts GraphRAG, annonceret 13. februar 2024 og lagt frit på GitHub i juli 2024, er den udgave, de fleste møder. Den bruger en sprogmodel til at bygge grafen ud af dokumenterne på forhånd og samler så beslægtede entiteter i hierarkiske communities, som bruges ved opslag.

Strukturerede mapper er den stilleste af de tre og den, der har listet sig ind på de to andre. I organiserer dokumenterne i et mappetræ med navne, man kan gætte indholdet ud fra, og giver agenten filværktøjer: en måde at se en mappes indhold på, søge efter mønstre og åbne en bestemt fil. Der er hverken vektorindeks eller graf. Agenten finder vej, som I selv ville, bare hurtigere og i større mængder. Claude Code er referenceimplementeringen. Som Vadim Geshel har dokumenteret, indekserer Claude Code ikke kodebasen på forhånd og bruger ikke embeddings. Den udforsker undervejs med Glob, Grep og Read.

Sådan opfører vector RAG sig i praksis

RAG er velbeskrevet, der findes værktøj til det overalt, og det er skrøbeligt på en stille måde.

Chunking er det problem, ingen advarer højt nok om. Stack Overflows ingeniørblog skrev det ligeud i december 2024: det er svært at hakke dokumenter ordentligt i stykker. Snittet rammer midt i en tanke, små stykker mister sammenhængen, store stykker udvander relevansen. Det, modellen får at se, er fragmenter. Og så skriver den flydende prosa uden om fragmenter.

Det dybere problem er, hvad en embedding overhovedet indfanger. Vektorsøgning presser betydning ned i afstand, og derfor finder den passager, der ligner hinanden, men den kan ikke følge en tankerække på tværs af dokumenter. Spørg »hvad ændrede sig mellem vores kontrakt med kunden fra 2024 og den fra 2025«, og databasen må håbe på, at de to udgaver ligger tæt på hinanden. Det gør de sjældent. Sproget er ens, og forskellene er præcis det, I ledte efter.

En artikel fra Prism Labs i 2026 satte gode ord på fejltilstanden: når ét dokument bliver rettet, bliver alle beslægtede embeddings i stilhed kandidater til et selvsikkert forkert svar. Indekset ved ikke, hvilken version der gælder. Det gør modellen heller ikke.

RAG vinder stadig, når samlingen er reelt stor, altså millioner af dokumenter, reelt broget, og spørgsmålet lyder »find mig noget, der nævner X«. Til nålen i høstakken er det det rigtige værktøj. Til »hvad var det nu, vi besluttede«, er det det forkerte.

Det, knowledge graphs kan, som RAG ikke kan

En knowledge graph svarer på spørgsmål, der spænder over hele materialet.

Microsoft byggede GraphRAG, fordi almindelig RAG falder igennem på det, deres oprindelige blogindlæg kaldte »narrative private data«: spørgsmål, hvor svaret ikke står i én enkelt passage, men ligger i, hvordan passagerne hænger sammen. Deres eget skoleeksempel er at spørge, hvad de gennemgående temaer er i et datasæt. Vektorsøgning henter de passager, der ligner ordet »temaer« mest, hvilket er ubrugeligt. GraphRAG henter de community-opsummeringer, den lavede under indekseringen, og det er faktisk svaret.

Prisen er den del, virksomheder undervurderer. GraphRAGs indeksering kører en sprogmodel hen over hvert eneste dokument for at trække entiteter og relationer ud. Microsofts egen community-blog forklarer, at den sprogmodeldrevne udtrækning af entiteter bruger omkring 58 % af alle tokens i indekseringen. Uafhængige analyser melder om indekseringsomkostninger tre til fem gange højere end ved vektorindeksering, og i én sammenligning brugte et enkelt GraphRAG-opslag 610.000 tokens mod under 100 i en let variant. Microsofts LazyGraphRAG, udsendt i januar 2025, får indekseringsprisen ned på cirka 0,1 % af den oprindelige ved at udskyde community-opsummeringen til selve opslaget. Forskellen var stor nok til, at Microsoft selv måtte gøre noget ved den.

En knowledge graph vinder, når relationerne er svaret. Compliance-undersøgelser, svindelopsporing, forskning, der skal hoppe flere led på tværs af en litteratursamling, alt hvor spørgsmålet er, hvem der hænger sammen med hvem gennem hvad. Den taber, og den taber grimt på pris og kompleksitet, når det virkelige spørgsmål er »hvad står der i den PDF«.

Hvorfor strukturerede mapper er den, mindre virksomheder bør prøve først

For de fleste virksomheder under 200 medarbejdere slår en velordnet mappe begge de andre.

Mappe-tilgangen behandler jeres dokumenter, som Claude Code behandler en kodebase. Agenten har Glob, som finder filer efter navnemønster, Grep, som søger inde i filerne, og Read, som åbner en bestemt fil. Den bruger Glob og Grep til at finde de rigtige filer og læser derefter kun dem. Det er hentning i to trin: find først, indlæs bagefter. Vadim Geshels gennemgang af designet bag Claude Code kaldte selve læsningen for bekræftelsestrinnet, ikke opdagelsesværktøjet, og det er derfor, context windowet, altså det, modellen kan have i hovedet på én gang, bliver ved med at være lille, selv i store kodebaser.

Anthropics indlæg om context engineering fra september 2025 sagde det bredere. Disciplinen består i at finde den mindste mængde tokens med højest signal, der giver det ønskede resultat. Når konteksten vokser, sætter »context rot« ind: modellens evne til at huske præcist falder, længe før man rammer den hårde grænse. En vektordatabase hælder top-k-stykkerne ind uanset hvad. En agent, der navigerer i mapper, læser kun det, den skal bruge.

LlamaIndex beskrev det samme skifte i januar 2026 i teksten »Files Are All You Need«. Deres pointe er, at en agent med enkle filsøgeværktøjer kan skifte frem og tilbage mellem at søge og læse, sådan som et menneske skimmer på tværs af filer eller ruller ned i én af dem for at løse en opgave. Simon Willisons tekst om fil-native agent-systemer fra februar 2026 pegede samme vej og noterede, at filsystem-kontekst gav frontier-modeller et målbart løft på tværs af tusindvis af forsøg med SQL-generering.

Sådan ser det ud hos en mindre virksomhed: dokumenterne ligger allerede i mapper. I omdøber dem, så et menneske kan gætte indholdet (2025-Q3-kontrakt-acme-fornyelse.pdf, ikke endelig_endelig_v2.pdf). I skriver en enkelt side i roden, der forklarer, hvad hver mappe indeholder. I giver agenten filværktøjer, enten gennem Claude Code, Claude med filsystem-MCP eller noget tilsvarende. Det er hele infrastrukturen.

Hvornår vinder hvad

Valget handler sjældent om, hvad der er klogest. Det handler om størrelse, form og budget.

Vector RAG passer, når samlingen er reelt stor, altså hundredtusindvis af dokumenter og opefter, når spørgsmålene handler om ord og lighed (»find passager om X«), og når dokumenterne ligger stille nok til, at man sjældent skal indeksere forfra. Offentlige vidensbaser, supportarkiver i store virksomheder, materiale til retssager. Et studie fra 2025 udgivet som LaRA, med 2.326 testtilfælde fordelt på fire QA-opgaver, fandt intet svar, der passer alle: det rigtige valg afhænger af modellens størrelse, opgavetypen og samlingens form.

En knowledge graph passer, når relationerne på tværs er selve svaret. Svindelnetværk, regulatorisk eksponering på tværs af forretningsområder, forskningssyntese, hvor værdien ligger i at forbinde artikler frem for at finde én af dem. Sæt penge af til indekseringen, til den løbende vedligeholdelse af grafen og til de folk, der skal drive begge dele.

Strukturerede mapper passer i overraskende mange af de tilfælde, hvor de to andre er overkill: enhver dokumentsamling, et menneske kunne finde rundt i (de fleste mindre virksomheder, altså jer), dokumenter, der ændrer sig, og hvor det at være opdateret betyder mere end skala, situationer, hvor agenten skal bruge selve filen og ikke et fragment, og ethvert hold, der gerne vil levere noget i dette kvartal frem for næste år. Prisen er disciplinen ved at navngive tingene ordentligt. Gevinsten er, at sporet er synligt: I kan se præcis, hvilke filer agenten åbnede.

I vores arbejde med danske virksomheder er strukturerede mapper stedet, vi starter. Vi går videre til RAG, når mængden af dokumenter reelt overstiger, hvad mappe-navigation kan bære, og vi har endnu ikke mødt en kunde, hvor en knowledge graph var det rigtige at bygge først. De hold, der går direkte til RAG, bruger typisk tre måneder på infrastruktur for at løse et problem, som disciplineret navngivning løser på en uge.

Vil I forstå det lag, der overhovedet gør de her adgangsmønstre mulige, så begynd med artiklen om MCP.