La mise à niveau que vous n'avez pas demandée

Pourquoi les mises à jour brisent ce qui fonctionnait

Une version plus récente du modèle est en moyenne meilleure et diffère de manière spécifique. Les fournisseurs optimisent pour des benchmarks agrégés ; vous avez déployé contre votre propre tranche étroite de réalité. Lorsque le modèle change, les comportements que vous avez ajustés autour changent également — la formulation sur laquelle reposait votre requête, la structure JSON attendue par votre intégration, la limite de refus approuvée par votre équipe de conformité, la longueur qui s'intégrait dans votre interface utilisateur.

Les mises à jour arrivent de trois manières. Le fournisseur retire une version du modèle et vous migre. Vous avez utilisé un alias flottant qui résout silencieusement vers la nouvelle version. Ou vous avez délibérément mis à niveau pour réduire les coûts ou la latence, en supposant que la qualité s'améliorerait. Les trois produisent le même résultat : le comportement a changé et personne n'a mesuré ce qui a changé.

Construisez l'outil qui vous informe

Le seul contrôle important est un ensemble fixe de cas de test avec des réponses connues — un ensemble doré. Deux cents exemples réels tirés de votre trafic réel, couvrant vos cas courants, vos cas limites et les situations où être incorrect est coûteux. Chaque exemple comporte la réponse que votre entreprise considère comme correcte.

Exécutez cet ensemble contre le modèle actuel et enregistrez les résultats. Cette enregistrement est votre point de référence. Lorsque une nouvelle version apparaît, exécutez à nouveau l'ensemble et comparez. La comparaison représente tout le produit : vous avez désormais des preuves au lieu d'impressions.

La construction de cet ensemble prend quelques jours et nécessite vos opérateurs, pas vos ingénieurs, pour définir ce que « correct » signifie. La plupart des organisations sautent cette étape car elle semble être une surcharge avant le lancement. C'est l'assurance la moins chère du système entier.

Contrôlez quand le changement vous atteint

Fixez explicitement des versions de modèle dans chaque configuration de production. Une version fixée transforme une embuscade en une décision planifiée. Traitez ensuite chaque mise à jour comme un petit projet :

Exécutez l'ensemble doré contre la nouvelle version et comparez, cas par cas, avec la référence
Faites examiner chaque cas où la réponse a changé par le propriétaire de l'entreprise, pas seulement ceux où elle s'est détériorée — les améliorations peuvent également briser des systèmes en aval
Envoyez une petite part du trafic en direct vers la nouvelle version et surveillez les signaux opérationnels : taux d'escalade, temps moyen de gestion, nombre de réécritures du système par le personnel avant l'envoi, clics « thumbs down »
Gardez la version ancienne accessible pendant une fenêtre de rollback et connaissez qui a l'autorité pour tirer la poignée
Enregistrez la décision, la date et les preuves, afin que la prochaine mise à jour démarre à partir d'un état connu

Notez ce qui ne figure pas sur cette liste : un demo. Regarder un nouveau modèle répondre avec assurance à cinq questions ne vous dit rien du vingtième centile de votre trafic, là où proviennent vos plaintes.

Surveillez les signaux que votre entreprise génère déjà

Entre les mises à jour, le dérèglement de la qualité apparaît dans des chiffres que vous collectez probablement déjà. Les escalades vers un humain. Le temps moyen de gestion. La fréquence à laquelle le personnel réécrit le brouillon du système avant l'envoi. Les contacts répétés sur le même problème dans une semaine. Toute augmentation de trois ou quatre points en deux semaines vaut un coup d'œil à ce qui a changé au niveau du modèle.

Donnez à une personne la tâche permanente d'examiner ces chiffres chaque semaine par rapport à la version du modèle en production. Pas un comité, pas une revue trimestrielle. Un propriétaire nommé et une vérification de quinze minutes.

Mettez-le dans le contrat

Demandez à votre fournisseur une notification écrite avant la mise hors service d'une version, un délai minimal de support pour les versions fixées et l'accès à la version précédente pendant la migration. Les fournisseurs qui desservent des industries réglementées offrent généralement cela. Ceux qui ne le font pas vous le diront, et cette réponse est utile avant de construire dessus plutôt qu'après.

La position honnête

Vous ne pouvez pas empêcher votre fournisseur d'améliorer ses modèles, et vous ne le voudriez pas non plus. Ce que vous pouvez faire, c'est vous assurer que l'amélioration se produit selon vos conditions : mesurée, étalée, réversible et détenue par quelqu'un.

C'est là la tâche peu glamour de faire fonctionner l'IA en production plutôt que de la tester — et c'est ce que nous faisons pour nos clients qui préféreraient consacrer leur attention à leur activité. De toute façon, construisez l'ensemble doré. Tout le reste en dépend.