RAG, MCP & agents — AI verbinden met kennis en acties #

Een kaal LLM kent alleen wat het tijdens training leerde; RAG geeft het een bibliotheekkaart (relevante documenten ophalen), MCP geeft het gereedschap (live data opvragen en handelen), en een agent combineert dat tot plannen-en-uitvoeren.

Inhoud #

De drie rollen (kies het juiste gereedschap) #

• LLM = het brein. Interne kennis, bevroren op de cutoff. Top voor redeneren, schrijven, bekende code, vertalen. Faalt bij actuele/private data en exacte recall.
• RAG = de bibliothecaris. Haalt relevante stukken uit een vaste verzameling (documenten, wiki, beleid) en geeft die mee aan het model. Voor kennis die in een corpus staat en niet elke minuut verandert. Faalt bij live data en bij handelen.
• MCP = de gereedschapskist. Standaard om het model live een database te laten bevragen, een API aan te roepen, bestanden te lezen/schrijven, een ticket aan te maken. Voor real-time data en acties. Kost setup, latency en vraagt om beveiliging. Volledig uitgewerkt in [[wiki/tools/mcp-model-context-protocol]].
• ⚠️ De vaak gebruikte metafoor “USB-C voor AI” heeft geen bronsteun in het MCP-bronnencluster (acht bronnen, april–juli 2026; geen enkele gebruikt hem) en gaat op twee punten kreupel: USB-C is symmetrisch terwijl bij MCP de rolverdeling vastligt (de client start de server, de server is passief), en USB-C suggereert plug-and-play terwijl er bij MCP een configuratiebestand en per-aanroep-goedkeuring aan te pas komen. Bruikbaar als openingsbeeld, niet als uitlegmodel — zie het oordeel over alle metaforen in [[wiki/tools/mcp-model-context-protocol]].

Vuistregel: begin met het simpelste dat werkt (kaal LLM) → voeg RAG toe als je antwoorden in een corpus moet gronden → pak MCP als de AI met de wereld moet interacteren, niet alleen erover praten.

In de praktijk is het geen keuze maar een combinatie. De bron van deze driedeling (Pravash, Level Up Coding, 1 juni 2026) beschrijft zijn eigen eindconfiguratie als beide tegelijk: RAG voor documentatie die traag verandert (onboarding, architectuurbesluiten, runbooks) en MCP voor alles wat live systemen raakt. De scherpste hulpvraag om te kiezen: moet er na afloop iets veranderd zijn in een systeem? Ja → altijd MCP; RAG kan principieel niets veranderen.

Hoe RAG werkt #

Drie stappen: Retrieve → Augment → Generate (“open-boek-examen”).
1. Ingestion & chunking — documenten opknippen in stukken. Te groot = ruis; te klein = contextverlies. Strategieën: recursief splitsen, semantisch, parent-child, late chunking.
2. Embeddings & vector database — elk stuk wordt een vector, opgeslagen in een vector-DB (Pinecone, Weaviate, Chroma, Qdrant, pgvector).
3. Hybride zoeken + reranking — combineer semantisch (vector) met trefwoord (BM25), en sorteer daarna opnieuw op relevantie. Dit is de 2026-standaard; pure vector-search schiet vaak tekort.

Belangrijk: RAG lost hallucinatie niet automatisch op. Slechte retrieval → mooi geschreven, maar fout antwoord. “RAG is een geweer dat nog steeds gericht moet worden.” Naïeve pijplijnen falen ~40% bij retrieval; vandaar reranking en (agentic) verfijning.

RAG is geen geheugen #

Een veelgemaakte fout is een RAG-pijplijn aan een agent plakken en dat “geheugen” noemen. Het zijn twee verschillende problemen:

	RAG	Geheugen
Beantwoordt	wat staat er in onze documenten?	wat weet het systeem over déze gebruiker of dit traject?
Bron	een vaste verzameling (proprietary dataset knowledge)	wat er tijdens gesprekken en handelingen ontstaat (user-specific persistence)
Gedrag bij verandering	stapelt: het oude document blijft naast het nieuwe staan	werkt bij of verwijdert, met een expliciete keuze per feit

