Graph RAG

Wat is Graph RAG?

Graph RAG is retrieval-augmented generation waarbij de zoekstap door een graaf van entiteiten en hun onderlinge relaties loopt, in plaats van enkel de tekstfragmenten op te halen die het meest op je vraag lijken. Het taalmodel schrijft nog altijd het antwoord. Wat verandert, is wat het aangereikt krijgt: geen vijf losse passages, maar een samenhangende set feiten, en soms een samenvatting van een hele groep documenten.

Gewone vector RAG werkt goed als het antwoord in één passage staat. Ze loopt vast als het antwoord pas bestaat zodra je dingen uit veel verschillende documenten met elkaar verbindt, of als de vraag over de hele verzameling gaat. Niemand heeft ooit een alinea geschreven die zegt welke leveranciers leveren aan de fabrieken die vorig kwartaal kwaliteitsincidenten hadden. Dat feit is een pad door drie tabellen, of door dertig documenten, en een zoekopdracht op gelijkenis tussen fragmenten kan geen pad volgen.

Een graaf kan dat wel. Leverancier levert aan fabriek, fabriek had een incident, incident dateert van vorig kwartaal. Graph RAG bouwt of gebruikt die structuur en laat het model daarover redeneren.

Twee families

De naam dekt twee aanpakken die een woord delen en verder weinig. Het loont om te weten welke van de twee iemand bedoelt.

Een graaf die uit documenten gehaald wordt. Microsoft Research publiceerde deze versie in 2024 en bracht ze in juli van dat jaar uit als de open-source bibliotheek GraphRAG. Bij het indexeren leest een LLM elk fragment en haalt er entiteiten, de relaties ertussen en korte beschrijvingen uit. Die worden knopen en verbindingen. Een algoritme voor community detection (Leiden) groepeert daarna sterk verbonden entiteiten in clusters, op meerdere niveaus, en het LLM schrijft voor elke cluster een rapport. Bij een vraag vertrekt een local search van de entiteiten in je vraag en waaiert uit naar hun buren. Een global search leest de clusterrapporten in plaats van de documenten en voegt ze samen tot één antwoord. Die globale modus is de reden dat deze familie bestaat: zo beantwoord je "wat zijn de grote thema's in de klachten van dit jaar" over een paar duizend tickets. Het eigen voorbeeld van Microsoft was een nieuwscorpus over de oorlog in Oekraïne. Gewone RAG kreeg een vraag over een bepaalde groepering niet beantwoord, omdat geen enkele passage daarover ging, terwijl de graaf de verspreide vermeldingen wel aan elkaar knoopte.

Een graaf die je al hebt. De meeste bedrijven hoeven geen graaf uit proza te halen, want de structuur zit al in hun systemen: klanten, orders, producten, sites, techniekers, onderdelen. Laad die in een graph database, of laat ze staan waar ze staan en beschrijf het schema, en laat het model zelf een query op die graaf schrijven. Het GraphRAG-pakket van Neo4j bevat een Text2Cypher-retriever die een vraag omzet in een Cypher-query, ze uitvoert en de rijen aan het model geeft, en een retriever die eerst via gelijkenis een startknoop zoekt en daarna met Cypher verder door de graaf loopt. De property graph index van LlamaIndex doet hetzelfde met een TextToCypher-retriever en met Cypher-sjablonen waarin het model enkel de gaten invult. Zit je graaf in RDF, dan is de querytaal SPARQL in plaats van Cypher, en het idee is identiek.

De tweede familie ligt dichter bij text-to-SQL dan bij de eerste. Ze is goedkoper, voorspelbaarder en makkelijker te controleren, omdat de graaf jouw data is en niet de lezing die een model van jouw documenten maakte.

De vragen waar gewone vector RAG geen antwoord op heeft

Twee soorten vragen breken het ophalen van fragmenten, en allebei komen ze in elk bedrijf voor.

