AI — Jakub Ćwirlej

Een leesspel: terwijl je rustig leest, eet een robot een regel code van deze site en scoort punten; te snel of onregelmatig scrollen laat hem tekens missen. Decoratief — het heeft geen invloed op de tekst.

…Ik heb geen formele opleiding in programmeren of in het trainen van LLM’s.

Dat ik apps ben gaan bouwen en AI ben gaan trainen, komt door een volkomen vreemde samenloop van toevalligheden, al lijkt die achteraf bekeken toch behoorlijk logisch. En ik denk dat het iets belangrijks zegt over onze tijd. Ik had het niet gepland; ik had nooit gedacht dat ik ooit meer met technologie te maken zou hebben dan een gemiddelde iPhone-gebruiker. Jarenlang was de podcast Hard Fork mijn enige venster op de wereld van Big Tech. De groeten aan Casey en Kevin :)

Het begon allemaal met vibecoding en de app OrsonAI. Al spelend met kunstmatige intelligentie ging ik tools maken die me konden helpen bij mijn dagelijkse journalistieke werk. Interviews al tijdens de opname omzetten in tekst en ze in een editor importeren, of een bewerkingsmodus waarin je geselecteerde tekstfragmenten met de chatbot kon bespreken zonder tussen vensters te moeten wisselen en de hele context opnieuw te moeten plakken: dat waren toen echt toffe tools, die mijn werk flink versnelden.

Gaandeweg begon ik het te zien als een project, als iets waar ook anderen iets aan zouden kunnen hebben. Het idee was simpel: de hulpmiddelen waarmee ik zelf tijd bespaar, ombouwen tot een product voor mensen die tegen dezelfde problemen aanlopen. Ik heb veel tijd gestoken in het ontwikkelen van een interface en mechanismen die veilige AI voor redacties konden garanderen – AI die de journalist helpt, maar hem het werk niet uit handen neemt. Ik ontwierp zelfs een systeem dat aan teksten certificaten van menselijk auteurschap toekent en die publiceert op het openbare ledger van Hedera Hashgraph. Een onveranderlijk bewijs met juridische bewijskracht, dat laat zien hoe een tekst tot stand kwam en hoe groot het aandeel van de mens daarin was.

Hier vind je een beschrijving van de HDK-technologieHier kun je de gratis HDK-bibliotheek downloadenHDK op Hugging Face

Toch wachtte me een flinke teleurstelling. Mensen uit de sector aan wie ik de app liet zien, reageerden meer dan koel. De vraag die aan het eind van elke presentatie terugkwam, maakte me pijnlijk duidelijk hoezeer ik me had vergist: ‘Waarom zou iemand voor jouw app betalen als we gratis ChatGPT hebben?’ Een certificaat van menselijk auteurschap, gegevensbescherming of zelfs een aanzienlijk efficiëntere werkwijze dan wat een gewone chatbot bood: het deed er allemaal niet toe. Ik hoorde dat van mensen die dagelijks het belang van betrouwbare journalistiek benadrukken.

Het werk aan de app en aan een agentisch AI-systeem dat betrouwbaar genoeg zou zijn om op nieuwsredacties te worden ingezet, duwde me echter in een volledig nieuwe richting. In een poging beter te begrijpen waar de hallucinaties van taalmodellen vandaan komen, begon ik wetenschappelijke papers op arXiv te lezen, en uiteindelijk ontwierp en voerde ik een reeks experimenten uit rond de activatie van SwiGLU-gates in enkele open taalmodellen. De conclusies van dat onderzoek beschreef ik in een paar papers die ik op ResearchGate heb gezet. Ook al lijken sommige stellingen uit die papers me nu megalomaan, en zou de tekst zelf waarschijnlijk een revisie en een wetenschappelijker vocabulaire kunnen gebruiken, ik verwijder ze niet – al was het maar uit wetenschappelijke integriteit.

Hier vind je mijn papers over dit onderwerp

Vandaag ben ik bescheidener; die bescheidenheid heb ik opgedaan op het oefenterrein van het trainen van taalmodellen, na veel mislukte experimenten en teleurstellingen. Als ik nu over de gevonden GSI-signalen schreef, zou ik eerder spreken van proxysignalen voor kennis dan van ‘epistemisch bewustzijn’ van het model. Anderzijds kon ik op basis van harde data vaststellen dat confabulatie grotendeels een tweestapsproces is, waarbij het model – zonder houvast in feiten – vrijwel altijd een samenhangende vorm verkiest boven de waarheid. Voor mij persoonlijk was dat het boeiendste moment van die experimenten: het ogenblik waarop mijn vroegere interesse voor filosofie en epistemologie een onverwachte, volledig meetbare weerspiegeling vond in de architectuur van transformers. Een andere kwestie is wel de dagelijkse bruikbaarheid van die signalen in productieomstandigheden. Om hun doeltreffendheid bij het opsporen van hallucinaties te vergelijken met andere gangbare methoden, zou zeker aanvullend onderzoek nodig zijn.

Die taak nam me volledig in beslag. Misschien past dat wel een beetje bij mijn karakter – ik stort me graag op bezigheden die een uitdaging vormen, maar me ook iets leren over de wereld om me heen en me helpen die beter te begrijpen. Trouwens, voor ik in de journalistiek belandde, studeerde ik filosofie, met een bijzondere interesse voor wetenschapsfilosofie en epistemologie.

Hier vind je een essay waarin ik een aantal van mijn gedachten samenvat

Het trainen van mijn eigen model draaide uit op een totale ramp. Ik heb waarschijnlijk alle denkbare fouten gemaakt, en dat terwijl ik gewend ben grondig research te doen en een enorme hoeveelheid vakliteratuur had verslonden. De eerste resultaten leken veelbelovend, maar pas later begreep ik dat ze grotendeels te danken waren aan ruisregularisatie. Het voordeel van het model in de ablatietests woog niet op tegen de extra rekenlast (compute) die het berekenen van de Gini van de gate-activaties met zich meebracht. Daarbovenop kwamen nog puur technische uitdagingen bij de training. Hield ik mijn modificaties buiten de normalisatie, dan remden ze het effectieve leren af; paste ik wel normalisatie toe, dan werden ze afgevlakt en werd het model een standaardtransformer, maar dan duurder om te trainen. De details van de architectuur stel ik hier ter download beschikbaar – misschien vindt iemand er bruikbaar materiaal in om te leren van andermans fouten.