RAG haalt op en vergeet; een geheugenlaag legt selectief vast, werkt bij en haalt gericht terug. Uitgewerkt in [[wiki/fundamenten/ai-geheugen]]; de producten staan in [[wiki/tools/geheugenlagen-voor-agents]].

GraphRAG — en de vraag of het genoeg is #

Baseline RAG hakt documenten in losse chunks en zoekt op gelijkenis. Dat werkt goed voor lokale vragen (“wat is de levertijd?”) en faalt zodra een antwoord vereist dat je de puntjes verbindt tussen losse stukken: een narratieve boog, een complexe organisatiestructuur, of een globale vraag als “wat zijn de vijf grootste thema’s in deze data?” — daar valt namelijk geen enkele “gelijkende” chunk voor terug te halen.

GraphRAG brengt niet alleen entiteiten in kaart maar ook hun relaties. Twee toevoegingen die de bron uitlicht:
– Weighted graphs (attributie: IBM Research) — de LLM kwantificeert de sterkte van verbindingen, waardoor het systeem herkent dat “immunoloog” niet zomaar een woord naast “zorgbedrijf” is maar een primaire knoop in een groter geheel.
– Hiërarchische semantische clusters (attributie: Microsoft Research) — vooraf samengevatte thema’s op verschillende abstractieniveaus, zodat globale vragen wél beantwoordbaar worden.
– Provenance — in de aangehaalde casestudy kon het systeem claims terugkoppelen naar specifieke knopen (in dat voorbeeld 6.494 entiteiten en 15.211 relaties), zodat een gebruiker de output kan auditen tegen de brondata.

⚠️ Twee bronnen, twee conclusies — bewust niet samengevoegd.

Standpunt	Bron	Kern
GraphRAG is de oplossing	blog.devwithawais.com, 3 april 2026	GraphRAG lost de tekortkomingen van baseline-RAG op en levert whole-dataset reasoning plus traceerbaarheid. Gepresenteerd zonder voorbehoud; het stuk is in feite een pleidooi voor GraphRAG + Mem0, met citaten van Microsoft Research en IBM Research — partijen die de bijbehorende stack verkopen.
GraphRAG is een techniek, geen architectuur	Medium (Vimal Dwarampudi), 31 mei 2026	“GraphRAG improves grounding. It does not provide formal domain understanding. The model is still guessing — just with better raw material to guess from.” Zonder ontologie en validatielaag blijft de LLM zelf beslissen hoe hij de opgehaalde graafdata interpreteert.

De jongere bron sluit de oudere niet logisch uit — ze erkent dat GraphRAG de grounding verbetert. Maar de praktische conclusie verschilt fundamenteel: “bouw GraphRAG” tegenover “GraphRAG alleen is precies waar teams te vroeg stoppen”. Beide zijn Medium-publicaties van individuele auteurs zonder benchmark. Onbeslist.

De semantische laag: ontologie, knowledge graph, orkestratie #

Het argument van de tweede bron hierboven is dat betere retrieval het correctheidsprobleem niet oplost. Waar een antwoord correct moet zijn en niet alleen plausibel — zorg, financiën, juridische regels, enterprise search — zet zij drie lagen vóór het model:

Component	Wat het is	Wat het níét is
Ontologie	het betekenismodel: welke soorten dingen bestaan, welke relaties tussen die dingen legaal zijn, en welke regels een geldige combinatie bepalen	geen schema. Een schema zegt welke velden er zijn; een ontologie wat dingen betekenen. Slaat zelf geen feiten op
Knowledge graph	de feiten die op dit moment daadwerkelijk waar zijn in het domein, met herkomst	geen gegeneraliseerde kennis en geen trainingsdata-statistiek
Semantische orkestratielaag	de brug: intentie mappen op concepten, de query annoteren vóór retrieval, en opgehaalde data valideren tegen de ontologie voordat de LLM die ooit ziet	geen tool-keuze maar een architecturale rol

