Hoe we stopten met tokens verbranden en Knowledge Graph Optimalisatie voor AI onder de knie kregen
Ik heb gisteravond drie uur lang Claude Code getest op een gigantische legacy fintech-codebase van 500.000 regels.
Rond 02:14 uur zat ik wezenloos naar ons API-dashboard te staren. De factuur liep niet zomaar op. Hij explodeerde. We hadden er op één avond 4.000 dollar doorheen gejaagd.
Drie uur werk. Vierduizend dollar. Weg.
Ruwe code in Claude dumpen is financiële zelfmoord
We behandelden het LLM als een vuilnisbak. We propten ruwe, ongestructureerde data direct in het context window en verwachtten magie.
Dat werkte voor geen meter.
Ruwe data aan Large Language Models voeren zonder structurele context is een gegarandeerde manier om geld te verbranden. Erger nog: het triggert bizarre hallucinaties. De agent begreep niet hoe de payment gateway verbonden was met het gebruikersschema. Hij bleef dezelfde enorme repository maar herlezen, gokte wat naar de architectuur en bracht elke token genadeloos in rekening.
> Zonder kaart leest een AI-agent je data niet. Hij verdwaalt er gewoon in.
Dat was het moment waarop de harde realiteit van onze setup doordrong. We betaalden de hoofdprijs voor een AI die compleet in de war was. Deze enorme tokenverspilling was onhoudbaar.
We hebben de test direct stilgezet. We vervingen de ruwe tekstdump door een gestructureerde graaf. We brachten de exacte relaties tussen functies in kaart voordat de AI überhaupt naar de code keek. Het verschil was bizar groot. De tokenkosten daalden met 99,9%, waardoor onze rekening kromp van 4.000 dollar naar exact 4 dollar. De agent begreep de architectuur meteen.
Dit is niet alleen een hoofdpijndossier voor developers. Het is een serieus probleem voor je hele bedrijf.
Kopers klikken niet meer door naar je website. Ze stellen hun vragen aan AI-agents. Maar je AI-agents falen omdat ze de relaties tussen je datapunten niet begrijpen.
Als je data bestaat uit een platte hoop tekst, kan de machine het niet lezen. Hij kan de punten niet verbinden.
Ik ben doodziek van adviezen die founders vertellen dat ze maar gewoon een custom GPT moeten bouwen. Als je data niet structureert voor machine-to-machine communicatie, ben je onzichtbaar. Je zit in de prompt, of je bestaat niet.
Het besef dat ruwe tekst een doodlopende weg is, dwong ons tot een fundamentele vraag die we altijd hadden ontweken: wat betekent optimaliseren voor deze modellen nu echt?
---
Waarom traditionele SEO en basis-RAG doodlopen
Wat is knowledge graph optimalisatie voor AI?
Knowledge graph optimalisatie voor AI is het technische proces van data structureren in machineleesbare nodes en edges om structurele context te leveren aan large language models. Dit verschilt totaal van traditionele SEO omdat het prioriteit geeft aan machine-to-machine communicatie in plaats van menselijk leesbare webpagina's of simpele zoekmachinerankings.
Ik ben klaar met zogeheten experts die beweren dat je gewoon een simpele RAG-pipeline moet aansluiten. Het werkt niet. Zeker niet voor complexe AI-taken.
Als je SEO geen rekening houdt met M2M-communicatie (machine-to-machine), besta je simpelweg niet voor moderne AI-agents. Het oude handboek kan de prullenbak in. Je kunt niet alleen optimaliseren voor menselijke ogen en hopen dat bots het wel snappen.
De illusie van schema markup
Wij moesten dit door schade en schande leren. Ik probeerde standaard entity resolution en simpele schema markup in onze AI coding agent te stoppen om het project te refactoren. Ik dacht dat standaard SEO-trucs wel zouden vertalen naar codebegrip.
Ik verwachtte een heldere kaart.
Het mislukte faliekant.
Ik keek vol ongeloof naar de terminal. De agent hallucineerde afhankelijkheden die helemaal niet bestonden. Hij miste de koppeling tussen onze authenticatiemodule en de centrale database volledig. Hij zat gewoon te gokken.
De reden? Traditionele SEO-entiteitsoptimalisatie voor Google AI Overviews is totaal iets anders dan het bouwen van structurele contextkaarten voor complexe codebases. Google wil weten wie een artikel heeft geschreven. Een AI coding agent moet exact weten hoe een wijziging in auth.js doorwerkt in het databaseschema.
> Je kunt niet zomaar wat JSON-LD over een repository gooien en verwachten dat een autonome agent de hele architectuur snapt.
Schema markup is gemaakt voor zoekmachines om rich snippets te tonen. Het is niet gebouwd om een LLM te leren hoe een omvangrijke softwarearchitectuur draait. Het is een groot probleem wanneer founders die twee zaken met elkaar verwarren.
Simpele Retrieval-Augmented Generation (RAG) is net zo erg. Het haalt blind stukken tekst op basis van vectorovereenkomst binnen. Het pakt de ruwe code, maar verliest de onderlinge relaties. Het geeft de AI puzzelstukjes zonder het voorbeeld op de doos. Je houdt een gefragmenteerde bende over.
We hadden structurele context nodig.
Dit is waarom basis-RAG faalt bij complexe architecturen:
Het resultaat? Een verwarde AI-agent en een gigantische tokenrekening. We verbrandden geld aan een systeem dat zijn eigen kaart niet eens kon lezen.
---
De ommekeer: structurele context boven ruwe data
We pakten het verkeerd aan.
Een enorme codebase blind in een LLM proppen is een gegarandeerde manier om geld te verbranden. Het gaat mis zodra je verwacht dat een machine complexe architectuur begrijpt door er een miljoen regels platte tekst in te dumpen. De AI raakt het spoor bijster. Het context window loopt vol. Je API-rekening ontploft.
Er was een radicale koerswijziging nodig.
Nodes, edges en het einde van hallucinaties
De doorbraak kwam hard binnen. We realiseerden ons dat lokale knowledge graphs geen theoretisch speeltje voor academici zijn. Ze zijn bittere noodzaak voor AI-begrip.
We stopten met het voeren van ruwe code. In plaats daarvan zetten we onze hele workflow om naar een persistente codegraaf met Graphify.
Dit is wat er veranderde:
Nog voordat het LLM ook maar één regel logica las, brachten we de nodes en edges in kaart. We definieerden precies hoe elke functie, class en module op elkaar aansloot.
> We gaven de AI geen doolhof meer, maar een duidelijke routekaart.
Toen we dit testten op de repository van de klant, logen de cijfers er niet om. Het tokenverbruik kelderde met 99,9%. In plaats van 4.000 dollar aan overbodige context, betaalden we precies 4 dollar om een lichte, gestructureerde kaart mee te sturen.
De nauwkeurigheid schoot omhoog. Het hallucineren stopte meteen.
De AI hoefde immers niet meer te raden hoe auth_module.py verbonden was met het databaseschema. De structurele context was al aanwezig, hard vastgelegd in de graaf.
Dit is het technische onderscheid tussen amateuristisch prompt engineering en enterprise semantisch zoeken.
Amateurs proppen het context window vol en bidden dat het model het snapt. Dat is lui en peperduur. Enterprise semantisch zoeken bouwt structurele context. Het geeft de machine exact wat nodig is om relaties direct te navigeren.
Ik ben klaar met influencers die developers vertellen dat ze gewoon 'betere prompts' moeten schrijven. Een prompt fixt een gebrek aan structuur niet.
Zoals we zeggen: je zit in de prompt, of je bestaat niet. Maar als je prompt een chaotische tekstdump is, ben je alsnog nergens. Je hebt een graaf nodig.
Dat inzicht veranderde onze architectuur compleet, maar riep direct een technische vraag op bij onze CFO.
---
Hoe je een lokale knowledge graph bouwt die écht werkt
Hoe verlagen knowledge graphs de LLM-tokenkosten?
Knowledge graphs verlagen LLM-tokenkosten en optimaliseren context windows door massale, overbodige ruwe tekstinvoer te vervangen door een compacte, gestructureerde relatiekaart. Hierdoor bevraagt de kunstmatige intelligentie alleen de specifieke nodes en edges die nodig zijn om een taak foutloos uit te voeren, zonder overbodige data te verwerken.
Ruwe code in een LLM dumpen is pure geldverspilling. Ik ben klaar met theoretici die roepen dat je je data maar 'beter moet chunken'. Dat is waardeloos advies. Bij complexe architecturen faalt dat genadeloos. We hadden een echte oplossing nodig voor onze klant, geen nieuw lapmiddel.
De ontologie in kaart brengen: stap voor stap
Dit is het concrete framework om je contextlimieten op te lossen:
Laten we naar de tools kijken. Ik heb Graphify en code-review-graph rechtstreeks tegenover elkaar gezet op de codebase. Ik wilde zien welke tool het context window voor Claude Code het beste optimaliseerde.
Graphify ziet er gelikt uit en levert een fraaie visuele weergave op. Maar onder de motorkap vervuilde het context window met overbodige metadata. Tijdens de test op de fintech-repository zag ik ons tokenverbruik met 40% stijgen, puur om de graaf zelf te parsen. Het gaf de AI opnieuw een doolhof in plaats van een kaart.
Daarna schakelde ik over naar code-review-graph.
Lelijke interface. Nul marketing. Maar het genereerde een strakke, persistente codegraaf die de exacte ontologie (nodes en edges) vastlegde zonder enige ballast.
> Geef je de AI eerst de structurele contextkaart, dan dwing je het model om relaties te volgen in plaats van te gokken.
Het effect was direct merkbaar. Het tokenverbruik daalde met meer dan 99,9%, waardoor onze kosten letterlijk krompen tot centen per query. De accuraatheid ging door het dak. De AI stopte met het verzinnen van afhankelijkheden en schreef direct werkende code. Het model wist precies waar de authenticatie-middleware aansloot op het databaseschema, omdat de graaf die relatie expliciet definieerde.
Het is een groot risico als je deze verschuiving negeert. Je zit in de prompt, of je bestaat niet.
Als je technische SEO geen rekening houdt met M2M-communicatie, ben je onzichtbaar voor moderne AI-agents. Kopers klikken niet meer op je site. Ze laten hun agents het werk doen. En als die agent jouw graaf niet kan lezen, verlies je.
---
Je zit in de prompt, of je bestaat niet
De M2M-werkelijkheid
Laten we helder zijn: het tijdperk van puur mensgericht zoeken is voorbij.
Ik ben klaar met adviezen die founders vertellen dat ze betere blogposts moeten schrijven. Content is voor mensen. Context is voor machines. We leven in 2026 en machineleesbare data is de enige valuta die er nu toe doet.
Kijk naar je eigen analytics. Kopers klikken niet meer door naar je site. Ze scrollen niet meer door tien blauwe linkjes. Ze laten hun AI-agents het zware werk doen, en die agents slaan jouw ontworpen landingspagina's straal voorbij.
Als je SEO-strategie M2M-communicatie negeert, besta je simpelweg niet. Dat is een hard feit.
Ruwe tekst is waardeloos. Je hebt nodes nodig. Je hebt edges nodig. Je hebt een persistente graaf nodig die een LLM kan lezen zonder te hallucineren of je budget op te stoken.
> Als jij je data niet structureert in een graaf voor machines, doet je concurrent het wel.
Zij voeden de AI als eerste de structurele contextkaart. Zij optimaliseren het context window. Zij pakken jouw marktaandeel af terwijl jij nog bezig bent met het finetunen van meta descriptions.
Wij hebben dit aan den lijve ondervonden. We wilden niet langer toezien hoe onze eigen klanten verdwenen uit AI-antwoorden door een gebrek aan de juiste architectuur. Precies daarom zijn we intern AnswerShaper gaan gebruiken. We zochten geen logge software, maar een betrouwbare manier om graafcreatie te automatiseren en AI te dwingen relaties te volgen in plaats van te gokken. Het levert exact de structurele context die AI-agents eisen, zonder marketingonzin.
Stop met optimaliseren voor bezoekers die er niet meer zijn. Begin met optimaliseren voor de agents die de beslissingen nemen.
Je zit in de prompt, of je bestaat niet.
Aan jou de keuze.