Le premier modèle de risque de crédit de Ramp a nécessité près de quatre mois et plus de 3 000 lignes de code pour être mis en production. En tant qu'entreprise de services financiers, Ramp devait également que les sorties de chaque modèle soient exactement reproductibles à la demande, ce que du code de déploiement sur mesure et ponctuel rendait difficile à garantir. Les discussions sur l'apprentissage automatique ont tendance à se concentrer sur le modèle lui-même, mais le temps d'ingénierie était en réalité dominé par le « pipeline de caractéristiques » — le code qui nettoie, convertit et transforme les données brutes en entrées utilisables — que l'équipe estimait représenter 99 % du travail réel.

L'équipe d'ingénierie de Ramp a construit Turbo, un système de configuration basé sur YAML, pour standardiser cela. Ils ont identifié les entités partagées par chaque flux de travail ML : un pipeline de caractéristiques (données brutes vers caractéristiques) et un pipeline de modèle (caractéristiques vers prédictions). Une classe « JobSpec » lit un fichier YAML, matérialise ces éléments sous forme d'objets Pydantic et les soumet à un environnement de calcul — une tâche d'entraînement qui ajuste un nouveau modèle, ou une tâche de prédiction qui en charge un depuis le magasin de modèles. Comme les deux tâches partagent le même schéma, déployer un modèle revient presque à copier un fichier de configuration et à en modifier quelques lignes.

Le gain a été immédiat : les pipelines décrits dans un fichier de configuration aujourd'hui produiront les mêmes résultats s'ils sont exécutés à nouveau dans un ou deux ans, tant que les données sous-jacentes n'ont pas changé, ce qui répond directement à l'exigence de reproductibilité. Un modèle de prévision de séries temporelles migré a également bénéficié gratuitement d'une gestion cohérente des jours fériés, puisque chaque modèle construit avec l'abstraction hérite de la même logique d'ingénierie des caractéristiques au lieu de la réimplémenter indépendamment.

Transformer chaque pipeline ML en deux éléments réutilisables (caractéristiques, modèle) décrits dans un seul fichier YAML

Séparer le pipeline de caractéristiques du pipeline de modèle en tant qu'entités réutilisables signifiait que les 99 % du travail ML qui ne relève pas de la modélisation ne devaient être résolus qu'une seule fois.

Un schéma YAML déclaratif, plutôt qu'une bibliothèque de code, signifiait que des ingénieurs sans formation en ML pouvaient déployer et maintenir des modèles sans écrire eux-mêmes du code de pipeline.

Le partage d'un même schéma entre l'entraînement et la prédiction signifiait qu'un développeur n'avait qu'un seul ensemble de concepts à apprendre pour faire les deux, au lieu d'outils distincts pour chaque étape.

La standardisation de l'ingénierie des caractéristiques (par exemple, la gestion des jours fériés dans les modèles de séries temporelles) a corrigé toute une classe de bogues d'incohérence d'un coup au lieu de corriger chaque modèle séparément.

Lorsque la même forme de pipeline en deux étapes se répète à travers les systèmes, l'encoder une fois sous forme de schéma déclaratif — cela transforme une tâche réservée aux experts et longue de plusieurs mois en quelque chose que tout ingénieur peut remplir.

Au moment où Ramp a écrit sur Turbo, un nouveau modèle pouvait être déployé en moins de 5 minutes avec une moyenne d'environ 40 lignes de YAML, contre 4 mois et plus de 3 000 lignes de code auparavant. Près de 20 modèles étaient en production, construits par 9 développeurs différents, dont beaucoup n'avaient jamais entraîné ni déployé de modèle d'apprentissage automatique avant l'existence de Turbo.

VÉRIFIEZ LES SOURCES

Les sources

  1. Turbo-Charging ML Development Ramp Engineering (Builders Blog) · builders.ramp.com ·