Si ton modèle a « commencé à se comporter différemment » du jour au lendemain sans changement de modèle, c'est probablement de la dérive de tokenisation. Même tokenizer, entrée sémantiquement identique, séquences de tokens complètement différentes. Un exemple GPT-2 tiré de l'article de MarkTechPost : `" classify"` avec un espace devant tokenise à un seul ID, `[36509]`; `"classify"` sans l'espace tokenise à deux IDs, `[4871, 1958]`. Pour le modèle, ce ne sont pas le même mot — ce sont des entrées différentes qui atterrissent dans des régions différentes de l'espace des tokens. Que ton prompt soit « presque le même » que ce que le modèle a vu pendant le fine-tuning, ce n'est pas la même chose qu'être pareil.

L'article quantifie le mode d'échec. En utilisant le tokenizer de GPT-2 et un classifieur fine-tuné, le format de prompt aligné SFT atteint environ 83 % d'accuracy. Enlève les sauts de ligne et tu tombes à 40-50 %. Reformule l'instruction et le chevauchement Jaccard de tokens avec le format d'entraînement chute à ~50 %, ce qui pousse l'entrée hors-distribution et tank l'accuracy. Le fix proposé est APO (Automated Prompt Optimization) : tester cinq-plus variantes de template, scorer chacune par chevauchement Jaccard d'ensembles de tokens contre le template SFT original, mettre à l'échelle l'accuracy de validation par une pénalité OOD proportionnelle au chevauchement, et choisir le template gagnant sur la métrique combinée. L'implémentation, c'est quelques lignes de HuggingFace `AutoTokenizer.encode()` plus de la comparaison d'ensembles.

Le pattern plus large, c'est que les régressions de prompt en production ne sont habituellement pas des régressions de modèle — ce sont des décalages au niveau tokenizer entre ce que le modèle a appris pendant l'instruction tuning et ce que ton application envoie maintenant. C'est le genre de bug qui survit à tous les tests que tu as à moins de vérifier explicitement les séquences de tokens contre une distribution de référence. C'est aussi pourquoi « le même prompt » copié-collé d'un Notion vers un éditeur de code peut dégrader silencieusement — l'éditeur a normalisé tes espaces ou enlevé un saut de ligne final, et te voilà à une distance différente des données d'entraînement. Les modèles RLHF et instruction-tuned sont particulièrement sensibles parce que le formatage devient partie de la représentation de la tâche, pas juste de la décoration autour.

Quoi faire lundi : log les séquences de tokens brutes pour les prompts en production (ne compare pas les chaînes, compare les IDs de token) et diff contre le prompt original que tu as testé au déploiement. Ajoute un test de régression Jaccard-overlap dans ton pipeline CI de prompts. Si tu fais du fine-tuning, sauve la tokenisation exacte de ton format d'entraînement et valide les entrées d'inférence contre. Pour les développeurs sur des modèles à poids fermés que tu ne peux pas réentraîner, le mouvement pratique, c'est la boucle APO de l'article : cherche empiriquement des variantes de prompt qui maximisent le chevauchement de tokens avec des formats que le modèle a clairement déjà vus. La question « est-ce que mon prompt marche » devient une question au niveau tokenizer, pas au niveau formulation.