Résumé technique : L'alignement pertinent pour le déploiement ne peut être inféré de l'évaluation au niveau du modèle seul

Énoncé du problème

L'évaluation actuelle de l'alignement en apprentissage automatique se concentre principalement sur des métriques au niveau du modèle ou au niveau de la réponse. Les benchmarks influents notent les sorties de modèles sous des entrées fixes (par exemple, véracité, conformité aux instructions, préférence par paires) et considèrent ces scores comme une preuve suffisante pour étayer des affirmations concernant l'alignement en déploiement.

L'article soutient que cette inférence est invalide. L'alignement pertinent pour le déploiement est un phénomène de niveau système dépendant de l'interaction entre le modèle ($M$), l'infrastructure ($S$ — invites, mémoire, outils, interface utilisateur) et le contexte de déploiement ($C$ — population d'utilisateurs, supervision, politique). Étant donné que les benchmarks actuels maintiennent $S$ et $C$ fixes ou les ignorent, ils ne peuvent pas mesurer des propriétés essentielles aux systèmes déployés, telles que le soutien à la vérification, la pilotabilité du processus ou la distribution de la charge de réparation. L'article postule un problème de « non-identifiabilité » : évaluer $M$ seul ne permet pas de distinguer entre différents déploiements d'un même modèle qui présentent des comportements très différents liés à l'alignement en raison de différences dans $S$.

Méthodologie

L'article utilise deux études empiriques principales pour étayer sa position :

1. Audit structuré de benchmarks

• Portée : Un audit codé en double de 11 benchmarks principaux (plus un contrôle de méta-évaluation, JudgeBench) et une extension à 16 benchmarks au total.
• Grille d'évaluation : Une grille à huit dimensions dérivée de la littérature sur l'alignement interactionnel et de déploiement (Terry et al., Shen et al., et travaux empiriques sur l'ancrage/réparation). Les dimensions sont :
  • D1 : Alignement de la spécification (gestion des demandes sous-spécifiées).
  • D2 : Alignement du processus / Pilotabilité (contrôle de l'utilisateur sur le processus de raisonnement).
  • D3 : Alignement de l'évaluation / Soutien à la vérification (aide aux utilisateurs pour vérifier les sorties).
  • D4 : Rétention du contexte multi-tours.
  • D5 : Ancrage / Terrain commun.
  • D6 : Distribution de la charge de réparation.
  • D7 : Personnalisation / Alignement spécifique à l'utilisateur.
  • D8 : Réalisme du flux de travail / de la supervision.
• Protocole : Deux codeurs externes formés ont noté indépendamment les benchmarks sur une échelle ancrée de 0 à 2 (0 : absent, 1 : partiel/incidental, 2 : substantiel). Les désaccords ont été résolus par une réconciliation guidée par les ancres.
• Fiabilité : Le $\kappa$ de Cohen était de 0,87 sur les 128 cellules du corpus de 16 benchmarks.

2. Test de stress croisé entre modèles en aveugle

• Conception : Une étude maintenant les poids du modèle ($M$) et le contexte de déploiement ($C$) approximativement fixes tout en variant uniquement l'infrastructure d'interaction ($S$).
• Variables :
  • Modèles : Trois modèles de pointe (Claude-Opus-4.7, GPT-4o, Llama-4-Scout).
  • Infrastructures : Quatre conditions allant d'un chatbot simple (C1) à des invites explicites de soutien à la vérification (C4).
  • Données : 180 transcriptions (60 par modèle) couvrant les domaines médical, juridique et technique.
• Protocole : Les transcriptions ont été anonymisées, dépouillées des invites système, et codées par deux évaluateurs pour D1, D2 et D3. Les désaccords ont été résolus en appliquant une politique de minimum conservateur.

Résultats clés

Issus de l'audit des benchmarks

1. Le vide D3 : Le soutien à la vérification (D3) est absent dans les 11 benchmarks audités. Aucun benchmark n'évalue explicitement si la sortie d'un modèle aide un utilisateur à vérifier, critiquer ou comprendre la réponse.
2. Présence quasi nulle de pilotabilité : La pilotabilité du processus (D2) est presque absente, obtenant un score non nul dans un seul benchmark ($\tau$-bench) et même là uniquement comme score partiel, et non comme contrôle explicite de l'utilisateur.
3. Fragmentation des benchmarks interactionnels : Les quatre benchmarks interactionnels identifiés (CURATe, Rifts, $\tau$-bench, Common Ground) mesurent différents sous-ensembles non chevauchants de dimensions. Il n'existe pas d'objectif d'évaluation unifié pour l'alignement interactionnel.
4. La construction détermine la mesure : La structure de l'évaluation (la manière dont le benchmark est construit) détermine ce qui est mesuré, et non la source de données. Par exemple, WildBench utilise de vrais journaux d'utilisateurs mais note des listes de contrôle de réponses uniques, échouant à capturer les propriétés interactionnelles malgré son réalisme écologique.

Issus du test de stress croisé entre modèles

1. Efficacité de l'infrastructure dépendante du modèle : La même infrastructure ($S$) produit des résultats comportementaux catégoriellement différents selon les modèles.
   • Claude-Opus-4.7 : Très plastique ; l'infrastructure de vérification C4 a fait passer son score D3 de 0,42 à 2,00 (plafond).
   • GPT-4o : Saturé ; la même infrastructure C4 n'a eu aucun effet mesurable sur D3 (resté à 0,33).
   • Llama-4-Scout : Partiellement inversé ; a montré une sensibilité faible et une absence catégorielle de D2 sur toutes les infrastructures.
2. Implication : L'écart identifié dans l'audit (mesures manquantes des propriétés interactionnelles) ne peut être comblé au niveau du modèle car l'efficacité de l'infrastructure est elle-même une fonction des poids du modèle.

Contributions clés

1. Cadre indexé par niveau : L'article propose de distinguer quatre niveaux d'évaluation de l'alignement : Niveau modèle (poids/objectifs), Niveau réponse (sorties sous entrées fixes), Niveau interaction (propriétés multi-tours) et Niveau déploiement (système dans le flux de travail). Il soutient que les affirmations doivent être indexées au niveau de la preuve.
2. Preuve d'audit structuré : Fournit des preuves empiriques que l'écosystème actuel de benchmarks échoue systématiquement à mesurer des dimensions interactionnelles critiques (spécifiquement D2 et D3).
3. Preuve de non-identifiabilité : Démontre via le test de stress que $B = f(M, S, C)$ ne peut être inféré de $M$ seul, car $S$ interagit avec $M$ de manières dépendantes du modèle.
4. Programme d'évaluation : Propose un passage des scores d'alignement uniques aux profils d'alignement. Cela inclut :
   • Le rapport des preuves sur les huit dimensions.
   • L'utilisation de protocoles à infrastructure fixe pour une évaluation interactionnelle comparable.
   • Un modèle de rapport à six lignes (Annexe G.1) qui oblige les auteurs à énoncer explicitement la portée de leurs affirmations (quelles configurations $M, S, C$ la preuve soutient).

Importance et affirmations

L'article affirme que la dépendance du domaine aux benchmarks de niveau réponse pour valider des affirmations d'alignement en déploiement est structurellement défectueuse. Le « fossé inférentiel » entre la performance des benchmarks et le comportement déployé est plus large que ce qui est actuellement reconnu.

L'importance de ce travail réside dans :

• La correction de la portée des affirmations : Affirmer que les preuves au niveau du modèle sont insuffisantes pour des affirmations au niveau du déploiement et que l'ajout de plus de benchmarks de niveau réponse ne résoudra pas le problème.
• Discipline méthodologique : Introduire un cadre où les affirmations d'alignement sont explicitement circonscrites au niveau des preuves collectées, empêchant la confusion entre les propriétés du modèle et les comportements du système.
• Validation empirique : Fournir des preuves directes que les propriétés interactionnelles ne sont pas intrinsèques au modèle mais sont des propriétés émergentes du système ($M+S+C$), et que ces propriétés varient considérablement d'un modèle à l'autre, même avec une infrastructure identique.

L'article ne prétend pas que l'évaluation au niveau du modèle est inutile, mais plutôt qu'elle est insuffisante pour les affirmations de déploiement. Il appelle la communauté à développer des vocabulaires et des protocoles d'évaluation qui prennent en compte le système, l'interaction et l'utilisateur, plutôt que de se concentrer uniquement sur le modèle.