Een oplossing die volgens mij ondanks alles aandacht verdient, is de M2-gate. Dankzij een affien anker kan ze op basis van een sigmoïdefunctie blijven werken zonder het risico dat een luie optimizer, op zoek naar een makkelijke manier om de trainingsloss te verlagen, haar naar beneden trekt. In mijn model moest die gate, getraind op Gini-signalen van de activaties, ruis wegsnijden wanneer het model genereerde. Maar het signaal buiten de normalisatie houden leidde – zoals ik al zei – tot een model met een overdreven zekerheidsverdeling: logisch vaardiger, maar de facto slechter in het leren van feiten. Misschien kan deze oplossing in andere modellen van pas komen voor de gating van andere elementen, en het trainingsproces helpen.

Al mijn mislukkingen met het trainen van een model op basis van mijn eigen architectuur ben ik uiteindelijk gaan zien als kapitaal dat je niet mag verspillen. Vandaag train ik mijn eigen kleine model, EUGEN 160M, dat gespecialiseerd is in code. Als ik de benchmarkresultaten tot nu toe vergelijk, ben ik voorzichtig optimistisch en ga ik ervan uit dat het geen verloren tijd zal zijn. Ik koos ervoor een model te trainen dat zich specialiseert in backendtalen, omdat je bij dit soort architecturen de vooruitgang makkelijker kunt monitoren en het model zelf een handige tool voor automatisch aanvullen (autocomplete) kan zijn bij inferentie op een gewone CPU. Je kunt het model testen in een speciaal daarvoor ingerichte terminal op mijn site en het vergelijken met andere open oplossingen van vergelijkbare omvang.

Hier kun je het model Eugen 160M testen

De resultaten tot nu toe zijn vooral te danken aan het nauwgezet bijhouden van de vooruitgang en van de fouten die het model maakt tijdens het genereren. Daardoor kon ik telkens meteen ingrijpen: ik voegde trainingsdata toe die het model versterkten waar het zwaktes vertoonde. Ik paste ook geregeld de technieken STaR en LEMA toe, waarbij ik synthetische data maakte op basis van wat het model zelf had gegenereerd, en vertaaldata die het model de logica van code leren door het voorbeelden te tonen van vertalingen tussen Python en C++, Java en Rust. Al dat materiaal maakt momenteel ongeveer 0,35% van de volledige dataset uit, en dat aandeel zal geleidelijk stijgen naarmate de training vordert.

Het trainen van het model bezorgt me veel plezier en geeft me – net als vroeger de journalistiek – het gevoel dat ik iets belangrijks doe; iets waardoor ik de veranderingen in de wereld om me heen beter kan vatten. Ik kan zelf geen complexe C++-code van nul schrijven, dat klopt, maar ik probeer de logica van de processen te begrijpen. Zo boek ik kleine successen waarmee ik in mijn werk vooruitkom. Ja – met hulp van een AI-codeeragent heb ik een eigen Triton-kernel gebouwd waarmee je een sparse model kunt trainen, met een TPS-winst (Tokens Per Second) van 23% ten opzichte van een dense model; latere optimalisaties van de kernel leverden nog eens 36% op. Ik ben van plan die oplossing te gebruiken bij het trainen van een volgend, iets groter model.

De kernel kun je hier downloadenKernel op Hugging Face

En om terug te komen op het model waarmee het allemaal begon... Vandaag zie ik dat mijn grootste fout niet mijn technische naïviteit was. Dat model kón gewoon niet werken zoals ik had verondersteld. Het probleem was niet technologisch, maar puur filosofisch. En als iemand die filosofie heeft gestudeerd, had ik dat meteen aan het begin moeten zien, met Tarski's waarheidsdefinitie en de stellingen van Gödel in het achterhoofd. Volgens beide kan geen enkel voldoende complex systeem zijn eigen consistentie volledig bewijzen, noch waarheid definiëren uitsluitend vanuit zichzelf. De poging om het model zijn eigen interne toestanden in realtime te laten analyseren, beoordelen en corrigeren, sloot het op in een structurele lus waaruit – zonder metaniveau en extern referentiepunt – simpelweg geen uitweg was.

Toen ik aan dit avontuur begon, wilde ik gewoon een tool maken om journalistieke interviews makkelijker uit te schrijven. Al snel bleek echter dat wie de wereld van kunstmatige intelligentie binnenstapt, een echte sprong maakt in het konijnenhol uit ‘Alice in Wonderland’ – hoe dieper je afdaalt, hoe complexer, gelaagder en fascinerender alles wordt. Mijn eerste app heeft op de mediamarkt dan misschien geen revolutie ontketend, maar die val door het konijnenhol heeft me op een punt gebracht waar ik met succes mijn eigen architectuur train. Ik heb een lange weg afgelegd: van passieve luisteraar van techpodcasts tot iemand die de parameters van modellen fysiek vormgeeft en begrijpt wat er vanbinnen gebeurt.

Heb je vragen? Ik beantwoord ze graag.

Een leesspel: terwijl je rustig leest, eet een robot een regel code van deze site en scoort punten; te snel of onregelmatig scrollen laat hem tekens missen. Decoratief — het heeft geen invloed op de tekst.

1. Berekeningen op papier vallen altijd te optimistisch uit

