Waarom temperatuur 0 geen bewijs is van reproduceerbare AI-codegeneratie

Nee. Temperatuur 0 vermindert de variatie in door AI gegenereerde code, maar elimineert die niet: ook bij greedy decoding blijft variatie bestaan door inferentiehardware en providerwijzigingen. Reproduceerbaarheid is een eigenschap van de hele vastgezette pipeline, niet van één samplinginstelling, en vraagt om herhaalde runs, tests, statische analyse en expliciete rapportage van variatie.

Veel teams behandelen temperatuur 0 (de instelling waarbij een taalmodel steeds het meest waarschijnlijke vervolgwoord kiest) als bewijs dat een model "deterministisch" werkt en dus reproduceerbare output geeft. Een studie van 24 oktober 2026 over temperatuurcontrole in zogenoemde LLM-as-judge safety-evaluaties, gepubliceerd op arXiv, laat zien dat die aanname niet houdbaar is. Temperatuur 0 verlaagt de ruis, maar laat grensgevallen en afwijkende beoordelingsuitkomsten bestaan. De onderzoekers stellen bovendien vast dat sommige nieuwere modellen samplingparameters niet meer volledig ondersteunen, waardoor de instelling die je denkt te sturen, in de praktijk kan zijn uitgefaseerd.

Voor iedereen die AI inzet om code te laten schrijven of te laten beoordelen, is dat een praktisch signaal. Reproduceerbaarheid betekent niet "één knop op nul zetten", maar de volledige keten vastleggen en herhaald meten. Hieronder wat het onderzoek vaststelt en wat dat concreet van beslissers vraagt.

Wat toont het onderzoek over temperatuur 0 en reproduceerbaarheid precies aan?

De arXiv-studie rapporteert dat identieke evaluaties onder niet-ingestelde samplingparameters kunnen variëren, dat temperatuur 0 de variatie vermindert maar niet wegneemt, en dat resterende verschillen zelfs optreden bij top_k=1 (een instelling die de keuze beperkt tot het hoogst gerangschikte kandidaatwoord). Eén enkele pass/fail-run van een AI-beoordelaar kan die ruis verbergen. De onderzoekers bevelen daarom aan temperatuur, seed, modelidentiteit, herhaalde runs en meningsverschillen tussen beoordelaars vast te leggen.

Een als IEEE-preprint verspreid onderzoek analyseert daarnaast niet-determinisme op token-niveau. De resultaten wijzen erop dat GPU-uitvoering en kleine numerieke verschillen tokenprobabiliteiten kunnen laten variëren, vooral bij middenwaarschijnlijke tokens. Dat ondersteunt de bredere conclusie dat temperatuur 0 geen bewijs van bit-identieke uitvoering is; daarvoor moet ook de inferentie-infrastructuur zelf worden vastgelegd en getest. Kortom: temperatuur 0 is geen garantie voor bit-identieke uitvoering.

Waarom levert een hogere temperatuur bij codegeneratie ook meer kwetsbare code op?

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. De peer-reviewed studie Multi-SALLM, verschenen op 26 augustus 2026, onderzocht gegenereerde Python-, Java- en C++-code en 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.

Dat 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. Naar onze inschatting betekent dit dat functionele acceptatietests alléén onvoldoende zijn: een stuk code dat de tests haalt, kan nog steeds een beveiligingslek bevatten dat pas bij statische analyse of review zichtbaar wordt.

Hoe meet en rapporteer je reproduceerbaarheid van AI-code als de infrastructuur de variatie veroorzaakt?

Door reproduceerbaarheid te behandelen als eigenschap van de hele vastgezette pipeline, niet van het model. De aanpak in Skyt 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 je kunt pinnen, en meet en rapporteer wat je niet kunt pinnen.

Een werkbare volgorde, mede op basis van deze drie studies en onze eigen inschatting:

• Leg de keten vast. Promptcontract, modelidentiteit en versie, API-configuratie, seed waar ondersteund, uitvoeringsomgeving en afhankelijkheden.
• Definieer vooraf wat reproduceerbaar moet zijn. Byte-identiek, schema-conform, test-equivalent of security-conform. Dit zijn verschillende eisen met verschillende meetmethoden.
• Voer meerdere runs uit. Eén geslaagde run bewijst niets; herhaling maakt de spreiding zichtbaar.
• Valideer de output. Functionele tests én statische beveiligingsanalyse, omdat werkende code niet automatisch veilige code is.
• Bewaar ruwe output en effectieve configuratie en rapporteer de variatie expliciet: spreiding, mislukte validaties en afwijkende uitkomsten, in plaats van alleen een geslaagd eindresultaat.

Het belangrijke onderscheid dat zelden expliciet wordt gemaakt: 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 je nodig hebt, hangt af van het gebruik.

Wat betekent dit voor bestuurders, juristen en CISO's die AI-codegeneratie toestaan?

Onze analyse: omdat temperatuur 0 de variatie niet wegneemt, geeft een leveranciersverklaring dat een model "deterministisch" draait geen controleerbare zekerheid; daarom moet een CISO in het acceptatiebeleid vastleggen dat elke AI-codebijdrage herhaald wordt gedraaid en met tests én statische analyse wordt gevalideerd voordat ze in een productierepository terechtkomt. Omdat Multi-SALLM aantoont dat bredere sampling meer kwetsbare varianten oplevert, raken ontwikkelteams blootgesteld aan securityschuld die functionele tests niet vangen; daarom hoort een statische beveiligingsscan als blokkerende stap in de pijplijn, niet als optioneel naslagwerk achteraf. Omdat nieuwere modellen samplingparameters kunnen uitfaseren, kan een modelupdate stilzwijgend het gedrag van bestaande workflows veranderen; daarom moet een jurist in het leverancierscontract een meldplicht voor model- en parameterwijzigingen opnemen, gekoppeld aan een herbeoordelingstermijn. En omdat infrastructuur-niet-determinisme betekent dat variatie ook zonder sampling optreedt, is "het model deed het de vorige keer goed" geen verdedigbaar bewijs; daarom moet een bestuurder eisen dat de effectieve configuratie, de ruwe output en de gerapporteerde spreiding per oplevering worden bewaard, zodat een beslissing achteraf te reconstrueren is. Verdere houvast staat in het themahub over AI-verificatie en controleerbaarheid.

Wie deze logica doortrekt, ziet dezelfde valkuil als elders in AI-governance: een enkele geslaagde uitkomst wordt als bewijs gebruikt waar herhaalde, gedocumenteerde controle nodig is. Datzelfde patroon beschreven we eerder bij de vraag waarom unanieme AI-modellen geen onafhankelijke feitencontrole bewijzen en bij de uitleg waarom één betrouwbaarheidsscore tekortschiet bij AI-output. Voor het vastleggen van wat je bewaart, bieden deze concrete voorbeelden van controlebewijs en hoe je ze documenteert praktische houvast.

Bronnen: Het artikel steunt op peer-reviewed en preprint-onderzoek gepubliceerd via arXiv, Springer (Multi-SALLM), ACM (Skyt) en IEEE Computer Society.