LLM-wiki’s, FDE’s en andere termen uit het AI-tijdperk begrijpen

Artificiële intelligentie heeft een volledig nieuw vocabularium geïntroduceerd in gesprekken over technologie en bedrijfsstrategie.

Organisaties horen dat ze AI-agents, Retrieval-Augmented Generation, context engineering, LLM-wiki’s, MCP-integraties en Forward Deployed Engineers nodig hebben.

Het probleem is dat deze termen vaak worden gebruikt voordat hun praktische betekenis duidelijk wordt uitgelegd.

Sommige termen beschrijven technologieën. Andere verwijzen naar softwarearchitecturen, technische functies of methoden om AI binnen een organisatie te implementeren.

Het is belangrijk om dat onderscheid te begrijpen.

Een bedrijf heeft niet noodzakelijk elk nieuw AI-concept nodig. Het moet bepalen welke combinatie van modellen, data, software en expertise een concreet operationeel probleem kan oplossen.

Deze gids behandelt enkele van de belangrijkste termen die de huidige AI-markt vormgeven en legt uit wat ze betekenen voor bedrijven die een echte implementatie overwegen.

1. Wat is een LLM?

Een LLM, of Large Language Model, is een artificieel-intelligentiemodel dat is getraind om taal te begrijpen en te genereren.

LLM’s vormen de basis van veel moderne AI-assistenten en kunnen onder meer:

• Vragen beantwoorden;
• Documenten samenvatten;
• Informatie extraheren;
• Teksten classificeren;
• Rapporten opstellen;
• Softwarecode genereren;
• Content vertalen;
• Bedrijfsprocessen ondersteunen.

Een LLM is de intelligente component van een AI-oplossing, maar vormt zelden de volledige oplossing.

Een productiesysteem heeft ook interfaces, datakoppelingen, gebruikersrechten, bedrijfsregels, monitoring en mechanismen nodig om de output van het model te controleren.

Medewerkers toegang geven tot een algemene AI-assistent is daarom niet hetzelfde als AI integreren in een bedrijfsproces.

2. Wat is RAG?

RAG staat voor Retrieval-Augmented Generation.

Het is een architectuur waarmee een AI-model externe informatie kan raadplegen voordat het een antwoord genereert.

Zonder RAG baseert een LLM zich voornamelijk op de informatie uit zijn training en op de inhoud die rechtstreeks in het gesprek wordt aangeleverd.

Met RAG kan een applicatie een vooraf bepaalde verzameling documenten of gegevens doorzoeken. Vervolgens worden relevante passages als aanvullende context aan het model doorgegeven.

Een RAG-systeem kan een medewerker bijvoorbeeld laten vragen:

• Wat staat er in ons interne reisbeleid?
• Welke supportprocedure geldt voor deze klant?
• Wat zijn de voorwaarden van dit contract?
• Hoe moet deze machine worden onderhouden?
• Welke regelgeving is op dit product van toepassing?

Een traditionele RAG-pipeline verdeelt documenten meestal in kleinere onderdelen, vaak chunks genoemd. Wanneer iemand een vraag stelt, zoekt het systeem naar de chunks die waarschijnlijk het antwoord bevatten.

RAG is nuttig wanneer informatie regelmatig verandert, specifiek is voor de organisatie of niet permanent in het model mag worden verwerkt.

Het ophalen van enkele relevante fragmenten biedt echter niet altijd voldoende structuur om relaties tussen verschillende documenten te begrijpen.

Dat is een van de problemen die LLM-wiki’s proberen op te lossen.

3. Wat is een LLM-wiki?

Een LLM-wiki is een gestructureerde kennisbank die is ontworpen om door AI-agents te worden doorzocht, gelezen en in sommige gevallen onderhouden.

In plaats van bedrijfskennis uitsluitend als afzonderlijke documentfragmenten op te slaan, organiseert een LLM-wiki informatie in onderling verbonden pagina’s.

