Réparer ou reconstruire : cinq signes qu'un système d'IA a atteint sa limite

La fin d'une AI : un processus insidieux

Un système d'IA ne meurt presque jamais de manière soudaine imposant une décision. Il continue de répondre, de générer des scores et de produire des fichiers chaque matin. Pendant ce temps, l'équipe trouve des contournements, les demandes de changement s'accumulent et la dépense annuelle augmente sans que personne ne décide de l'augmenter. La fin de vie arrive lentement avec une augmentation des coûts de maintien, un coût qui n'apparaît jamais à l'ordre du jour.

Ainsi, la décision est reportée. Rebâtir semble coûteux et perturbateur ; continuer semble gratuit. Ce n'est pas le cas, et le rôle d'un leader ici est de remarquer le moment où les coûts de maintien dépassent le coût de remplacement.

Les cinq signaux

Ce sont ceux qui se maintiennent à travers les industries et les types de systèmes. N'importe lequel d'entre eux est un signal d'alerte. Trois ensemble signifient que la décision a déjà été prise pour vous.

Les modifications mineures ne le restent plus. Une règle de tarification qui prenait deux jours à ajuster la première année prend désormais trois semaines et affecte quatre autres choses. Le système a accumulé suffisamment de cas particuliers que personne ne peut prédire l'étendue d'un changement.
Les contournements sont devenus le processus. Les gens exportent la sortie et la corrigent dans un tableur avant que quiconque ne l'utilise. Ce tableur a désormais un propriétaire, une convention de nommage et une sauvegarde. Le système réel est le contournement ; le officiel est une source de données.
Vous ne pouvez pas répondre aux questions de base. Pourquoi le système a-t-il refusé ce client en mars ? Quelle version était en cours lorsque les chiffres ont changé ? Si personne ne peut répondre sans une semaine d'investigation, vous assumez une exposition réglementaire et réputationnelle que vous n'avez pas prise en compte.
La connaissance vit dans une ou deux personnes. Chaque changement dépend d'une même personne. Ils ne cachent rien ; ils sont simplement la seule copie survivante des décisions de conception. C'est un risque de personnel déguisé en technique.
La contrainte a changé. Le système a été construit autour d'une limitation qui n'existe plus — une fenêtre contextuelle, un plafond de latence, un prix par appel, une fonctionnalité nécessitant trois composants et qui n'en nécessite désormais qu'un seul. Une grande partie de ce que vous maintenez est du matériel pour un problème qui a disparu.

Ce qui ne constitue pas un signal

Une mauvaise série de qualité de sortie est généralement un problème de données, pas de conception. Le lancement d'un nouveau modèle n'est pas une raison pour reconstruire quoi que ce soit ; si votre système est bien structuré, le remplacement du modèle est une modification de configuration et vous devriez tester si cela fonctionne. Un incident bruyant n'en est pas non plus — les incidents se concentrent autour des systèmes visibles, pas ceux qui sont fragiles.

La distinction importante est entre un système qui fonctionne mal et un système qui devient coûteux à modifier. Le premier est réparable. Le second est un verdict structurel, et aucune quantité de patch ne l'inversera.

Prixer le maintien, pas seulement la reconstruction

Les propositions de reconstruction perdent parce que seul un côté du bilan obtient un chiffre. Mettez un montant sur l'autre avant de décider.

Additionnez ce que le système actuel a consommé au cours des douze derniers mois : les heures d'ingénierie consacrées à la maintenance et aux incidents, la facture du fournisseur et du calcul, les heures que les gens passent à corriger manuellement en aval, et la valeur des modifications demandées par l'entreprise et non obtenues. Cet élément dernier est généralement le plus important et n'est presque jamais compté. Ensuite, regardez les douze derniers mois deux ans plus tôt. Si la ligne augmente tandis que la sortie est plate, vous avez votre réponse, et vous l'avez dans la seule devise qu'un conseil d'administration peut argumenter.

Reconstruire par tranches et conserver les données

La reconstruction ne signifie pas un programme de deux ans avec une date de basculement. Les systèmes qui se prêtent bien à la reconstruction le font une capacité à la fois : mettez en place le nouveau chemin pour une tranche étroite du trafic, faites-le fonctionner à côté de l'ancien, comparez les sorties sur des cas réels, déplacez la tranche, répétez. Le vieux système reste en ligne jusqu'à ce que la dernière tranche disparaisse. À aucun moment, l'entreprise ne dépend d'un seul week-end de basculement.

La seule chose digne d'être conservée est les données — les exemples étiquetés, les corrections, le record de ce que le système a mal compris et comment les gens ont corrigé cela. Ce jugement accumulé est l'actif véritablement précieux. Le code autour est remplaçable, et à un moment donné, il devrait l'être.

La plupart des organisations attendent environ une année de trop. Le coût de cette année est rarement visible, ce qui est précisément la raison pour laquelle il doit être mesuré. Nous avons construit notre pratique autour du support de ce poids pour nos clients, mais la mesure est à votre charge et elle vaut la peine d'être faite avant le prochain cycle budgétaire plutôt qu'après.