Alisina NawabiJe kunt uitleggen waarom gewone (vector-)RAG losse gelijkende stukken tekst ophaalt terwijl GraphRAG een kennisgraaf van entiteiten en relaties bouwt en die aflopen, en je kunt bepalen wanneer vector-RAG genoeg is en wanneer een graaf loont.
Handig vooraf: Wat is RAG
Je denkt waarschijnlijk dat GraphRAG gewoon RAG is, maar dan chiquer. Of dat die kennisgraaf eronder een soort database is die je met een nette query bevraagt. Allebei mis, en het verschil bepaalt of je een simpele vraag beantwoordt of eentje die geen enkel document los kan beantwoorden.
Stel je vraagt: welke klanten zijn geraakt door het defect dat vorig kwartaal in component X zat? Gewone RAG, het ophalen van losse stukken tekst die semantisch op je vraag lijken, vindt braaf de passages die component X noemen en de passages die een klant noemen. Alleen: de keten component X naar product Y naar klant A, B en C staat verspreid over drie documenten. Niemand heeft die verbinding ooit in één zin opgeschreven. Dus RAG geeft je losse feiten en laat het knopen aan jou.
Een kennisgraaf legt die knoop wel. Kijk eerst wat er in beide gevallen gebeurt, dan geef ik het een naam.
GraphRAG is RAG met een kennisgraaf eronder. Waar gewone RAG losse tekststukken ophaalt die op je vraag lijken, haalt GraphRAG eerst de entiteiten (mensen, producten, projecten, begrippen) en hun relaties uit je documenten en zet ze in een graaf van knopen en verbindingen. Bij een vraag loopt het systeem die verbindingen af, traverseren heet dat, in plaats van alleen te kijken wat op elkaar lijkt. Zo beantwoordt het vragen die meerdere documenten overspannen.
Gewone RAG is een bibliothecaris die je elke pagina aanreikt waar je zoekwoord op staat, gesorteerd op hoezeer ze op je vraag lijken. GraphRAG is een bibliothecaris die eerst een kaart tekende van wie-hoort-bij-wat door alle boeken heen, en die kaart volgt van het ene feit naar het volgende.
Het echte werk zit in die extra stap die gewone RAG niet heeft. Bij het inlezen leest een taalmodel elk stuk tekst en trekt er de entiteiten en relaties uit: "component X zit in product Y", "klant A kocht product Y". Die losse feiten worden knopen en verbindingen in één graaf. Microsoft's versie clustert die graaf daarna in groepjes samenhangende entiteiten en schrijft per groep alvast een samenvatting. Bij een keten-vraag loopt het systeem de verbindingen af; bij een overkoepelende vraag leunt het op die samenvattingen.
Het lijken-op verdwijnt trouwens niet. Om de juiste entiteiten in de graaf te vinden, gebruikt GraphRAG nog steeds embeddings, die betekenis omzetten in een plek in een vectorruimte. Semantisch zoeken is hoe je binnenkomt, de graaf is hoe je vervolgens de verbanden legt. Daarom is het geen of-of.
Waar dit echt loont, is precies waar losse chunks stuklopen. Microsoft Research bouwde GraphRAG rond twee zwaktes van gewone RAG: dat het de punten niet kan verbinden als de informatie verspreid staat en slecht is in overkoepelende vragen over een heel corpus. Vraag "wat zijn de terugkerende thema's in alle klantfeedback" en geen enkele losse passage bevat het antwoord: dat is een patroon over duizenden stukjes. Op zulke globale, samenvattende vragen geeft GraphRAG volgens de eigen metingen van Microsoft duidelijk vollediger en gevarieerder antwoorden dan een gewone RAG-basislijn.
Gratis is die kracht niet. Die extractie-stap laat een taalmodel door al je documenten ploegen, en dat is fors duurder dan alleen chunks embedden. Hoe fors? Microsoft bouwde er een luie variant naast die het zware werk uitstelt tot je een vraag stelt, en die indexeert voor ongeveer een duizendste van de kosten van de volle graaf. Dat cijfer zegt vooral iets over hoe zwaar de volle extractie is.
En een graaf is zo goed als die extractie. Herkent het model "component X" verkeerd, of mist het de relatie klant naar product, dan loopt de traversal langs de verkeerde verbanden of vindt niets. Het probleem verdwijnt niet, het verschuift naar het bouwen van een goede graaf. Een graaf is ook geen wondermiddel tegen een model dat dingen verzint: hij grondt het antwoord beter, maar de laatste stap blijft een taalmodel dat tekst genereert. Meer kracht, maar ook meer om goed te krijgen.
Wanneer heb je die graaf echt nodig?
Gewone RAG is genoeg, en goedkoper, als het antwoord in één document of één passage staat. Twijfel je überhaupt of je RAG wel moet bouwen of beter kant-en-klaar afneemt, begin daar. Een graaf loont pas zodra je feiten uit meerdere documenten aan elkaar moet knopen of een heel corpus wilt samenvatten. Loop het even door.
Staat het antwoord in één document, of moet je feiten uit meerdere documenten aan elkaar knopen?
De kern is niet dat GraphRAG beter is dan RAG. De kern is dat "lijken op" en "verbonden zijn" twee verschillende dingen zijn. Zolang je vraag in de tekst zelf staat, is lijken-op genoeg. Zodra het antwoord tussen de documenten in zit, in de verbanden die niemand ooit uitschreef, heb je iets nodig dat die verbanden expliciet maakt. Dat is het hele idee achter een graaf: de relaties zijn de data.
Veelgestelde vragen
Van documenten naar een levende graaf
Ik denk met je mee, ontwerp en bouw een kennisgraaf op je eigen data: entiteiten en relaties eruit, antwoorden met bron erin. Van eerste idee tot iets dat live staat.
Dit artikel is geproduceerd samen met het Agent Team. Meer over de redactie.