Onderliggend feitenmodel is RDF: elke uitspraak is een triple van subject, predicaat en object (ProductA → hasFeature → "waterproof"). Precies en machineleesbaar, maar zonder ontologie weet het systeem niet wat de uitspraak betekent of of hij überhaupt geldig is — waterproof mag wél bij een jas horen en niet bij een koptelefoon. Een veelgebruikt ordeningsraamwerk daarbij is POLE+O: Person, Object, Location, Event, plus de ontologie die die vier pijlers formele betekenis geeft.

De kern in één zin van de bron: “The LLM’s job becomes writing, not reasoning.” Het model is de laatste stap, niet de eerste — de gestructureerde lagen doen het redeneren en de validatie, het model maakt er lopende taal van.

Waarom dit ook zonder ontologiebouw relevant is: het maakt zichtbaar dat de reeks kaal LLM → RAG → MCP een complexiteitsladder is, geen betrouwbaarheidsladder. Ook met perfecte retrieval blijft het model interpreteren. Wil je zekerheid, dan moet de controle buiten het model liggen — precies het principe uit [[hallucinaties-voorkomen-controlelaag]].

⚠️ Deze bron is een architectuurbetoog zonder één cijfer of benchmark, met een duidelijke voorkeur voor het semantic-web-erfgoed (RDF, OWL, ontologieën). Geen zichtbaar commercieel belang, wel een schoolstandpunt.

Function calling, MCP en agents #

• Function calling / tool use — het model vráágt om een tool met gestructureerde argumenten; jouw systeem voert die (gevalideerd) uit en geeft het resultaat terug.
• MCP — standaardiseert die koppeling, zodat tools herbruikbaar zijn over apps heen. MCP vervangt function calling niet, het voedt het: de client vertaalt de MCP-tools naar het formaat van het model dat toevallig gebruikt wordt. Zie [[wiki/tools/mcp-model-context-protocol]] voor het onderscheid, en voor MCP versus een gewone API (een API is een deur; MCP is de afspraak hóé je deuren beschrijft).
• Agent — gebruikt LLM + tools om een doel na te streven: plannen → tool aanroepen → resultaat bekijken → bijsturen. Patronen: ReAct (redeneer-handel-observeer), planner-executor (plan eerst, voer dan uit), multi-agent (gespecialiseerde agents). Begin met één agent; voeg complexiteit alleen toe als een concreet faalpunt dat vereist.

Agent of workflow? De praktijktoets — toegevoegd 19 augustus 2026 #

De definitie hierboven beschrijft het patroon; in de praktijk wordt het woord “agent” gebruikt voor vrijwel alles waar een LLM in zit. Twee vragen scheiden ze:

1. Wie bepaalt de volgorde? Ligt het pad vooraf vast (de mens besliste, de LLM vult in), of kiest het systeem per geval zelf een actie uit een afgebakende ruimte?
2. Komt het resultaat terug in het systeem? Leest het de eigen uitkomst terug en past het de volgende ronde aan, of eindigt elke run bij het antwoord?

Cron + terugkoppeling = agent. Prompt + antwoord = workflow, hoe slim het antwoord ook is. Toegepast op zes praktijkbronnen over marketing-agents (augustus 2026) doorstaat vrijwel niets die toets — uitgewerkt in [[wiki/toepassingen/marketing-agents-workflow-of-agent]]. Dat sluit aan bij Anthropic’s eigen agentrichtlijn, in die bronnen geciteerd als: “many agent problems should start as workflows… founders should earn autonomy.” Autonomie is een verdiende positie, geen startpunt; de aanbevolen startvorm is draft-and-approve (systeem schrijft een concept, mens keurt goed), met daarboven triage, coördinator en pas als laatste begrensde actie (één afgebakende handeling onder duidelijke regels).

Waar de architectuur in de praktijk aan hangt #

Twee waarnemingen uit datzelfde cluster die het architectuurbeeld hierboven aanvullen — beide beschrijvingen zonder meting, geen bewezen praktijk:

