Architecturale patronen voor grafisch verbeterde RAG: verder gaan dan vectorzoeken in productie

Retrieval-augmentedgeneration (RAG) is de de facto standaard geworden voor het baseren van grote taalmodellen (LLM’s) op privégegevens. De standaardarchitectuur – het opsplitsen van documenten, het inbedden ervan in een vectordatabase en het ophalen van top-k-resultaten via cosinus-gelijkenis – is effectief voor ongestructureerd semantisch zoeken.

Voor bedrijfsdomeinen die worden gekenmerkt door sterk onderling verbonden gegevens (toeleveringsketen, financiële compliance, fraudedetectie), faalt vector-only RAG echter vaak. Het vangt gelijkenis maar mist structuur. Het worstelt met multi-hop redeneervragen zoals: “Hoe zal de vertraging in Component X van invloed zijn op onze Q3-deliverable voor klant Y?” omdat de vectoropslag niet “weet” dat Component X deel uitmaakt van het product van Klant Y.

Dit artikel onderzoekt het grafiek-verbeterde RAG-patroon. Voortbouwend op mijn ervaring met het bouwen van logsystemen met hoge doorvoer bij Meta en private data-infrastructuur bij Cognee, zullen we door een referentiearchitectuur lopen die de semantische flexibiliteit van vectorzoeken combineert met het structurele determinisme van grafendatabases.

Het probleem: wanneer zoeken naar vectoren context verliest

Vectordatabases blinken uit in het vastleggen van betekenis, maar negeren de topologie. Wanneer een document wordt opgedeeld en ingebed, worden expliciete relaties (hiërarchie, afhankelijkheid, eigendom) vaak afgevlakt of geheel verloren.

Overweeg een risicoscenario voor de toeleveringsketen. Hoewel dit een hypothetisch voorbeeld is, vertegenwoordigt het precies de klasse van structurele problemen die we voortdurend tegenkomen in bedrijfsdata-architecturen:

• Gestructureerde gegevens: Een SQL-database die definieert dat Leverancier A Component X levert aan Fabriek Y.

• Ongestructureerde gegevens: Een nieuwsbericht waarin staat: “Overstromingen in Thailand hebben de productie bij leverancier A stopgezet.”

Een standaard vectorzoekopdracht naar “productierisico’s” zal het nieuwsrapport ophalen. Het ontbreekt echter waarschijnlijk aan de context om dat rapport te koppelen aan de output van Factory Y. De LLM ontvangt het nieuws, maar kan de cruciale zakelijke vraag niet beantwoorden: “Welke fabrieken lopen gevaar?”

In de productie manifesteert dit zich als hallucinatie. De LLM probeert de kloof tussen het nieuwsbericht en de fabriek te overbruggen, maar mist de expliciete link, waardoor het óf relaties vermoedt óf een ‘ik weet het niet’-antwoord retourneert, ondanks dat de gegevens in het systeem aanwezig zijn.

Het patroon: hybride ophalen

Om dit op te lossen, gaan we van een “Flat RAG” naar een “Graph RAG” -architectuur. Het gaat om een ​​drielaagse stapel:

1. Inslikken (de “Meta”-les): Bij Meta hebben we, toen we aan de loginfrastructuur van Shops werkten, geleerd dat de structuur bij opname moet worden afgedwongen. U kunt geen betrouwbare analyses garanderen als u later de structuur probeert te reconstrueren uit rommelige logboeken. Op dezelfde manier moeten we in RAG entiteiten (knooppunten) en relaties (randen) extraheren tijdens opname. We kunnen een LLM- of benoemd entiteitsherkenningsmodel (NER) gebruiken om entiteiten uit tekstblokken te extraheren en deze aan bestaande records in de grafiek te koppelen.

2. Opslag: We gebruiken een grafiekendatabase (zoals Neo4j) om de structurele grafiek op te slaan. Vectorinsluitingen worden opgeslagen als eigenschappen op specifieke knooppunten (bijvoorbeeld een RiskEvent-knooppunt).

3. Ophalen: We voeren een hybride query uit:

Referentie-implementatie

Laten we een vereenvoudigde implementatie van deze supply chain-risicoanalysator bouwen met behulp van Python, Neo4j en OpenAI.

1. Modelleren van de grafiek

