DEV Community

Perceval Hasselman
Perceval Hasselman

Posted on

Voorbij het taalmodel: de architectuur van betrouwbare AI-agents

#agents #ai #architecture #llm

Door Perceval Hasselman

Kunstmatige intelligentie wordt steeds vaker beschreven alsof het fundamentele probleem inmiddels is opgelost.

We beschikken over grote taalmodellen die software kunnen schrijven, documenten kunnen analyseren, afbeeldingen kunnen genereren, complexe instructies kunnen interpreteren en externe hulpmiddelen kunnen aanroepen. Daardoor ontstaat gemakkelijk het idee dat de volgende stap eenvoudig is: maak de modellen groter, sneller en autonomer.

Die conclusie is misleidend.

Een Large Language Model (LLM) is geen autonome intelligentie in de traditionele betekenis van software-engineering. Een taalmodel is in essentie een probabilistisch inferentiesysteem dat patronen in een enorme hoeveelheid data heeft geleerd en op basis daarvan nieuwe tokens voorspelt.

Zodra we zo'n model echte taken laten uitvoeren, externe systemen laten benaderen, informatie laten ophalen, beslissingen laten voorbereiden of meerdere stappen achter elkaar laten uitvoeren, bouwen we niet langer alleen een model.

We bouwen een systeem rondom dat model.

Daarmee verschuift het belangrijkste engineeringprobleem.

De vraag is niet langer uitsluitend:

Hoe maken we een taalmodel dat betere antwoorden genereert?

De belangrijkere vraag wordt:

Hoe bouwen we een systeem waarin een probabilistisch model betrouwbaar genoeg kan functioneren binnen een gecontroleerde softwareomgeving?

Dat is geen puur AI-probleem.

Het is een architectuurprobleem.

1. Een LLM is geen AI-agent

Een veelvoorkomende misvatting is dat een AI-agent simpelweg een taalmodel is waaraan enkele API's zijn gekoppeld.

Een productieklare agentische architectuur ziet er eerder als volgt uit:

                    ┌───────────────────┐
                    │    Gebruikersdoel │
                    └─────────┬─────────┘
                              │
                              ▼
                    ┌───────────────────┐
                    │   Orchestrator   │
                    └─────────┬─────────┘
                              │
             ┌────────────────┼────────────────┐
             │                │                │
             ▼                ▼                ▼
       ┌───────────┐    ┌────────────┐   ┌─────────────┐
       │    LLM    │    │   Geheugen │   │  Retrieval  │
       └─────┬─────┘    └────────────┘   └─────────────┘
             │
             ▼
       ┌─────────────┐
       │ Tool-laag   │
       └──────┬──────┘
              │
       ┌──────┴──────────────┐
       ▼                     ▼
   Externe API's         Databases
Enter fullscreen mode Exit fullscreen mode

Het taalmodel vormt slechts één component.

De rest van de architectuur zorgt voor eigenschappen die een taalmodel niet automatisch bezit:

  • permanente toestand;
  • autorisatie;
  • externe kennis;
  • geheugen;
  • tool-uitvoering;
  • validatie;
  • foutafhandeling;
  • logging;
  • monitoring;
  • beveiliging;
  • beleidsregels.

Dat onderscheid is fundamenteel.

In plaats van het model als de volledige applicatie te beschouwen, moeten we het model zien als één probabilistische component binnen een groter softwaresysteem.

2. Probabilistische AI tegenover deterministische software

Traditionele software werkt voornamelijk met expliciete regels.

Neem bijvoorbeeld:

resultaat = prijs * aantal
Enter fullscreen mode Exit fullscreen mode

Wanneer prijs en aantal hetzelfde blijven, blijft het resultaat hetzelfde.

Een taalmodel werkt fundamenteel anders.

Het model berekent waarschijnlijkheden over mogelijke vervolgtokens op basis van de beschikbare context. Zelfs wanneer een gebruiker het resultaat als een concreet antwoord ervaart, blijft het onderliggende proces probabilistisch.

Hier ontstaat een interessante spanning.

Software-engineers denken vaak in:

Input → Functie → Output
Enter fullscreen mode Exit fullscreen mode

Generatieve AI werkt eerder volgens:

Context → Waarschijnlijkheidsverdeling → Gegenereerde output
Enter fullscreen mode Exit fullscreen mode

De tweede benadering maakt AI buitengewoon flexibel, maar introduceert tegelijkertijd onzekerheid.

Daarom hebben betrouwbare AI-systemen deterministische grenzen rondom probabilistische componenten nodig.

