Waarom je tensor-vormfouten zich onzichtbaar verstoppen (en hoe betere notatie ze voorkomt)
Waarom tensor-vormen stiekem voor problemen zorgen
Je training loopt. De loss daalt. De scores zien er prima uit. Drie weken later in productie blijkt de output toch structureel verkeerd. En niemand weet waarom.
Vaak zit de fout niet in de code zelf, maar in een as die iets anders betekent dan je in gedachten had. Het is geen crash. Het is een stille fout die elke voorspelling beïnvloedt.
Het notatieprobleem
Wat je niet benoemt, kun je niet controleren.
De meeste tensor-frameworks kijken alleen naar de vorm. Een shape zoals (32, 768, 12, 64) kan van alles betekenen: batch, sequentie, heads of features. De compiler ziet alleen getallen. Zolang de vermenigvuldiging klopt, is de operatie geldig. De betekenis verdwijnt in de gewichten.
Dat is precies waar het misgaat. Niet door rekenfouten, maar door onduidelijke intentie.
Wat betere notatie oplevert
Stel je voor dat elke tensor zijn betekenis meedraagt via het type-systeem. Niet alleen de vorm, maar expliciet benoemde dimensies.
In plaats van achteraf te zoeken welke as wat doet, declareer je dat direct:
tensor: [batch=32, sequence=128, heads=12, dim_per_head=64]
Daarna kun je controleren of je alleen broadcast langs de juiste assen doet, of je reducties de juiste dimensies raken, en dat heads en features gescheiden blijven.
Het systeem wordt dan een extra controlelaag. Het vangt verwisselingen op voordat je drie weken traint.
De echte kosten van verborgen bugs
Deze fouten kosten meer dan je denkt.
In onderzoek lopen experimenten vast omdat je niet weet waarom de cijfers niet repliceren. In productie mislukt een model subtiel: je precisie zit net onder de verwachting. In teams ontstaan verschillen omdat iedereen zijn eigen conventie volgt. Bij code-integratie ontstaat een mismatch die niemand meer terugvindt.
Hoe benoemen alles verandert
Als je dimensies expliciet benoemt, kun je opeens veel meer controleren.
Je code kan zelf checken of broadcast alleen gebeurt langs geldige assen. Gradients kunnen reduceren langs de juiste dimensies. En als je een laag combineert met attention, blijven de betekenissen consistent door de hele stack heen. Refactoring wordt ook veiliger, omdat het systeem weet wanneer je de semantiek verandert.
Wat dit betekent voor infrastructure-builders
Wie infrastructuur bouwt — zoals tensor-DSLs, libraries voor autodiff, compiler-passes of team-wide notations — moet hier rekening mee houden. De keuze van notatie bepaalt welke bugs blijven zitten.
De vraag is niet alleen of je dimensies benoemt. Het gaat om wat je je kunt veroorloven om niet te checken.
De weg vooruit
Je hoeft geen nieuwe taal te leren om te beginnen. Volg deze stappen:
- Benoem elke dimensie bij het aanmaken van een tensor — via een comment of docstring
- Voeg asserties toe die checken dat as-betekenissen correct blijven bij compositie
- Gebruik type-annotaties voor shapes als je taal dat ondersteunt
- Stel team-brede standaarden op en controleer ze tijdens code-review
Sommige teams gaan verder en ontwikkelen DSLs waarin benoemde dimensies native zijn. Het systeem vangt mismatches op voordat je code loopt.
De kern
Stille bugs ontstaan doordat de betekenis van code niet duidelijk is.
Close de gap tussen wat code zegt en wat code betekent. Benoem je dimensies. Maak je intentie machine-readable.
Je toekomstige zelf van 3 uur ’s nachts zal je dankbaar zijn.