De stille verschuiving: van «het model vragen» naar «agenten orkestreren bovenop de data»
In 2024 en een groot deel van 2025 draaide het gesprek over taalmodellen toegepast op data-analyse om de chat: een CSV plakken, een grafiek vragen, een tabel krijgen. Dat patroon raakt uitgeput. Wat de recente ontwikkelingen domineert is iets anders: modellen die niet met tekst antwoorden, maar code uitvoeren, catalogi raadplegen, aannames valideren en controleerbare resultaten teruggeven.
Het praktische verschil is enorm. Een chat die een CSV «interpreteert» hallucineert rijen en gemiddelden met een verontrustend gemak. Een agent die SQL of Python uitvoert tegen een echte opslag kan geen cijfer verzinnen zonder dat de database-engine protesteert. Dat is de kern van de verandering: het model is niet langer de analist, maar wordt de planner die queries schrijft en resultaten verifieert.
Volwassen text-to-SQL: waar het werkt en waar het nog steeds breekt
Het genereren van SQL-queries op basis van natuurlijke taal is de meest verspreide toepassing, en ook de meest overschatte in demo’s. Volgens officiële documentatie van de belangrijkste leveranciers van analytische databases zijn de publieke text-to-SQL-benchmarks gestaag verbeterd, maar die cijfers worden behaald op schone schema’s, met zelfverklarende kolomnamen en zonder semantische ambiguïteit.
In een echte opslag verandert dat. Een terugkerend geval: de tabel heet fact_ventas_v3, er bestaat een fact_ventas_v2 die niet meer wordt bijgewerkt maar nog steeds leeft, en er is een kolom importe die in werkelijkheid in centen staat in de rijen van vóór een specifieke migratie. Geen enkel model raadt dat. Dat wordt opgelost door een datacatalogus met beschrijvingen, lineage en gedocumenteerde bedrijfsregels.
Wat wel werkt
- Verkennende queries binnen een afgebakend domein (een afdeling, een gesloten set tabellen).
- Vertaling van veelgestelde vragen naar geparametriseerde queries die vooraf door een mens zijn gecontroleerd.
- Generatie van SQL-concepten die een analist in seconden corrigeert in plaats van vanaf nul te schrijven.
Wat niet werkt (en wat we moeten toegeven)
- Vragen waarbij ongeschreven bedrijfsdefinities nodig zijn («actieve klanten» kan vijf verschillende dingen betekenen).
- Schema’s met honderden tabellen zonder beschrijvingen: het foutpercentage schiet omhoog.
- Berekeningen waarbij een verkeerd gekozen JOIN rijen verdubbelt en niemand dat opmerkt tot het rapport bij de directie belandt.
Agenten met code-uitvoering: het patroon dat zich opdringt
De aanpak die het meest is gegroeid, bestaat erin het model een geïsoleerde code-interpreter te geven. Het model schrijft pandas, DuckDB of R, voert het uit, leest de uitvoer en itereert als er een fout is. Dit heeft een beslissend voordeel voor de analyse: het resultaat is reproduceerbaar. Je kunt het script opslaan, versioneren en de volgende maand opnieuw uitvoeren.
Hier is een detail dat je alleen leert door deze tools dagelijks te gebruiken: de meeste fouten komen niet voort uit statistisch redeneren, maar uit het beheer van typen en null-waarden. Datums in gemengde formaten, categorieën met trailing spaties, bedragen met decimale komma geërfd van een oude export. Een krachtig model schrijft een onberispelijke groupby en groepeert vervolgens verkeerd omdat «Madrid» en «Madrid » twee verschillende waarden zijn. De oplossing is geen beter model: het is een laag voor voorafgaande opschoning en expliciete validaties.
Integratie met de stack: MCP en semantische catalogi
De meest relevante architectonische vernieuwing van de afgelopen maanden is de standaardisering van connectors. Het open protocol dat wordt gepromoot om assistenten met databronnen te verbinden (bekend als MCP) maakt het mogelijk dat eenzelfde model een opslag, een CRM en een spreadsheet raadpleegt zonder dat elke integratie maatwerk is.
Dit heeft een gevolg dat organisaties beginnen te aanvaarden: de waarde zit niet langer in het model, maar in de semantische laag. Metrieken één keer definiëren (netto-omzet, churn, marge) en ze aanbieden als tools die het model kan aanroepen, is wat een flitsende pilot onderscheidt van een systeem dat de derde maand overleeft.
Een patroon dat opduikt bij teams die de testfase al voorbij zijn: minder lange prompts, meer geregistreerde functies met een naam en een precieze beschrijving. Het model kiest tussen tien goed gedocumenteerde tools in plaats van SQL te improviseren over vijftig tabellen.
Evaluatie: het probleem dat bijna niemand goed oplost
Meten of een LLM goed analyseert is moeilijker dan het aan de praat krijgen. Publieke benchmarks weerspiegelen jouw data niet. De praktijk die zich bij volwassen teams consolideert, is het bouwen van een set vragen met handmatig geverifieerde antwoorden over de eigen opslag, en die uitvoeren bij elke model- of promptwijziging.
Zonder die evaluatieset is elke migratie naar een nieuw model een gok in het duister. En hier is een nuance die we in gedachten moeten houden: beter worden op een generieke benchmark garandeert niet dat je beter wordt in jouw domein. We hebben modellen gezien die slechter presteren op aggregatietaken met datumhiërarchieën omdat ze de redeneerstijl veranderen, niet omdat ze slechter zijn.
Kosten en latentie: de factor die de architectuur bepaalt
Een interactieve analyse verdraagt twee seconden wachten; een gepland rapport dat elke nacht over duizenden rijen wordt uitgevoerd, verdraagt de kosten van een groot model per query niet. Vandaar de tendens naar hybride architecturen:
- Kleine modellen of deterministische regels voor de veelgestelde en goed getypeerde vragen.
- Grote modellen alleen voor open verkenning en foutopsporing.
- Resultaatcache voor herhaalde queries, die in de praktijk de meerderheid vormen.
De tokenuitgaven worden een echte operationele kostenpost zodra twintig mensen het systeem dagelijks gebruiken. Ontwerpen zonder hiermee rekening te houden is de snelle weg naar annulering van het project.
Governance en privacy: het gesprek dat laat komt, maar komt
Klantgegevens naar een externe leverancier sturen vereist het herzien van contracten, retentie en dataresidentie. De opties voor private deployment en modellen die op eigen infrastructuur draaien, zijn voldoende volwassen geworden om levensvatbaar te zijn in gereguleerde sectoren, zij het met onderhoudskosten die veel bedrijven onderschatten.
Een veelgemaakte fout: aannemen dat «de leverancier traint niet met mijn data» het probleem oplost. Dat lost het niet op als de data je perimeter verlaat. De echte beslissing is architectonisch, niet contractueel.
Waarop te letten in de komende maanden
- Verificatie van resultaten: mechanismen die de uitvoer van het model toetsen aan een bron van waarheid voordat ze die tonen.
- Automatische lineage: weten uit welke tabel en welke transformatie elk cijfer komt dat het systeem presenteert.
- Hybride interfaces: de chat verdwijnt niet, maar leeft samen met dashboards waar het LLM alleen de uitleg bij de grafiek schrijft.
- Continue evaluatie: eigen suites die bij elke modelupdate worden uitgevoerd.
De eerlijke conclusie is dat LLM’s al duidelijke waarde bieden bij verkenning, datadocumentatie en ondersteunde querygeneratie, en dat ze fragiel blijven bij elke taak waar een verkeerd cijfer gevolgen heeft. Ontwerpen met die asymmetrie in gedachten, met de data en de validatie in het centrum en het model aan de periferie, is vandaag het verschil tussen een experiment en een systeem in productie.