Ik zit al een tijdje te puzzelen op een vraag die al eindeloos besproken is maar nooit echt goed beantwoord: als we zeggen dat een model "dommer is geworden" of "weer generfd is", hoeveel daarvan is echt en hoeveel is puur een illusie door één enkele sample?
De laatste tijd zie ik veel mensen om me heen modellen de pelikaantest laten doen (een SVG van een pelikaan op een fiets). Die test is echt pittig: het gaat niet alleen om code schrijven, maar vooral om ruimtelijke verhoudingen – snavel en stuur, poten en pedalen, frame en wielen. Is het ruimtelijk inzicht van het model ook maar een beetje zwakker, dan krijg je een behoorlijk abstract plaatje.
Maar nadat ik hem een paar dozijn keer heb gedraaid, merkte ik dat de grootste valkuil van de pelikaantest is: oordelen op basis van één enkele output.
Een LLM is in de kern een probabilistische sampler met een flinke dosis willekeur. Met dezelfde prompt kan het model de ene keer een perfect ruimtelijk inzicht hebben – frame, cranks, voetpositie, alles klopt – en als je hem op een ander moment opnieuw draait, krijg je ineens postmoderne abstracte kunst. Als aanbieder A in 16 van de 20 runs een grotendeels logische houding oplevert en aanbieder B maar in 8 van de 20, dán is het verschil statistisch betekenisvol. Op basis van één willekeurige screenshot roepen dat "A de volledige versie is en B aangelengd" is eigenlijk gewoon een muntje opgooien.
Wil je echt iets vergelijken, dan heb je een gezamenlijke Baseline nodig: leg de modelversie, het reasoning-niveau, de prompt en het tijdvenster vast, zet eerst een referentiepunt neer en kijk daarna alleen nog naar relatieve verschillen.
Maar dat brengt een paar behoorlijk lastige technische details met zich mee:
1. Hoe beoordeel je die pelikaan? Puur handmatig beoordelen schaalt niet; een LLM-as-a-judge in z'n eentje is sterk geneigd zichzelf op de borst te kloppen. Voorlopig lijkt het erop dat je het moet opsplitsen in vier dimensies – Pelican (volledigheid), Bicycle (geometrische juistheid), Riding (hoe vogel en fiets ruimtelijk op elkaar aansluiten) en Animation (beweging en clipping) – en dat kruiselings moet controleren met een visuele judge plus statische regels op de SVG-DOM.
2. De levensduur van testvragen. Zodra een "killer-vraag" rondgaat, belandt die vroeg of laat in de trainingsdata of wordt er gericht op gefinetuned. Op de lange termijn kun je niet blind varen op één vraag; je hebt een dynamische pool van probes nodig die ruimtelijke relaties, instruction following en structureel redeneren afdekt.
Ik heb deze tests een tijd handmatig gedraaid om modellen te checken, en het grootste pijnpunt was de administratie: steeds opnieuw draaien, SVG's opslaan, parameters noteren, timestamps uitlijnen… na een paar dozijn sets ben je er helemaal klaar mee. Wat echt tijd kost is vaak niet de test zelf, maar al het kleine bijhouden en ordenen eromheen.
*knip. E.e.a. kan ook zonder reclame te maken
De laatste tijd zie ik veel mensen om me heen modellen de pelikaantest laten doen (een SVG van een pelikaan op een fiets). Die test is echt pittig: het gaat niet alleen om code schrijven, maar vooral om ruimtelijke verhoudingen – snavel en stuur, poten en pedalen, frame en wielen. Is het ruimtelijk inzicht van het model ook maar een beetje zwakker, dan krijg je een behoorlijk abstract plaatje.
Maar nadat ik hem een paar dozijn keer heb gedraaid, merkte ik dat de grootste valkuil van de pelikaantest is: oordelen op basis van één enkele output.
Een LLM is in de kern een probabilistische sampler met een flinke dosis willekeur. Met dezelfde prompt kan het model de ene keer een perfect ruimtelijk inzicht hebben – frame, cranks, voetpositie, alles klopt – en als je hem op een ander moment opnieuw draait, krijg je ineens postmoderne abstracte kunst. Als aanbieder A in 16 van de 20 runs een grotendeels logische houding oplevert en aanbieder B maar in 8 van de 20, dán is het verschil statistisch betekenisvol. Op basis van één willekeurige screenshot roepen dat "A de volledige versie is en B aangelengd" is eigenlijk gewoon een muntje opgooien.
Wil je echt iets vergelijken, dan heb je een gezamenlijke Baseline nodig: leg de modelversie, het reasoning-niveau, de prompt en het tijdvenster vast, zet eerst een referentiepunt neer en kijk daarna alleen nog naar relatieve verschillen.
Maar dat brengt een paar behoorlijk lastige technische details met zich mee:
1. Hoe beoordeel je die pelikaan? Puur handmatig beoordelen schaalt niet; een LLM-as-a-judge in z'n eentje is sterk geneigd zichzelf op de borst te kloppen. Voorlopig lijkt het erop dat je het moet opsplitsen in vier dimensies – Pelican (volledigheid), Bicycle (geometrische juistheid), Riding (hoe vogel en fiets ruimtelijk op elkaar aansluiten) en Animation (beweging en clipping) – en dat kruiselings moet controleren met een visuele judge plus statische regels op de SVG-DOM.
2. De levensduur van testvragen. Zodra een "killer-vraag" rondgaat, belandt die vroeg of laat in de trainingsdata of wordt er gericht op gefinetuned. Op de lange termijn kun je niet blind varen op één vraag; je hebt een dynamische pool van probes nodig die ruimtelijke relaties, instruction following en structureel redeneren afdekt.
Ik heb deze tests een tijd handmatig gedraaid om modellen te checken, en het grootste pijnpunt was de administratie: steeds opnieuw draaien, SVG's opslaan, parameters noteren, timestamps uitlijnen… na een paar dozijn sets ben je er helemaal klaar mee. Wat echt tijd kost is vaak niet de test zelf, maar al het kleine bijhouden en ordenen eromheen.
*knip. E.e.a. kan ook zonder reclame te maken
[ Voor 7% gewijzigd door F_J_K op 05-10-2026 21:02 ]
/u/28468/librarian2.png?f=community)
/u/243496/appel-forum.png?f=community)
/u/164119/crop5a5a2a556d2af_cropped.png?f=community)