← Nieuwste papers
🤖 machine learning

Training-Inference Kernel Contracts: Bounding Divergence in Post-Training and Deployment

Dit artikel stelt een "kernel contracts"-framework voor om de distributionele divergentie tussen trainings- en inferentiekernels in post-training-pipelines formeel te specificeren en te begrenzen, waarbij theoretische grenzen op policy-gradient bias worden afgeleid en een gestructureerde deployment-pipeline wordt geschetst, terwijl wordt opgemerkt dat het een conceptueel framework presenteert zonder empirische validatie op productieschaal.

Oorspronkelijke auteurs: Bruce Changlong Xu, Lan Wu

Gepubliceerd 2026-06-09
📖 6 min leestijd🧠 Diepgaand

Oorspronkelijke auteurs: Bruce Changlong Xu, Lan Wu

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een briljante chef hebt (het AI-model) die jarenlang heeft geleerd koken in een hoogwaardige, perfect gekalibreerde testkeuken. In deze keuken gebruiken ze uiterst nauwkeurige digitale weegschalen, verse ingrediënten en een traag, zorgvuldig kookproces om ervoor te zorgen dat elk gerecht perfect is. Dit is de Trainingskeuken.

Stel je nu voor dat je de recepten van deze chef wilt serveren aan duizenden hongerige klanten bij een drukke foodtruck. Om aan de vraag te voldoen, schakel je over naar een andere opstelling: je gebruikt vooraf verpakte kruidenzakjes, een snellere (maar iets minder nauwkeurige) grill en een systeem waarbij bestellingen samen worden gebundeld om tijd te besparen. Dit is de Inference-keuken (de uitvoeringskeuken).

Het probleem is volgens dit artikel dat, hoewel de chef dezelfde persoon is die hetzelfde geheime recept gebruikt (de modelgewichten), het eten dat uit de foodtruck komt niet exact hetzelfde is als uit de testkeuken. Het verschil is minuscuul — misschien een snufje zout hier of een iets andere aanbrading daar — maar over duizenden bestellingen kan dit kleine verschil zich opstapelen. Soms komt een gerecht dat bedoeld was als "pittig" er "mild" uit, of een veiligheidscontrole die in de keuken wel werkte, faalt op de foodtruck.

Het artikel noemt deze kloof de "Training-Inference Kernel Contract." Hier is een eenvoudige uiteenzetting van hun oplossing:

1. Het Probleem: "Twee Verschillende Chefs"

Momenteel, wanneer we AI bouwen, gaan we ervan uit dat de "Trainingschef" en de "Inference-chef" precies hetzelfde doen. Maar in werkelijkheid gebruiken ze verschillende instrumenten en methoden.

  • Training gebruikt hoogwaardige wiskunde (zoals een digitale weegschaal).
  • Inference gebruikt snelle, minder nauwkeurige wiskunde (zoals een visuele schatting) om sneller te gaan en geld te besparen.

Omdat ze verschillende instrumenten gebruiken, maken ze soms ook andere beslissingen. In een normaal restaurant betekent dit misschien alleen dat een soep net iets anders proeft. Maar voor AI kan dit betekenen:

  • De "Reward Hack": In Reinforcement Learning (waarbij de AI leert door vallen en opstaan) kan de AI denken dat hij een geweldig werk doet omdat de "snelle" keuken hem een goede score gaf, terwijl de "precieze" keuken hem een slechte score zou hebben gegeven. Het is alsof een student een A haalt op een oefentoets, maar faalt op het echte examen omdat het beoordelingsmodel is veranderd.
  • De "Safety Slip": Een prompt waar het model in de testkeuken weigert op te antwoorden, krijgt in de foodtruck misschien per ongeluk toch een antwoord omdat de snelle grill de smaak net genoeg veranderde om de veiligheidsfilter te omzeilen.

2. De Oplossing: Het "Kernel Contract"

De auteurs stellen een nieuw regelboek voor genaamd een Kernel Contract. Zie dit niet als een juridisch document voor advocaten, maar als een Kwaliteitscontrole-checklist die met de AI meereist.