Meerstapsvragen (multi-hop). "Welke leveranciers leveren aan de fabrieken die vorig kwartaal kwaliteitsincidenten hadden?" Het antwoord vraagt een leverancierslijst per fabriek, een incidentenlijst per fabriek en een datumfilter, aan elkaar gekoppeld. Geen enkele passage bevat alle drie. Vectorzoeken geeft fragmenten over leveranciers en fragmenten over incidenten terug, en laat het koppelen over aan een model dat de rijen die het niet kreeg ook niet kan zien.

Globale vragen. "Wat zijn de grote thema's in de klachten van dit jaar?" Er valt geen passage op te halen, want het antwoord is een eigenschap van de hele verzameling. Vector RAG geeft de tien klachten terug die het meest op het woord "thema" lijken en vat die samen. Het team van Microsoft mat dit op twee verzamelingen van ongeveer één en 1,7 miljoen tokens. Beoordeeld op hoe volledig en hoe gevarieerd de antwoorden waren, kreeg hun aanpak met een graaf in de meeste rechtstreekse vergelijkingen de voorkeur op vector RAG, tussen ruwweg 62 en 83 procent naargelang de verzameling en het criterium.

Een vraag die één ding noemt en één feit wil ("wat is de garantietermijn op de X200") heeft dit allemaal niet nodig, en een graaf maakt dat antwoord niet beter.

Voorbeeld: de servicehistoriek van een installateur

Een installatiebedrijf heeft tien jaar servicedata: tickets, de technieker die elk ticket afhandelde, de site, het onderdeel dat vervangen werd, en welk team de site in welk jaar installeerde. Alles zit in een ticketsysteem en een ERP.

Iemand vraagt: "Welk onderdeel valt het vaakst uit op sites die team B in 2024 installeerde?"

Met fragmenten ophalen krijg je tickets waar team B in voorkomt en tickets over pannes die vaak terugkomen. Team B staat zelden op een ticket, want de installatie gebeurde jaren voor het ticket geopend werd. Het antwoord is een telling over een pad, en dat pad ziet er in Cypher zo uit:

MATCH (:Team {name: 'B'})-[i:INSTALLED]->(s:Site)
WHERE i.year = 2024
MATCH (s)<-[:AT_SITE]-(t:Ticket)-[:REPLACED]->(p:Part)
RETURN p.name, count(t) AS failures
ORDER BY failures DESC
LIMIT 5

De taak van het model is die query schrijven uit de vraag en het schema, ze uitvoeren, en de bovenste rij in een zin gieten. Elk cijfer in het antwoord is terug te voeren op een ticket. Dat is de tweede familie, en voor een bedrijf waarvan de data al in tabellen zit, is dat de familie om mee te beginnen.

De eerste familie komt pas in beeld bij een vraag als "wat schrijven de techniekers telkens weer in hun notities over de X200", want dat is proza, en de entiteiten (onderdeel, symptoom, oorzaak) moeten eerst uit vrije tekst gehaald worden.

Vector RAG versus Graph RAG

De dimensie die beslist, is de vorm van de vraag: zit het antwoord in één passage, of in de verbanden over veel passages heen?

Vector RAG beantwoordt vragen waarvan het antwoord in één of enkele passages staat. Zoeken is een zoekopdracht op gelijkenis, indexeren is één embedding-call per fragment, en de pijplijn is goedkoop, snel en goed begrepen. Staat het antwoord in de tekst, dan wint dit op kost en eenvoud, en hybride zoeken plus reranking dicht de meeste gaten.

Graph RAG beantwoordt vragen waarvan het antwoord pas bestaat als je entiteiten over documenten of tabellen heen verbindt, en vragen over de hele verzameling. Zoeken is een traversal of een query op de graaf. Indexeren kost ofwel een LLM-pass over elk fragment, ofwel hergebruik je structuur die je al hebt. Het antwoord komt met een expliciet pad dat je kan nakijken.

De meeste productiesystemen met een graaf houden de vectorindex ernaast. Het pakket van Neo4j en de bibliotheek van Microsoft beginnen veel vragen met een zoekopdracht op gelijkenis om een instappunt te vinden, en lopen van daaruit de graaf door.

Wat het kost