• De datalaag is het werk, niet het model. De consistente opbouw in die bronnen: datapijplijn → warehouse → gewone code op een cron → LLM alléén waar oordeel nodig is → resultaat terug het warehouse in. Agentframeworks worden er expliciet afgeraden (“a lot of the times you don’t need it, it’s just bloat”). De genoemde faalmodi van de vorige generatie — API rate limits, MCP-failures, afgekapte responses, context window bloat — zijn stuk voor stuk datalaag- en contextproblemen, geen modelproblemen; zie [[wiki/fundamenten/context-engineering]].
• Multi-agent: twee ontwerpideeën, geen bewijs. Een hiërarchie met een aansturende agent boven gespecialiseerde subagents, elk in een geïsoleerde instantie “so they don’t bleed over to each other”, plus één agent die de betrouwbaarheid van een andere bewaakt (“sometimes they become unreliable”). Beide plausibel en beide zonder faalanalyse of vergelijking met een enkelvoudige opzet. De vuistregel hierboven blijft dus staan: begin met één agent.
• Eén concreet regressiemechanisme. Een eval-set van 50 echte gevallen met de juiste antwoorden erbij, opnieuw gedraaid bij elke wijziging van prompt, model, tools of workflow. Dat is in dat hele cluster het enige antwoord op de vraag wat er gebeurt bij een modelwissel — en daarmee het minimale dat je in een productie-opzet inbouwt.

Veiligheid (cruciaal bij tools/MCP/agents) #

Tool-toegang verandert “leuke demo” in “security review”. Risicopatroon: private data + onbetrouwbare content + uitgaande communicatie = een lek met een chat-interface. Behandel opgehaalde content en MCP-servers als onbetrouwbaar; gebruik minimale rechten, validatie, logging en menselijke goedkeuring bij gevoelige acties ([[verantwoord-ai-gebruik]]). Let op [[kernbegrippen-llm|prompt injection]].

Sleutelinzichten #

• De LLM/RAG/MCP-driedeling is hét mentale model om “hoe bouw/kies ik een AI-oplossing?” uit te leggen — uitstekend voor zakelijke trainingen.
• Voor de meeste organisaties is RAG op de eigen kennisbank de eerste echte stap voorbij “gewoon ChatGPT”.
• Koppel altijd aan [[privacy-risicos-llms|privacy]]: zodra je private data ophaalt of tools aanroept, wordt governance belangrijk.
• RAG en geheugen zijn niet hetzelfde. “Wat staat er in onze documenten” en “wat weet het systeem over jou” zijn twee verschillende bouwwerken; ze door elkaar halen is een van de vaakst gemaakte fouten bij agents.
• “Agent” is in de markt een verkoopwoord geworden. Twee vragen ontmaskeren het: wie bepaalt de volgorde, en komt het resultaat terug in het systeem. Cron + terugkoppeling = agent; prompt + antwoord = workflow. Autonomie is een verdiende positie, geen startpunt — begin bij draft-and-approve
• Meer retrieval maakt een antwoord beter gegrond, niet gegarandeerd juist. Zolang het model de opgehaalde feiten zelf mag interpreteren, blijft het gokken met beter ruw materiaal.

Inzetbaar voor #

• Training (zakelijk/IT): beslisboom “LLM vs RAG vs MCP” als kern-werkvorm.
• Infographic: de Retrieve→Augment→Generate-pijplijn.
• Blog: “Voorbij ChatGPT: zo zet je AI op je eigen documenten (RAG uitgelegd).”
• Video: “Wat is een AI-agent en wanneer heb je er een nodig?”

Gerelateerd #

