Je hebt geen pre-built graph nodig voor RAG — LogicRAG en de kunst van pas bouwen wat je nodig hebt

GraphRAG is hot. Microsoft GraphRAG, LightRAG, HippoRAG — iedereen bouwt pre-built knowledge graphs om documenten doorzoekbaar te maken. Het idee is simpel: haal entiteiten en relaties uit je corpus, stop ze in een graph, en gebruik die graph voor betere retrieval.

Maar een paper van Hong Kong Polytechnic University, geaccepteerd voor AAAI 2026, stelt een fundamentele vraag: heb je die graph eigenlijk wel nodig?

Het korte antwoord: vaak niet. En het langere antwoord heeft forse implicaties voor hoe organisaties hun RAG-architectuur moeten inrichten.

LogicRAG: bouw de graph pas als je de vraag kent

De paper, "You Don't Need Pre-built Graphs for RAG", introduceert LogicRAG. Het uitgangspunt is even simpel als radicaal: in plaats van vooraf een dure graph over je hele corpus te bouwen, bouw je per query een tijdelijke redeneerstructuur.

De architectuur werkt in drie stappen:

1. Query-decompositie: de LLM splitst de vraag in subproblemen
2. DAG-constructie: subproblemen worden nodes in een directed acyclic graph, logische afhankelijkheden worden edges
3. Topologische linearisatie + greedy retrieval: de DAG wordt gesorteerd en subproblemen worden sequentieel opgelost, waarbij elk antwoord context levert voor de volgende stap

Het resultaat is een query-specifiek redeneerpad, niet een generieke graph die voor alle vragen hetzelfde is.

De cijfers

Op multi-hop QA benchmarks (MuSiQue, 2WikiMQA, HotpotQA) scoort LogicRAG significant beter dan alle graph-gebaseerde baselines:

• 2WikiMQA: 64,7% string accuracy — +14,7 procentpunt boven HippoRAG2
• MuSiQue: 30,4% string accuracy — +3,4 procentpunt boven de beste baseline
• Token-efficiëntie: 1.778 tokens per query — minder dan GraphRAG, LightRAG, RAPTOR en HippoRAG

De echte winst zit in wat de tabel niet laat zien: de afwezigheid van pre-constructiekosten. GraphRAG en LightRAG verbruiken miljoenen tokens en tientallen minuten alleen al om de graph te bouwen. LogicRAG slaat die stap over.

Wat hier echt gebeurt

Dit is geen "GraphRAG killer". Het is een workload-placement correctie.

Pre-built graphs zijn nuttig wanneer relaties stabiel, herbruikbaar en domeinspecifiek zijn — denk aan applicatieketens, beleidshiërarchie, procesmodellen, risico-controls. LogicRAG is sterker wanneer de vraaglogica telkens anders is, de kennisbasis vaak wijzigt, of preprocessing economisch niet uit kan.

De implicatie voor RAG-architectuur:

| Situatie | Gebruik | |---|---| | Stabiele domeinrelaties (architectuur, compliance, NORA-mappings) | Pre-built graph | | Ad-hoc analysevragen, incidentanalyse, beleidsvergelijkingen | LogicRAG | | Vaak wijzigende kennisbases (code, tickets, projectdocumentatie) | LogicRAG | | Multi-hop QA met logische afhankelijkheden | LogicRAG |

Een architectuurvoorstel in vijf lagen

Voor productieomgevingen stel ik een gelaagde retrieval-architectuur voor:

Laag 1 — Corpus en indices: Qdrant voor vector search, BM25 voor sparse retrieval, document metadata, chunk provenance, versiebeheer. Dit is je grondlaag — de feitelijke data.

Laag 2 — Optionele persistente graph: alleen voor stabiele domeinen zoals architectuurprincipes, applicatielandschap, dataproducten, controls, NORA/BIO2-mappings. Niet voor alles.

Laag 3 — LogicRAG planner: bouw per vraag een tijdelijke DAG met subvragen, afhankelijkheden, retrieval intent, top-k budget en confidence criteria. Dit is de orchestration layer.

Laag 4 — Execution: voer subvragen uit met retrievers, rerankers, en het juiste model per subvraag — lokaal voor simpele retrieval, cloud frontier voor complexe synthesis.

Laag 5 — Governance: log query decomposition, DAG, retrieved chunks, pruned context, model calls, final answer, uncertainty en rejected evidence. Alles herleidbaar.

Dit is geen los RAG-algoritme meer. Dit is een harness pattern: decomposition, scheduling, retrieval, pruning, reflection, synthesis.

De vier governance-controls die je nodig hebt

LogicRAG is een research-paper, geen enterprise-oplossing. Voor productiegebruik onder AVG, BIO2 of ISO 27001 heb je vier hardening-controls nodig:

1. Planner validation: een tweede model of rule-based validator moet controleren of de subvragen de oorspronkelijke vraag volledig dekken
2. Evidence boundary control: iedere subvraag mag alleen zoeken binnen geautoriseerde collecties en metadatafilters
3. Provenance-preserving pruning: context pruning mag nooit bronverwijzingen, documentversies of confidence scores verwijderen
4. Answer completeness gate: het finale antwoord pas vrijgeven als alle verplichte subvragen evidence hebben of expliciet als onbeantwoord zijn gemarkeerd

Voor AI-governance is vooral de audit trail cruciaal. Je moet kunnen aantonen: waarom deze subvraag, waarom deze bron, waarom deze context weggegooid, waarom deze conclusie. LogicRAG's expliciete DAG is daarvoor juist beter geschikt dan een black-box graph-retrieval — mits je de logging inregelt.

Zwakke plekken

De paper is niet perfect. De query-decompositie is zelf LLM-afhankelijk — als de planner faalt, stuurt retrieval de verkeerde kant op. De evaluatie is beperkt tot multi-hop QA benchmarks, niet tot enterprise-faalmodi zoals incomplete documenten, versieverwarring, autorisatiegrenzen of juridische interpretatie. En de LLM-gebaseerde context pruning kan evidence loss veroorzaken die in compliance-contexten niet traceerbaar is.

Maar dat zijn implementatie-uitdagingen, geen architectuurfouten.

Conclusie

De belangrijkste takeaway van LogicRAG is niet technisch maar architectonisch: bouw niet standaard een zware graph over alles. Bouw eerst een redeneerplan per vraag, gebruik retrieval adaptief, en reserveer permanente graphs voor stabiele, herbruikbare domeinrelaties.

Voor organisaties die nu GraphRAG-pilots draaien is dat een relevant signaal. Je hoeft niet al je documenten door een dure graph-pipeline te halen om betere antwoorden te krijgen. Soms is het antwoord op "moeten we een knowledge graph bouwen?" gewoon: "waarvoor precies?"

---

De paper is beschikbaar op arXiv:2508.06105. Code op github.com/chensyCN/LogicRAG. Eerder schreven we over RAG-Anything en het vision-model datalek en AI-geletterdheid als governance-principe.