03 dec 2025·6 min
Andrej Karpathy deep learning: lessen voor het uitrollen van AI
Andrej Karpathy over deep learning laat zien hoe je neurale netten omzet in producten met duidelijke aannames, metrics en een engineering-georiënteerde workflow.
Andrej Karpathy over deep learning laat zien hoe je neurale netten omzet in producten met duidelijke aannames, metrics en een engineering-georiënteerde workflow.
Een deep learning-demo kan als magie aanvoelen. Een model schrijft een nette alinea, herkent een object of beantwoordt een lastige vraag. Vervolgens probeer je die demo om te zetten in een knop die mensen dagelijks gebruiken, en dan wordt het rommelig. Dezelfde prompt gedraagt zich anders, randgevallen stapelen zich op en de wow-factor wordt een supportticket.
Die kloof is waarom het werk van Andrej Karpathy zoveel weerklank vond bij makers. Hij promootte een denkwijze waarbij neurale netten geen mysterieuze artefacten zijn. Het zijn systemen die je ontwerpt, test en onderhoudt. De modellen zijn niet nutteloos. Producten vragen alleen om consistentie.
Als teams zeggen dat ze “praktische” AI willen, bedoelen ze meestal vier dingen:
Teams struikelen omdat deep learning probabilistisch en contextgevoelig is, terwijl producten beoordeeld worden op betrouwbaarheid. Een chatbot die 80% van de vragen goed beantwoordt kan toch kapot aanvoelen als die andere 20% vol vertrouwen fout antwoordt en moeilijk te detecteren is.
Neem een "auto-reply" assistent voor klantenondersteuning. Het ziet er goed uit op een paar handgeprikte tickets. In productie schrijven klanten in straattaal, voegen screenshots toe, mengen talen of vragen naar randgevallen in beleid. Nu heb je guardrails nodig, duidelijke weigeringsgedragingen en een manier om te meten of het concept daadwerkelijk een agent hielp.
Veel mensen kwamen Karpathy’s werk tegen via praktische voorbeelden, niet abstracte wiskunde. Zelfs vroege projecten maakten een simpel punt: neurale netten worden nuttig als je ze behandelt als software die je kunt testen, kapotmaken en repareren.
In plaats van te stoppen bij “het model werkt”, verschuift de focus naar het laten werken op rommelige, reële data. Dat omvat datapijplijnen, trainingsruns die om saaie redenen falen en resultaten die veranderen als je één klein dingetje aanpast. In die wereld klinkt deep learning minder mystiek en meer als engineering.
Een Karpathy-achtige aanpak draait minder om geheime trucjes en meer om gewoontes:
Die basis is later belangrijk omdat product-AI grotendeels hetzelfde spel is, alleen met hogere inzetten. Als je de craft niet vroeg bouwt (duidelijke inputs, duidelijke outputs, herhaalbare runs), verandert het uitrollen van een AI-feature in gokwerk.
Een groot deel van Karpathy’s impact was dat hij neurale netten behandelde als iets waar je over kunt redeneren. Duidelijke uitleg verandert het werk van een “geloofssysteem” in engineering.
Dat is belangrijk voor teams omdat de persoon die het eerste prototype uitrolt vaak niet dezelfde is die het onderhoudt. Als je niet kunt uitleggen wat een model doet, kun je het waarschijnlijk niet debuggen en al helemaal niet ondersteunen in productie.
Dwing vroeg helderheid af. Voordat je de feature bouwt, schrijf op wat het model ziet, wat het oplevert en hoe je zult vaststellen of het beter wordt. De meeste AI-projecten vallen op basics, niet op wiskunde.
Een korte checklist die later rendeert:
Duidelijk denken verschijnt als gedisciplineerde experimenten: één script dat je opnieuw kunt draaien, vaste evaluatiedatasets, versiebeheer voor prompts en gelogde metrics. Baselines houden je eerlijk en maken voortgang zichtbaar.
Een prototype bewijst dat een idee kan werken. Een uitgerolde feature bewijst dat het werkt voor echte mensen, in rommelige omstandigheden, elke dag. Die kloof is waar veel AI-projecten stranden.
Een onderzoeksdemo kan traag, duur en fragiel zijn, zolang het maar capaciteit toont. Productie draait de prioriteiten om. Het systeem moet voorspelbaar, observeerbaar en veilig zijn, ook als invoer raar is, gebruikers ongeduldig zijn en het verkeer piekt.
In productie is latency een feature. Als het model 8 seconden nodig heeft, haken gebruikers af of ze drukken de knop steeds opnieuw, en jij betaalt voor elke retry. Kosten worden ook een productbeslissing, omdat een kleine promptwijziging je rekening kan verdubbelen.
Monitoring is ongezegbaar. Je moet niet alleen weten dat de service up is, maar ook dat de outputs binnen acceptabele kwaliteit blijven. Datadrift, nieuw gebruikersgedrag en upstream wijzigingen kunnen de performance stilletjes breken zonder een foutmelding te geven.
Veiligheids- en beleidschecks verschuiven van "nice to have" naar verplicht. Je moet schadelijke verzoeken, privégegevens en randgevallen op een consistente en testbare manier afhandelen.
Teams beantwoorden doorgaans dezelfde reeks vragen:
Een prototype kan door één persoon gebouwd worden. Uitrollen vereist meestal product om succes te definiëren, datawerk om inputs en evaluatiesets te valideren, infrastructuur om het betrouwbaar te draaien en QA om faalmodi te testen.
"Werkt op mijn machine" is geen releasecriterium. Een release betekent dat het voor gebruikers werkt onder load, met logging, guardrails en een manier om te meten of het helpt of schaadt.
Karpathy’s invloed is cultureel, niet alleen technisch. Hij behandelde neurale netten als iets dat je kunt bouwen, testen en verbeteren met dezelfde discipline die je op elk engineering-systeem toepast.
Het begint met het opschrijven van aannames voordat je code schrijft. Als je niet kunt zeggen wat er waar moet zijn voor de feature om te werken, zul je het later niet kunnen debuggen. Voorbeelden:
Dat zijn testbare uitspraken.
Baselines volgen. Een baseline is het eenvoudigste dat zou kunnen werken, en het is je reality check. Het kan regels zijn, een search-template of zelfs "niets doen" met een goede UI. Sterke baselines beschermen je tegen weken besteden aan een fancy model dat niets beter doet.
Instrumentatie maakt iteratie mogelijk. Als je alleen naar demo’s kijkt stuur je op gevoel. Voor veel AI-features vertelt een kleine set cijfers al of je verbetert:
Itereer daarna in korte loops. Verander één ding, vergelijk met de baseline en houd een eenvoudig logboek bij van wat je probeerde en wat bewoog. Als vooruitgang echt is, zie je het in een grafiek.
AI uitrollen werkt het beste als je het behandelt als engineering: duidelijke doelen, een baseline en snelle feedbackloops.
Stel het gebruikersprobleem in één zin vast. Schrijf het alsof het een klacht van een echte persoon is: “Supportagents doen er te lang over om antwoorden op veelvoorkomende vragen te schrijven.” Als je het niet in één zin kunt zeggen, is de feature waarschijnlijk te groot.
Kies een meetbaar resultaat. Kies één getal dat je wekelijks kunt volgen. Goede keuzes zijn tijdwinst per taak, acceptatiepercentage van eerste concept, vermindering van bewerkingen of ticketdeflectieratio. Bepaal wat "goed genoeg" betekent voordat je bouwt.
Definieer de baseline die je moet verslaan. Vergelijk met een simpel template, een regelsysteem of "alleen mens". Als de AI de baseline niet verslaat op je gekozen metric, ship dan niet.
Ontwerp een kleine test met representatieve data. Verzamel voorbeelden die overeenkomen met de realiteit, inclusief rommelige gevallen. Houd een kleine evaluatieset apart die je niet mentaal "train" door hem elke dag opnieuw te lezen. Schrijf op wat telt als een pass en wat als een fail.
Rol uit achter een flag, verzamel feedback en iterereer. Begin met een kleine interne groep of een klein percentage gebruikers. Log de input, de output en of het hielp. Los de belangrijkste faalmodus eerst op en voer dezelfde test opnieuw uit zodat je echte vooruitgang ziet.
Een praktisch patroon voor draft-tools: meet “seconden tot verzenden” en “percentage concepten dat met minimale bewerkingen gebruikt wordt.”
Veel mislukkingen van AI-features zijn geen modelmislukkingen. Het zijn "we zijn nooit overeengekomen wat succes is"-mislukkingen. Als je deep learning praktisch wilt laten voelen, schrijf dan aannames en metingen op voordat je meer prompts schrijft of modellen traint.
Begin met aannames die je feature in de praktijk kunnen breken. Veelvoorkomende aannames gaan over data en mensen: invoertekst is in één taal, gebruikers vragen per keer om één intentie, de UI biedt genoeg context, randgevallen zijn zeldzaam en gisteren’s patroon blijft volgende maand waar (drift). Schrijf ook op wat je nog niet afhandelt, zoals sarcasme, juridisch advies of lange documenten.
Zet elke aanname om in iets dat je kunt testen. Een nuttig format is: “Gegeven X, moet het systeem Y doen, en we verifiëren het door Z.” Houd het concreet.
Vijf dingen die de moeite waard zijn om op één pagina te zetten:
Houd offline en online bewust gescheiden. Offline metrics vertellen je of het systeem de taak geleerd heeft. Online metrics vertellen je of de feature mensen daadwerkelijk helpt. Een model kan offline goed scoren en toch gebruikers irriteren omdat het traag is, te vol vertrouwen, of fout in de gevallen die er echt toe doen.
Definieer “goed genoeg” als drempels en consequenties. Voorbeeld: “Offline: minstens 85% correct op de eval-set; Online: 30% van de concepten geaccepteerd met minimale bewerkingen.” Als je een drempel mist, beslis vooraf wat er gebeurt: houd het achter een toggle, verlaag de rollout, routeer laag-vertrouwengevallen naar een template of pauzeer en verzamel meer data.
Teams behandelen een AI-feature vaak als een normale UI-aanpassing: ship het, kijk wat er gebeurt, pas later aan. Dat breekt snel omdat modelgedrag kan veranderen met prompts, drift en kleine configuratiewijzigingen. Het resultaat is veel inspanning zonder duidelijk bewijs dat het geholpen heeft.
Een praktische regel is simpel: als je de baseline en de meting niet kunt benoemen, ben je nog niet klaar om te shippen.
De meest voorkomende faalmodi:
Een concreet voorbeeld: je voegt AI toe om supportantwoorden te genereren. Als je alleen duimpjes bijhoudt, mis je misschien dat agents langer doen over het beoordelen van drafts, of dat antwoorden accuraat maar te lang zijn. Betere metrics zijn “% verzonden met minimale bewerkingen” en “mediaan tijd tot verzenden.”
Behandel releasedag als een engineering-handoff, niet als een demo. Je moet in eenvoudige woorden kunnen uitleggen wat de feature doet, hoe je weet dat het werkt en wat je doet als het faalt.
Voordat je shipt, zorg dat je hebt:
Houd ook een offline-evaluatieset die op echt verkeer lijkt, randgevallen bevat en stabiel genoeg blijft om over weken te vergelijken. Als je prompts, modellen of datacleaning verandert, draai dan dezelfde set opnieuw en kijk wat er bewoog.
Een supportteam wil een assistent die concepten voor antwoorden schrijft in de ticket-view. De agent verstuurt geen berichten automatisch. De assistent suggereert een concept, markeert kernfeiten die gebruikt zijn en vraagt de agent om te controleren en te bewerken voordat verzonden wordt. Die ene keuze houdt het risico laag terwijl je leert.
Begin met bepalen wat “beter” betekent in cijfers. Kies uitkomsten die je vanaf dag één kunt meten met bestaande logs:
Voordat je een model inzet, stel een saaie maar reële baseline vast: opgeslagen templates plus een eenvoudige regelslaag (detecteer refund vs verzending vs wachtwoordreset en vul het beste template in). Als de AI die baseline niet verslaat, is het nog niet klaar.
Draai een kleine pilot. Maak het opt-in voor een handvol agents en beperk het tot één ticketcategorie eerst (bijv. orderstatus). Voeg snelle feedback toe op elk concept: “helpful” of “not helpful”, plus een korte reden. Leg vast wat de agent wijzigde, niet alleen of ze op een knop klikten.
Definieer ship-criteria vooraf zodat je later niet hoeft te gokken. Bijvoorbeeld: handelstijd verbetert met 10% zonder stijging in escalatie of heropen-rate, en agents accepteren drafts met minimale bewerkingen minstens 30% van de tijd.
Bepaal ook wat rollback triggert: een piek in escalaties, een daling in tevredenheid of herhaalde beleidsfouten.
Kies één AI-idee dat je in 2 tot 4 weken kunt uitrollen. Houd het klein genoeg zodat je het kunt meten, debuggen en terugdraaien zonder drama. Het doel is niet om te bewijzen dat het model slim is. Het doel is om een gebruikersuitkomst betrouwbaarder beter te maken dan wat je al hebt.
Zet het idee om in een één-pagina plan: wat de feature doet, wat het niet doet en hoe je weet dat het werkt. Neem een baseline en de exacte metric die je gaat volgen op.
Als je snel wilt implementeren, is Koder.ai (koder.ai) gebouwd rond het maken van web-, server- en mobiele apps via een chatinterface, met features zoals snapshots/rollback en broncode-export wanneer je diepergaande controle nodig hebt.
De gewoonte die je moet behouden is simpel: elke AI-wijziging moet gepaard gaan met een geschreven aanname en een meetbaar resultaat. Zo voelt deep learning minder als magie en meer als werk dat je kunt uitrollen.
Omdat demo’s meestal gebouwd zijn op schone, zorgvuldig geselecteerde invoer en beoordeeld worden op gevoel, terwijl producten te maken hebben met rommelige invoer, gebruikersdruk en herhaaldelijk gebruik.
Om de kloof te dichten: definieer een input/output-contract, meet kwaliteit op representatieve data en ontwerp fallbacks voor timeouts en gevallen met lage vertrouwen.
Kies één metric die gekoppeld is aan gebruikerswaarde en die je wekelijks kunt volgen. Goede standaardkeuzes:
Bepaal het "goed genoeg"-doel voordat je prompts of modellen finetunet.
Gebruik het eenvoudigste alternatief dat realistisch gezien zou kunnen worden uitgerold:
Als de AI de baseline niet verslaat op de belangrijkste metric (zonder latency/kosten te breken), ship hem dan nog niet.
Houd een kleine set aan die lijkt op reëel verkeer, niet alleen ideale voorbeelden.
Praktische regels:
Dit maakt voortgang zichtbaar en vermindert onbedoelde regressie.
Begin met voorspelbare, testbare guardrails:
Behandel guardrails als productvereisten, geen optionele afwerking.
Monitor zowel systeemgezondheid als uitvoerkwaliteit:
Log ook inputs/outputs (met privacycontroles) zodat je fouten kunt reproduceren en de belangrijkste patronen kunt repareren.
Stel vooraf een maximaal budget vast: streef-latency en max kosten per request.
Verminder kosten zonder te gokken:
Een kleine kwaliteitswinst is zelden de moeite waard als het veel trager of veel duurder wordt in productie.
Rol uit achter een flag en voer een geleidelijke rollout uit.
Een praktisch uitrolplan:
Rollback is geen falen; het is onderdeel van AI onderhoudbaarheid.
Minimale rollen die afgedekt moeten zijn (zelfs als één persoon meerdere petten draagt):
Shippen werkt het best als iedereen het eens is over metric, baseline en rollback-plan.
Gebruik het als je snel van idee naar werkende app wilt, maar toch engineeringdiscipline wilt behouden.
Een praktisch workflow:
Het hulpmiddel versnel je iteraties; je hebt nog steeds duidelijke aannames en meetbare outputs nodig.