Nous ne travaillons pas encore vraiment avec des modèles d’IA : nous jouons avec eux comme des enfants autorisés à appuyer sur les boutons d’un superordinateur. Nous connaissons déjà quelques commandes. On peut produire un résultat impressionnant et répéter une séquence qui fonctionne parfois. Mais nous ne comprenons pas ce qui se passe à l’intérieur, pourquoi le modèle a choisi cette réponse particulière ou ce qui va se briser après la prochaine édition.
Jusqu'à ce que nous apprenions, au moins assez bien, comment un modèle évolue dans une instruction et prend une décision, nous n'utiliserons que la petite fraction de ses capacités que nous avons remarquées de l'extérieur. Nous continuerons d’appuyer sur des boutons au lieu de contrôler le processus. Nous obtiendrons des résultats isolés au lieu d’utiliser le système à son plein potentiel.
Dans les trois premières parties de cette série, une instruction longue est devenue un programme caché, une sortie correcte n'est plus la preuve d'un processus correct et les validateurs locaux se sont révélés incapables de garantir un contrôle global. Une dernière question demeure : pouvons-nous parcourir l’exécution d’un modèle comme un programme dans un débogueur et voir exactement où il a pris le mauvais tournant ?
Dans un programme conventionnel, un bug peut ne pas être corrigé du premier coup, mais un débogueur réduit radicalement l'espace de recherche. Nous définissons un point d'arrêt, exécutons le programme, inspectons les valeurs des variables, passons en revue les transitions et voyons quelle condition s'est déclenchée. Avec un processus d'IA, nous travaillons souvent différemment : nous ajoutons une règle d'approbation, exécutons le processus, constatons le même échec, répétons la règle dans la section de correction, obtenons un laissez-passer, puis découvrons qu'une autre branche est cassée. De l'extérieur, cela ressemble à du débogage. En pratique, il s’agit de tests en boîte noire par essais et erreurs.
Le pire n’est pas qu’un seul changement puisse provoquer une régression. Le vrai problème est que nous ne savons souvent pas pourquoi la deuxième manche a réussi. Le modèle a-t-il réellement commencé à appliquer la nouvelle règle ? Est-il arrivé de choisir une autre branche ? La nouvelle formulation a-t-elle pris le pas sur un autre élément du contexte ? Ou est-ce que le vieil échec n’est tout simplement pas apparu dans cette série ? Quand tout ce que nous pouvons voir c'estentrée → sortie, un résultat positif n’explique pas mieux le mécanisme d’amélioration qu’un résultat négatif ne localise le mécanisme d’échec.
Revenons à l'exemple courant avec lePREFERENCE_CHANNEL_CHANGEDévénement. Après une correction, la spécification technique est passée à la version 4, mais Jira, QA et l'approbation sont restés sur la version 3. Dans le package final, le résultat était le même quel que soit l'endroit où la panne s'est réellement produite :
attendu : version_spec_technique : 4 version_jira : 4 version_qa : 4 version_approbation : 4 réel : version_spec_technique : 4 version_jira : 3 version_qa : 3 version_approbation : 3À partir de ce seul résultat, nous pouvons formuler au moins cinq hypothèses différentes :