Les services de prédiction et d'optimisation basés sur le Machine Learning intéressent aujourd'hui de nombreuses entreprises: des grandes banques aux petites boutiques en ligne. En résolvant les problèmes de divers clients, nous avons rencontré un certain nombre de problèmes, qui ont servi de base à nos discussions sur les caractéristiques des tests ML. Pour ceux qui sont intéressés, voici notre prochain article de Sergey Agaltsov, responsable des tests de Jet Infosystems.
Auparavant, seules les grandes entreprises pouvaient tirer parti de l'apprentissage automatique, car il était coûteux et difficile, et il y avait très peu de données dans le domaine public. Aujourd'hui, c'est devenu beaucoup plus facile. L'expertise ML peut être demandée auprès d'un intégrateur, d'une entreprise spécialisée ou d'un site thématique. C'est bon pour tout le monde, car avec la croissance de l'expertise, de nouveaux algorithmes sont développés et la «tirelire d'expérience» dans le domaine de l'apprentissage automatique s'enrichit constamment.
Le seul aspect pour lequel nous n'avons pas trouvé de solution toute faite est le test des services ML. Google, vous pouvez vous assurer que dans les résultats de recherche, il n'est pas fait mention des activités des testeurs dans le développement de ces services. Bien sûr, les experts en science des données testent eux-mêmes leurs modèles à l'aide de diverses mesures, et selon ces mesures, le service peut même être aussi précis que possible, mais la réalité est que le modèle n'est pas toujours en mesure de prendre en compte diverses nuances de production et goulots d'étranglement. Ensuite, la logique de l'apprentissage automatique commence à devenir un code dur.
À cet égard, nous commençons à faire face à un certain nombre de problèmes:
- Notre modèle d'optimisation tient-il toujours compte d'éventuelles contraintes de production?
- Nos modèles sont-ils capables de fonctionner avec des goulots d'étranglement?
- Notre modèle est-il capable de répondre correctement aux changements de production?
C'est là que nous avons décidé de concentrer l'équipe de test.
Notre tâche consiste à unifier les pratiques de test ML afin de pouvoir répondre à tous les problèmes ci-dessus. Pour le moment, nous sommes parvenus à un certain nombre de conclusions, et maintenant je vais vous dire lesquelles.
Tester la conformité aux restrictions et exigences de production pour leur prise en compte par l'algorithme d'optimisation
Dans les tests classiques, dans tout test, nous avons toujours un «résultat attendu». Nous savons parfaitement quelle devrait être la réaction du système sur l'une ou l'autre des données d'entrée. Cependant, si nous parlons de ML dans les environnements de production, ce résultat le plus attendu peut être la conformité aux documents réglementaires, tels que les GOST, les instructions technologiques et les organigrammes temporaires, qui limitent à la fois les processus de production eux-mêmes et les critères de qualité du produit final. Lors de leurs tests, nous devons être sûrs que toutes ces restrictions sont effectivement respectées, et malgré leur nombre, nous sommes sûrs que chacune d'entre elles est couverte par des cas de test.
Sur l'exemple d'un véritable projet d'optimisation de la production de matériaux N (nous n'avons pas encore divulgué le cas, nous utiliserons donc des noms anonymes), nous avons résolu ce problème comme suit:
- Nous avons classé toutes les catégories de mélanges de matériaux N par le niveau d'éléments chimiques qu'ils contiennent. En conséquence, nous avons obtenu une liste, que nous avons plus tard prévu d'utiliser comme aide pour assurer une couverture de test suffisante.
- Nous étions convaincus que les recommandations émises par le modèle pour tous ces mélanges étaient en fait acceptées inconditionnellement par les technologues de production et avons enregistré le résultat de ce problème dans un fichier CSV. Ainsi, nous avons reçu des recommandations du système d'un certain «gold standard».
- Ensuite, un script a été écrit qui a parcouru la liste de nos mélanges de référence à travers le modèle de version en version et a comparé le résultat de sa livraison avec ce qui était stocké dans notre csv «étalon-or».
- Si aucun changement dans le comportement du modèle n'était détecté, les tests de régression pourraient être considérés comme réussis. Sinon, un «débriefing» a été mené.
Ainsi, nous avons pu résoudre le problème des tests de régression et gagner la confiance que les changements introduits dans le modèle n'affectent pas les résultats antérieurs de notre travail.
Des tests axés sur les goulots d'étranglement
Les modèles d'optimisation sont mieux à même de prédire ce qui se trouve le plus souvent dans les données historiques et, inversement, un modèle peut «se transformer en citrouille» dès qu'il rencontre quelque chose d'inhabituel pour lui-même.
Souvent, dans de tels cas, le service d'optimisation doit «inviter» un modèle de comportement adéquat et cela génère le code dur que j'ai écrit plus tôt. Mais comment identifier ces goulots d'étranglement et déboguer le service? J'en parlerai sur l'exemple du développement d'un service de recommandations sur la gestion de la production du matériau N (le cas n'est pas encore sujet à divulgation, donc les noms voilés sont mentionnés ci-dessous).
Tout d'abord, notre architecte a développé un émulateur d'intégration qui a généré des données similaires à productives et a ainsi rempli le cadre de date, sur la base duquel le modèle d'optimisation a émis des recommandations pour le traitement du matériau N. Ensuite, le testeur a analysé ces recommandations et identifié les plus suspectes - celles qui ont été éliminées. paramètres de débit massique total recommandés. Déjà à ce stade, nous avons pu identifier de nombreux problèmes lorsque le modèle d'une manière ou d'une autre ne pouvait pas traiter correctement le flux de données entrant. Cela nous a permis de stabiliser l'état du service et de passer à l'étape suivante.
La deuxième étape était le test «Silence». Le service a été relevé dans l'environnement de production en arrière-plan. Il a travaillé sans distraire l'opérateur de traitement des matériaux N de la commande de la machine, et nous avons à notre tour collecté des «solutions d'opérateur», en les comparant avec ce que le service recommandait. Pour cette raison, nous avons trouvé les angles morts du modèle qui ne pouvaient pas être rattrapés à l'étape précédente.
Le modèle doit pouvoir répondre aux changements de production.
Nous avons un portefeuille de services dans notre portefeuille de projets pour optimiser la production de matériaux combustibles. L'essence du service est que le technologue transfère le stock des composants de production au modèle, définit les indicateurs limitants de la qualité du produit et définit le plan de production nécessaire, et en réponse reçoit une recommandation: dans quelles proportions il a besoin d'utiliser certains composants afin d'obtenir le carburant de la quantité spécifiée la qualité.
Dans le processus de développement de ce service, nous avons rencontré un curieux problème que nous ne pouvions pas prévoir à l'avance.
Pendant plusieurs années, l'entreprise dans la production de carburant a travaillé dans une certaine gamme de révolutions globales et en même temps utilisé plus / moins le même rapport de composants.
Mais récemment, l'organisation a modifié l'offre de ces composants et il est devenu possible de compenser ce fait en augmentant la vitesse des unités. Le client s'attendait à ce que le modèle puisse répondre à ces changements, donc du point de vue de la production technologique - c'est une solution acceptable, mais cela ne s'est pas produit. Pourquoi? La réponse est évidente: le modèle a été formé sur un échantillon historique, ce qui n'était pas le cas auparavant. Vous pouvez parler longtemps de la question de savoir qui a raison dans cette situation et qui est à blâmer, mais à l'avenir, nous avons prévu de réduire la probabilité de telles situations comme suit:
- Travailler plus étroitement avec le représentant client de l'unité de production pour identifier les goulots d'étranglement et les changements potentiels de produit.
- Couvrir les cas de test avec des cas similaires à l'avance.
- Rédiger des autotests pour vérifier la conformité aux restrictions de production et la corrélation des signes.
Quelques mots sur les outils de test que nous avons dû utiliser:
- suivi des bogues - Jira,
- système de gestion de la qualité - Test Rail,
- système de contrôle de version - GitLab,
- CI / CD - Jenkins,
- autotests - Java + Junit / TestNG,
- scripts d'interaction directe avec le modèle - Python + Jupyter.
Testez-vous le ML?
Pour nous, la construction d'une pratique de test de ML est devenue un défi, elle a dû être développée à partir de zéro. Mais les tests sont nécessaires - ils aident à réduire le nombre d'erreurs avant de passer en mode d'essai et à raccourcir le temps de mise en œuvre.
Aujourd'hui, nous devons tous partager et échanger nos expériences. Nous devons entamer des discussions sur les tests sur des sites spécialisés et des forums professionnels, qui, soit dit en passant, deviennent de plus en plus dans le domaine du ML. Et si vous avez déjà établi des pratiques pour tester le ML, je pense que tout le monde sera intéressé à en lire plus, alors partagez votre expérience dans les commentaires.
Sergey Agaltsov, responsable des tests, Jet Infosystems