Een pagina kan bijvoorbeeld gaan over:

• Een klant;
• Een product;
• Een bedrijfsproces;
• Een technisch systeem;
• Een intern beleid;
• Een contract;
• Een terugkerend supportprobleem;
• Een beslissing uit een eerder project.

De pagina’s kunnen links naar gerelateerde onderwerpen en verwijzingen naar de oorspronkelijke bronnen bevatten.

Recent onderzoek beschrijft de LLM-wiki als een agent-native architectuur waarin documenten worden omgezet in gestructureerde pagina’s met links in beide richtingen.

Een agent kan zoeken, lezen en links volgen totdat er voldoende informatie is verzameld om een vraag te beantwoorden.

Wat is het verschil tussen een LLM-wiki en traditionele RAG?

Traditionele RAG haalt meestal afzonderlijke documentfragmenten op basis van hun overeenkomst met de vraag van de gebruiker.

Een LLM-wiki probeert kennis op een meer georganiseerde manier weer te geven.

Bij het onderzoeken van een terugkerend klantprobleem kan een agent bijvoorbeeld navigeren tussen pagina’s over:

1. De klant;
2. Het gebruikte product;
3. Eerdere incidenten;
4. De relevante dienstverleningsovereenkomst;
5. De technische component die het probleem veroorzaakt.

Het verschil kan als volgt worden samengevat:

• RAG haalt relevante informatie op;
• Een LLM-wiki organiseert kennis zodat een agent relaties kan volgen.

Beide benaderingen kunnen binnen hetzelfde systeem worden gecombineerd. RAG kan de oorspronkelijke documenten vinden, terwijl de wiki vaak gebruikte kennis gestructureerd beschikbaar houdt.

Wat zijn de risico’s van een LLM-wiki?

Een LLM-wiki is niet automatisch betrouwbaar.

Wanneer een AI-model documenten omzet in samenvattingen of gestructureerde pagina’s, kunnen belangrijke details verdwijnen of verkeerd worden vereenvoudigd.

Een ongecontroleerde omzetting van documenten kan kritieke feiten verliezen wanneer er geen evaluatie- en verfijningsmechanismen aanwezig zijn.

Een professionele implementatie heeft daarom behoefte aan:

• Verwijzingen naar oorspronkelijke bronnen;
• Versiebeheer;
• Toegangscontrole;
• Processen om informatie bij te werken;
• Geautomatiseerde evaluaties;
• Menselijke controle van kritieke inhoud;
• Duidelijk eigenaarschap van de kennisbank.

4. Wat is een AI-agent?

Een AI-agent is een softwaresysteem dat een AI-model gebruikt om te bepalen welke stappen nodig zijn om een doel te bereiken.

Een traditionele chatbot reageert op een bericht.

Een agent kan een reeks acties uitvoeren.

Een supportagent kan bijvoorbeeld:

1. Een vraag van een klant ontvangen;
2. Interne documentatie doorzoeken;
3. Het klantaccount raadplegen;
4. Eerdere incidenten analyseren;
5. Een antwoord voorbereiden;
6. Een supportticket aanmaken;
7. Een medewerker om goedkeuring vragen.

Een agent genereert dus niet alleen tekst. Hij communiceert ook met tools en systemen.

Dat maakt AI-agents potentieel waardevoller, maar ook complexer en risicovoller.

Voor een agent in productie moeten duidelijke regels bestaan rond:

• De data waartoe hij toegang heeft;
• De tools die hij mag gebruiken;
• De acties die hij mag uitvoeren;
• De situaties waarin menselijke goedkeuring nodig is;
• De registratie van alle acties;
• Het gedrag wanneer het model onzeker is.

De beste zakelijke toepassingen zijn doorgaans beperkt en meetbaar. Een agent die een duidelijk afgebakend proces uitvoert, is beter te evalueren en te controleren dan een algemene “AI-medewerker”.