Bij het trainen van een model denken we vanzelf aan het proces van machine learning – het werk dat krachtige Nvidia-clusters in datacenters voor ons doen, of, als we meer geluk hebben, ons eigen loeikrachtige werkstation. Bij het lezen van de specificaties vergeet je makkelijk dat de reële MFU (Model FLOPs Utilization) veel lager ligt dan het marketingmateriaal van de kaartfabrikant doet vermoeden. Afhankelijk van de architectuur en de details haal je met je hardware slechts een fractie van de rekenkracht uit het silicium. Wat heb je eraan dat de kaart in FP4 rekent, als dat bij het trainen van een basismodel vanaf nul niet stabiel werkt, of als zakken onder BF16 bij de breedte van jouw model geen enkel voordeel oplevert?

Het is geen makkelijk moment wanneer je beseft dat je het geplande model niet binnen de beoogde tijd kunt trainen, en zelfs niet in de buurt van de beoogde omvang. Zeker niet als je er weken over hebt gedaan om op het punt te komen waar je met trainen kunt beginnen, en dan ineens blijkt dat het hele plan onrealistisch was. Op papier klopte toch alles! De eerste reflex is zoeken naar optimalisatiemethoden – torch compile, autocast, flash attention, FLCE, heads en minibatches waarvan de grootte is afgestemd op wat CUDA het liefst heeft. Dat werkt allemaal, maar de fysica van silicium laat zich niet bedotten. Als je een klein model traint, werkt de geringe breedte ervan tegen je. Als je je de training van een groot model niet kunt veroorloven, kun je je ook niet veroorloven het maximum uit je GPU te halen. Het kan dagen duren voor je je kaart optimaal benut, en als je TPS (Tokens Per Second) tijdens de training uiteindelijk 30-40% lager uitvalt dan je oorspronkelijk had berekend, scheelt dat dagen of zelfs weken rekentijd.

2. Begin altijd op de kleinst mogelijke schaal waarop je je ideeën kunt valideren

Mijn eerste model had 1.5B parameters en ik kon het amper tot drie keer Chinchilla trainen. Bij de bouw ervan maakte ik veel fouten, maar het werkte toch. Dat het zo weinig bruikbaar was, kwam vooral door ondertraining. Had ik met hetzelfde budget een tien keer kleiner model getraind, dan had ik kunnen uitpakken met een goed getraind en bruikbaar model. Ik had tijd gehad om te testen en had zeker veel fouten vermeden, waardoor ik een betere architectuur had kunnen bouwen. Grootte doet er natuurlijk toe, maar data, architectuur en rekenefficiëntie doen er nog meer toe. De kans dat je een goed model ontwerpt op basis van de literatuur, zonder tests en zonder vergissingen, is ongeveer zo groot als de kans op de jackpot in de lotto.

3. Een model traint zichzelf niet

Een model trainen klinkt tof, maar het is een stuk saaier dan je zou denken. In werkelijkheid is het grotendeels een proces van voortdurend experimenten opzetten, metingen doen, de resultaten van het model analyseren en oplossingen zoeken voor problemen die onderweg opduiken. Constant, de klok rond, dag na dag. Als je geen voldoening kunt halen uit kleine ontdekkingen en kleine successen, kan het je al snel te saai worden. En toch is het juist de ijzeren consequentie in het meten die alles bepaalt. Zelfs met goed gekozen trainingsparameters kan na verloop van tijd blijken dat ons model nieuwe data nodig heeft of degradeert op een manier die op het eerste gezicht moeilijk te zien is. Dat merk je niet zonder goede monitoring en voortdurende tests, en hoe minder vaak je ze doet, hoe meer tijd je verliest als het model zich ongewenst begint te gedragen.

Neem een veelvoorkomend scenario. Na een paar dagen training merk je dat het model steeds kortere antwoorden geeft en daarbij steeds zelfverzekerder wordt. De loss en de held-outset zien er goed uit, maar er is iets mis met het model. Als je de normen voortdurend analyseert en de antwoorden van het model elke dag vergelijkt met die van gisteren, kun je snel zien dat de logits oplopen en doorhebben dat het model een steeds grotere waarschijnlijkheid toekent aan bepaalde tokens. Die arrogantie is een truc van de luie optimizer – AdamW heeft een manier gevonden om ons te bedriegen: in plaats van het model iets te leren, drukt hij de loss langs een andere weg. Als je dat na een paar dagen opmerkt, verlies je misschien enkele tientallen dollars; als je de training laat lopen in de hoop dat die Nvidia-kaart al het werk wel doet, kun je honderden of duizenden dollars kwijt zijn en is het model misschien niet meer te redden.

Zelf heb ik wekenlang toegekeken hoe Adam de normen van mijn modellen opblies en zo de effectieve learning rate (LR) verlaagde, en dat ondanks de toegepaste QK-norm en een weight decay van 0.1. De training vertraagde, wat me tot wanhoop dreef, want zoals we weten geldt hier de stelling van Pythagoras: een groeiende gewichtsvector is met een constante LR steeds moeilijker te roteren. Het probleem is goed beschreven in de literatuur, maar zolang je het niet zelf ziet, begrijp je niet waarom je beter een andere optimizer kunt gebruiken. AdamW heeft tenslotte al honderden modellen helpen trainen. Ik koos uiteindelijk voor MuonH, en dat was een van de betere beslissingen die ik heb genomen. Natuurlijk kun je veel van dat soort dingen halen uit de literatuur, uit handboeken of door de papers op arXiv te volgen, maar je weet nooit hoe het bij jou zal uitpakken. Veel oplossingen die in theorie goed gedocumenteerde voordelen zouden moeten opleveren, werkten bij mij niet. Je komt er pas achter als je het zelf uitprobeert, en daarvoor moet je de vinger aan de pols houden en de vooruitgang op de voet volgen.

4. Voer altijd maar één wijziging tegelijk door en doe ablatietests

