GraphRAG vs. almindelig vektorsøgning

Retrieval-augmenteret generering er blevet standardmåden at forankre en sprogmodel i egne data, og for de fleste teams betyder det én ting: embed alt til vektorer, gem dem i en vektordatabase og hent de nærmeste træffere for hvert spørgsmål. For en stor klasse problemer virker dette bemærkelsesværdigt godt. Men der findes en anden klasse, hvor det stille svigter, og svigtet er let at overse, fordi systemet stadig giver selvsikre, plausible svar — bare ufuldstændige eller forkerte.

Den afgørende skelnen er ikke, hvilken teknologi der er nyere eller mere sofistikeret. Det er formen på dine data og formen på spørgsmålene. Får du den diagnose rigtig, bliver valget mellem rent vektorsøg og en grafbaseret tilgang åbenlyst.

Hvad vektorsøg faktisk er godt til

Vektorsøg svarer på lighedsspørgsmål. Du har meget tekst, nogen spørger, og svaret ligger i én passage — eller nogle få — der er semantisk tæt på spørgsmålet. Produktdokumentation, vidensbaser, supportarkiver, forskningsbiblioteker: et næsten perfekt match. Faktummet sidder i en chunk, chunken ligner forespørgslen, og hentningen finder det.

For denne klasse er vektorsøg hurtigt, billigt og svært at slå. At lægge grafmaskineri ovenpå ville være overingeniørkunst — kompleksitet uden gevinst. Hvis dine spørgsmål besvares af den mest relevante passage, behøver du intet mere avanceret, og vi siger det i stedet for at sælge dig et større system.

Hvor vektorsøg stille brister

Problemet begynder, når svaret ikke ligger i nogen enkelt passage, men i relationerne mellem passager. Tænk på: hvilke leverandører rammes af en forordning, der ændrer en anden forordning, som styrer en komponent brugt i en produktlinje ejet af et bestemt datterselskab? Ingen enkelt chunk indeholder det. Det skal samles ved at følge links fra ét faktum til det næste.

Vektorsøg kan ikke følge links. Det henter passager, der ligner spørgsmålet, men lighed er ikke forbindelse. De enkelte hop kan hver være tekstligt ulige forespørgslen, så de rigtige passager dukker aldrig op. Modellen svarer så fra det, den hentede — flydende, selvsikkert, forkert. Netop denne tilstand overrasker teams, fordi intet kaster en fejl.

Hvad en videnskraf tilføjer

En videnskraf gemmer fakta som eksplicitte entiteter og relationer: denne forordning ændrer den, denne komponent hører til det produkt, dette produkt til det datterselskab. GraphRAG kombinerer denne struktur med hentning. I stedet for kun at finde lignende tekst kan den traversere grafen — ændringslinket, så komponentlinket, så ejerskabslinket — og bygge et svar fra en kæde af forbundne fakta.

Dette låser op for fler-hop-spørgsmål, fladt hentning ikke kan røre. Det giver en anden fordel, der betyder enormt i regulerede miljøer: sporbarhed. Fordi svaret blev bygget ved at gå en eksplicit sti gennem grafen, kan du vise den sti. Svaret kommer med ræsonnementet vedhæftet, som bedømmere kan verificere.

Grafens omkostning

Grafer er ikke gratis. At bygge en betyder at udtrække entiteter og relationer fra dataene — et modelleringsarbejde, vektorsøg helt springer over. Du skal afgøre, hvad entiteterne er, hvilke relationer der forbinder dem, og holde strukturen opdateret. For tekst, hvor svarene virkelig ligger i enkeltpassager, er dette ren overhead uden afkast.

Netop derfor kommer diagnosen først. At gribe efter en graf, fordi den lyder kraftigere, er en almindelig og dyr fejl. Grafen fortjener sin omkostning kun, når dine spørgsmål virkelig kræver at følge forbindelser; ellers er den kompleksitet, du vedligeholder for altid uden gevinst.

Hybriden, der oftest vinder

I praksis er de stærkeste systemer sjældent rene. De fleste ægte korpora indeholder begge slags spørgsmål: mange, som én relevant passage besvarer, og nogle, der kræver at forbinde fakta. Den rigtige arkitektur bruger vektorsøg til semantisk genkaldelse og et graflag til de relationelle fler-hop-tilfælde, og ruter hvert spørgsmål til den mekanisme, der passer.

At designe den opdeling godt — hvad der modelleres som graf, hvad der bliver flad tekst, og hvordan de to kombineres ved forespørgsel — er dér, størstedelen af ingeniørdømmekraften ligger. Gjort rigtigt betaler du for grafkompleksitet kun dér, hvor den betaler sig tilbage.

Hvordan du ser, hvad du behøver

Du kan som regel diagnosticere sagen fra spørgsmålene alene. Skriv de ti sværeste spørgsmål ned, dine brugere faktisk stiller. Hvis hvert besvares af den ene mest relevante passage, behøver du vektorsøg og intet mere. Hvis nogle kun kan besvares ved at kombinere flere fakta, der ikke er tekstligt ens, har du fler-hop-spørgsmål, og et graflag fortjener sin plads.

Vi starter hvert hentningsprojekt med præcis denne øvelse, på dine ægte spørgsmål og data, før nogen kode skrives. Teknologien følger diagnosen, aldrig omvendt — og diagnosen er næsten altid klarere end markedsføringen omkring begge tilgange.