• [[hoe-llms-werken]] — waarom een kaal model beperkt is (cutoff)
• [[hallucinaties]] — wat RAG wel/niet oplost
• [[kernbegrippen-llm]] — vector-DB, function calling, agent, prompt injection
• [[verantwoord-ai-gebruik]] · [[privacy-risicos-llms]] — governance bij tools/data
• [[ai-implementatie-agile]] — RAG + Human-in-the-Loop als implementatiepatroon voor productie
• [[hallucinaties-voorkomen-controlelaag]] — agents die feiten uit één bronsysteem trekken i.p.v. te gokken, plus een mechanische controlelaag eromheen
• [[aeo-answer-engine-optimization]] — retrieval/grounding is het mechanisme waarmee AI-zoekmachines je content citeren
• [[wiki/fundamenten/context-engineering]] — RAG als één onderdeel van een breder contextontwerp (write/select/compress/isolate)
• [[wiki/fundamenten/ai-geheugen]] — de andere helft van de kennisvraag: wat het systeem over de gebruiker onthoudt
• [[wiki/tools/geheugenlagen-voor-agents]] — de producten die deze geheugenlaag leveren, met hun vendorclaims
• [[wiki/toepassingen/marketing-agents-workflow-of-agent]] — de praktijktoets uit dit artikel toegepast op zes bronnen over marketing-agents: wat er werkelijk draait, wat alleen verteld wordt, en het researchagent-playbook
• [[wiki/markt-en-trends/van-uitvoerder-naar-dirigent]] — wat het orkestreren van zo’n keten met je vak doet
• [[wiki/tools/mcp-model-context-protocol]] — MCP uitgewerkt: rolverdeling, primitieven, de beslisregel, metaforen met oordeel, beveiliging en wat er níét gedekt is

Bronnen #

• [[RAW/LLM vs RAG vs MCP I Finally Know When to Use Each One.md]] — Pravash, Level Up Coding, 1 juni 2026, wanneer welk gereedschap + cheat sheet. Geen commercieel belang. ⚠️ Het codevoorbeeld onder het kopje “MCP: The Toolkit” ís geen MCP — het is Anthropic tool use met een handgeschreven agentic loop (eigen uitvoerfunctie, while-lus), zonder server, client of protocol. De proza-uitleg en de driedeling hierboven blijven overeind; het codevoorbeeld mag nooit als MCP-voorbeeld worden hergebruikt. Toegelicht in [[wiki/tools/mcp-model-context-protocol]] (§11, T4).
• [[RAW/RAG Systems The Complete Zero-to-Hero Guide (2026 Edition).md]] — Basukori, chunking/embeddings/hybride zoeken/reranking (2026-06)
• [[RAW/RAG Pipeline — LLM Concept.md]] — RAG-pijplijn in detail (dubbel aanwezig in RAW: zie lint)
• [[RAW/Modern AI and LLM Concepts.md]] — function calling, MCP, A2A, agents, veiligheid
• [[RAW/The End of AI Amnesia Why the Next Generation of Agents Won’t Forget You.md]] — Muhammad Awais, 3 april 2026, blog.devwithawais.com. GraphRAG, weighted graphs, hiërarchische clusters, en het onderscheid datasetkennis vs. gebruikerspersistentie. ⚠️ Pleidooi voor GraphRAG + Mem0; citeert Microsoft Research en IBM Research, beide partijen met een belang bij de stack.
• [[RAW/Ontologies, Knowledge Graphs, and a Semantic Layer The Architecture That Makes AI Stop Guessing.md]] — Vimal Dwarampudi, 31 mei 2026, medium.com. Ontologie, knowledge graph, semantische orkestratie, RDF, POLE+O; referentie-implementatie op GitHub. ⚠️ Architectuurbetoog zonder cijfers; geen commercieel belang zichtbaar.
• [[RAW/AI Agent Memory Systems in 2026 Mem0, Zep, Hindsight, Memvid and Everything In Between.md]] — Dev Genius, 20 maart 2026. Levert het “geheugen is geen RAG”-argument. ⚠️ Alle cijfers erin zijn vendorclaims; zie [[wiki/tools/geheugenlagen-voor-agents]].
• [[RAW/youtube_Marketing Agents Are Too Good Now.md]] (27 juli 2026) · [[RAW/youtube_How I Run a Marketing Agency With 6 AI Agents.md]] (15 juni 2026) · [[RAW/youtube_AI Agents are the new SaaS.md]] (1 juli 2026) — drie van zes videobronnen achter de praktijktoets en de architectuurwaarnemingen bij “Function calling, MCP en agents”. Leveren: de vierlaagsopbouw, de multi-agent-hiërarchie met geïsoleerde instanties, de eval-set van 50 en “earn autonomy”. ⚠️ Alle drie verkopende partijen; beschrijvingen zonder meting. Volledig oordeel inclusief herkomst in [[wiki/toepassingen/marketing-agents-workflow-of-agent]]; auteurschap van de derde is onbevestigd.