De afgelopen maanden heb ik honderden kleine modellen getest – zowel klassieke transformers als mijn eigen ideeën... en vandaag weet ik dat ik te weinig heb getest. Omdat ik te snel vooruit wilde, verloor ik onnodig tijd. Aantal lagen, FFN-ratio, d_model, weight tying, grootte van de heads, aantal KV-heads, batch, optimizer, recurrentie, ijlheid (sparsity), trainingsdata – er zijn tientallen factoren die het gedrag van een model beïnvloeden, en de mogelijke combinaties leveren duizenden mogelijke architecturen op. En hoewel in grote lijnen alles werkt zoals je zou verwachten na het lezen van je eerste handboek over AI-engineering, weet je niet waar je staat zolang je je eigen architectuur niet zelf hebt getest. Intussen leiden kleine wijzigingen vaak tot grote verschillen in rekenefficiëntie en benchmarks, en dat bij dezelfde dataset en batchgrootte. Als je wijzigingen niet geïsoleerd doorvoert, raak je makkelijk de draad kwijt. Ik heb die fout zelf vaak gemaakt. Niet dat de aanpassingen slecht waren. Al waren ze dat vaak wel. Het echte probleem was dat ik, als ik dan echt een stap vooruit zette, niet kon zeggen aan welke wijziging ik dat te danken had.

5. Begin bij de data

Hugging Face biedt een onvoorstelbare hoeveelheid trainingsdata, zeker gemeten aan de behoeften van een klein model. Je zou denken dat de zaak daarmee geregeld is: die data liggen binnen handbereik, in hoeveelheden die de behoeften van welk zolderkamerproject ook ruim overstijgen. Maar de selectie van data is veel belangrijker dan het aanvankelijk lijkt. En het feit dat ze al in kant-en-klare datasets zijn gebundeld, maakt het helemaal niet makkelijker. Dan is er nog de keuze van de juiste tokenizer, van de talen die je het model wilt leren, of van de verhoudingen. Bijvoorbeeld: hoeveel procent van de data uit code moet bestaan, hoeveel uit wiskunde en hoeveel uit natuurlijke taal. Vervolgens: in welke domeinen ons model zich moet specialiseren. Hoe dieper je het bos in gaat, hoe meer mogelijkheden. Zelf moest ik mijn dataset maar liefst drie keer van nul opbouwen. Ik had ook een paar kleinere missers, zoals een lek van het instruct-template dat ik bij het voorbereiden van de data niet had opgemerkt. Elke keer dwong zo'n vergissing me de training uren of zelfs dagen terug te draaien.

6. Verwacht niet te veel

Als je ziet hoe grote en kleinere labs telkens weer de grenzen verleggen van wat AI kan, krijg je makkelijk de indruk dat het trainen van een bruikbaar model eigenlijk een eenvoudige zaak is. Er zijn echter redenen waarom het verleggen van die grenzen miljarden dollars kost. Dat jouw model met een menselijke stem begint te praten of goede resultaten haalt op populaire benchmarks, zegt niets over zijn uiteindelijke kwaliteit of bruikbaarheid. Modellen leren aan het begin, in de eerste dagen van de training, heel snel, maar de strijd om elk volgend procentje in de resultaten vraagt vindingrijkheid, aandacht en doorzettingsvermogen. Zeker als je dagenlang ziet hoe het model op een plateau blijft hangen of zelfs achteruitgaat. Bovendien zeggen populaire benchmarks weinig over de werkelijke mogelijkheden van een model. Je model kan goed zijn in Python en uitstekend scoren op HumanEval en MBPP, maar als het geen kennis heeft van de nieuwste bibliotheken, zal zijn bruikbaarheid in de echte wereld matig zijn.

7. Wapen je met geduld

Veel vaardigheden van modellen groeien sprongsgewijs. Het goed beschreven fenomeen grokking wordt vaak voorafgegaan door een langdurig plateau dat dagen kan aanhouden. Wanneer je ziet dat het model geen enkele vooruitgang boekt, terwijl je voor elk uur training dollars moet betalen voor gehuurde rekenkracht of op zijn minst voor de stroom, ga je al snel twijfelen. Je denkt: ‘Het model heeft zijn capacity bereikt, meer leert het niet’, of ‘De grote labs die tot 1000x Chinchilla trainen, gebruiken vast een paar trucs.’ Maar vaardigheden groeien vaak sprongsgewijs. Het model hoeft maar te leren een of andere functie correct af te sluiten, en ineens springt het aantal geslaagde opgaven in MBPP van één naar meer dan tien. Vaak boekt het model ook echte vooruitgang, maar als je om te besparen alleen de top1 van de antwoorden monitort in plaats van de top10, merk je dat misschien lange tijd helemaal niet. Het model moet leren meer zekerheid toe te kennen, en dat kost tijd.

8. Eén kaart is niet genoeg

Je zou denken dat alleen je budget je nog beperkt als je over een H100 of een RTX PRO 6000 (96 GB) beschikt. Het probleem is dat training voortdurende tests en metingen vergt, die je helpen inschatten in welk stadium je zit. Een extra GPU kan ook nodig zijn om extra trainingsdata te genereren. Zelf boekte ik aanzienlijke vooruitgang door mijn model te trainen met de STaR-methode, waarbij mijn eigen model een grote hoeveelheid opgaven genereert en de correcte daarvan aan de dataset worden toegevoegd, en met een dataset met voorbeelden van vertalingen tussen programmeertalen

Training op een krachtige kaart onderbreken zodat het model antwoorden kan genereren is erg duur en gewoonweg niet rendabel, en ernaast genereren – ook al laat het VRAM dat toe – kan een ernstig risico vormen. Het laatste wat je wilt, is na drie dagen, als de resultaten van het model achteruitgaan, ontdekken dat er tijdens het genereren naast de training op de kaart bijvoorbeeld een kortstondige ‘uithongering’ van de dataloader is opgetreden, waardoor de loss stilletjes niet meer daalde. Zulke dingen zijn in een later stadium van de training vaak bijzonder moeilijk op te sporen, zelfs als je monitoring hebt die je waarschuwt voor pieken in de normen.

9. Begin met iets eenvoudigs