Stel dat een taalmodel concludeert:

"Deze klant lijkt recht te hebben op een terugbetaling."

Dat betekent niet dat het taalmodel vervolgens zelfstandig een terugbetaling zou moeten uitvoeren.

Een robuuster systeem werkt bijvoorbeeld als volgt:

LLM
 ↓
Voorgestelde beslissing
 ↓
Validatie
 ↓
Autorisatie
 ↓
Bedrijfsregels
 ↓
API-aanroep
Enter fullscreen mode Exit fullscreen mode

Het model kan een actie voorstellen.

De software bepaalt vervolgens of die actie daadwerkelijk toegestaan is.

Dit leidt tot een belangrijk architectuurprincipe:

Het model kan bepalen wat het wil doen; het systeem bepaalt wat het mag doen.

3. RAG is een kennissysteem, geen menselijk geheugen

Retrieval-Augmented Generation, beter bekend als RAG, is inmiddels een van de belangrijkste architectuurpatronen binnen moderne AI-systemen.

De basis is relatief eenvoudig:

Gebruikersvraag
      ↓
Embedding
      ↓
Vectorzoekopdracht
      ↓
Relevante documenten
      ↓
Context
      ↓
LLM
      ↓
Antwoord
Enter fullscreen mode Exit fullscreen mode

In plaats van uitsluitend te vertrouwen op informatie die tijdens de training in de parameters van het model terechtkwam, wordt relevante externe informatie opgehaald en aan het model aangeboden.

Dit kan zeer krachtig zijn.

Maar RAG wordt regelmatig verkeerd geïnterpreteerd.

Een vector database is geen equivalent van menselijk geheugen.

Een vectorzoekmachine probeert voornamelijk de vraag te beantwoorden:

Welke opgeslagen informatie lijkt semantisch het meest relevant voor deze vraag?

Dat betekent niet automatisch dat de gevonden informatie:

  • correct is;
  • volledig is;
  • actueel is;
  • juridisch geldig is;
  • afkomstig is van een betrouwbare bron;
  • voldoende is om een beslissing te nemen.

Stel dat een organisatie honderdduizenden documenten bezit.

Een gebruiker vraagt:

"Mag deze klant volgens het huidige beleid zijn abonnement kosteloos beëindigen?"

Een klassieke RAG-implementatie kan enkele documenten ophalen die semantisch overeenkomen met de vraag.

Maar misschien heeft het systeem meer informatie nodig:

  1. de actuele algemene voorwaarden;
  2. het specifieke klantcontract;
  3. de abonnementsdatum;
  4. regionale regelgeving;
  5. eventuele uitzonderingsregels.

Daarom wordt agentische retrieval interessant.

In plaats van:

Vraag → Retrieval → Antwoord
Enter fullscreen mode Exit fullscreen mode

kan een systeem werken met:

Vraag
 ↓
Plan
 ↓
Informatie ophalen
 ↓
Bewijs beoordelen
 ↓
Is er voldoende informatie?
 ├── Nee → Nieuwe zoekactie
 └── Ja
       ↓
    Antwoord
Enter fullscreen mode Exit fullscreen mode

Retrieval wordt daarmee onderdeel van het redeneerproces.

4. Context engineering wordt belangrijker dan prompt engineering

De AI-industrie heeft de afgelopen jaren veel aandacht besteed aan prompt engineering.

Dat is begrijpelijk.

Een goede instructie kan het gedrag van een taalmodel aanzienlijk beïnvloeden.

Maar in complexe systemen ontstaat een ander probleem: context engineering.

Een model ontvangt namelijk niet alleen een prompt.

Het ontvangt een context die kan bestaan uit:

  • systeeminstructies;
  • gebruikersberichten;
  • documenten;
  • toolresultaten;
  • eerdere acties;
  • geheugen;
  • metadata;
  • gestructureerde toestand;
  • externe informatie.

De kwaliteit van die context bepaalt mede wat het model vervolgens kan doen.

Meer context betekent bovendien niet automatisch betere resultaten.

Een model dat honderden documenten tegelijk ontvangt, kan te maken krijgen met:

  • irrelevante informatie;
  • tegenstrijdige informatie;
  • verouderde informatie;
  • duplicaten;
  • hogere kosten;
  • langere verwerkingstijden;
  • verlies van aandacht voor belangrijke informatie.

Een goed ontworpen systeem probeert daarom een minimale maar voldoende context samen te stellen.

Het doel is niet:

Geef het model alle beschikbare informatie.

Het doel is:

Geef het model precies de informatie die nodig is voor de volgende beslissing.

