Waarom temperatuur 0 geen bewijs is van reproduceerbare

Temperatuur 0 vermindert variatie in AI-gegenereerde code, maar garandeert geen reproduceerbaarheid. U moet de volledige pipeline vastleggen, herhaald testen en expliciet rapporteren welke variatie overblijft — want infrastructuur en modelupdates kunnen uitkomsten veranderen zonder dat u dat merkt.

De aanleiding is een analyse van 2 november 2026 van temperatuurcontrole in AI-evaluaties, die aantoont dat temperatuur 0 (de instelling waarbij een taalmodel steeds het meest waarschijnlijke vervolgwoord kiest) variatie niet elimineert. Een onderzoek naar gegenereerde Python-, Java- en C++-code laat zien dat GPU-uitvoering, modelversies en samplingparameters allemaal invloed hebben op de uiteindelijke output, zelfs wanneer temperatuur op nul staat. In onze inschatting betekent dit dat u temperatuur 0 niet kunt gebruiken als bewijs dat een AI-systeem deterministisch werkt. Reproduceerbaarheid is een eigenschap van de hele vastgezette keten, niet van één instelling.

Waarom temperatuur 0 geen garantie biedt

Veel teams behandelen temperatuur 0 als bewijs dat een model "deterministisch" werkt en dus reproduceerbare output geeft. Onderzoek toont aan dat die aanname niet houdbaar is. Temperatuur 0 verlaagt de ruis, maar laat grensgevallen en afwijkende beoordelingsuitkomsten bestaan. Bovendien stellen onderzoekers vast dat sommige nieuwere modellen samplingparameters niet meer volledig ondersteunen, waardoor de instelling die u denkt te sturen, in de praktijk kan zijn uitgefaseerd.

Identieke evaluaties kunnen variëren onder niet-ingestelde samplingparameters. Temperatuur 0 vermindert die variatie, maar elimineert haar niet. Resterende verschillen treden zelfs op bij top_k=1 — een instelling die de keuze beperkt tot het hoogst gerangschikte kandidaatwoord. Onderzoek op token-niveau wijst erop dat GPU-uitvoering en kleine numerieke verschillen tokenprobabiliteiten kunnen laten variëren, vooral bij middenwaarschijnlijke tokens. Dit ondersteunt de conclusie dat temperatuur 0 geen bewijs van bit-identieke uitvoering is.

Welke risico's ontstaan bij bredere sampling

Een hogere temperatuur vergroot de variatie in de output. Dat helpt bij het vinden van functioneel werkende oplossingen, maar brengt ook meer onveilige varianten naar boven. Onderzoek naar gegenereerde code in meerdere talen vond dat temperatuur en het aantal samples de kans op correcte code kunnen verhogen, maar de security@k (de kans dat een gegenereerde oplossing binnen k pogingen veilig is) in veel geteste configuraties juist daalt naarmate temperatuur en k stijgen.

Dit is een concrete afweging, geen detail. Wie breder laat samplen om "een werkende oplossing" te krijgen, vergroot tegelijk de kans dat er een kwetsbare variant tussen zit. Functionele acceptatietests alleen zijn onvoldoende: een stuk code dat de tests haalt, kan nog steeds een beveiligingslek bevatten dat pas bij statische analyse of review zichtbaar wordt.

• Variatie door hardware — GPU-uitvoering en numerieke verschillen veranderen tokenprobabiliteiten onafhankelijk van temperatuur.
• Modelversie-afhankelijkheid — een update van de leverancier kan samplingparameters stilzwijgend uitfaseren.
• Onveilige varianten in brede sampling — meer samples verhoogt de kans op kwetsbare code, niet alleen op werkende code.
• Infrastructuur-niet-determinisme — variatie treedt ook op zonder sampling, door de inferentie-omgeving zelf.
• Verborgen ruis in enkele runs — één enkele pass/fail-run van een AI-beoordelaar kan variatie maskeren.

Wat moet u vastleggen en testen

Reproduceerbaarheid moet als eigenschap van de hele vastgezette pipeline worden behandeld, niet van het model. Een werkbare aanpak beschrijft reproduceerbaarheid als eigenschap van een gepinde keten en meet zowel byte-identieke output als overeenstemming met een gevalideerde referentie-implementatie. De kern: pin wat u kunt pinnen, en meet en rapporteer wat u niet kunt pinnen.

1. Documenteer de volledige configuratie — vastleggen welk model, welke versie, welke samplingparameters, welke hardware en welke inferentie-omgeving elke AI-codebijdrage heeft gegenereerd.
2. Voer herhaalde runs uit en rapporteer spreiding — draai dezelfde prompt minstens tweemaal en documenteer waar de outputs verschillen.
3. Zet statische beveiligingsscan als blokkerende stap in — functionele tests vangen kwetsbare code niet; statische analyse moet een verplichte controle zijn voordat code in productie gaat.
4. Bewaar effectieve output en gerapporteerde variatie per oplevering — zodat een beslissing achteraf te reconstrueren is en u kunt aantonen welke controles hebben plaatsgevonden.
5. Neem een meldplicht voor model- en parameterwijzigingen in het leverancierscontract op — gekoppeld aan een herbeoordelingstermijn, zodat u weet wanneer het gedrag van bestaande workflows kan veranderen.

Welk onderscheid maakt praktisch verschil

Deterministische berekening (dezelfde bits), een reproduceerbare pipeline (dezelfde gevalideerde uitkomst via een vaste keten) en semantisch equivalente code (functioneel gelijk, maar anders geschreven) zijn drie verschillende dingen. Welke u nodig hebt, hangt af van het gebruik. Voor code die in kritieke systemen draait, hebt u waarschijnlijk reproduceerbare pipelines en statische bewijzen van veiligheid nodig. Voor prototyping kan semantische equivalentie volstaan. Temperatuur 0 garandeert geen van deze drie.

Hoe tooling en menselijk oordeel samengaan

Automatische tests en statische analyse kunnen veel variatie opvangen en veel kwetsbare patronen flaggen. Maar geen tool kan voor u bepalen welke residuele variatie acceptabel is in uw context, welke beveiligingsrisico's u kunt dragen, of wanneer een modelupdate uw workflows opnieuw moet worden gevalideerd. Die keuzes blijven uw professionele verantwoordelijkheid. Tooling kan u helpen die keuzes reproduceerbaar te documenteren en te verdedigen; het kan ze niet voor u nemen.