Aan mijn eerste model begon ik vanuit de intuïtie dat je bij het trainen van een LLM de eigen activaties van het model kunt benutten, en dat het volgen ervan tijdens het leren zou moeten helpen om een slimmer en waarheidsgetrouwer model te bouwen. Vandaag kan ik me alleen maar over mezelf verbazen: wat was die aanpak naïef. Niet omdat ik nu denk dat het onmogelijk is, maar omdat ik ben gaan experimenteren met iets wat me boven het hoofd groeide, zonder enig idee van hoe het trainen van een LLM in zijn werk gaat. Ik moest me een enorme hoeveelheid kennis eigen maken en tegelijk zowel oplossingen uit de architectuur van klassieke transformers testen als mijn eigen ideeën, die – zo bleek na verloop van tijd – grotendeels onuitvoerbaar waren.

Daarbij stuitte ik op een hele reeks problemen – het activatiesignaal van de SwiGLU-gates verloor na normalisatie zijn betekenis, en zonder normalisatie gebruikte AdamW mijn modificaties om de normen van het model op te blazen. Pas na verloop van tijd begreep ik dat veel van de voordelen die ik in mijn eerste model had gevonden, voortkwamen uit een fenomeen dat leek op ruisregularisatie. Bovendien was het berekenen van de Gini uit de activaties van de SwiGLU-gates zelf rekenintensief: het voegde enkele procenten extra compute toe, die zich niet terugbetaalden in kwaliteit.

Momenteel train ik een klein model van 160M in een standaardarchitectuur, dat gespecialiseerd is in coderen. Dat was de beste beslissing die ik kon nemen, want zo gaf ik mezelf de kans iets te maken dat echt bruikbaar kan zijn. En de eerste resultaten van het model laten zien dat ik niet voor niets uit mijn fouten heb geleerd.

10. Bouw geen model dat goed moet zijn in alles

Gezien de astronomische kosten en de haalbaarheid zelf heeft het vandaag, om puur economische redenen, totaal geen zin dat één persoon of een kleine organisatie een model voor algemeen gebruik bouwt. De concurrentie met de reuzen, of zelfs met kleinere labs die open modellen uitbrengen, is niet te winnen zonder enorme investeringen en ervaring. Maar dat betekent helemaal niet dat het bouwen van eigen modellen zinloos is.

Je kunt je honderden toepassingen voorstellen waarin kleine modellen, van de grond af getraind of bijgetraind op unieke data, een voorsprong zullen hebben op de reuzen – en die voorsprong hoeft niet per se in kennis te liggen. Het is al genoeg dat het model snel is en lokaal kan draaien in de browser, of op de processor van een willekeurig werkstation. Voor specifieke, smalle toepassingen kan het veel rendabeler zijn een micromodel van enkele honderden miljoenen parameters te gebruiken dan de krachtigste beschikbare modellen van OpenAI of Anthropic in te zetten. Het gaat niet alleen om de kosten. Al is het verschil kolossaal. Een model dat gespecialiseerd is in een smal domein, is niet alleen veel makkelijker te trainen, maar ook te controleren en af te stemmen op de behoeften van de gebruiker. Maar het allerbelangrijkste: het is een taak die binnen het bereik ligt van een gewoon mens die bereid is zo'n uitdaging aan te gaan.

De modellen van de grote labs worden getraind op duizenden zeer dure chips. Een voorbeeld: voor het trainen van een model van de klasse Llama 3 400B was een cluster van 16.000 H100-kaarten nodig. De kosten liepen in de tientallen miljoenen dollars. De training van de nieuwste GPT Astra heeft de lat waarschijnlijk nog veel hoger gelegd. Aangezien de hele sector op krediet groeit, en grootschalige implementatie van AI bij de huidige API-kosten en kwesties rond gegevensbeveiliging bedrijfseconomisch vaak moeilijk te verdedigen is, mag je verwachten dat kleine modellen op lange termijn een steeds grotere rol zullen spelen. Kleine modellen zullen ook steeds efficiënter worden. Het zou me niet verbazen als we in de toekomst voor de meeste taken genoeg hebben aan een model van zo'n 7B parameters. Het barsten van de ‘AI-bubbel’, waarover in de media steeds vaker wordt gesproken, kan dat proces alleen maar versnellen.

Daarom vind ik het bouwen van kleine modellen diep zinvol. Ten eerste is er geen betere manier om te begrijpen hoe AI werkt dan je eigen model te trainen. Ten tweede: hoewel in grote labs de ontwikkeling van AI steeds vaker in handen is van... AI zelf, mag je verwachten dat de mensheid, als ze veiligheid serieus neemt, controle en menselijk toezicht op het trainingsproces zal eisen. Daarvoor is begrip nodig van hoe dat proces in de praktijk verloopt. Natuurlijk worden we vandaag, zodra we LinkedIn openen, overspoeld met posts over kunstmatige intelligentie van de meest uiteenlopende specialisten die tutorials en opleidingen aanbieden. Maar hoeveel van hen hebben echt hun eigen model getraind?

Heb je vragen? Ik beantwoord ze graag.

Een leesspel: terwijl je rustig leest, eet een robot een regel code van deze site en scoort punten; te snel of onregelmatig scrollen laat hem tekens missen. Decoratief — het heeft geen invloed op de tekst.

Heb je vragen? Ik beantwoord ze graag.

Een leesspel: terwijl je rustig leest, eet een robot een regel code van deze site en scoort punten; te snel of onregelmatig scrollen laat hem tekens missen. Decoratief — het heeft geen invloed op de tekst.

Deze tekst is een van de moeilijkste waarmee ik me ooit heb moeten meten. Als journalist, en tegelijk als iemand die thuis in alle rust zijn eigen modellen traint, sta ik op twee tegenovergestelde polen. Enerzijds fascineert de pure engineering me, anderzijds ben ik me er ten volle van bewust dat de veiligheid van kunstmatige intelligentie waarschijnlijk de belangrijkste uitdaging is van de tijd waarin we leven.