We hebben een schema nodig dat onze ongestructureerde ‘risicogebeurtenissen’ verbindt met onze gestructureerde ‘toeleveringsketen’-entiteiten.

2. Inslikken: structuur en semantiek verbinden

In deze stap gaan we ervan uit dat de structurele grafiek (leveranciers -> fabrieken) al bestaat. We nemen een nieuwe ongestructureerde ‘risicogebeurtenis’ op en koppelen deze aan de grafiek.

3. De hybride ophaalquery

Dit is de belangrijkste onderscheidende factor. In plaats van alleen maar de top-k-brokken terug te geven, gebruiken we Cypher om een ​​vectorzoekopdracht uit te voeren om de gebeurtenis te vinden, en vervolgens te doorlopen om de stroomafwaartse impact te vinden.

De uitvoer: in plaats van een generiek tekstfragment ontvangt de LLM een gestructureerde payload:

({‘issue’: ‘Ernstige overstromingen…’, ‘impacted_supplier’: ‘TechChip Inc’, ‘risk_to_factory’: ‘Assembly Plant Alpha’})

Hierdoor kan de LLM een nauwkeurig antwoord genereren: “De overstroming bij TechChip Inc brengt Assembly Plant Alpha in gevaar.”

Productielessen: latentie en consistentie

Het verplaatsen van deze architectuur van een notebook naar productie vereist afwegingen.

1. De latentiebelasting

Het doorlopen van grafieken is duurder dan het eenvoudig opzoeken van vectoren. In mijn werk op het gebied van productbeeldexperimenten bij Meta hadden we te maken met strikte latentiebudgetten waarbij elke milliseconde invloed had op de gebruikerservaring. Hoewel het domein anders was, is de architectuurles rechtstreeks van toepassing op Graph RAG: je kunt het je niet veroorloven om alles in één keer te berekenen.

Verzachting: We gebruiken semantische caching. Als een gebruiker een vraag stelt die vergelijkbaar is (cosinusovereenkomst > 0,85) met een eerdere zoekopdracht, serveren we het in de cache opgeslagen grafiekresultaat. Dit vermindert de “grafiekbelasting” voor veelvoorkomende zoekopdrachten.

2. Het ‘oude rand’-probleem

In vectordatabases zijn gegevens onafhankelijk. In een grafiek zijn gegevens afhankelijk. Als leverancier A stopt met het leveren van fabriek Y, maar de voorsprong in de grafiek blijft staan, zal het RAG-systeem vol vertrouwen een relatie hallucineren die niet langer bestaat.

Verzachting: Grafiekrelaties moeten Time-To-Live (TTL) hebben of worden gesynchroniseerd via Change Data Capture (CDC)-pijplijnen vanaf de bron van de waarheid (het ERP-systeem).

Beslissingskader voor infrastructuur

Moet u Graph RAG adopteren? Dit is het raamwerk dat we bij Cognee gebruiken:

1. Gebruik alleen vector-RAG als:

   • Het corpus is plat (bijvoorbeeld een chaotische Wiki- of Slack-dump).

   • De vragen zijn breed (“Hoe reset ik mijn VPN?”).

   • Latentie

2. Gebruik grafiek-verbeterde RAG als:

   • Het domein is gereguleerd (financiën, zorg).

   • “Verklaarbaarheid” is vereist (u moet het verplaatsingspad tonen).

   • Het antwoord hangt af van multi-hop relaties (“Welke indirecte dochterondernemingen worden getroffen?”).

Conclusie

Graph-enhanced RAG is geen vervanging voor het zoeken naar vectoren, maar een noodzakelijke evolutie voor complexe domeinen. Door uw infrastructuur te behandelen als een kennisgrafiek, geeft u de LLM het enige dat hij niet kan hallucineren: de structurele waarheid van uw bedrijf.

Daulet Amirkhanov is een software-ingenieur bij UseBead.

Welkom bij de VentureBeat-community!

In ons gastpostprogramma delen technische experts inzichten en bieden ze neutrale, niet-gevestigde diepgaande inzichten over AI, data-infrastructuur, cyberbeveiliging en andere geavanceerde technologieën die de toekomst van het bedrijfsleven vormgeven.

Lees meer uit ons gastpostprogramma — en bekijk ons richtlijnen als u geïnteresseerd bent om een ​​eigen artikel bij te dragen!