Une fois le modèle open source restreint, la première chose qui échoue est le jugement de régression.

Une fois que des restrictions externes s’appliquent à un modèle open source, la première chose qui se brise n’est souvent pas « peut-il toujours être téléchargé ? mais “les résultats de cette fois peuvent-ils être visualisés avec la dernière fois ?” Le nom du modèle est toujours là et l’interface peut toujours être connectée. Ce qui devient vraiment difficile, c’est que la ligne de jugement commence à dériver : avec le même ensemble de mots d’invite, le même lot d’échantillons et le même flux de travail, les résultats obtenus ne correspondent plus à la même distribution de comportement.

Cette chose semble simple sur le papier, mais en pratique cela devient très ennuyeux. Le format de sortie auparavant passable a soudainement un peu plus d’explications, la séquence d’appel de fonction auparavant stable commence à changer, il existe une couche supplémentaire d’invites de politique dans certaines zones, ou la même requête obtient des longueurs de contexte différentes sous différentes entrées. Chacun d’eux à lui seul n’est pas un accident, mais pris ensemble, ils perturberont le jugement du retour.

Ce qui a cassé en premier, c’est le calibre comparatif.

De nombreuses équipes se concentreront d’abord sur les scores de référence, mais les scores ne conviennent qu’à indiquer les capacités approximatives et ne conviennent pas pour expliquer « si le comportement actuel peut encore être suivi par l’ancien processus ». Le véritable point à mettre en ligne n’est pas que le modèle s’exécute seul, mais qu’il fonctionne avec l’analyseur, les appels d’outils, les tentatives, la mise en cache, l’audit et le routage. Tant que l’un des liens change de calibre, la partition perdra son sens de référence.

La situation la plus courante est qu’aucun problème n’est visible dans l’ensemble d’évaluation, mais que la chaîne commence à se détériorer en ligne. Les échantillons de test sont suffisamment propres et le modèle répond très bien aux questions. Cependant, une fois l’entrée réelle reçue, une petite dérive de champ peut biaiser les étapes automatisées suivantes. Le résultat ressemble à “le modèle peut toujours être utilisé”, mais en fait cela signifie “la méthode de comparaison a échoué”.

La ligne de base doit être enregistrée en fonction du workflow

Pour supprimer de tels changements, nous ne comptons pas sur l’exécution de plusieurs séries de listes, mais sur la transformation de la ligne de base en un flux de travail rejouable. L’entrée doit avoir une version, la sortie doit avoir un schéma, la réponse de l’outil doit être jouable et les échantillons ayant échoué doivent conserver le contexte d’origine. Ce n’est qu’ainsi, après avoir basculé vers d’autres modèles, d’autres régions et d’autres stratégies, que nous pourrons savoir si l’écart réside dans le modèle lui-même ou dans les maillons avant et arrière.

Ce type de référence craint surtout de stocker uniquement un score et une conclusion. Les scores serviront à réconforter les gens, les conclusions serviront à rédiger des rapports, mais les détails vraiment utiles manquent. Une fois les restrictions renforcées ultérieurement, l’équipe ne peut que reconstituer les échantillons, reconstituer le calibre et reconstituer les limites anormales, ce qui équivaut à diviser le travail de comparaison qui aurait pu être effectué en une seule fois en plusieurs cycles de retouche.

Le véritable coût de la migration est de rétablir la confiance

Une fois le modèle restreint, l’action de migration ressemble à un passage à un élément disponible, mais elle rétablit en réalité la confiance dans le fait que « ce processus est relativement stable ». La confiance ne se construit pas par un seul appel réussi, mais par un ensemble de résultats de comparaison qui peuvent être vérifiés à plusieurs reprises. Sans cet ensemble de résultats, il ne serait possible de l’exécuter que temporairement si nous retournions au passé ; avec cet ensemble de résultats, ce serait dans la plage contrôlable si nous changions vers le passé.

C’est pourquoi certaines équipes ont réalisé des remplacements en surface, mais en interne elles doivent encore attendre longtemps avant d’oser augmenter leurs capacités. Ce qui bloque vraiment, ce n’est pas l’action d’accès, mais la question à laquelle personne n’ose répondre : si les limites les plus importantes de l’ancien processus sont toujours valables dans le nouveau modèle. Tant qu’on ne répond pas clairement à cette question, toute affirmation selon laquelle « la migration est terminée » n’est qu’une affirmation mise en scène.

Seules les pièces adaptées au test méritent d’être reconstruites

Tous les scénarios ne méritent pas d’alourdir autant la chaîne de régression. Les conversations ad hoc, la génération légère et les résumés ponctuels ont des limites lâches, et la construction excessive est une perte de temps. Mais dès que le modèle commence à participer à la génération de code, à l’extraction d’informations, aux décisions de routage et à l’exécution des outils, le jugement de régression n’est plus un accessoire mais une partie du flux de travail.

Les contraintes externes peuvent amplifier cette différence. La question de savoir si elle peut continuer à être utilisée n’est généralement que la couche la plus superficielle ; ce qui détermine réellement si l’équipe peut être stable, c’est s’il existe une méthode stable pour comparer les nouveaux résultats à l’ancienne référence à des fins de comparaison. Une fois la comparaison établie, la migration n’est plus qu’un problème d’ingénierie ; une fois la comparaison échouée, tous les jugements ultérieurs commenceront à vaciller.