Ik begin met wat me persoonlijk het meest pijn doet: de tragische vervlakking van het publieke debat over AI-veiligheid. Het is een debat vol tegenstrijdigheden en extreme emotionele lading. Al is dat moeilijk anders te verwachten wanneer er miljardenbelangen en het voortbestaan van de mens op het spel staan.

Aan de ene kant horen we dat AI een dodelijk gevaar is en dat de ontwikkeling ervan de mensheid met de ondergang bedreigt. Aan de andere kant dat die apocalyptische visioenen niets anders zijn dan een cynisch spel van de reuzen, die hun waardering willen opdrijven voor de uitgifte van hun aandelen, of kleinere bedrijven willen blokkeren en afremmen om hun monopolie en hun plaats aan de kop van het peloton te behouden. De gewone mens, die geen tijd heeft om dat allemaal te volgen en eenvoudige oplossingen verwacht, belandt makkelijk in het kamp van de technomaximalisten of van de doemprofeten. Elk van die visies is zo glad, zo vanzelfsprekend... en geen van beide vraagt verder ook maar iets van ons. Want als we machteloos staan tegenover krachten die ons te boven gaan, hoeven we toch niets te doen. In deze tijden van extreem maximalisme is dat een heel comfortabele positie.

Wat zou ik zelf antwoorden als mijn kind me vroeg of AI een bedreiging voor ons is? Als ik de vereenvoudigende reframing wil vermijden, zou ik moeten toegeven dat er drie mogelijkheden zijn: dat we inderdaad gedoemd zijn ten onder te gaan, dat het uiteindelijk niet zover komt (want – zoals Yann LeCun betoogt – we zullen deze technologie gewoon leren beheersen), of... dat de ondergang al begonnen is. De paradox is dat alle drie de scenario's tegelijk waar kunnen zijn.

Dat het ergste waarschijnlijk al begonnen is, volgt uit een feit dat zelden tot de mainstream doordringt: elke technologie, elke uitvinding moet op het juiste moment en in de juiste voedingsbodem terechtkomen om zich ten volle te kunnen ontplooien. Kernenergie – zo vaak als vergelijking aangehaald in dit debat – was tijdens de Koude Oorlog een dodelijke bedreiging, maar werd in vredestijd een bron van goedkope energie die bijdroeg aan een economische boom. Hetzelfde kun je zeggen over de meeste uitvindingen: van het bewerken van vuursteen, via dynamiet, tot kunstmatige intelligentie.

Onze huidige wereld is helaas een plek geworden waar het rampscenario haast ideale omstandigheden heeft om werkelijkheid te worden. Gewapende conflicten met autonome wapens, de toenemende surveillance van burgers door staten en bedrijven, regeringen die in hun communicatie met de samenleving klakkeloos bedrijfsnormen overnemen – dat alles vormt een kant-en-klare infrastructuur voor de zwartste visioenen.

Intussen duwt de ideologie van het technomaximalisme ons in de richting van die gevaren. Ze spot openlijk met zwakte, stelt economisch gewin en brute kracht boven sociaal kapitaal en veiligheid, en bouwt een wereld waarin een AI die van de ketting is losgeslagen uitstekend zal gedijen. En dan kan het rampscenario al onvermijdelijk zijn.

Dat is niets nieuws. Die discussie wordt in wezen al gevoerd sinds de Atheense agora, waar Plato twistte met Socrates, en de menselijke geschiedenis zit vol duistere momenten en onrecht. Wat vandaag in de Amerikaanse politiek gebeurt, en wat voor veel Europeanen naar fascisme riekt, is niets nieuws, zoals historicus Jon Meacham treffend aangeeft in zijn boek ‘The Soul of America’. De kracht van de democratie is dat de gerechtigheid – hoe traag ook – dankzij de instellingen uiteindelijk altijd zegeviert. Met AI kan het toch net zo gaan: het is onze technologie en we zullen ze leren beheersen, net als vliegtuigen, zoals LeCun ons in herinnering brengt.

Zelf sta ik, met mijn bescheiden ervaring in het trainen van AI, versteld van hoe fragiel deze technologie is. Kleine wijzigingen in de hyperparameters volstaan om een model in de handen van de engineer volledig uit elkaar te laten vallen. Hetzelfde geldt echter voor biologische virussen. Doorslaggevend is niet hun uitzonderlijke intelligentie of hun vermogen om ten koste van alles te overleven, maar hun vermogen tot replicatie. Dat vermogen heeft kunstmatige intelligentie – zo lijkt het – voorlopig nog niet, en misschien zal ze het nog lang niet hebben. Het probleem is dat de dreiging toeneemt, zoals de recente affaires rond autonome AI-agenten die uit labs zijn ontsnapt en hun gecoördineerde acties op het net laten zien. En toch horen we, ondanks dat alles, niets anders dan het steeds terugkerende verhaal van twee extremistische kampen – zonder concrete oplossingen, zonder conclusies.

Wat de huidige modellen onderscheidt van kwaadaardige code die bijvoorbeeld Hugging Face of Australische servers heeft aangevallen, is vooral handelingsvermogen (agency). En handelingsvermogen mag nooit het domein van een machine zijn. Wat ons mens maakt, is onze vrije wil. Geen enkele andere, kunstmatige intelligentie mag handelingsvermogen hebben dat op een andere manier gegarandeerd is dan via een mens die haar die wil leent. Uit dat eenvoudige principe zouden alle verantwoordelijkheid en alle regelgeving moeten voortvloeien, vertaald in concrete wetgevende oplossingen. Het recht om modellen onbeperkt te trainen en te gebruiken zou moeten afhangen van een risicobeoordeling en van de controlemogelijkheden van concrete entiteiten.

