De AI Tech Stack uitgelegd: van vector database tot orchestration — Sean Vermond

Je wilt iets bouwen met AI. Misschien een slimme zoekfunctie voor je website. Misschien een chatbot die je klantenservice ontlast. Misschien een tool die automatisch samenvattingen maakt van vergaderingen. Je hebt de termen geleerd — RAG, fine-tuning, embeddings — en nu wil je weten: hoe zit het in elkaar? Waar begin je?

Welkom bij de AI tech stack.

Als iemand die zelf systemen bouwt, vind ik de stack-metafoor perfect. Het is precies hoe ik naar projecten kijk. Elke laag heeft een functie, en samen vormen ze een werkend geheel. Mijn eigen stack — Next.js voor de frontend, Payload CMS voor content, PostgreSQL als database, het hele spul gehost op een eigen server — is in essentie dezelfde gedachte. Lagen die samenwerken. De AI-wereld heeft een vergelijkbaar concept, maar dan met andere lagen, andere tools, en een steile leercurve.

Vandaag ga ik die stack voor je uitpluizen. Niet als een technisch handboek, maar als een rondleiding. En ik ga het doen met een metafoor die het hele artikel draagt: de professionele keuken.

Want een AI-systeem bouwen lijkt verrassend veel op een restaurant runnen. Je hebt ingredienten nodig (data), recepten (modellen), een chef die alles coordineert (orchestration), en een restaurant waar gasten een ervaring hebben (de interface). Elke laag is essentieel. Sla je er een over, dan serveert je restaurant rauwe ingredienten op een kartonnen bord.

Laten we beginnen bij de basis.

Laag 1: Data — de ingredienten

Geen restaurant zonder ingredienten. Geen AI zonder data.

Waarom data de fundatie is

Elk AI-systeem begint met data. De kwaliteit van je data bepaalt het plafond van je systeem. Je kunt het meest geavanceerde model ter wereld gebruiken, de beste orchestration opzetten, de mooiste interface bouwen — als je data rommel is, is je output rommel.

Dit klinkt als een open deur, maar je zou versteld staan van hoeveel AI-projecten stranden op dit punt. Bedrijven willen een AI-chatbot, maar hun interne documentatie is verspreid over vijftien SharePoint-sites, drie Confluence-ruimtes en de inbox van Henk van finance. Ik zie het keer op keer: de eerste stap is niet een model kiezen — het is je data op orde krijgen. Dat is niet sexy, maar het is de realiteit.

De ingredienten in de keuken

In onze keukenmetafoor zijn de ingredienten je ruwe data: documenten, databases, API-responses, klantgesprekken, productinformatie. De kwaliteit varieert. Sommige ingredienten zijn vers en goed gelabeld (gestructureerde databases). Andere zijn een beetje over de datum en moeilijk te identificeren (die ene PDF uit 2019 die niemand meer snapt).

Wat je nodig hebt

Data opslag: Je data moet ergens leven. Voor ongestructureerde data (documenten, emails, notities) heb je een systeem dat ze opslaat en doorzoekbaar maakt. Dit kan varieren van een simpele bestandsserver tot een uitgebreid data lake.

Data processing: Ruwe data moet worden opgeschoond, gestructureerd en verrijkt. Denk aan: duplicaten verwijderen, formaten standaardiseren, ontbrekende waarden aanvullen. In de keuken: groenten wassen, snijden, marineren.

Vector database: Zoals we in het vorige artikel bespraken, heb je een vector database nodig om embeddings op te slaan. Dit is waar je documenten worden omgezet in numerieke representaties die je AI-systeem kan doorzoeken op betekenis. Populaire opties op dit moment: Pinecone, Weaviate, Chroma, Qdrant, en Milvus.

De keuze: Voor een MKB-bedrijf dat begint met AI raad ik aan simpel te starten. Een PostgreSQL-database met de pgvector-extensie kan al verrassend ver komen als vector database. Ik gebruik zelf PostgreSQL voor bijna alles — het is betrouwbaar, het is gratis, en met pgvector heb je een vector database erbij zonder extra infrastructuur. Je hoeft niet meteen de duurste ingredienten te kopen — begin met wat er is en schaal op wanneer nodig.

