MLOps sans le mot à la mode : ce qu'il faut réellement pour qu'un système AI continue de fonctionner

MLOps est la discipline consistant à maintenir un système d'apprentissage automatique utile après son lancement. En termes simples, il couvre quatre tâches : la surveillance (surveiller si le modèle fonctionne toujours dans le monde réel), le recyclage (l'actualiser à mesure que les données changent), la gestion des versions (savoir exactement quel modèle et quelles données ont produit quel résultat) et la plomberie de déploiement qui expédie une nouvelle version en toute sécurité. Un modèle n’est pas un produit fini le jour de sa mise en ligne. Il s’agit d’un composant périssable situé à l’intérieur d’un système qui doit être alimenté, surveillé et corrigé. MLOps est le nom de ce travail en cours. Ignorez-le et le modèle s'écarte discrètement de la réalité, la précision glisse et un matin, les prédictions sont fausses d'une manière que personne ne vérifie. Le lancement est le début du travail, pas sa fin.

Que signifie réellement MLOps en production ?

MLOps est ce que DevOps est par rapport aux logiciels ordinaires, adapté au fait qu'un modèle dépend de données, pas seulement de code. Une application normale se comporte aujourd’hui de la même manière que le jour où vous l’avez expédiée, jusqu’à ce que quelqu’un modifie le code. Un modèle ne le fait pas. Le monde dans lequel il a appris continue de bouger, de sorte que sa précision peut se dégrader alors que chaque ligne de code reste intacte.

Cette différence est tout le problème. Avec le logiciel que vous demandez, fonctionne-t-il toujours? Avec un modèle, il faut aussi se demander s'il tient toujours. MLOps est l'ensemble de pratiques et d'outils qui vous permettent de répondre à la deuxième question chaque jour, et non une fois par trimestre lorsqu'un client se plaint.

Quel est le travail après le lancement d'un modèle ?

Le travail du deuxième jour se répartit en quatre tâches récurrentes. Aucune d’entre elles n’est glamour, et toutes sont ce qui sépare un système qui gagne sa vie d’un système qui pourrit.

Surveillance. Suivez les entrées et les sorties du modèle en production. Surveillez la dérive des données (les données en direct commencent à être différentes des données d'entraînement) et la précision diminuant par rapport aux résultats réels une fois qu'ils sont connus. L'alerte que vous souhaitez est celle qui se déclenche avant qu'un client ne le remarque, pas après.
Recyclage. Lorsque les performances diminuent ou que les données ont clairement bougé, actualisez le modèle avec des données plus récentes et expédiez la mise à jour. Décidez dès le départ si cela est déclenché par une métrique franchissant une ligne ou s'il s'exécute selon un calendrier, et faites-en une routine et non un exercice d'incendie.
Gestion des versions. Enregistrez quelle version du code, des données et du modèle entraîné a produit un résultat donné. Lorsqu'une sortie est contestée, vous devez reconstruire exactement ce qui a été exécuté. Sans cela, toute enquête part de conjectures.
Validation et déploiement. Testez un nouveau modèle par rapport à celui actuel avant qu'il n'affecte le trafic réel, publiez-le progressivement et gardez un chemin rapide vers la version précédente si elle sous-performe.

Il s'agit de la même discipline d'ingénierie qui transforme un pilote en un système qui survit au contact avec de vrais utilisateurs. La démo prouve que le modèle peut fonctionner une fois. Ce travail prouve que cela continue de fonctionner.

Pourquoi les systèmes AI pourrissent-ils sans MLOps ?

Parce que les données sous-jacentes ne cessent de changer et qu’un modèle non surveillé n’a aucun moyen de vous dire qu’il a pris du retard. Un modèle de fraude formé sur les modèles de l'année dernière passe lentement à côté de celui de cette année. Un extracteur de documents adapté aux factures d'un fournisseur commence à supprimer des champs lorsque le format d'un nouveau fournisseur arrive. Le code est bien. Le modèle a tout simplement vieilli par rapport à la réalité pour laquelle il a été construit.

Le danger est que cet échec reste silencieux. Un serveur en panne appelle quelqu'un à 3 heures du matin. Un modèle à la dérive renvoie simplement des réponses légèrement moins bonnes, jour après jour, et continue de les renvoyer avec confiance. Personne n'est bipé. Au moment où quelqu'un repère un numéro étrange, le système peut avoir été discrètement erroné pendant des mois. C'est ce que les gens veulent dire lorsqu'ils disent qu'un système AI a pourri : non pas qu'il s'est cassé, mais que personne ne l'a vu se décomposer.

C'est pourquoi les systèmes durables, comme ceux nécessaires pour document AI dans une entreprise, traitent la surveillance et le recyclage comme faisant partie de la construction, et non comme quelque chose à ajouter s'il reste du budget.

De quelle quantité de MLOps un projet a-t-il réellement besoin ?

Moins que ce que le paysage des fournisseurs implique, et plus que ce que la plupart des pilotes prévoient dans leur budget. La bonne quantité dépend des enjeux, et non de la taille du catalogue d’outillage.

Type de système	Quels sont les besoins en matière de surveillance	Cadence de reconversion
Entrées stables et à faibles enjeux	Journalisation de sortie de base et vérification simple de la précision	Rarement, seulement lorsqu'un problème surgit
Intrants changeants et critiques pour l'entreprise	Alertes de dérive et de précision avec un propriétaire nommé	Sur un déclencheur défini ou un horaire régulier
Décisions conséquentes concernant les personnes	Journalisation complète, examen humain des cas extrêmes, piste d'audit	Programmé, avec chaque version enregistrée

Deux principes maintiennent cela honnête. Tout d'abord, créez la surveillance avant d'en avoir besoin, même si le système est petit, car il est bien plus difficile d'améliorer la visibilité dans un système actif que de le concevoir. Deuxièmement, attribuez un propriétaire nommé au système en cours d'exécution. Le travail opérationnel sans propriétaire n’a pas lieu, et un modèle sans personne qui le surveille est un modèle en voie de pourriture.

Le point pratique à retenir

Lorsque vous mettez en service un système AI, demandez qui en est responsable au cours du sixième mois et comment il saura s'il cesse de fonctionner. Si la réponse est une date de lancement et le silence après cela, vous achetez une démo avec une piste plus longue. Si la réponse nomme une personne, un ensemble de mesures qu'elle surveille et un plan pour actualiser le modèle, vous achetez quelque chose conçu pour rester utile. MLOps n'est que l'habitude peu glamour de tenir une promesse après la fin de la soirée de lancement. Encelyte construit les documents des systèmes AI et AI avec ce travail de la deuxième journée conçu dès le départ.