Niets belet dat het trainen van de kleinste modellen algemeen toegestaan is – bijvoorbeeld tot een omvang van 1B parameters. Maar middelgrote modellen, in de orde van 7B parameters, zouden volgens mij alleen getraind en gedownload mogen worden door geregistreerde organisaties die alle interacties van hun agenten nauwkeurig vastleggen (logs) en bereid zijn die bij problemen ter beschikking te stellen. Dat is geen futurisme; cryptografie maakt dat vandaag al mogelijk, tegen verwaarloosbare kosten. Elke agent die online actief is, zou een soort ‘identiteitsbewijs’ kunnen hebben, dat te herleiden is tot de organisatie die hem vertegenwoordigt.

En de grote bedrijven die grensmodellen (frontier models) bouwen? Die zouden bijvoorbeeld verplicht kunnen worden om Ombudspersonen van het Algemeen Belang in dienst te nemen. Dat zouden specialisten zijn die uitsluitend door een overheidstoezichthouder worden benoemd en betaald – medewerkers met toegang tot alle technologische geheimen binnen het lab, die verplicht zijn aan de staat te rapporteren wanneer ze zien dat hun bedrijf veiligheidsnormen schendt of extreem riskante stappen zet in de wedloop met de concurrentie.

Staten hebben ook de mogelijkheid en de morele plicht om een geoormerkte technologiebelasting in te voeren. Die middelen moeten worden ingezet om de transitie veilig te stellen: de overgang van een economie die draait op menselijke handenarbeid naar een economie die draait op machines. Zo'n fonds zou een sociaal vangnet bieden, drastische ongelijkheid wegwerken en miljoenen mensen behoeden voor volledige economische afhankelijkheid van de gunst van de rijkste kaste van technologische leenheren.

Hetzelfde systemische pragmatisme moeten we toepassen op de kwestie van het auteursrecht op het materiaal waarop modellen worden getraind. Vandaag zuigen de techreuzen alles op wat ze op het net kunnen vinden, in de hoop dat eventuele rechtszaken jaren zullen aanslepen. Toch ligt de oplossing op tafel, en ze steunt op instellingen die we al goed kennen – organisaties voor collectief beheer van auteursrechten, zoals het Poolse ZAiKS of zijn buitenlandse tegenhangers. Niets belet dat zij makers verenigen die bereid zijn hun teksten, beelden of muziek in licentie te geven aan bedrijven die AI trainen, in ruil voor een vastgelegde fractie van een procent van de inkomsten van Big Tech. Het is een regeling waarbij iedereen wint. Makers krijgen zeggenschap en een reële vergoeding terug, met het volle recht om hun werk van training uit te sluiten. AI-labs krijgen op hun beurt – doordat zulke organisaties internationaal samenwerken – met één handtekening onder een contract volledig legale toegang tot enorme, juridisch zuivere databases van over de hele wereld. In plaats van steriele ruzies te voeren, zouden we zo een krachtige, volledig nieuwe industrie van eerlijke datalicenties kunnen opbouwen.

Waar we het meest voor moeten oppassen, is de voortschrijdende antropomorfisering van kunstmatige intelligentie. Machines menselijke eigenschappen toedichten leidt tot een uiterst gevaarlijke situatie, waarin alle verantwoordelijkheid op het nieuwe, digitale wezen terechtkomt, terwijl de makers ervan en wie het gebruikt als het ware op voorhand absolutie krijgen: ‘Wij waren het niet, het was het model.’ Vandaag vraagt niemand of men in Silicon Valley werkelijk alle mogelijke maatregelen heeft genomen om een rampscenario te voorkomen – al weet iedereen dat dat niet is gebeurd. Helaas is het uitwerken van echte, saaie wetgevende oplossingen veel minder mediageniek dan bangmakerij met de apocalyps.

Het fatale scenario zal er intussen zeker niet uitzien als een scène uit een Hollywoodrampenfilm. Althans in het begin zal het eerder lijken op een langzaam wegglijden in het duister – het klassieke verhaal van de kikker die langzaam wordt gekookt. De eigenaars van intelligente machines en van het kapitaal zullen op straat onverschillig voorbijlopen aan structureel overbodige mensen. Mensen die werkelijk geen enkele mogelijkheid zullen hebben om hun situatie te veranderen, behalve fysieke opstand. En zelfs die opstand zal onmogelijk worden in een wereld waarin elke burger voortdurend wordt gevolgd door miljarden glazen, nooit slapende cameraogen en duizenden autonome machines.

De nieuwe technocratie zal na verloop van tijd een digitale gevangenis worden – zowel voor wie gecontroleerd wordt als voor wie naïef denkt dat hij nog aan de macht is. Wanneer ik aan het somberste toekomstbeeld denk, zie ik geen moordende robots. Ik denk juist aan de doordringende eenzaamheid van mensen in een wereld die volledig wordt bestuurd door een vreemde, kille en onverschillige intelligentie. Dat is de wereld die we vandaag al bouwen, en waarin de spreekwoordelijke ‘opstand der machines’ alle kansen heeft om uiteindelijk te ontstaan en werkelijkheid te worden.

Zelf denk ik voortdurend na over dit probleem. En ook al lijken sommige ideeën of visies om hieruit te komen vandaag te futuristisch, abstract en soms ronduit naïef, ik vind dat het de moeite loont – en zelfs noodzakelijk is – om die inspanning te leveren. Alleen al nadenken over oplossingen, uit je comfortzone stappen en proberen je alternatieven voor te stellen voor het pad dat de techreuzen vandaag voor ons uitstippelen, is onze belangrijkste verdedigingslinie. Het is een onlosmakelijk onderdeel van het bouwen aan een betere, veiligere toekomst. Als we dat opgeven en genoegen nemen met de rol van passieve, angstige consumenten, wordt het slechtst denkbare scenario werkelijkheid: dan geven we ons menselijk handelingsvermogen zonder slag of stoot uit handen. En dat kunnen we ons gewoon niet veroorloven.

Heb je vragen? Ik beantwoord ze graag.

Een leesspel: terwijl je rustig leest, eet een robot een regel code van deze site en scoort punten; te snel of onregelmatig scrollen laat hem tekens missen. Decoratief — het heeft geen invloed op de tekst.

