Machine Learning sur Big Data

Nous concevons des plateformes ML autour d'un petit ensemble de principes : les caractéristiques doivent être définies une seule fois et réutilisées ; les expériences doivent être reproductibles par défaut ; les modèles doivent être versionnés et enregistrés avant d'atteindre la production ; et les chemins d'inférence doivent être observables de la même manière que les services sous-jacents. Les principes ne sont pas nouveaux ; la discipline de les appliquer de manière cohérente est ce qui distingue les plateformes qui se développent de celles qui se figent.

Notre boîte à outils préférée varie selon l'environnement. Nous avons construit autour d'offres gérées telles que Databricks, SageMaker, Vertex AI et Azure ML, autour de piles open-source (MLflow, Feast, Ray, Kubeflow, Argo) sur Kubernetes, et autour d'hybrides des deux. Le choix est dicté par vos investissements existants, le confort opérationnel de votre équipe et le profil de latence des charges de travail en question.

À travers tout cela, nous insistons sur quelques incompressibles : chaque artefact (jeu de données, jeu de caractéristiques, modèle) est identifié par un hachage adressable par son contenu ; chaque promotion entre environnements est journalisée avec l'historique des entrées et les résultats des tests qui l'ont justifiée ; et chaque modèle en production est associé à un moniteur qui sait ce qu'est un bon fonctionnement.

• Pipelines d'entraînement reproductibles
• Stores de caractéristiques avec parité en ligne et hors ligne
• Stores vectoriels pour la récupération et la similarité
• Registre de modèles, staging et rollback
• Surveillance de la dérive, des performances et des coûts
• Entraînement et inférence soucieux des coûts

L'entraînement distribué est moins souvent justifié qu'il n'est tenté. Beaucoup de nos clients sont convaincus qu'ils ont besoin d'un cluster multi-nœuds, pour découvrir ensuite qu'un modèle à gradient boosting bien réglé sur une seule grande machine est plus performant pour moins d'argent et moins de problèmes opérationnels. Nous commençons par établir une base solide sur une seule machine, et nous n'évoluons horizontalement que lorsque les données, l'architecture du modèle ou les objectifs de latence l'exigent clairement.

Lorsque la distribution est réellement nécessaire — pour le fine-tuning de modèles fondamentaux, pour les recommenders profonds distribués, ou pour de très grands espaces de caractéristiques — nous utilisons Ray, PyTorch DDP, DeepSpeed, Spark MLlib ou Horovod selon le cas, et nous portons une attention particulière au chemin des données. L'entraînement distribué, qui est limité par le stockage ou le brassage, est un mode de défaillance malheureusement courant, et son remède implique rarement plus de GPU.

La reproductibilité est traitée comme une propriété du pipeline d'entraînement, et non comme une aspiration pleine d'espoir. Les graines aléatoires, les versions de bibliothèque, les définitions d'environnement, les instantanés de données et les hyperparamètres sont tous capturés automatiquement et liés à l'artefact modèle résultant. Trois mois plus tard, lorsqu'un régulateur ou un analyste demande pourquoi le modèle se comporte de telle manière, la piste est intacte.

“Plus de GPU est rarement la solution ; une meilleure infrastructure de données l'est généralement.”

L'architecture d'inférence est dictée par le consommateur, et non par le modèle. Un score de risque qui informe une décision de lot une fois par jour nécessite une plateforme différente d'une recommandation en temps réel servie au quatre-vingt-dix-neuvième centile en moins de dizaines de millisecondes. Nous concevons les chemins de service en fonction des exigences de latence, de débit et de fraîcheur du consommateur, et nous ne sommes pas sentimentaux quant à la réutilisation de l'infrastructure entre les cas d'utilisation lorsque cela a du sens.

Pour l'inférence en temps réel, nous utilisons généralement une combinaison d'un magasin de fonctionnalités avec un service en ligne, un serveur de modèles (Triton, BentoML, KServe ou un équivalent géré) et un cache côté requête si nécessaire. Pour l'inférence par lots, nous nous appuyons sur le même cluster d'entraînement, avec une fenêtrage déterministe et les mêmes contrôles de lignage que les pipelines en amont. Pour l'inférence en flux, nous intégrons le modèle directement dans la topologie de traitement de flux, en notant les événements en cours.

Nous accordons une attention particulière aux coûts à ce niveau, car c'est là que les projets d'apprentissage automatique deviennent le plus souvent coûteux. La quantification, la distillation, le traitement par lots, la fusion des requêtes, l'auto-dimensionnement en fonction des signaux de demande réels et la volonté d'utiliser des modèles plus petits lorsqu'ils sont suffisants réduisent régulièrement le coût d'inférence d'un ordre de grandeur sans perte mesurable de précision.

Un modèle en production est un artefact vivant. Les données changent, les concepts évoluent, les services en amont se modifient et les consommateurs en aval trouvent de nouvelles façons d'utiliser le résultat. Nous concevons des systèmes d'apprentissage automatique en prévoyant qu'ils seront réentraînés des dizaines de fois au cours de leur vie utile, chaque réentraînement suivant le même chemin contrôlé et auditable que le premier déploiement.

La détection de dérive est activée par défaut — dérive des caractéristiques et dérive des étiquettes, lorsque les étiquettes sont disponibles — et est associée à des seuils d'action explicites. Certains modèles se réentraînent selon un calendrier ; d'autres se réentraînent sur signal ; le choix dépend de la manière dont les étiquettes arrivent et du coût d'un modèle obsolète. Dans tous les cas, le réentraînement produit un nouveau candidat qui concourt avec le titulaire sur le même harnais d'évaluation, et le gagnant est promu selon les mêmes contrôles de publication utilisés à l'origine.

Lorsque les modèles sont exposés à des conditions adverses — fraude, abus, jeux — nous ajoutons le 'red-teaming' et le déploiement en 'shadow' comme pratique courante. Le trafic de production est acheminé vers le modèle en direct et un candidat, et le comportement du candidat est comparé en détail avant la promotion. La discipline est banale et la sécurité qu'elle procure est substantielle.

À travers nos engagements, le résultat le plus constant n'est pas un modèle unique – c'est une accélération mesurable du cycle de vie du ML. Les clients qui avaient besoin de mois pour faire passer un modèle du carnet à la production le font désormais en semaines. Les modèles qui nécessitaient auparavant une équipe dédiée pour fonctionner, s'exécutent silencieusement entre les révisions de routine. La capacité qui était consommée à maintenir ce qui existait déjà est libérée pour construire ce qui vient ensuite.

Le deuxième résultat constant est une courbe de coûts défendable. Parce que le travail sur les caractéristiques est réutilisé, parce que l'inférence est de taille appropriée, parce que le calcul est surveillé comme une préoccupation de premier ordre, le coût marginal du prochain cas d'usage ML diminue. C'est la propriété qui distingue une plateforme d'un portefeuille de pilotes.