Ramp redujo el despliegue de modelos de ML de 4 meses a 5 minutos con un sistema de configuración YAML

El primer modelo de riesgo crediticio de Ramp tardó casi cuatro meses y más de 3000 líneas de código en llegar a producción. Como empresa de servicios financieros, Ramp también necesitaba que los resultados de cada modelo fueran exactamente reproducibles a demanda, algo que el código de despliegue hecho a medida y puntual dificultaba garantizar. Las conversaciones sobre aprendizaje automático suelen centrarse en el propio modelo, pero el tiempo de ingeniería lo dominaba en realidad el «pipeline de características» —el código que limpia, convierte y transforma los datos brutos en entradas utilizables—, que el equipo estimó que representaba el 99 % del trabajo real.

El equipo de ingeniería de Ramp creó Turbo, un sistema de configuración basado en YAML, para estandarizar esto. Identificaron las entidades compartidas por todo flujo de trabajo de ML: un Pipeline de Características (datos brutos a características) y un Pipeline de Modelo (características a predicciones). Una clase «JobSpec» lee un archivo YAML, materializa estas como objetos Pydantic y los envía a un entorno de cómputo: un Train Job que ajusta un nuevo modelo, o un Predict Job que carga uno desde el almacén de modelos. Como ambos trabajos comparten el mismo esquema, desplegar un modelo se acerca a copiar un archivo de configuración y editar unas pocas líneas.

El beneficio fue inmediato: los pipelines descritos en un archivo de configuración hoy producirán los mismos resultados si se ejecutan de nuevo dentro de uno o dos años, siempre que los datos subyacentes no hayan cambiado, lo que resuelve directamente el requisito de reproducibilidad. Un modelo de previsión de series temporales migrado también adquirió de forma gratuita un tratamiento coherente de los días festivos en todos los casos, ya que cada modelo construido con la abstracción hereda la misma lógica de ingeniería de características en lugar de reimplementarla de forma independiente.

Convertir cada pipeline de ML en dos piezas reutilizables (características, modelo) descritas en un único archivo YAML

Separar el Pipeline de Características del Pipeline de Modelo como entidades reutilizables hizo que el 99 % del trabajo de ML que no es modelado solo tuviera que resolverse una vez.

Un esquema YAML declarativo, en lugar de una biblioteca de código, hizo que los ingenieros sin formación en ML pudieran desplegar y mantener modelos sin escribir ellos mismos código de pipeline.

Que el entrenamiento y la predicción compartieran un mismo esquema hizo que un desarrollador solo tuviera que aprender un conjunto de conceptos para hacer ambas cosas, en lugar de herramientas separadas para cada etapa.

Estandarizar la ingeniería de características (por ejemplo, el tratamiento de días festivos en modelos de series temporales) corrigió toda una clase de errores de inconsistencia de una vez, en lugar de parchear cada modelo por separado.

Cuando la misma forma de pipeline de dos etapas se repite en distintos sistemas, codifícala una vez como un esquema declarativo: convierte una tarea de varios meses reservada a expertos en algo que cualquier ingeniero puede rellenar.

Cuando Ramp escribió sobre Turbo, un nuevo modelo podía desplegarse en menos de 5 minutos con un promedio de unas 40 líneas de YAML, frente a los 4 meses y más de 3000 líneas de código anteriores. Había casi 20 modelos en producción, construidos por 9 desarrolladores distintos, muchos de los cuales nunca habían entrenado ni desplegado un modelo de aprendizaje automático antes de que existiera Turbo.