Pinecone Nexus en het einde van Agentic RAG zoals wij het kennen
Ik keek naar de Nexus-aankondiging van Pinecone op 5 mei 2026, terwijl ik aan mijn bureau zat met een koude koffie en een halfafgemaakte agent die ongeveer 47.000 tokens per vraag at om vragen over een map met contracten te beantwoorden. Ik had al geaccepteerd dat dit precies was wat agentische systemen in 2026 kosten. Gooi genoeg tokens naar de ophaallus en uiteindelijk vindt de agent de juiste paragraaf. Dat is de afspraak.
Toen zei Ash Ashutosh, de CEO van Pinecone, iets tijdens de aankondigingsoproep waardoor de deal in mijn hoofd kapot ging.
Hij noemde RAG "gebouwd voor menselijke gebruikers" en Nexus "gebouwd voor agentische gebruikers." Dat klinkt als marketing totdat je stilstaat bij wat het eigenlijk betekent. Het retrieval-augmented patroon dat iedereen de afgelopen twee jaar in agentloops heeft verpakt, is ontworpen voor het human-in-the-loop-geval: een persoon typt een vraag, een systeem haalt een aantal passages op, een model voegt die passages weer samen in proza. Het inpakken van dat patroon in een agentlus veranderde niets aan waar het patroon voor diende. Het zorgde er alleen maar voor dat het patroon vaker werd uitgevoerd.
En elke extra run kost het redeneringsbudget van de agent die hij niet heeft.
Dat is het kader dat ik niet kan afschudden. Agentic RAG was nooit het antwoord op ophalen. Het was een oplossing voor het feit dat het ophalen altijd het knelpunt was, en we bleven hopen dat meer instanties dit zouden compenseren. Pinecone Nexus is de architectonische erkenning dat dit niet het geval is. Je kunt een ophaalprobleem niet oplossen door het ophalen autonomer te maken. Je moet kennis stroomopwaarts van de agent verzamelen, zodat de agent stopt met het bibliothecariswerk en het werk gaat doen waar hij eigenlijk goed in is.
Ik ga doornemen wat Nexus eigenlijk is, hoe de cijfers eruit zien (met alle kanttekeningen die ze verdienen), waar dit past naast Karpathy's LLM Wiki, Microsoft Fabric IQ en Google Knowledge Catalog, en de vraag die elke bouwer in 2026 moet beantwoorden: wanneer verslaat de verzamelde kennis agent RAG, en wanneer is de oude lus nog steeds de juiste keuze?
Een deel hiervan zal klinken als een lofrede voor agent RAG. Dat is het niet. Aan het einde van dit bericht zul je zien waarom de toekomst hybride is – en waarom Nexus het eerste stukje infrastructuur is dat de hybride eerlijk maakt.
Wat Agentic RAG u daadwerkelijk kost
Laat ik dit in cijfers uitwerken voordat we bij de architectuur komen, want elk gesprek over terughalen is handgebaar totdat je de echte kosten op tafel legt.
De eigen framing van Pinecone besteedt ruwweg 85 procent van de rekencyclus van een agent aan het ophalen van context in plaats van aan de daadwerkelijke taak. Dat komt overeen met de sporen van de agent waar ik het hele jaar naar heb gekeken. Open een agent RAG die wordt uitgevoerd terwijl debug-login is ingeschakeld en u zult hetzelfde patroon zien: toolaanroep, ophalen, evalueren, opnieuw ophalen met een andere query, opnieuw evalueren, soms een subagent voortbrengen om samen te vatten wat terugkwam, en uiteindelijk het antwoord genereren. Zes tot tien tooloproepen zijn normaal. Twaalf is niet ongebruikelijk. Ik heb runs gezien die twintig bereikten voordat ze samenkwamen op iets bruikbaars.
Elk van deze oproepen sleept context met zich mee. Ze verbruiken allemaal tokens – niet alleen de opgehaalde stukken, maar elk tussenkladblok dat de agent naar zichzelf schrijft om te onthouden wat hij heeft geprobeerd. De ophaallus is niet alleen traag. Het is duur op een manier die het samenvoegt, omdat hoe langer de agent redeneert over luidruchtige ophaalacties, des te meer redeneersporen hij in de context moet houden.
Industrieanalyses ondersteunen dit. Agentic RAG werkt tegen ongeveer 3 tot 10x de tokenkosten van de standaard RAG. De kosten schalen met het aantal modeloproepen. Iteratieve ophaalschalen kosten rechtstreeks met het aantal stappen. Geen van deze cijfers komt van Pinecone – ze komen uit onafhankelijke productiegidsen die begin 2026 zijn gepubliceerd, en ze beschrijven de patronen die teams al een jaar stilletjes accepteren.
Dan is er het determinismeprobleem.
Omdat de agent bij elke stap verschillende beslissingen neemt, afhankelijk van wat hij heeft opgehaald, kan dezelfde query tijdens uitvoeringen verschillende paden en verschillende uitvoer opleveren. Ik heb tien keer achter elkaar identieke vragen gesteld aan mijn eigen contractagent en zag hoe hij tijdens de runs drie verschillende clausules aanhaalde – geen enkele was precies verkeerd, maar geen enkele was hetzelfde. Dat soort non-determinisme is prima als je aan het verkennen bent. Het is onaanvaardbaar als je iets bouwt dat controleerbaar moet zijn.
Het voltooiingspercentage van taken is de andere helft van de rekening. Pinecone noemt het bereik van 50-60 procent voor agent RAG op hun eigen benchmarks. Ik sta sceptisch tegenover welke leveranciersbenchmark dan ook, maar de richting is eerlijk: zelfs als agent RAG werkt, werkt het niet consistent genoeg om in compliance-gevoelige workflows te worden verzonden zonder dat een mens elke output controleert. Dat betekent dat u agentische RAG-prijzen betaalt voor een systeem dat nog steeds menselijke validatie vereist. Kies de helft van de zin die u het meest beledigt.
Ik besprak een verwante invalshoek toen ik schreef over waarom MCP voorbij veertig gereedschappen instort — dezelfde architectonische fout herhaalt zich. Het protocol gaat ervan uit dat de agent al zijn opties tegelijkertijd in context kan houden. De wiskunde zegt dat dit niet kan. Schema-injectie, ophaallussen, uitwaaieren van gereedschap: dit zijn allemaal symptomen van een dieperliggende bug. We blijven proberen agenten tijdens runtime slimmer te maken in plaats van het structurerende werk tijdens de buildtime te doen.
Nexus is het eerste grote stuk infrastructuur dat deze bug bij naam noemt.
Wat Pinecone Nexus eigenlijk is
Haal de opstarttaal weg en Nexus doet één specifiek ding dat ertoe doet: het verplaatst het dure deel van het ophalen van de zoektijd naar de opnametijd.
Dat is de hele truc. Al het andere is implementatiedetail.
Hier is het mechanisme. In plaats van onbewerkte documenten (of onbewerkte delen van documenten) op te slaan en deze op verzoek op te halen, voert Nexus tijdens de opname een contextcompiler uit op het bronmateriaal. De compiler leest de gegevens, begrijpt het soort taken dat de agent moet uitvoeren en produceert getypte, taakspecifieke gestructureerde artefacten: vooraf gebouwde, vooraf geaggregeerde, vooraf geciteerde antwoorden op de vraagvormen die de agent gaat stellen.
Wanneer er tijdens runtime een query binnenkomt, zoekt de agent niet. Het verklaart zijn bedoeling in KnowQL, de nieuwe declaratieve querytaal van Pinecone, en Nexus haalt het relevante gecompileerde artefact op in één enkele rondreis. Geen ophaallus. Geen heropname. Geen iteratieve verfijning. Het werk is al gedaan.
KnowQL is de moeite waard om even bij stil te staan, omdat dit het deel van de aankondiging is dat aangeeft waar dit architectonisch naartoe gaat. Het heeft zes primitieven: intentie, filter, herkomst, uitvoervorm, vertrouwen en budget. Dat is geen API. Dat is een taal ontworpen voor agenten. Intentie zegt wat de agent probeert te doen. Filter verkleint de reikwijdte. Herkomst vereist citaten. Uitvoervorm specificeert de structuur die de agent terug verwacht. Vertrouwen bepaalt de kwaliteit van de antwoorden. Budgetlimieten voor tokenuitgaven.
Vergelijk dat eens met de JSON-toolaanroepen die ik twee jaar lang heb geschreven om het ophalen in te pakken: op maat gemaakte schema's voor elk ophaalpatroon, aangepaste lijmcode, geen standaardmanier om uit te drukken: "Ik heb dit nodig beantwoord met citaten en een betrouwbaarheidsscore van minder dan 200 ms." KnowQL is de eerste poging die ik heb gezien om agenten een vocabulaire te geven voor toegang tot kennis dat overeenkomt met de manier waarop agenten daadwerkelijk redeneren. Of KnowQL specifiek wint, staat open. Het patroon van declaratieve agent-native querytalen doet dat vrijwel zeker.
Het andere onderdeel is de contextcompiler zelf, het deel van het systeem dat daadwerkelijk artefacten bouwt op basis van onbewerkte gegevens. Pinecone beschrijft het als een autonome coderingsagent die put uit een vooraf gecontroleerde vaardighedenbibliotheek (chunkingstrategieën, extractie van entiteiten, parseren van tabellen, samenvattingspatronen) en synthetiseert taakspecifieke artefacten die worden geëvalueerd aan de hand van een bestaande testset. Met andere woorden: de compiler is zelf een agent, maar hij draait één keer, tijdens het bouwen, op basis van een specificatie van wat het systeem moet beantwoorden. Not on every query.
Dit komt dichter in de buurt van hoe een database werkt dan hoe RAG werkt. U definieert een schema, u indexeert uw gegevens op basis van dat schema, u bevraagt de index. Het schema in Nexus is de evaluatieset. De index bestaat uit de gecompileerde artefacten. De vraag is KnowQL. Iedereen die met traditionele databases heeft gewerkt, zal het patroon onmiddellijk voelen, omdat het het patroon is dat elk werkend datasysteem aandreef voordat we de plot verloren met vectorzoeken.
De cijfers — en waar de sterretjes leven
Pinecone publiceerde naast de lancering van Nexus een benchmark genaamd KRAFTBench (Knowledge Retrieval Assessment Framework for Text). Elk getal dat volgt is de claim van Pinecone. Niets ervan is onafhankelijk gereproduceerd op de dag dat ik dit schrijf, en ik wil dat je elk cijfer leest met dat voorbehoud in gedachten.
Met deze kanttekeningen:
- Het tokengebruik per zoekopdracht daalde van ongeveer 49.000 naar ongeveer 6.000 – een vermindering van ongeveer 88 procent.
- De taakvoltooiing op de financiële analysebenchmark bereikte ongeveer 100 procent, tegenover 50-60 procent voor de agentische RAG-basislijn en ongeveer 62,7 procent voor een AI-codeerbasislijn.
- Tooloproepen per zoekopdracht zijn gedaald van zes of meer naar één: één enkele declaratieve oproep.
- De latentie is aanzienlijk gedaald (Pinecone claimt een tot 30x snellere tijd tot voltooiing).
- De basislijn van de codeeragent AI waartegen Nexus meette, verbrandde ongeveer 528.000 tokens per zoekopdracht. Bij één financiële analysetaak claimt Pinecone een zoekopdracht die voorheen 2,8 miljoen tokens verbruikte, aangevuld met ongeveer 4.000 – een reductie van 98 procent.
Deze cijfers zijn opvallend. Ze zijn ook een leveranciersbenchmark voor een taakcategorie die de leverancier heeft geselecteerd. De eerlijke lezing is: richtinggevend is dit wat het verschuiven van werk van querytijd naar compileertijd zou moeten doen. De exacte omvang zal er anders uitzien in uw werklast, mogelijk zelfs erger. Waarschijnlijk nog steeds een substantiële verbetering ten opzichte van herhaalbare gestructureerde taken. Mogelijk slechter dan agent RAG bij verkennende long-tail-vragen. We zullen het pas echt weten als er onafhankelijke evaluaties komen – en ik verwacht die in de loop van de zomer.
Waar ik steeds op terugkom is de vorm van de verbetering, niet de grootte. Van zes tooloproepen naar één gaan is geen tuning-overwinning. Het is een architecturale ineenstorting. U kunt agent RAG voor altijd blijven optimaliseren en nooit "één declaratieve oproep" bereiken, omdat de lus structureel is voor de aanpak. Gecompileerde artefacten komen daar omdat ze de lus volledig hebben verwijderd.
Dat is het deel waarvan ik denk dat de meeste dekking onderbieding is.
Hoe een Nexus-workflow er eigenlijk van begin tot eind uitziet
Laat ik dit concreet maken met de voorbeeldworkflow die Pinecone tijdens de aankondiging liet zien, want de abstractie breekt open zodra je de pijplijn ziet.
Je hebt een map met contracten in Box of Google Drive. Een paar honderd pdf's, elk verschillend, meestal met uittrekbare tekst, maar een niet triviaal percentage met tabellen, handtekeningblokken, exposities en ingesloten wijzigingen. De taak die u door uw agent wilt laten uitvoeren: beantwoord vragen over verlengingsvoorwaarden voor de gehele portefeuille. Dingen als "welke contracten worden automatisch verlengd binnen de komende 90 dagen", "wat is de gemiddelde opzegtermijn voor verlenging bij onze top 20 leveranciers", "welke contracten hebben roltrapclausules die zijn gekoppeld aan CPI versus een vast percentage."
Onder agent RAG is dit elke keer een dans met meerdere tools. De agent haalt een paar kandidaat-brokken op. Leest ze. Realiseert zich dat er meer context nodig is. Opnieuw vragen. Haalt gerelateerde contracten op. Probeert te aggregeren. Hallucineert een clausule. Opnieuw ophalen om te verifiëren. Stelt uiteindelijk een antwoord op. Veertigduizend tokens later krijg je iets bruikbaars. Misschien.
Onder Nexus ziet de pijplijn er als volgt uit:
- Brongegevens — De contracten staan in Box of Drive. Daar verandert niets aan. 2. Parsen — Pinecone kan worden geïntegreerd met de Unstructured-service, die de daadwerkelijke tekst plus de tabellen, entiteiten en structurele elementen extraheert. Dit is gewoon moderne parsering – niets exotisch. 3. Compilatie — De contextcompiler voert de geparseerde uitvoer uit en evalueert deze aan de hand van een testset van de vraagvormen die u interesseren. Het synthetiseert artefacten. Eén artefact zou een gestructureerde tabel kunnen zijn waarin de verlengingsvoorwaarden voor elk contract in de portefeuille worden verzameld, waarbij de herkomst terugverwijst naar de brondocumenten. Een ander voorbeeld zou een relatiegrafiek kunnen zijn die oudercontracten koppelt aan wijzigingen. De compiler bouwt deze één keer, bij opname. 4. Artefact — Het gecompileerde artefact is datgene waar de agent daadwerkelijk vragen over stelt.
Voor de ‘gemiddelde opzegtermijn voor verlenging bij onze top 20 leveranciers’ verzamelt het artefact die gegevens al met citaten op veldniveau. Het uitzoeken welke contracten meetellen als "top 20 leveranciers" en welke clausules meetellen als "opzegtermijn voor verlenging" werd tijdens het compileren gedaan. 5. Query — De agent voert een enkele KnowQL-aanroep uit met intentie, filter, herkomstvereisten en uitvoervorm. 6. Reactie — Nauwkeurig, gestructureerd, geciteerd, geen agentloop.
In die laatste stap vindt de filosofische verschuiving plaats. Het antwoord is precies omdat het artefact voor deze vraagvorm is gebouwd. Het is gestructureerd omdat KnowQL de uitvoervorm heeft gespecificeerd. Het wordt geciteerd omdat de compilatie de herkomst terugvoert naar de brondocumenten. En er is geen agentloop, omdat er niets meer te achterhalen valt op het moment van de query: het uitzoeken is al gebeurd.
Lees nu dezelfde zes stappen en stel uzelf de vraag die ik stelde toen ik het diagram voor het eerst zag: wat gebeurt er als iemand een vraag stelt die de compiler niet had verwacht?
Want dat is het addertje onder het gras. En het is een echte.
Waar gecompileerde kennis breekt
Ik wil eerlijk zijn over de limieten, want elke "dit verandert alles"-post die de limieten niet aanpakt, verkoopt iets.
Nexus blinkt uit bij bekende, herhaalbare, goed gespecificeerde zoekopdrachten. Voorwaarden voor contractverlenging. Vragen van financieel analisten over een bekende structuur voor het indienen van inkomsten. Klantenondersteuningsvragen op basis van een stabiele kennisbank. Compliancevragen tegen een vaste regelgeving. Dit zijn werklasten waarbij de vraagvormen van tevoren bekend zijn, de gegevens voldoende gestructureerd zijn om op basis daarvan te kunnen worden samengesteld, en de kosten van het foutief zijn hoog genoeg om het compilatiewerk vooraf te rechtvaardigen.
Nexus gaat worstelen met verkennende, lange of nieuwe vragen – het soort waarbij je van tevoren niet weet wat je nodig hebt. Als je een onderzoeksagent bouwt die op basis van vermoedens door een documentcorpus dwaalt, kunnen samengestelde artefacten niet op elk vermoeden anticiperen. De evaluatieverzameling van de compiler is eindig. De ruimte van mogelijke vragen is dat niet.
Een paar specifieke risico's die ik wil noemen:
Onderhoud van artefacten. Pinecone zegt dat artefacten worden bijgewerkt wanneer de onderliggende gegevens veranderen, maar de kosten voor hercompilatie zijn werkelijk onzeker. Als uw gegevens elk uur veranderen en het opnieuw compileren per artefact minuten duurt, wordt de wiskunde snel lelijk. Voor statische of langzaam veranderende gegevens – de meeste ondernemingscontracten, de meeste wettelijke documenten, de meest stabiele kennisbanken – is dit geen probleem. Voor gegevens met hoge snelheid is dit een echte vraag.
Samengestelde fouten tijdens het compileren. De compiler is een LLM-agent die gestructureerde artefacten produceert. LLM's hallucineren. Als de compiler tijdens het bouwen een verkeerde aggregatie hallucineert, zal elke zoekopdracht tegen dat artefact met volledig vertrouwen het verkeerde antwoord en een valse bronvermelding retourneren. Pinecone verzacht dit met de eval-set - de compiler optimaliseert op basis van uitstaande testgegevens - maar geen enkele eval-set dekt alles. Afwijking van bron naar artefact is een categorie fouten die niet bestond in standaard RAG, waar de bron en de opgehaalde tekst hetzelfde waren.
Fallback-gedrag is onduidelijk. Wat gebeurt er als de agent een KnowQL-query verzendt die niet overeenkomt met een gecompileerd artefact? Valt het terug op traditioneel ophalen? Komt hij leeg terug? Leidt dit tot een hercompilatie? De lanceringsmaterialen zijn hierover stil, en het antwoord is enorm belangrijk voor productie-implementaties.
De kosten voor de bouwtijd zijn niet nul. De zoektijd is goedkoop omdat de compilatie al heeft plaatsgevonden. Maar compilatie is een autonome coderingsagent die tegen uw volledige corpus werkt. Dat is echte rekenkracht, echte modelgevolgtrekking, echt geld. Voor kleine datasets is dit verwaarloosbaar. Voor corpora op ondernemingsniveau is de bouwtijdrekening een budgetcategorie die niemand eerder heeft hoeven voorspellen.
De nette manier om hierover na te denken: Nexus verlegt de afweging van 'elke zoekopdracht duur' naar 'elke hercompilatie duur, elke zoekopdracht goedkoop'. Voor werklasten met een hoog aantal zoekopdrachten tegen stabiele gegevens is die wiskunde geweldig. Voor workloads met een laag queryvolume tegen vluchtige gegevens is de wiskunde slechter. Je moet je werklast kennen voordat je weet of de architectuur past.
De vergelijkingskaart: Nexus, LLM Wiki, Kenniscatalogus, Fabric IQ
Nexus komt niet in een vacuüm aan. Het patroon van verzamelde kennis convergeert vanuit ten minste vier richtingen, en het is de moeite waard om ze op dezelfde kaart te zien, omdat ze een gemeenschappelijke diagnose delen, maar naar verschillende oplossingen streven.
Karpathy's LLM Wiki, die ik in detail heb besproken toen ik een kennisbank met prijsverlaging in Obsidian bouwde, is de infrastructuur-light-versie van hetzelfde idee. Deponeer grondstoffen in een map. Voer een LLM-compilatiepas uit die gestructureerde wikipagina's, indexen en kruislinks produceert. Query's uitvoeren op de wiki door de index te lezen. Geen vectordatabase. Geen insluitingen. Geen KnowQL. Gewoon afwaarderen en een LLM die de structuur begrijpt die het heeft gebouwd.
De LLM Wiki en Nexus zijn het eens over de kernstelling: bouw de structuur op tijdens opname, niet tijdens de zoekopdracht. Ze zijn het niet eens over de infrastructuur: de versie van Karpathy draait op Obsidian, Claude Code en jouw bestandssysteem. Nexus draait op de gehoste database van Pinecone, KnowQL, en de contextcompiler. De Wiki is geschikt voor persoonlijke kennisbanken van minder dan ongeveer 400.000 woorden. Nexus is geschikt voor gegevens op ondernemingsniveau met taakspecifieke compilatiebehoeften die geen enkele afwaarderingsstructuur kan uitdrukken.
Beide zijn correct. Ze bezetten verschillende schalen.
De Cloud Knowledge Catalog van Google (voorheen Dataplex Universal Catalog, hernoemd in april 2026) bewandelt een derde pad. Het bouwt een continue semantische laag bovenop gestructureerde gegevens en stelt deze via Model Context Protocol-eindpunten bloot aan agenten. De semantische laag is dynamisch (het synthetiseert context uit schema's, querylogboeken en Looker-modellen) en de binding aan de zakelijke betekenis gebeurt grotendeels handmatig. Waar Nexus een autonome compiler gebruikt om artefacten uit onbewerkte data te produceren, gebruikt Knowledge Catalog door mensen gedefinieerde ontologie om agenten te gronden in de organisatorische waarheid. Beide verminderen hallucinaties. Ze doen dit via tegenovergestelde uiteinden van het structurerende spectrum.
De Fabric IQ Ontology van Microsoft (momenteel in preview) ligt dichter bij de Google-aanpak dan de Pinecone-aanpak. Fabric IQ stelt een grafiekontologie samen (entiteitstypen, relaties, eigenschappen, voorwaarde-actieregels) die agenten doorzoeken via MCP-eindpunten. De grafiek is expliciet. Het schema is expliciet. De semantische binding is handmatig. Routing is deterministisch omdat de structuur deterministisch is. Fabric IQ is het antwoord voor organisaties die hun AI-agents willen baseren op een door mensen samengesteld ondernemingsvocabulaire met strikt beheer.
Deze tegen elkaar in kaart brengen:
- Pinecone Nexus — autonome compilatie, taakgeoptimaliseerde artefacten, declaratieve agent-native querytaal (KnowQL). Hoge automatisering, snelle iteratie, door de leverancier gedefinieerde query-semantiek.
- Karpathy's LLM Wiki — handmatige of semi-automatische compilatie in markdown, navigatie door indexen. Infrastructuur-licht, lage ceremonie, schaalbaar tot misschien 400.000 woorden.
- Google Knowledge Catalog — doorlopende semantische laag met handmatige ontologiebinding, MCP-blootgesteld. Sterk in bestuur, afhankelijk van door mensen samengestelde ontologie.
- Microsoft Fabric IQ — samengestelde ontologiegrafiek, expliciete relaties, MCP-blootgestelde, deterministische routing. Het sterkste bestuur, het langzaamst op te zetten.
Het patroon bij alle vier: doe het structurerende werk stroomopwaarts van de agent, niet bij elke vraag. De verschillen gaan over waar de structurering plaatsvindt, wie het doet en hoe de agent met het resultaat praat.
Die convergentie is het signaal. Vier heel verschillende bedrijven, vier heel verschillende stapels, die allemaal dezelfde architecturale conclusie bereiken. Als dat gebeurt, is de conclusie meestal juist.
Wat dit op dit moment betekent voor iedereen die agenten bouwt
Terugkijkend op de aankondiging, is hier het concrete advies dat ik mezelf een jaar geleden zou geven.
Stop met het toevoegen van meer agency aan uw ophaallus. Als uw agent faalt omdat het ophalen luidruchtig is, zullen meer iteraties het probleem niet oplossen. Meer tools zullen het niet oplossen. Een groter model lost dit niet op. Het ophalen is verkeerd en de redenering kan de stroomopwaartse ruis niet compenseren. De volgende stap is het compileren van de gegevens in een vorm die overeenkomt met de vragen, en niet het ophalen van de gegevens in een andere agent.
Begin vroeg met het stellen van de evaluatiesetvraag. Wat Nexus doet wat standaard RAG niet kan, is het optimaliseren van de compilatie op basis van een bekende set vraagvormen. Dat veronderstelt dat u weet waar uw agent voor is. Als u de twintig belangrijkste vraagvormen waarmee uw agent te maken krijgt niet kunt verwoorden, bent u nog niet klaar om kennis te verzamelen. U bevindt zich nog in de verkenningsfase en agent RAG is nog steeds het juiste hulpmiddel. De volwassenheidscurve luidt: verkennende agent → stabiele use case → samengestelde kennislaag. Als u de middelste stap overslaat, wordt de evaluatieset overgeslagen, wat betekent dat het hele uitgangspunt van de compilatie wordt overgeslagen.
Behandel gecompileerde kennis als een implementatiemijlpaal. Wanneer een werklast verandert van "we zijn aan het uitzoeken wat we moeten vragen" naar "we stellen herhaaldelijk dezelfde vormen van vragen", is dat het moment om over te stappen van agentische RAG naar een gecompileerde laag. Nexus, LLM Wiki, Fabric IQ - kies degene die bij uw schaal past. De trigger is hetzelfde.
Hybride is het antwoord, geen compromis. Agentic RAG blijft het juiste hulpmiddel voor echt verkennend werk. Een onderzoeksagent die door een corpus dwaalt en nieuwe vragen volgt, zal beter presteren dan de verzamelde kennis over die nieuwe vragen, omdat de samensteller daarop niet kan anticiperen. De architectuur die ik in 2026 en 2027 verwacht te winnen is hybride: gebundelde kennis voor de hoogwaardige, herhaalbare, governance-kritische workloads, en agentische RAG voor verkenning. De twee zijn complementair en geen vervanging.
Bekijk de evaluatiediscipline die bij deze verschuiving hoort. Compilatie tegen een evaluatieset is een disciplineverschuiving. Het dwingt je om de uitvoervormen, de betrouwbaarheidsvloeren, de latentiebudgetten en de citatievereisten vooraf te specificeren. Die specificiteit is goed voor de kwaliteit van agenten, ongeacht of u ooit Nexus adopteert. Zelfs als je op agent RAG blijft, zal het schrijven van je evaluatieset op de manier waarop Nexus wil dat je het schrijft, foutmodi aan het licht brengen die je hebt genegeerd.
In mijn eigen werk heb ik agenten door deze transitie heen geduwd. De contractagent die ik bovenaan dit bericht noemde, is de eerste werklast die ik verplaats van agentic RAG naar een gecompileerd artefactpatroon - gedeeltelijk met behulp van Nexus waar het in vroege toegang is, gedeeltelijk mijn eigen contextcompiler bouwend tegen een kleinere evaluatieset voor de delen waar ik volledige controle wil. Het eerste signaal is wat de benchmarks van Pinecone suggereren: wanneer je compileert, is de agent niet langer een bibliothecaris, maar een redenaar. De symbolische kosten storten in. Het non-determinisme verdwijnt grotendeels. Auditing wordt mogelijk omdat elk antwoord zijn samengestelde herkomst heeft.
Dat laatste punt – controleerbaarheid – is volgens mij het punt dat uiteindelijk het belangrijkst zal zijn in gereguleerde sectoren. Wanneer een agent een vraag beantwoordt door gegevens op te halen uit een gecompileerd artefact met citaten op veldniveau, kunt u bewijzen wat hij wist en waar hij dat vandaan wist. Agentic RAG heeft je dat nooit gegeven. Het ophaalpad was elke keer anders. Het audittraject was een fictie. Gecompileerde kennis is de eerste architectuur waarin antwoorden van agenten kunnen worden verdedigd in een nalevingsbeoordeling zonder met de hand te zwaaien.
Ik heb een deel van deze discipline al behandeld toen ik schreef over waarom context-engineering beter is dan configuratie – hetzelfde principe schaalt op. Configureer minder. Bedenk de structuur van wat de agent leest. Verplaats het werk stroomopwaarts.
De eerlijke weddenschap op wat wint
Hier is de voorspelling die ik bereid ben op papier te zetten.
Over 18 maanden zal de standaardarchitectuur voor hoogwaardige enterprise-agents bestaan uit samengestelde kennislagen – onder welke leveranciersnaam dan ook. Pinecone Nexus vandaag, maar het patroon is groter dan het product. De bedrijven die hierop gokken – Pinecone, Microsoft, Google, plus degene die de volgende golf zal lanceren – hebben gelijk wat betreft de richting. Of hun specifieke implementaties winnen, staat open. De structurele verschuiving is dat niet.
Agentic RAG zal niet verdwijnen. Het zal zich terugtrekken in de werklast waar het eigenlijk past: verkennende onderzoeksagenten, ad-hocanalyses, situaties waarin de vraagvorm werkelijk onbekend is. Dat is een kleiner oppervlak dan werd aangenomen in de periode 2024-2025, maar het is niet nul. Het eerlijke kader is dat we agent RAG te veel hebben toegepast omdat dit het enige hulpmiddel was dat we hadden. Nu hebben we twee instrumenten. We staan op het punt te ontdekken welke werklasten bij welke horen.
De bouwers die in 2026 de meeste invloed krijgen, zullen degenen zijn die deze transitie vroeg correct lezen. Dat betekent dat u nu moet beginnen met het formuleren van de evaluatieset voor uw hoogwaardige workloads, zelfs als u nog niet klaar bent om te compileren. Het betekent dat u de onafhankelijke benchmarks van Nexus en zijn concurrenten in de gaten moet houden terwijl deze deze zomer landen. Het betekent experimenteren met KnowQL – of equivalenten daarvan – zodat u kunt denken in declaratieve agent-native querytalen voordat deze verplicht worden. En het betekent dat je weerstand moet bieden aan het instinct om nog een iteratielus toe te voegen aan je bestaande agentische RAG-pijplijn, terwijl het de juiste zet is om de lus volledig te verwijderen.
I want to land this on the metaphor that finally made the architecture click for me.
Agentic RAG was de agent die elke ochtend een bibliotheek binnenliep, de bibliothecaris om een boek vroeg, het las, om een ander boek vroeg, het las, aantekeningen maakte, om een derde boek vroeg en uiteindelijk met een antwoord naar buiten liep. Elke ochtend. Voor elke vraag. Zelfs dezelfde vragen.
Verzamelde kennis is dat de bibliothecaris van de ene op de andere dag een aangepaste encyclopedie voor de agent schrijft, precies afgestemd op de vragen die de agent gaat stellen, waarbij elk feit wordt aangehaald en elke relatie vooraf wordt getraceerd. De agent loopt de bibliotheek binnen, opent de encyclopedie op de rechterpagina, leest één artikel en loopt naar buiten. Hetzelfde antwoord. Eén procent van het werk.
We betalen al twee jaar de prijzen van agenten RAG omdat niemand de encyclopedie had geschreven. Pinecone Nexus is de weddenschap dat 2026 het jaar is waarop de encyclopedie wordt geschreven. Of u Nexus specifiek adopteert, is een kleinere vraag dan of u het patroon overneemt.
Als uw agent nog elke ochtend de bibliotheek binnenloopt, komt de encyclopedie voor die workflow. De enige vraag is of u het op uw eigen voorwaarden schrijft – of eerst ziet hoe uw concurrenten die van hen samenstellen.
Veelgestelde vragen
Wat is Pinecone Nexus en waarin verschilt het van de gewone RAG?
Pinecone Nexus is een kennisengine voor AI-agents die het ophaalwerk verplaatst van de tijd van de query naar de tijd van het compileren. In plaats van bij elke zoekopdracht onbewerkte stukken op te halen, compileert Nexus taakspecifieke gestructureerde artefacten vooraf bij opname met behulp van een contextcompiler, en agenten ondervragen die artefacten via KnowQL – de declaratieve querytaal van Pinecone – in één enkele toolaanroep. Reguliere RAG haalt op aanvraag op. Nexus doet het ophaalwerk vooraf. Zie de workflow-walkthrough hierboven voor de volledige architectonische uitsplitsing.
Wat is KnowQL en waarom is het belangrijk voor AI-agents?
KnowQL is de declaratieve querytaal van Pinecone voor agenten, met zes primitieven: intentie, filter, herkomst, uitvoervorm, vertrouwen en budget. Het is belangrijk omdat het agenten een vocabulaire geeft voor toegang tot kennis dat aansluit bij de manier waarop agenten redeneren – waarbij aangepaste tooldefinities en op maat gemaakte retrieval-lijmcode worden vervangen door een enkele declaratieve oproep. KnowQL is voor agenten wat SQL was voor databases.
Zal Pinecone Nexus agent RAG volledig vervangen?
Nee. Samengestelde kennislagen zoals Nexus blinken uit in herhaalbare, goed gespecificeerde zoekopdrachten tegen stabiele gegevens. Agentic RAG blijft het juiste hulpmiddel voor verkennend werk en long-tail vragen waarbij de vraagvorm vooraf onbekend is. De architectuur die in 2026 wint is hybride: gebundelde kennis voor hoogwaardige, governance-kritische workloads, agentische RAG voor verkenning.
Hoe verhouden Pinecone Nexus, Karpathy's LLM Wiki en Microsoft Fabric IQ zich tot elkaar?
Alle drie de bewegingen structureren zich stroomopwaarts van de agent, maar op verschillende schaalniveaus. Karpathy's LLM Wiki kent een prijsverlaging en weinig infrastructuur, ideaal voor persoonlijke kennisbanken van minder dan 400.000 woorden. Fabric IQ Ontology bouwt een expliciete, door mensen samengestelde grafiek voor ondernemingsbestuur. Pinecone Nexus maakt gebruik van een autonome contextcompiler die is geoptimaliseerd voor evaluatiesets, tussen de handmatige benadering van Fabric IQ en de lichtgewicht benadering van LLM Wiki.
Wat zijn de risico's van de overstap van agent RAG naar een gecompileerde kennislaag?
Vier belangrijke risico's: de kosten voor het opnieuw compileren van artefacten op vluchtige gegevens, LLM-hallucinaties die tijdens het compileren worden geïntroduceerd en die zich voortplanten naar elke downstream-query, onduidelijk terugvalgedrag voor query's die de compiler niet had verwacht, en betekenisvolle rekenkosten tijdens het bouwen die niet bestonden in standaard RAG. Gecompileerde kennis wint aan stabiele data met herhaalbare queries. Het worstelt met snelle gegevens en verkennende werklasten.
Laten we samenwerken
Wilt u AI-systemen bouwen, workflows automatiseren of uw technische infrastructuur schalen? Ik help je graag.
- Fiverr (aangepaste builds en integraties): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (ondernemingsoplossingen): ramlit.com
- ColorPark (ontwerp en branding): colorpark.io
- xCyberSecurity (beveiligingsdiensten): xcybersecurity.io