Het dure stuk is de extractie. In de familie die een graaf uit documenten haalt, leest een LLM bij het indexeren elk fragment, en daarna leest het de graaf nog eens om de clusterrapporten te schrijven. De repository van Microsoft opent met een waarschuwing dat indexeren "an expensive operation" kan zijn en zegt je klein te beginnen. In hun paper indexeerde het team een verzameling podcasttranscripties van ongeveer één miljoen tokens, en die indexeerrun duurde 281 minuten, bijna vijf uur, op één machine.

Het duidelijkste cijfer komt van Microsoft zelf. Toen het in november 2024 LazyGraphRAG aankondigde, stelde het dat de indexeerkost van LazyGraphRAG gelijk is aan die van vector RAG en 0,1 procent van die van volledige GraphRAG. Omgekeerd gelezen: indexeren met volledige GraphRAG kost in de orde van duizend keer wat het embedden van dezelfde fragmenten kost. LazyGraphRAG komt daar door het LLM bij het indexeren over te slaan, een conceptgraaf te bouwen met gewone extractie van naamwoordgroepen, en het model pas bij de vraag aan te spreken, enkel op het stuk van de graaf dat de vraag raakt. Microsoft levert het binnen Microsoft Discovery, zijn onderzoeksplatform op Azure. In de open-source bibliotheek GraphRAG staat het sinds december 2024 aangekondigd als de volgende mijlpaal en is het nog altijd in geen enkele release verschenen. Microsoft zelf zegt intussen dat die repository grotendeels in onderhoudsmodus zit.

Ook de kost per vraag verschilt per modus. Een global search leest elk clusterrapport via een map-reduce, dus één vraag kan honderden aanroepen van het model kosten. De latere dynamische clusterselectie van Microsoft sneed daar gemiddeld 77 procent van af door rapporten weg te laten die niets met de vraag te maken hebben. Een local search of een Cypher-query kost ongeveer wat een gewone RAG-vraag kost.

De tweede familie heeft geen extractiefactuur. Je betaalt voor een graph database of voor een schemabeschrijving, plus één aanroep van het model om de query te schrijven.

Waar moet je op letten bij Graph RAG

Extractiefouten planten zich voort. Leest het LLM "Peeters BV" als een persoon, of mist het een relatie, dan is die fout nu een feit in de graaf, en elk antwoord dat erover loopt neemt ze over. Het team van Microsoft toonde zelf dat hun standaard extractieprompts, geschreven voor nieuws, missen wat een chemicus uit chemiepapers verwacht, en bouwde een auto-tuning-stap die domeinprompts genereert. Reken op tijd om een staal van de geëxtraheerde graaf na te lezen voor je ze vertrouwt.

Entity resolution bepaalt het resultaat. "Team B", "installatieteam B" en "TB" moeten één knoop worden, anders klopt de telling uit het voorbeeld niet. De graph builder van Neo4j levert niet voor niets resolvers op exacte match, fuzzy match en embeddings. Op gestructureerde data is dit hetzelfde masterdataprobleem dat je al hebt. Op geëxtraheerde tekst is het lastiger.

Een graaf veroudert. Een vectorindex kan een gewijzigd document opnieuw embedden. Een geëxtraheerde graaf moet de extractie opnieuw draaien en, in het ontwerp van Microsoft, de clusters en hun rapporten herberekenen. Bepaal hoe wijzigingen binnenkomen voor je begint te bouwen.

Gegenereerde queries kunnen fout zijn. Een Cypher-query die draait, is nog geen Cypher-query die juist is. Toon de query aan de gebruiker, of beperk het model tot sjablonen, zoals de Cypher template retriever van LlamaIndex doet.

Wanneer je er niet aan begint. Een paar honderd FAQ-documenten, producthandleidingen, een HR-reglement: vragen die met één passage beantwoord zijn, over een kleine verzameling. Vector RAG met hybride zoeken kan dat aan, en een graaf voegt kost en een nieuwe foutbron toe zonder beter antwoord. Begin pas aan een graaf als je drie echte vragen kan opschrijven die een koppeling over documenten heen nodig hebben, of één globale vraag die je elke maand moet beantwoorden.