Dat verschil lijkt klein, maar heeft grote gevolgen voor de architectuur van AI-systemen.

5. Tool calling verandert de betekenis van een AI-applicatie

Een chatbot produceert voornamelijk informatie.

Een agent kan consequenties veroorzaken.

Dat verschil is enorm.

Stel dat een AI-systeem toegang heeft tot:

zoek_klant()
maak_factuur()
annuleer_abonnement()
verstuur_email()
verwerk_betaling()
Enter fullscreen mode Exit fullscreen mode

Het model is dan niet langer alleen een interface voor tekst.

Het is onderdeel geworden van een systeem dat daadwerkelijk acties kan uitvoeren.

Daarmee verandert ook het beveiligingsprobleem.

We hoeven niet meer uitsluitend te vragen:

Kan het model schadelijke tekst genereren?

De belangrijkere vraag wordt:

Kan het model een ongeautoriseerde verandering in de echte wereld veroorzaken?

Daarom moeten tools strikt worden afgebakend.

Een tool kan bijvoorbeeld een contract definiëren:

{
  "name": "maak_factuur",
  "parameters": {
    "klant_id": "string",
    "bedrag": "number",
    "valuta": "string"
  }
}
Enter fullscreen mode Exit fullscreen mode

Vervolgens moet de applicatie controleren:

Bestaat de klant?
Is het bedrag toegestaan?
Is de valuta geldig?
Heeft deze gebruiker voldoende rechten?
Is menselijke goedkeuring noodzakelijk?
Enter fullscreen mode Exit fullscreen mode

Deze regels mogen niet uitsluitend aan het taalmodel worden overgelaten.

Het model kan immers een overtuigend antwoord genereren zonder dat het antwoord noodzakelijkerwijs correct is.

Daarom geldt:

Een taalmodel moet geen autorisatiesysteem worden.

6. Geheugen is ingewikkelder dan chatgeschiedenis

Ook het begrip "AI-geheugen" wordt vaak te eenvoudig voorgesteld.

Een agentisch systeem kan verschillende soorten geheugen nodig hebben.

Kortetermijngeheugen

De toestand van de huidige taak:

Gebruikersvraag
→ tussenbeslissingen
→ toolresultaten
→ huidige status
Enter fullscreen mode Exit fullscreen mode

Episodisch geheugen

Gebeurtenissen uit eerdere interacties:

De gebruiker heeft eerder actie X uitgevoerd.
Het systeem heeft daarna actie Y uitgevoerd.
Enter fullscreen mode Exit fullscreen mode

Semantisch geheugen

Geabstraheerde kennis die uit eerdere interacties is afgeleid:

Deze organisatie gebruikt technologie X.
Deze klant heeft voorkeur Y.
Enter fullscreen mode Exit fullscreen mode

Procedureel geheugen

Informatie over hoe een taak moet worden uitgevoerd:

1. Identiteit controleren
2. Beleid ophalen
3. Controle uitvoeren
4. Goedkeuring vragen
5. Actie uitvoeren
Enter fullscreen mode Exit fullscreen mode

Deze vormen van geheugen hoeven niet in dezelfde database te worden opgeslagen.

Ook hoeven ze niet op dezelfde manier te worden opgehaald.

Een geavanceerde AI-agent heeft daarom niet simpelweg "een geheugen".

Hij heeft een geheugenarchitectuur.

7. Multi-agent-systemen zijn niet automatisch beter

Multi-agent-systemen zijn momenteel bijzonder interessant.

Een architectuur kan bijvoorbeeld bestaan uit:

                  Supervisor
                 /     |      \
                /      |       \
           Onderzoek  Code     Review
Enter fullscreen mode Exit fullscreen mode

Een agent onderzoekt informatie.

Een andere schrijft software.

Een derde controleert het resultaat.

Op papier lijkt dit sterk op een organisatie waarin gespecialiseerde medewerkers samenwerken.

Maar iedere extra agent introduceert ook nieuwe complexiteit:

  • extra communicatie;
  • meer tokens;
  • hogere latency;
  • synchronisatieproblemen;
  • extra foutmogelijkheden;
  • moeilijkere debugging;
  • onduidelijke verantwoordelijkheid.

Een enkele goed ontworpen agent met drie betrouwbare tools kan daarom beter functioneren dan tien slecht gedefinieerde agents.

De relevante vraag is niet:

Hoeveel agents moeten we gebruiken?

Maar:

Op welke punten vermindert decompositie de complexiteit?

