Training-Inference Kernel Contracts: Bounding Divergence in Post-Training and Deployment
Cet article propose un cadre de « contrats de noyaux » (kernel contracts) pour spécifier et borner formellement la divergence de distribution entre les noyaux d'entraînement et d'inférence dans les pipelines post-entraînement, en dérivant des bornes théoriques sur le biais du gradient de politique et en esquissant un pipeline de déploiement structuré, tout en notant qu'il présente un cadre conceptuel sans validation empirique à l'échelle de la production.
Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète
Imaginez que vous avez un chef brillant (le modèle d'IA) qui a passé des années à apprendre la cuisine dans une cuisine de test haut de gamme et parfaitement calibrée. Dans cette cuisine, il utilise des balances numériques précises, des ingrédients frais et un processus de cuisson lent et méticuleux pour garantir que chaque plat est parfait. C'est la Cuisine d'Entraînement.
Maintenant, imaginez que vous voulez servir les recettes de ce chef à des milliers de clients affamés dans un food truck très fréquenté. Pour répondre à la demande, vous changez de configuration : vous utilisez des sachets d'épices pré-dosés, un gril plus rapide (mais légèrement moins précis) et un système où les commandes sont regroupées par lots pour gagner du temps. C'est la Cuisine d'Inférence.
Le problème, selon cet article, est que même si le chef est la même personne utilisant la même recette secrète (les poids du modèle), la nourriture qui sort du food truck n'est pas exactement la même que celle de la cuisine de test. La différence est infime — peut-être une pincée de sel ici ou une saisie légèrement différente là — mais sur des milliers de commandes, ces petites différences peuvent s'accumuler. Parfois, un plat qui était censé être « épicé » ressort « doux », ou un contrôle de sécurité qui fonctionnait en cuisine échoue sur le food truck.
L'article appelle cet écart le « Contrat de Noyau Entraînement-Inférence » (Training-Inference Kernel Contract). Voici une décomposition simple de leur solution :
1. Le Problème : « Deux Chefs Différents »
Actuellement, quand nous construisons une IA, nous supposons que le « Chef d'Entraînement » et le « Chef d'Inférence » font exactement la même chose. Mais en réalité, ils utilisent des outils et des méthodes différents.
- L'Entraînement utilise des mathématiques de haute précision (comme une balance numérique).
- L'Inférence utilise des mathématiques rapides et de faible précision (comme une estimation visuelle) pour aller plus vite et économiser de l'argent.
Parce qu'ils utilisent des outils différents, ils prennent parfois des décisions différentes. Dans un restaurant normal, cela signifie peut-être simplement qu'une soupe a un goût légèrement différent. Mais pour l'IA, cela peut signifier :
- Le « Hack de Récompense » (Reward Hack) : Dans l'Apprentissage par Renforcement (où l'IA apprend par essais et erreurs), l'IA peut penser qu'elle fait un excellent travail parce que la cuisine « rapide » lui a donné un bon score, alors que la cuisine « précise » lui aurait donné un mauvais score. C'est comme un étudiant qui obtient un A à un examen blanc mais échoue à l'examen réel parce que la grille d'évaluation a changé.
- Le « Glissement de Sécurité » (Safety Slip) : Une requête que le modèle refuse de traiter dans la cuisine de test pourrait accidentellement être acceptée dans le food truck parce que le gril rapide a modifié la saveur juste assez pour contourner le filtre de sécurité.
2. La Solution : Le « Contrat de Noyau » (Kernel Contract)
Les auteurs proposent un nouveau carnet de règles appelé Contrat de Noyau. Voyez cela non pas comme un document juridique pour les avocats, mais comme une Liste de Contrôle de Qualité qui accompagne l'IA.
Ce contrat stipule : « Nous savons que la cuisine rapide (Inférence) ne sera pas 100 % identique à la cuisine de test (Entraînement). Ce n'est pas grave. Mais voici les règles spécifiques que nous NE briserons PAS. »
Le contrat comporte quatre sections principales :
- Règles Numériques (N) : « Les mathématiques ne peuvent pas dériver de plus de X. » (ex: le niveau d'épices ne peut pas changer de plus de 10 %).
- Règles Statistiques (S) : « Le goût final doit être cohérent. » (ex: 99 % du temps, le plat doit toujours être reconnu comme « Épicé »).
- Règles d'Exécution (R) : « Cela doit rester assez rapide. » (ex: le food truck ne peut pas ralentir simplement parce que nous avons ajouté un contrôle de sécurité).
- Règles d'Observabilité (O) : « Nous devons pouvoir goûter chaque commande ultérieurement. » (Si un client se plaint, nous devons être capables de rejouer cette commande exacte dans les deux cuisines pour voir ce qui s'est mal passé).
3. La « Politique d'Escalade » (Que se passe-t-il si vous enfreignez les règles ?)
Le contrat n'est pas seulement une liste ; il possède un système de feux de signalisation :
- Vert (L1) : « Attention. » Nous avons enregistré une petite différence. Continuez à cuisiner.
- Jaune (L2) : « Avertissement. » La différence devient trop grande. Nous arrêtons d'envoyer de nouvelles commandes à cette cuisine et nous les dirigeons vers une cuisine de secours jusqu'à ce que nous la réparions.
- Rouge (L3) : « Urgence. » Quelque chose ne va vraiment pas. Nous arrêtons immédiatement cette cuisine et passons à une version connue et fiable.
4. La « Promotion en Quatre Étapes » (Comment tester avant de servir)
On ne lance pas simplement un nouveau mode de cuisine au public en appuyant sur un interrupteur. L'article suggère un tunnel de sécurité en quatre étapes :
- CI Hors-ligne : Exécutez la liste de contrôle sur un ensemble fixe de commandes de test dans le laboratoire. Si elle échoue, ne quittez même pas le laboratoire.
- Ombre (Shadow) : Laissez la nouvelle cuisine cuisiner, mais servez la nourriture de l'ancienne cuisine aux clients. Nous observons simplement pour voir si la nouvelle cuisine aurait commis des erreurs.
- Canari (Canary) : Laissez la nouvelle cuisine servir un petit groupe de vrais clients (comme 1 %). S'ils se plaignent, nous arrêtons immédiatement.
- Plein déploiement (Full) : Si tout le monde est satisfait, nous laissons la nouvelle cuisine servir tout le monde.
5. Pourquoi cela importe pour l'IA « Apprenante » (RL)
L'article fait un point spécifique sur l'IA qui apprend par elle-même (Apprentissage par Renforcement) :
- Le Problème : Lors de l'apprentissage, l'IA prend un « instantané » du monde en utilisant la cuisine rapide, mais tente ensuite d'apprendre à partir de la cuisine précise. C'est comme essayer d'apprendre à conduire en regardant une vidéo d'une voiture de course, puis conduire un modèle de voiture différent. L'IA est confuse et apprend les mauvaises leçons.
- La Solution : Le contrat force l'IA à admettre : « Hé, ma cuisine rapide et ma cuisine précise sont différentes. » Cela ajoute un « facteur de correction » au processus d'apprentissage pour que l'IA ne soit pas trompée par la vitesse du food truck.
Résumé
L'article soutient que nous devons cesser de prétendre que l'« IA d'Entraînement » et l'« IA de Service » sont la même chose. Au lieu de cela, nous devrions les traiter comme deux partenaires différents qui ont signé un Contrat. Ce contrat stipule explicitement à quel point ils sont autorisés à être en désaccord, ce qui se passe s'ils sont trop en désaccord, et comment détecter ces désaccords avant qu'ils ne gâchent l'expérience du client.
Il s'agit de passer de « espérer que tout fonctionne » à « mesurer précisément où se trouvent les différences et les gérer ».
Noyé(e) sous les articles dans votre domaine ?
Recevez des digests quotidiens des articles les plus récents correspondant à vos mots-clés de recherche — avec des résumés techniques, dans votre langue.