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 je eigen use cases.

Stel: je geeft 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 vraag je 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 je niet ziet 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 je trekt 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 — en beide zijn 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 je de frontier kunt afleiden uit een handvol observaties. Dat kun je niet.

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

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

De kans is groot dat je verrast wordt 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 je de frontier aan het leren kennen bent.

Dat leerproces is het echte werk.

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

Waarschijnlijk weet je dit intuïtief al als je een tijdje met AI-tools hebt gewerkt. Je hebt de onverwachte misser meegemaakt. En je hebt waarschijnlijk ook het moment gehad waarop het model iets deed wat je niet had verwacht dat het kon.

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

In de tweedaagse workshop voor teams bouw je een evalset op basis van je eigen use cases, leer je de frontier van je systeem kennen op jouw domein, en vertrek je met een aanpak die je in productie kunt draaien.