Multi-agent-architecturen worden vooral interessant wanneer verschillende taken daadwerkelijk verschillende bevoegdheden, kennisgebieden of uitvoeringsomgevingen vereisen.

Anders bestaat het risico dat we gedistribueerde systeemcomplexiteit simpelweg vermommen als intelligentie.

8. Betrouwbaarheid vereist evaluatie

Traditionele software kan vaak worden getest met exacte verwachte uitkomsten.

AI is anders.

Er kunnen meerdere correcte antwoorden bestaan.

Stel dat het gewenste antwoord is:

De aanvraag is goedgekeurd.
Enter fullscreen mode Exit fullscreen mode

Dan kunnen ook deze antwoorden correct zijn:

Uw aanvraag is goedgekeurd.
Enter fullscreen mode Exit fullscreen mode

of:

We hebben uw aanvraag goedgekeurd.
Enter fullscreen mode Exit fullscreen mode

Een evaluatiesysteem kan daarom niet uitsluitend kijken naar exacte tekstovereenkomst.

Moderne AI-evaluatie kan onder andere kijken naar:

  • feitelijke juistheid;
  • retrieval precision;
  • retrieval recall;
  • correcte toolselectie;
  • correcte toolparameters;
  • naleving van beleidsregels;
  • hallucinatieratio;
  • latency;
  • kosten;
  • taakvoltooiing;
  • aantal menselijke escalaties.

Een mogelijke evaluatiepipeline:

Testdataset
    ↓
AI-systeem
    ↓
Trace
    ↓
Evaluator
    ↓
Metrics
    ↓
Regression test
Enter fullscreen mode Exit fullscreen mode

Dit is essentieel.

Zonder evaluaties wordt AI-ontwikkeling snel gebaseerd op intuïtie.

Een ontwikkelaar verandert een prompt, ziet één beter antwoord en concludeert dat het systeem verbeterd is.

Het kan tegelijkertijd op tientallen andere scenario's slechter zijn geworden.

9. Observability wordt onderdeel van de AI-architectuur

In traditionele software kan een logregel als deze al nuttig zijn:

POST /api/payment → 200 OK
Enter fullscreen mode Exit fullscreen mode

Bij een agentisch systeem is dat onvoldoende.

We moeten kunnen reconstrueren hoe een bepaalde actie tot stand kwam.

Bijvoorbeeld:

Gebruikersvraag
 ↓
Versie van systeeminstructie
 ↓
Geselecteerde documenten
 ↓
Modelaanroep
 ↓
Geselecteerde tool
 ↓
Toolparameters
 ↓
Toolresultaat
 ↓
Validatie
 ↓
Eindantwoord
Enter fullscreen mode Exit fullscreen mode

Dit noemen we vaak een AI trace.

Een dergelijke trace maakt het mogelijk om vragen te beantwoorden als:

  • Waarom werd deze tool gekozen?
  • Welke informatie beïnvloedde de beslissing?
  • Welke documenten werden opgehaald?
  • Was de retrieval succesvol?
  • Heeft het model relevante informatie genegeerd?
  • Was het toolresultaat incorrect?
  • Is het systeem in een lus terechtgekomen?
  • Welke promptversie veroorzaakte het probleem?

Zonder dergelijke observability wordt het debuggen van autonome AI-systemen bijzonder moeilijk.

10. Het grootste probleem is niet altijd het taalmodel

Een logische veronderstelling is dat een beter model automatisch een betere applicatie oplevert.

Dat is slechts gedeeltelijk waar.

Stel dat een systeem ongeveer deze eigenschappen heeft:

Modelkwaliteit:        90%
Retrievalkwaliteit:    60%
Toolbetrouwbaarheid:   70%
Contextkwaliteit:      65%
Evaluatiekwaliteit:    40%
Enter fullscreen mode Exit fullscreen mode

Het vervangen van het taalmodel kan de eerste waarde verbeteren.

Maar wanneer retrieval slecht blijft functioneren, zal de totale systeemprestatie mogelijk nauwelijks veranderen.

De kwaliteit van een AI-pipeline is namelijk afhankelijk van meerdere componenten.

Wanneer we een sterk vereenvoudigd model gebruiken:

P(succes) =
P(retrieval)
× P(reasoning)
× P(tool execution)
× P(validation)
Enter fullscreen mode Exit fullscreen mode

zien we hoe snel een systeem kan degraderen.

Bijvoorbeeld:

0,90 × 0,90 × 0,80 × 0,95 = 0,6156
Enter fullscreen mode Exit fullscreen mode

Een systeem kan dus een uitstekend taalmodel bevatten en toch slechts een middelmatige end-to-end-betrouwbaarheid hebben.