5. Wat is een Forward Deployed Engineer?

Een Forward Deployed Engineer, of FDE, is een engineer die nauw samenwerkt met een klant om technologie binnen de echte operationele omgeving te implementeren.

De functie bevindt zich op het kruispunt van software engineering, technisch advies, product discovery en implementatie.

In plaats van een volledig uitgewerkte specificatie te ontvangen en het systeem op afstand te ontwikkelen, helpt een FDE om het probleem te onderzoeken, de oplossing te ontwerpen, bestaande systemen te integreren en de ingebruikname te begeleiden.

Een FDE kan onder meer:

• Gebruikers en operationele teams interviewen;
• Bestaande processen in kaart brengen;
• De systemen en gegevens van de organisatie analyseren;
• Integraties en productiesoftware ontwikkelen;
• De oplossing in echte workflows testen;
• Adoptie en bedrijfsimpact meten;
• De implementatie aanpassen op basis van feedback.

Wat is het verschil tussen een FDE en een externe ontwikkelaar?

Een externe ontwikkelaar ontvangt doorgaans taken binnen een bestaande projectstructuur.

Een FDE draagt meestal een bredere verantwoordelijkheid: begrijpen wat er moet worden gebouwd en ervoor zorgen dat het in de praktijk werkt.

Het verschil gaat dus niet alleen over technische ervaring. Het gaat vooral over de nabijheid tot het bedrijfsprobleem.

Dit model is bijzonder relevant voor AI-projecten, omdat veel vereisten pas duidelijk worden nadat de oplossing met echte data, gebruikers en bedrijfsprocessen is verbonden.

6. Wat is context engineering?

Context engineering is het ontwerpen van de informatie, instructies en tools waarover een AI-model beschikt tijdens het uitvoeren van een taak.

Een prompt is slechts één onderdeel van die context.

De volledige context kan bestaan uit:

• Systeeminstructies;
• Bedrijfsdocumenten;
• Informatie over de gebruiker;
• Eerdere interacties;
• Gegevens uit databases;
• Beschikbare tools;
• Voorbeelden van goede antwoorden;
• Bedrijfsregels;
• Gewenste outputformaten;
• Beveiligingsbeperkingen.

Denk bijvoorbeeld aan een AI-assistent die contracten analyseert.

De prestaties hangen niet alleen af van de prompt, maar ook van de vraag of het systeem beschikt over:

• De juiste versie van het contract;
• De standaardclausules van het bedrijf;
• De toepasselijke regelgeving;
• De commerciële context van de klant;
• Instructies over welke risico’s moeten worden gemeld;
• Een gestructureerd formaat voor de analyse.

Context engineering lijkt daarom meer op systeemontwerp dan op het schrijven van een betere prompt.

7. Wat is MCP?

MCP staat voor Model Context Protocol.

Het is een open standaard om AI-applicaties met externe databronnen, tools en workflows te verbinden.

Voordat protocollen zoals MCP bestonden, bouwden ontwikkelaars vaak een afzonderlijke integratie voor elke combinatie van een AI-model en een externe tool.

MCP biedt een gemeenschappelijke structuur om het volgende beschikbaar te stellen:

• Informatiebronnen die de AI kan lezen;
• Tools die de AI kan uitvoeren;
• Herbruikbare prompts en workflows;
• Authenticatie- en toegangsmechanismen.

Een MCP-server kan een geautoriseerde AI-applicatie bijvoorbeeld in staat stellen om:

• Interne documentatie te lezen;
• Een productdatabase te doorzoeken;
• Een CRM te raadplegen;
• Een taak in een projectmanagementsysteem aan te maken;
• Monitoringgegevens van een systeem op te halen.

MCP maakt een integratie niet automatisch veilig. Rechten, authenticatie, datavalidatie en logging moeten nog steeds correct worden ontworpen.