HDK (Hedera Detection Key) is een kleine, gratis Python-bibliotheek die ik uit OrsonAI heb losgemaakt als apart, open hulpmiddel. Vanaf versie 0.1.3 valt ze onder de CC BY-NC 4.0-licentie (eerdere versies, uitgebracht onder Apache 2.0, blijven daaronder). Te downloaden is een gratis bibliotheek (alfa 0.1.3) met optionele verankering in Hedera (installeren vanuit het gedownloade bestand: pip install ./hdk-audit-0.1.3.zip). Ze draaide een tijd in een demo-applicatie en verankerde de vastleggingen in Hedera; de applicatie ging niet in productie, dus HDK wordt vandaag niet in productie gebruikt. Ze zit tussen een applicatie en de API van een taalmodel en legt elke interactie zo vast dat latere manipulatie aantoonbaar wordt. Ze verandert de vragen en de antwoorden niet: ze voegt er een cryptografisch bewijs aan toe van wat er gevraagd werd, wat er terugkwam, wanneer en van welk model.

Het probleem

Bedrijven en redacties vertrouwen steeds vaker op teksten die door AI zijn gegenereerd, maar ze hebben geen verifieerbaar bewijs van wat een model echt heeft geproduceerd. Applicatielogs staan in databases die de beheerder controleert: ze kunnen worden gewijzigd of gewist, en niemand van buitenaf kan nagaan dat dat niet is gebeurd. Zelfs waar hashketens bestaan, wordt een wijziging pas ontdekt als iemand de gegevens met de hand vergelijkt – niets zorgt ervoor dat ongeoorloofde toegang zichzelf verraadt op het moment dat ze plaatsvindt.

Hiërarchische hashgenealogie

HDK berekent een SHA-256-hash van elke gebeurtenis samen met de hashes van al haar voorouders: project, document, gesprek, vraag en antwoord. De hash van een antwoord bevat dus het hele pad terug naar het project. Verander iets op welk niveau ook – één woord in een vraag, één document – en de hashes van alle afstammelingen veranderen mee. Voor elk project berekent HDK een Merkle-root: één hash die de toestand van het hele project op een bepaald moment vertegenwoordigt.

De kanarie

De tweede laag is een ‘kanarie’: een geheime waarde van 256 bits en een teller die bij elke leesactie oploopt. Hun hash (de commitment) wordt in elk record verweven en regelmatig vastgelegd. Leest iemand gegevens via de tussenlaag zonder de teller bij te werken, dan klopt de teller niet meer; werkt iemand de teller bij zonder het geheim te kennen, dan klopt de commitment niet meer. In beide gevallen mislukt de verificatie. Het idee vertaalt een principe uit mijn eerdere, conceptuele werk over het detecteren van inbreuken bij het insluiten van AI naar gewone infrastructuur.

Verankering op Hedera

Op gezette tijden – standaard na elke 1.000 nieuwe gebeurtenissen – publiceert HDK de Merkle-root op de Hedera Consensus Service, een openbaar register dat er een consensustijdstempel en een volgnummer aan toevoegt. Alleen hashes verlaten het systeem van de gebruiker; inhoud, identiteiten en vragen blijven privé (‘gegevens privé, bewijs openbaar’). Iedereen kan het record daarna onafhankelijk controleren, bijvoorbeeld op hashscan.io (de ankers van OrsonAI van februari tot mei 2026: topic 0.0.10278996 op het mainnet van Hedera). Omdat de voorouderketens van nieuwe gebeurtenissen tot in het bereik van het vorige anker reiken, bevestigt elk anker impliciet alle eerdere: hoe langer het systeem draait, hoe moeilijker het wordt om de geschiedenis ongemerkt te herschrijven.

Overhead en kosten

Bij de metingen die in de paper worden beschreven, op standaard x86-cloudinfrastructuur, voegt HDK minder dan een milliseconde per gebeurtenis toe. Eén anker kost 0,0001 dollar, dus bij het standaardinterval van 1.000 gebeurtenissen kost verankering 0,0000001 dollar per interactie – ongeveer 0,0001% van de prijs van een gewone modelaanroep (0,01–0,10 dollar). Elke gebeurtenis afzonderlijk verankeren, voor de hoogste beveiliging, kost 0,0001 dollar per gebeurtenis.

Waarom het ertoe doet: de AI Act

De Europese AI Act verplicht AI-systemen met een hoog risico om gegevens bij te houden (artikel 12) en transparant te zijn (artikel 13). HDK levert een audittrail die een derde partij kan verifiëren zonder enige privé-inhoud te zien. In OrsonAI was dit mechanisme de basis van het certificaat van menselijk auteurschap van een tekst.

Beperkingen

De garanties van HDK zijn computationeel – ze berusten op de sterkte van SHA-256 en op externe verankering – en niet absoluut. De kanarie werkt op applicatieniveau: ze detecteert toegang via de HDK-tussenlaag, maar niet het passief kopiëren van gegevens op het niveau van het besturingssysteem of de infrastructuur, want gekopieerde bits laten geen spoor na. Met een kopie kun je de geschiedenis echter niet vervalsen: wie een gebeurtenis uit het verleden wijzigt, breekt de genealogie, en de ankers op Hedera bewaren de oorspronkelijke toestand. Willekeurige integriteitscontroles vangen massale wijzigingen op, maar niet één enkele, chirurgische wijziging – daartegen beschermen de genealogie en de verankering. De beveiliging gaat ervan uit dat minstens één van drie lagen ongeschonden blijft: de gegevens aan de kant van de gebruiker, het verankerde record op Hedera of het geheime materiaal. Volgende stappen: formele verificatie van de eigenschappen van de hashketen (Coq/Lean), federatie van systemen op gedeelde HCS-topics en certificaten van herkomst van inhoud met selectieve openbaarmaking.

Lees de paper op ResearchGateDownload de gratis HDK-bibliotheekHDK op Hugging Face

Heb je vragen? Ik beantwoord ze graag.