Daarom begint AI-engineering steeds meer op klassieke systems engineering te lijken.

11. De nieuwe AI-stack

Een volwassen AI-applicatie kan worden opgebouwd uit verschillende lagen:

┌──────────────────────────────┐
│       Gebruikersinterface    │
├──────────────────────────────┤
│      Agent / Orchestratie    │
├──────────────────────────────┤
│        Model / Inference     │
├──────────────────────────────┤
│     Context & Memory Layer   │
├──────────────────────────────┤
│         Retrieval / RAG      │
├──────────────────────────────┤
│          Tool Gateway        │
├──────────────────────────────┤
│     API's / Databases        │
├──────────────────────────────┤
│ Security / Policy / Audit    │
└──────────────────────────────┘
Enter fullscreen mode Exit fullscreen mode

Hierin zien we een belangrijke ontwikkeling.

Het taalmodel is niet langer noodzakelijkerwijs het volledige middelpunt van de applicatie.

Het is één laag binnen een groter systeem.

Dat is een fundamentele verschuiving in softwarearchitectuur.

AI-applicaties zijn niet simpelweg traditionele applicaties met een chatbotinterface.

Ze zijn steeds vaker probabilistische softwaresystemen die functioneren binnen een grotendeels deterministische infrastructuur.

12. Het fundamentele probleem: autonomie zonder onbeperkte macht

Dit wordt waarschijnlijk een van de belangrijkste architectuurvraagstukken van agentische AI.

Een bruikbare agent moet voldoende autonomie hebben.

Te weinig autonomie en het systeem is uiteindelijk slechts een dure chatbot.

Te veel autonomie en het systeem wordt moeilijk beheersbaar.

Daarom is graduele autonomie interessant.

Niveau 0 — Adviseren

De AI stelt een actie voor.

Een mens voert de actie uit.

Niveau 1 — Voorbereiden

De AI bereidt de actie volledig voor.

Een mens geeft toestemming.

Niveau 2 — Uitvoeren binnen grenzen

De AI mag vooraf gedefinieerde acties uitvoeren zolang bepaalde limieten niet worden overschreden.

Niveau 3 — Autonome uitvoering

De AI voert volledige workflows uit zonder directe menselijke interventie.

De juiste mate van autonomie zou vervolgens afhankelijk moeten zijn van het risico.

Een agenda-uitnodiging versturen is niet hetzelfde als een financiële transactie uitvoeren.

Een robuust systeem kan daarom werken volgens:

Risico
 ↓
Verificatie
 ↓
Autorisatie
 ↓
Toegestane autonomie
Enter fullscreen mode Exit fullscreen mode

Dat is veel betrouwbaarder dan simpelweg tegen een taalmodel zeggen dat het "voorzichtig" moet zijn.

Conclusie: AI-engineering wordt systems engineering

De meest interessante AI-systemen van de komende jaren zullen waarschijnlijk niet uitsluitend worden bepaald door de omvang van hun taalmodel.

Ze zullen worden bepaald door de architectuur rondom dat model.

De onderscheidende factor wordt steeds vaker het vermogen om verschillende technologieën betrouwbaar te combineren:

  • krachtige inferentiemodellen;
  • hoogwaardige retrieval;
  • zorgvuldig ontworpen context;
  • persistent geheugen;
  • betrouwbare tools;
  • deterministische bedrijfslogica;
  • observability;
  • evaluaties;
  • beveiliging;
  • gecontroleerde autonomie.

Een LLM is krachtig omdat het kan omgaan met ambiguïteit.

Traditionele software is krachtig omdat het expliciete regels kan afdwingen.

De toekomst van betrouwbare AI ligt in het combineren van beide.

Het doel is daarom niet om een machine te bouwen die zonder grenzen autonoom opereert.

Het doel is om een systeem te bouwen dat kan bepalen:

wanneer het moet redeneren, wanneer het informatie moet ophalen, wanneer het mag handelen, wanneer het moet verifiëren en wanneer het moet stoppen.

Dat is een aanzienlijk moeilijker probleem dan het bouwen van een chatbot.

En juist dat probleem kan de volgende generatie AI-systemen gaan definiëren.

Over de auteur

Perceval Hasselman schrijft over kunstmatige intelligentie, softwarearchitectuur, automatisering en opkomende technologie. Zijn interesse ligt met name bij de ontwikkeling van autonome systemen, AI-agents en de architectuur die nodig is om probabilistische AI betrouwbaar te integreren met traditionele software.

Top comments (0)