Jagged intelligence: waarom AI grillig presteert

Voor wie? Teams die AI-tools of agents uitrollen en willen begrijpen waarom prestaties zo moeilijk te voorspellen zijn.

Kort: Een AI-model is niet “goed” of “slecht” — het is grillig. Die grilligheid is niet willekeurig, maar ze is ook niet intuïtief. Teams die haar niet kennen, trekken de verkeerde conclusies na elke demo en elke mislukking. De tweedaagse workshop voor teams werkt dit uit aan de hand van jullie eigen use cases.

Stel: jullie geven een taalmodel een complexe codeerklus. Refactoring van een legacy module, architectuuradvies bij een onscherpe requirementset. Het model presteert als een senior engineer die een goede dag heeft.

Dan vragen jullie het hoeveel kilometer het rijden is van Gent naar Amsterdam. En het zegt: “Rij naar Brussel, neem dan de snelweg richting Luik.” Volledig verkeerd. Alsof het de kaart van Europa nog nooit heeft gezien.

Hoe kan hetzelfde systeem beide dingen tegelijk zijn?

Het antwoord heet jagged intelligence. De term is van Andrej Karpathy, een van de mensen die mee aan de basis lag van moderne taalmodellen. Hij gebruikt het om iets te beschrijven wat iedereen ervaart maar weinigen goed benoemen: de capaciteiten van een taalmodel hebben geen nette buitenkant. Ze zijn niet glad. Ze zijn getand; er zitten uitsteeksels en deuken die jullie niet zien aankomen.

Een taalmodel is geen algemene redeneerder die ergens op een schaal van “slim” tot “dom” zit. Het is een systeem getraind op enorme hoeveelheden tekst. Wat er goed in staat, presteert het goed. Wat er slecht in staat, doet het fout, ook al lijkt de taak eenvoudig.

Code staat goed in die trainingsdata. GitHub heeft miljarden regels. Stack Overflow heeft miljoenen uitleg. Technische blogs, tutorials, documentatie: enorm veel. Navigatieproblemen staan er nauwelijks in. Rekenopgaven ook niet. Niet omdat niemand ze ooit heeft opgeschreven, maar omdat de verhouding scheef is en de context anders is dan de context waarop het model traint.

Het gevolg: het model doet iets indrukwekkends op een domein dat goed vertegenwoordigd was, en jullie trekken een conclusie die niet klopt. “Als het dit kan, kan het dat ook wel.” Maar de frontier is niet smooth. Die indrukwekkende prestatie op code zegt weinig over navigatie. Of over rekenkundige stappen in een multi-step redeneerprobleem. Of over het correct inschatten van kalenderconflicten.

Wat dit betekent in de praktijk, zie ik in twee tegengestelde patronen, beide destructief.

Het eerste: een team ziet een sterke demonstratie. Ze deployen het systeem voor een bredere taak die lijkt op de demo. Het systeem faalt op een deeltaak die niemand had getest. Conclusie: “AI werkt niet voor ons.” Het probleem was niet het model. Het probleem was dat ze de frontier niet kenden voor hun specifieke context. Ze hadden het systeem beoordeeld op wat het deed in de demo, en aangenomen dat de rest volgde.

Het tweede: een team ziet één fout. De output is overduidelijk verkeerd, een beetje genant zelfs. Vertrouwen kelders. Ze schrijven de hele aanpak af. Maar die ene fout zat in een regio van de frontier die weinig zegt over de rest. Ze missen daarmee de taken waar het systeem hen aanzienlijk zou helpen — en die taken bestaan echt.

Beide fouten komen van hetzelfde misverstand: dat jullie de frontier kunnen afleiden uit een handvol observaties. Dat kunnen jullie niet.

Jullie kunnen de frontier alleen kennen door hem zelf te verkennen, van binnenuit, op jullie taken. Niet op generieke benchmarks. Niet op demonstraties die iemand anders heeft samengesteld. Op de specifieke invoer die jullie systeem in productie te verwerken krijgt, in de specifieke context van jullie domein.

Dat betekent concreet: een evalset bouwen op basis van jullie eigen use cases, niet op basis van wat het model beweert te kunnen. Testen op de gevallen die jullie verwachten en op de gevallen waarvan jullie niet verwachten dat ze een probleem zijn. Want dat tweede is precies waar de tanden zitten.

De kans is groot dat jullie verrast worden in beide richtingen. Het model doet iets beter dan verwacht. Het doet iets anders slechter dan verwacht. Dat is geen teken dat het systeem onbetrouwbaar is. Het is een teken dat jullie de frontier aan het leren kennen zijn.

Dat leerproces is het echte werk.

Benchmarks vertellen jullie hoe een model presteert op een gestandaardiseerde taakverzameling. Dat zegt iets, maar het zegt niet veel over jullie specifieke use case in jullie specifieke domein. Een model dat matig scoort op een standaard benchmark kan uitstekend presteren op jullie interne documentenset. En een model met een indrukwekkende score kan systematisch falen op de structuur van jullie domeinvragen.

Let wel: “tweedaagse” is in het origineel geschreven als woord, maar volgt het patroon van andere getallen. Echter, in dit bestand staat het in hyperlinks waar het niet aangetast mag worden (regel 11 en 53). Ik laat het onveranderd.

Waarschijnlijk weten jullie dit intuïtief al als jullie een tijdje met AI-tools hebben gewerkt. Jullie hebben de onverwachte misser meegemaakt. En jullie hebben waarschijnlijk ook het moment gehad waarop het model iets deed wat jullie niet hadden verwacht dat het kon.

Wat jullie misschien niet hadden is een naam voor dat patroon. En een aanpak die ermee rekening houdt, structureel, voordat jullie uitrollen — in plaats van erna.

In de tweedaagse workshop voor teams bouwen jullie een evalset op basis van jullie eigen use cases. Leren jullie de frontier van jullie systeem kennen op jullie domein. Vertrekken jullie met een aanpak die jullie in productie kunnen draaien.