Dit contract zegt: "We weten dat de snelle keuken (Inference) niet 100% identiek zal zijn aan de testkeuken (Training). Dat is oké. Maar dit zijn de specifieke regels die we NIET zullen breken."

Het contract heeft vier secties:

  • Numerieke Regels (N): "De wiskunde mag niet meer dan X afwijken." (bijv. Het pittigheidsniveau mag niet meer dan 10% veranderen).
  • Statistische Regels (S): "De uiteindelijke smaak moet consistent zijn." (bijv. 99% van de tijd moet het gerecht nog steeds als 'Pittig' worden herkend).
  • Runtime Regels (R): "Het moet nog steeds snel genoeg zijn." (bijv. De foodtruck mag niet vertragen alleen maar omdat we een veiligheidscontrole hebben toegevoegd).
  • Observability Regels (O): "We moeten elke specifieke bestelling later kunnen proeven." (Als een klant klaagt, moeten we die exacte bestelling in beide keukens opnieuw kunnen afspelen om te zien wat er misging).

3. Het "Escalatiebeleid" (Wat gebeurt er als de regels worden overtreden?)

Het contract is niet alleen een lijst; het heeft een verkeerslichtsysteem:

  • Groen (L1): "Let op." We hebben een klein verschil geregistreerd. Ga door met koken.
  • Geel (L2): "Waarschuwing." Het verschil wordt te groot. We stoppen met het sturen van nieuwe bestellingen naar deze keuken en sturen ze naar een back-up keuken totdat we het hebben opgelost.
  • Rood (L3): "Noodgeval." Er is iets kritiek mis. We schakelen deze keuken onmiddellijk uit en stappen over op een bekende, goede versie.

4. De "Vierfasen Promotie" (Hoe te testen voordat men het serveert)

Je zet niet zomaar een schakelaar om en stuurt de nieuwe keuken naar het publiek. Het artikel suggereert een veilige tunnel van vier stappen:

  1. Offline CI: Draai de checklist op een vaste set testbestellingen in het lab. Als het faalt, verlaat je het lab niet eens.
  2. Shadow (Schaduw): Laat de nieuwe keuken koken, maar serveer het eten van de oude keuken aan de klanten. We kijken alleen maar om te zien of de nieuwe keuken fouten zou hebben gemaakt.
    {% end %}
  3. Canary (Kanarie): Laat de nieuwe keuken een kleine groep echte klanten bedienen (zoals 1%). Als zij klagen, stoppen we onmiddellijk.
  4. Full (Volledig): Als iedereen tevreden is, laten we de nieuwe keuken voor iedereen koken.

5. Waarom dit belangrijk is voor "lerende" AI (RL)

Het artikel maakt een specifiek punt over AI die zichzelf leert (Reinforcement Learning).

  • Het Probleen: Wanneer de AI leert, maakt hij een "snapshot" van de wereld met de snelle keuken, maar probeert vervolgens te leren van de precieze keuken. Het is alsof je probeert te leren autorijden door een video van een racewagen te kijken, maar dan een ander type auto bestuurt. De AI raakt in de war en leert de verkeerde lessen.
  • De Oplossing: Het contract dwingt de AI om toe te geven: "Hé, mijn snelle keuken en mijn precieze keuken zijn verschillend." Het voegt een "correctiefactor" toe aan het leerproces zodat de AI niet wordt misleid door de snelheid van de foodtruck.

Samenvatting

Het artikel betoogt dat we moeten stoppen met de pretentie dat de "Trainings-AI" en de "Serving-AI" hetzelfde zijn. In plaats daarvan moeten we ze behandelen als twee verschillende partners die een Contract hebben getekend. Dit contract stelt expliciet vast hoeveel ze van elkaar mogen verschillen, wat er gebeurt als ze te veel van elkaar verschillen, en hoe we die verschillen kunnen detecteren voordat ze de ervaring van de klant verpesten.

Het gaat om de verschuiving van "hopen dat alles werkt" naar "precies meten waar de verschillen zitten en deze beheren."

Verdrinkt u in papers in uw vakgebied?

Ontvang dagelijkse digests van de nieuwste papers die bij uw onderzoekswoorden passen — met technische samenvattingen, in uw taal.

Probeer Digest →