GraphRAG vs vektor-RAG hvornår det virker

Microsofts oprindelige forskning introducerede GraphRAG som en måde at koble retrieval til en struktureret videngraf i stedet for ren tekstlighed. VentureBeat har samlet fire uafhængige benchmarks, der tester påstanden mod klassisk vektor-baseret RAG, og når fire forskellige test peger i samme retning, lytter jeg efter mønsteret snarere end enkelttallene. Mønsteret er dette: GraphRAG's fordel hænger næsten udelukkende sammen med opgavetypen, ikke med systemets generelle kvalitet. Jeg tænker ikke på det som en teknologi, der er "bedre" i sig selv. Det er en teknologi, der løser et andet problem end vektor-søgning gør, og derfor vinder den på nogle opgaver og taber på andre.

Vektor-RAG finder de tekststykker, der ligner spørgsmålet mest semantisk. GraphRAG bygger i stedet en struktur af enheder og relationer mellem dem, og kan derfor følge en tråd gennem flere dokumenter på en måde, ren lighed aldrig kan. Det er den strukturelle forskel, jeg selv stødte på, da jeg byggede grafen hos Agent Enterprise, og den forklarer hele resten af historien.

Der, hvor GraphRAG konsekvent slår vektor-RAG ifølge de fire benchmarks, er spørgsmål der kræver, at systemet forbinder information fra flere kilder, som ikke nødvendigvis ligner hinanden tekstligt. Jeg tænker på spørgsmål som "hvilke leverandører er involveret i de projekter, hvor vores compliance-afdeling har rejst en indsigelse inden for det seneste år" eller "hvordan hænger denne kundes supporthistorik sammen med deres kontraktændringer". Ingen af de to spørgsmål har et enkelt tekststykke, der besvarer dem. Svaret kræver, at man kobler flere separate fakta sammen, og det er præcis den slags kobling, en graf er bygget til at understøtte.

Det samme gælder multi-hop-spørgsmål, hvor svaret på trin ét er nødvendigt for at finde trin to. Vektor-søgning behandler hvert trin isoleret og finder ofte det forkerte stykke tekst, fordi det leder efter lighed frem for sammenhæng. En graf kan derimod følge relationen direkte fra A til B til C, uden at miste tråden undervejs. Det så jeg selv, da min egen graf hos Agent Enterprise pludselig kunne svare korrekt på spørgsmål, jeg tidligere måtte slå op manuelt i tre forskellige systemer. Det er også her, GraphRAG ifølge benchmarkene er stærkest til opsummering på tværs af et helt datasæt, for eksempel "hvad er de mest gennemgående temaer i vores kundeklager i dette kvartal". Det kræver overblik over hele korpusset, ikke bare de mest lignende enkeltstykker.

Når spørgsmålet derimod er et direkte faktaopslag, altså "hvad er vores returpolitik" eller "hvilken paragraf dækker force majeure i denne kontrakt", er vektor-RAG typisk både hurtigere og mere præcist, og det bekræfter mine egne erfaringer. Svaret findes ét sted i et dokument, og ren semantisk lighed finder det stykke uden omveje. At sende det samme spørgsmål gennem en graf tilføjer et ekstra lag af kompleksitet, uden at svaret bliver bedre af det. Det er ren overhead.

Det samme gælder, når datamængden er lille og velafgrænset, for eksempel en enkelt produktmanual eller en HR-håndbog. Her er relationerne mellem enhederne så simple, at en graf ikke tilføjer værdi, den tilføjer bare et vedligeholdelsespunkt mere. Jeg har set en global virksomhed med driftsopgaver i ni lande bygge en videngraf til præcis denne type opgave og bagefter opdage, at vektor-RAG alene havde løst det billigere og lige så godt. Det er en dyr lektion at lære efter implementeringen i stedet for før.

En videngraf koster ikke kun opsætning. Den koster løbende vedligeholdelse, for relationerne i grafen skal opdateres, hver gang de underliggende data ændrer sig, og det sker sjældent automatisk uden en dedikeret pipeline. Det er en reel driftsomkostning, som mange pilotprojekter undervurderer, fordi de kun regner på implementeringstiden og ikke på den løbende kuratering.

Der er også et metodisk problem, der er værd at kende, når man læser benchmarks på området. Mange af testene bruger en stor sprogmodel som dommer til at vurdere, hvilket svar der er bedst. Det er en praktisk løsning, fordi menneskelig vurdering af tusindvis af svar er urealistisk i praksis, men LLM-dommere har en dokumenteret tendens til at foretrække længere, mere velformulerede svar, uanset om de rent faktisk er mere korrekte. GraphRAG-systemer producerer ofte netop den type svar, fordi de trækker på flere kilder og strukturerer svaret bredere. Det kan gøre GraphRAG's fordel i benchmarks lidt større på papiret, end den er i praksis. Konklusionen står stadig: forskellen mellem de to metoder er reel og opgaveafhængig, men tallene skal læses med det forbehold in mente. For dem der vil kvalificere den slags målinger yderligere, er systematisk evaluering af AI-agenter et relevant udgangspunkt.

Mit udgangspunkt, når jeg rådgiver om det her, er altid at kortlægge, hvilke spørgsmål organisationen faktisk stiller sit system i dag, ikke hvilke den teoretisk kunne stille. Hvis langt de fleste forespørgsler er direkte faktaopslag i afgrænsede dokumenter, er vektor-RAG den billigere og hurtigere vej, og en graf vil kun tilføje kompleksitet uden gevinst.

Hvis derimod kernebehovet er at forbinde information på tværs af afdelinger, kontrakter, sagsforløb eller kundehistorik, hvor svaret kræver flere kilder koblet sammen, er en videngraf en investering, der kan betale sig hjem relativt hurtigt. Det er også konklusionen fra mit eget arbejde med Agent Enterprise: vi endte med en hybrid, hvor vektor-søgning håndterer det simple opslag, og en graf kobles på for de tværgående forespørgsler, der reelt kræver det. Det kræver mere arkitektur at bygge, men det undgår den fælde, jeg har set flere pilotprojekter falde i: at bygge en videngraf, fordi den er interessant teknologi, frem for fordi den løser et konkret problem, virksomheden faktisk har.