Laag 2: Het model — de recepten

Nu je ingredienten hebt, heb je recepten nodig. In de AI-wereld zijn dat je modellen.

De keuze: kopen, huren of zelf maken?

Dit is de eerste grote beslissing. En het is vergelijkbaar met de keuze die een restauranteigenaar maakt:

Kant-en-klaar kopen (API's van grote aanbieders): Je gebruikt de modellen van OpenAI (GPT-4), Anthropic (Claude 3.5 Sonnet), of Google (Gemini) via hun API. Je betaalt per gebruik. Je hebt geen eigen infrastructuur nodig. Dit is als een restaurant dat pasta koopt bij een premiumleverancier in plaats van zelf te maken. Het is snel, het is goed, maar je bent afhankelijk van de leverancier.

Open-source modellen draaien: Je draait een open-source model als Llama 3.1 (Meta's nieuwste, uitgebracht in juli 2024) op je eigen hardware of in de cloud. Je hebt meer controle, je data verlaat je omgeving niet, maar je hebt technische expertise en rekenkracht nodig. Dit is als een restaurant dat zelf pasta maakt — beter controle over het resultaat, maar je hebt een pastamaker en iemand die ermee kan werken nodig.

Fine-tunen: Je neemt een bestaand model en traint het verder op jouw data. Dit is als een chef die een basisrecept aanpast aan de smaak van zijn gasten. Het resultaat is unieker, maar het proces kost tijd en expertise.

GPU's: de ovens van de AI-keuken

Modellen draaien op GPU's — grafische processoren die oorspronkelijk zijn ontworpen voor games, maar die perfect blijken voor de wiskundige berekeningen van AI. Het is september 2024 en GPU-schaarste is nog steeds een reeel probleem. NVIDIA domineert de markt. De wachtlijsten voor hun nieuwste chips zijn lang. De prijzen zijn hoog.

In onze keukenmetafoor zijn GPU's de ovens. Je kunt het beste recept ter wereld hebben, maar zonder oven kun je niet koken. En op dit moment zijn de beste ovens schaars en duur.

Praktisch advies: Tenzij je een specifieke reden hebt om modellen zelf te draaien (privacy, kosten bij hoog volume, of specifieke fine-tuning), begin dan met API's. Laat OpenAI of Anthropic de ovens beheren. Focus jij op het recept. Ik werk zelf ook zo — mijn projecten draaien op API's van Claude en GPT-4, niet op zelf-gehoste modellen. De overhead van eigen GPU-infrastructuur is voor de meeste projecten simpelweg niet te rechtvaardigen.

Model evaluatie: hoe kies je?

De modellenkeuze hangt af van je use case:

Tekst genereren (schrijven, samenvatten, vertalen): GPT-4, Claude 3.5 Sonnet, Llama 3.1
Code genereren: GPT-4, Claude 3.5 Sonnet (die op codetaken bijzonder sterk presteert)
Afbeeldingen genereren: DALL-E 3, Midjourney, Stable Diffusion
Spraak naar tekst: Whisper (OpenAI, open-source)
Embeddings: OpenAI's text-embedding-3, Cohere Embed, open-source alternatieven als E5

Elk model heeft zijn sterke en zwakke punten. Er is geen "beste model" — er is het beste model voor jouw specifieke situatie. Mijn aanpak: begin met twee of drie modellen, test ze op jouw specifieke data, en kies op basis van resultaten. Niet op basis van benchmarks die iemand op Twitter postte.

Laag 3: Orchestration — de chef

Dit is de laag die het verschil maakt tussen een proof-of-concept en een productiesysteem. En het is de laag die de meeste mensen overslaan — met alle gevolgen van dien.

Wat orchestration is

Orchestration is de coordinatielaag die alles verbindt. Het bepaalt de workflow: welke stappen worden genomen wanneer een gebruiker een vraag stelt? Welke data wordt opgehaald? Welk model wordt aangesproken? Hoe wordt het antwoord gecontroleerd voordat het naar de gebruiker gaat?

De chef in de keuken. De chef kookt niet alles zelf. De chef coordineert. De chef weet welk gerecht welke ingredienten nodig heeft, in welke volgorde de stappen moeten worden uitgevoerd, en wanneer het resultaat goed genoeg is om te serveren. Zonder chef heb je een keuken vol getalenteerde koks die allemaal iets anders aan het maken zijn.

Dit is ook precies hoe ik naar systeemontwerp kijk. Ik denk in systemen, niet in losse componenten. De waarde zit niet in de individuele onderdelen — die zijn inwisselbaar. De waarde zit in hoe ze samenwerken.

Tools voor orchestration

De grootste naam op dit moment is LangChain — een open-source framework dat het bouwen van AI-applicaties vereenvoudigt. LangChain biedt bouwblokken voor veelvoorkomende patronen: RAG-pipelines, chatbots met geheugen, multi-staps redenering, en tool-gebruik.

Andere opties:

LlamaIndex: Specifiek sterk in het werken met documenten en kennisbanken. Als LangChain de alleskunner is, is LlamaIndex de specialist voor RAG.
Semantic Kernel (Microsoft): Microsofts antwoord op LangChain, goed geintegreerd met het Azure-ecosysteem.
Haystack: Een open-source framework van deepset, populair in Europa.

AI Agents: de opkomende trend

En dan zijn er AI agents — autonome systemen die niet alleen vragen beantwoorden, maar ook acties uitvoeren. Een agent kan je email lezen, beslissen dat er een vergadering gepland moet worden, je agenda checken, en de uitnodiging versturen. Zonder dat jij tussendoor iets hoeft te doen.

Agents zijn op dit moment (september 2024) het heetste onderwerp in AI. Iedereen praat erover. De realiteit is dat ze nog vroeg in hun ontwikkeling zijn — ze werken goed voor eenvoudige, goed gedefinieerde taken, maar worstelen met complexe, meerstaps processen. Maar de richting is duidelijk: AI gaat van reageren naar handelen.

In onze keuken: een AI-agent is niet alleen de chef die coordineert, maar de chef die ook zelf naar de markt gaat om ingredienten te kopen, leveranciers belt als iets op is, en het menu aanpast als een ingredient niet leverbaar is. Ambitieus? Ja. Mogelijk? Steeds meer.

Orchestration patterns

Een paar veelvoorkomende patterns die je tegenkomt:

Chain: Een reeks stappen die achter elkaar worden uitgevoerd. Vraag -> ophalen documenten -> genereren antwoord -> controleren -> versturen. Simpel, voorspelbaar, effectief.

Router: Het systeem analyseert de vraag en stuurt die naar het juiste pad. Een klantvraag over facturen gaat naar de financiele RAG-pipeline. Een technische vraag gaat naar de product-documentatie-pipeline. Elke route heeft zijn eigen logica.

Agent loop: Het systeem krijgt een doel, bedenkt zelf welke stappen nodig zijn, voert ze uit, evalueert het resultaat, en herhaalt tot het doel is bereikt. De meest autonome, maar ook de meest onvoorspelbare pattern.

Laag 4: Interface — het restaurant

De laatste laag is wat je gebruiker ziet en ervaart. En het is de laag die bepaalt of je AI-systeem daadwerkelijk wordt gebruikt.

Waarom de interface ertoe doet

Je kunt het meest briljante AI-systeem bouwen — als de interface verwarrend is, gebruikt niemand het. Dat klinkt voor de hand liggend, maar ik heb genoeg AI-projecten gezien die technisch indrukwekkend waren en door niemand werden gebruikt omdat de interface een Excel-sheet met een knop was.

Het restaurant. Je kunt de beste chef ter wereld hebben, de versste ingredienten, de meest verfijnde recepten — als je gasten aan een wiebelende tafel zitten met plastic bestek, komen ze niet terug. De ervaring telt.

Vormen van AI-interfaces

Chat interface: De meest voor de hand liggende en meest gebruikte vorm. De gebruiker typt een vraag, het systeem antwoordt. ChatGPT heeft dit pattern genormaliseerd. Het voordeel: gebruikers begrijpen het direct. Het nadeel: niet voor elke use case de beste keuze.

Embedded AI: AI die is ingebouwd in bestaande tools. Denk aan: een schrijfsuggestie in je emailclient, een samenvatting bovenaan een lang document, een automatische categorisering van inkomende tickets. De gebruiker hoeft niet naar een apart systeem — de AI komt naar hem toe.

Dashboard met AI-inzichten: Een overzichtspagina met door AI gegenereerde analyses, trends en aanbevelingen. Populair in business intelligence en marketing analytics.

Spraakinterface: AI die je aanspreekt of die je aanspreekt. Denk aan: een telefoonbot die afspraken inplant, of een voice assistant in een magazijn waar medewerkers hun handen vol hebben.

De keuze van framework

Voor de technisch geinteresseerden: de meeste AI-interfaces worden gebouwd met standaard webframeworks. Next.js, React, Vue — de bekende namen. Ik bouw mijn interfaces in Next.js met de Vercel AI SDK — dat is een bewuste keuze. Next.js geeft me server-side rendering voor snelle laadtijden, en de AI SDK maakt streaming responses triviaal. Het verschil tussen een chatinterface die drie seconden wacht en dan een lap tekst toont, en een interface die direct begint met typen — dat is het verschil tussen "dit voelt traag" en "dit voelt magisch." En dat maakt of breekt adoptie.

Andere opties:

Streamlit: Python-framework waarmee je snel prototypes kunt bouwen. Perfect voor interne tools.
Gradio: Vergelijkbaar met Streamlit, populair in de machine learning community.

De volledige stack in perspectief

Laten we de keukenmetafoor afronden door de hele stack samen te brengen:

| Laag | Keuken | AI Tech Stack | |------|--------|---------------| | Data | Ingredienten | Documenten, databases, vector stores | | Model | Recepten | LLM's (GPT-4, Claude, Llama), embedding models | | Orchestration | De chef | LangChain, LlamaIndex, custom pipelines | | Interface | Het restaurant | Chat UI, embedded AI, dashboards |

En net als in een restaurant zijn er nog ondersteunende functies:

Monitoring (de keukeninspectie): Tools als LangSmith, Weights & Biases, of Helicone die bijhouden hoe je systeem presteert. Waar gaat het mis? Welke vragen leiden tot hallucinaties? Hoe snel zijn je antwoorden?
Security (de brandbeveiliging): Guardrails, toegangscontrole, encryptie. Zeker nu de EU AI Act in werking is, is dit niet optioneel.
Kosten (de boekhouding): API-calls kosten geld. GPU's kosten geld. Opslag kost geld. Zonder kostenmonitoring kan een AI-project snel uit de hand lopen.

De praktijk: drie voorbeelden

Laat me de stack concreet maken met drie scenario's die ik regelmatig tegenkom.

Scenario 1: Interne kennisbank

Een bedrijf met 200 medewerkers wil een AI-assistent die vragen beantwoordt over interne processen, beleid en documenten.

Data: Confluence-pagina's, HR-handboek, IT-procedures, onboarding-documenten -> embeddings in Chroma
Model: Claude 3.5 Sonnet via API (sterk in het volgen van instructies, goed in Nederlands)
Orchestration: Simpele RAG-chain via LangChain — vraag -> zoek relevante documenten -> genereer antwoord met bronvermelding
Interface: Chat-widget geintegreerd in het intranet

Totale opzet: een paar weken. Kosten: beheersbaar (API-kosten schalen met gebruik).

Scenario 2: Klantenservice-bot

Een webshop wilt 60% van de standaard klantvragen automatiseren.

Data: Product-catalogus, FAQ's, retourbeleid, bestelgeschiedenis per klant -> Pinecone vector database
Model: GPT-4 via API, met fine-tuning op historische klantenservice-gesprekken voor de juiste toon
Orchestration: Router-pattern — classificeer de vraag (bestelling, retour, product, klacht) -> route naar de juiste pipeline -> guardrails (geen financieel advies, escaleer complexe klachten naar mens)
Interface: Chat-widget op de website + integratie met bestaand ticketsysteem

Complexer, maar de ROI is direct meetbaar: minder handmatige afhandeling, snellere responstijden, 24/7 beschikbaarheid.

Scenario 3: Document-analyse tool

Een juridisch kantoor wilt contracten automatisch laten analyseren op risico's.

Data: Duizenden historische contracten, jurisprudentie, interne richtlijnen -> embeddings in Weaviate
Model: Claude 3.5 Sonnet (sterk in lange documenten en redenering), mogelijk fine-tuned op juridische teksten
Orchestration: Multi-staps pipeline — upload contract -> extraheer clausules -> vergelijk met richtlijnen -> identificeer risico's -> genereer rapportage
Interface: Dashboard met upload-functie, risicovisualisatie per clausule, en een AI-gegenereerde samenvatting

Technisch het meest uitdagend van de drie, maar ook het scenario met de hoogste waarde per use case.

Waar begin je?

Als je dit leest en denkt "dit is veel", dan heb je gelijk. Het is veel. Maar laat me je geruststellen: je hoeft niet alles tegelijk te doen.

De meest succesvolle AI-implementaties die ik zie — en ik heb er inmiddels tientallen van dichtbij meegemaakt — beginnen klein:

Identificeer een concreet probleem dat AI kan oplossen. Niet "we willen AI gebruiken", maar "we willen dat klanten binnen 30 seconden antwoord krijgen op veelgestelde vragen."
Begin met een hosted model via API. Geen eigen GPU's, geen eigen model training. Gebruik GPT-4 of Claude via de API en focus op de use case.
Bouw een simpele RAG-pipeline. Je documenten -> embeddings -> vector database -> ophalen + genereren. Dit dekt 80% van de zakelijke use cases.
Itereer. Meet wat werkt en wat niet. Voeg lagen toe waar nodig. Fine-tune als de toon niet klopt. Voeg guardrails toe als het model afdwaalt. Schaal op als het gebruik groeit.

De stack die ik heb beschreven is het volledige plaatje. Maar je hoeft niet met het volledige plaatje te beginnen. Begin met ingredienten en een simpel recept. De chef en het restaurant komen later.

De toekomst van de stack

De AI tech stack evolueert razendsnel. Een paar trends die ik nu al zie:

Agents worden mainstream: De orchestratielaag wordt autonomer. Systemen die niet alleen antwoorden, maar handelen.
Multimodaliteit wordt standaard: Modellen die niet alleen tekst verwerken, maar ook afbeeldingen, audio en video begrijpen en genereren. Grok-2, dat vorige maand door xAI werd gelanceerd, laat zien waar dit naartoe gaat.
De stack wordt simpeler: Tools als LangChain, Vercel AI SDK en diverse no-code platforms maken het steeds makkelijker om AI-applicaties te bouwen zonder diepe technische kennis.
Kosten dalen: Modellen worden efficienter. Open-source alternatieven worden beter. De prijs per token daalt gestaag.

Over een jaar ziet deze stack er waarschijnlijk weer anders uit. Maar de fundamenten — data, model, orchestration, interface — blijven staan. Net als in een keuken: de technologie verandert, maar je hebt altijd ingredienten, recepten, een chef en een zaak nodig. En eerlijk gezegd: dat is wat mij elke dag weer enthousiast maakt. De puzzelstukken veranderen, maar het puzzelen zelf — het ontwerpen van systemen die echt werken — dat blijft.

Afsluiting

De AI tech stack is geen raketwetenschap. Het is een gelaagd systeem met duidelijke functies per laag. Het voelt overweldigend als je alles tegelijk bekijkt, maar dat geldt voor elke technische stack. De eerste keer dat iemand je uitlegt hoe het internet werkt — DNS, HTTP, TCP/IP, servers, CDN's — voelt dat ook als een ander universum. Tot je het snapt. En dan is het logisch.

Mijn advies: begin bij de laag die het dichtst bij jouw probleem staat. Heb je een dataprobleem? Begin daar. Weet je niet welk model je moet kiezen? Experimenteer met API's. Wil je een prototype bouwen? Pak Streamlit of de Vercel AI SDK en bouw iets in een weekend.

De beste manier om de AI tech stack te leren, is er iets mee te bouwen. Niet om het in theorie te bestuderen, maar om je handen vuil te maken. Start de oven. Pak je ingredienten. En maak iets.

Dit is deel 8 van de serie "Reis door AI". Lees ook deel 7: AI-afkortingen voor gevorderden als je de concepten RAG, fine-tuning en embeddings nog wilt opfrissen.