8. Wat zijn AI-evals?

Evals, een afkorting van evaluations, zijn gestructureerde tests waarmee de prestaties van een AI-systeem worden gemeten.

Traditionele software kan vaak met deterministische regels worden getest: een specifieke invoer moet een specifieke uitvoer opleveren.

AI-systemen zijn minder voorspelbaar. Twee antwoorden kunnen verschillend zijn geformuleerd en toch beide correct zijn. Een overtuigend antwoord kan tegelijkertijd feitelijke fouten bevatten.

AI-evaluaties kunnen onder meer meten:

• De juistheid van antwoorden;
• De volledigheid;
• Het correcte gebruik van bronnen;
• De naleving van instructies;
• De kwaliteit van classificaties;
• De keuze van tools door een agent;
• Het aantal succesvol uitgevoerde taken;
• De frequentie van niet-toegestane acties;
• De kosten en responstijd.

De evaluatieset moet realistische voorbeelden uit de werkelijke bedrijfsprocessen bevatten.

Zonder evals beoordelen teams een AI-systeem vaak op basis van enkele indrukwekkende demonstraties. Dat is onvoldoende om te bepalen of het systeem betrouwbaar in productie kan functioneren.

9. Wat zijn guardrails en human-in-the-loop-processen?

Guardrails zijn technische en operationele controles die beperken wat een AI-systeem kan doen.

Voorbeelden zijn:

• Toegang tot beperkte informatie blokkeren;
• Data controleren voordat ze naar het model worden verstuurd;
• Beperken welke tools een agent mag gebruiken;
• Bevestiging vereisen voor belangrijke acties;
• Output controleren op gevoelige informatie;
• Acties beperken op basis van de rol van de gebruiker;
• Alle activiteiten in een auditlog registreren.

Een human-in-the-loop-proces vereist dat een mens bepaalde beslissingen controleert of goedkeurt.

Een AI-systeem kan bijvoorbeeld een betalingsopdracht voorbereiden, maar een financiële medewerker moet deze goedkeuren voordat de betaling wordt uitgevoerd.

De vereiste menselijke betrokkenheid hangt af van het risico en de mogelijke gevolgen van een fout.

Het samenvatten van een intern document heeft mogelijk weinig toezicht nodig. Een beslissing rond betalingen, contracten, personeelszaken, gezondheidszorg of kritieke infrastructuur vereist veel strengere controles.

Deze termen beschrijven onderdelen van een systeem

LLM’s, RAG, LLM-wiki’s, MCP, agents en evals zijn niet noodzakelijk concurrerende oplossingen.

Ze beschrijven verschillende lagen van een AI-systeem.

Een vereenvoudigde bedrijfsarchitectuur kan als volgt werken:

1. Een LLM levert taal- en redeneercapaciteiten;
2. RAG haalt relevante brondocumenten op;
3. Een LLM-wiki organiseert terugkerende kennis en relaties;
4. Context engineering bepaalt welke informatie het model ontvangt;
5. MCP of specifieke API’s verbinden het model met bedrijfstools;
6. Een AI-agent coördineert een reeks acties;
7. Evals meten of het systeem goed werkt;
8. Guardrails beperken de risico’s;
9. Een FDE of implementatieteam brengt het volledige systeem naar productie.

Niet iedere organisatie heeft elke laag nodig.

De juiste architectuur hangt af van het bedrijfsproces, de bestaande systemen, de beschikbare data en het risiconiveau.

Begin met het bedrijfsprobleem

Een veelgemaakte fout bij AI-projecten is beginnen met een technologie omdat die veel aandacht krijgt.

Een bedrijf hoort over AI-agents en besluit dat het er één nodig heeft. Pas daarna probeert het te bepalen wat de agent precies moet doen.

Een betere aanpak begint met vragen zoals:

• Welk proces is momenteel te traag of te duur?
• Waar verliezen medewerkers tijd met het zoeken naar informatie?
• Welke beslissingen zijn afhankelijk van versnipperde data?
• Welke handmatige stappen kunnen veilig worden geautomatiseerd?
• Hoe ziet een meetbare verbetering eruit?
• Welke systemen en gegevens heeft de oplossing nodig?
• Wat zijn de gevolgen wanneer de AI een fout maakt?

Pas na het beantwoorden van deze vragen moet de technische architectuur worden gekozen.

De beste oplossing kan een agent zijn, maar ook een zoekinterface, traditionele workflowautomatisering, een nieuwe integratie of de modernisering van een bestaand systeem.

Hoe Dink enterprise AI benadert

Dink beschouwt de implementatie van AI als een combinatie van een bedrijfs- en software-engineeringvraagstuk, niet als een op zichzelf staand experiment met een model.

Het traject begint met een analyse van de bedrijfsprocessen, systemen, databronnen en technische omgeving.

De geschikte oplossing kan vervolgens een AI-agent, workflowautomatisering, AI-applicatie of volledig maatwerkplatform zijn.

Na de implementatie wordt de oplossing gemonitord en verbeterd op basis van adoptie, prestaties en bedrijfsimpact.

Dink combineert AI-upgrades op maat met technology assessments, maatwerksoftware en langdurig onderhoud van bestaande systemen.

Dit is vooral relevant voor organisaties met legacyomgevingen.

Een bedrijf hoeft zijn centrale systeem niet altijd te vervangen. Het kan effectiever zijn om het te documenteren, veilige integraties te creëren en AI stapsgewijs rond de bestaande operatie te introduceren.

Meer informatie vindt u op de website van Dink.

Veelgestelde vragen

Is een LLM-wiki beter dan RAG?

Niet in iedere situatie. RAG is effectief om informatie uit grote of regelmatig bijgewerkte documentcollecties op te halen. Een LLM-wiki kan nuttig zijn wanneer agents gestructureerde relaties moeten volgen en opgebouwde kennis regelmatig opnieuw gebruiken.

Kan een AI-agent zonder menselijk toezicht werken?

Een agent kan bepaalde vooraf vastgelegde acties zelfstandig uitvoeren. Processen met grotere risico’s moeten echter goedkeuringen, beperkingen en auditmechanismen bevatten.

Heeft een bedrijf een FDE nodig om AI te implementeren?

Niet noodzakelijk als formele functietitel. Complexe projecten hebben wel baat bij engineers die nauw met de bedrijfsgebruikers samenwerken en verantwoordelijkheid nemen van discovery tot productie.

Is MCP verplicht voor AI-integraties?

Nee. Bedrijven kunnen conventionele API’s en maatwerkintegraties blijven gebruiken. MCP biedt een gestandaardiseerde aanpak, maar vervangt geen goede beveiliging en softwarearchitectuur.

Kan AI aan een legacysysteem worden toegevoegd?

Ja. Met veilige API’s en integratielagen kunnen vaak AI-functionaliteiten worden toegevoegd zonder het volledige systeem te vervangen. Een technische assessment moet eerst de datakwaliteit, beveiliging, architectuur en operationele beperkingen onderzoeken.

Conclusie

Het vocabularium rond artificiële intelligentie zal blijven veranderen.

Sommige termen zullen permanente onderdelen van software engineering worden. Andere zullen verdwijnen of worden vervangen naarmate modellen en architecturen evolueren.

Organisaties hoeven niet elke nieuwe trend te volgen.

Ze moeten begrijpen wat elk concept doet, welk bedrijfsprobleem het oplost en wat nodig is om het betrouwbaar in productie te laten functioneren.

Het echte concurrentievoordeel komt niet voort uit het gebruik van de nieuwste terminologie. Het ontstaat door de juiste technologie, data, softwarearchitectuur en implementatiekennis te combineren om een meetbaar bedrijfsresultaat te bereiken.