A Ramp reduziu a implantação de modelos de ML de 4 meses para 5 minutos com um sistema de configuração em YAML

O primeiro modelo de risco de crédito da Ramp levou quase quatro meses e mais de 3.000 linhas de código para entrar em produção. Como empresa de serviços financeiros, a Ramp também precisava que os resultados de cada modelo fossem exatamente reproduzíveis sob demanda, algo que o código de implantação sob medida e pontual tornava difícil de garantir. As discussões sobre aprendizado de máquina tendem a se concentrar no modelo em si, mas o tempo de engenharia era na verdade dominado pelo 'pipeline de features' — o código que limpa, converte e transforma dados brutos em entradas utilizáveis — que a equipe estimou representar 99% do trabalho real.

A equipe de engenharia da Ramp criou o Turbo, um sistema de configuração baseado em YAML, para padronizar isso. Eles identificaram as entidades compartilhadas por todo fluxo de trabalho de ML: um Pipeline de Features (dados brutos para features) e um Pipeline de Modelo (features para previsões). Uma classe 'JobSpec' lê um arquivo YAML, materializa esses elementos como objetos Pydantic e os envia para um ambiente de computação — um Train Job, que ajusta um novo modelo, ou um Predict Job, que carrega um modelo do armazenamento de modelos. Como ambos os jobs compartilham o mesmo esquema, implantar um modelo é quase como copiar um arquivo de configuração e editar algumas linhas.

O retorno foi imediato: pipelines descritos em um arquivo de configuração hoje produzirão os mesmos resultados se executados novamente daqui a um ou dois anos, desde que os dados subjacentes não tenham mudado, resolvendo diretamente o requisito de reprodutibilidade. Um modelo de previsão de séries temporais migrado também passou a ter tratamento consistente de feriados em todos os casos de graça, já que todo modelo construído com a abstração herda a mesma lógica de engenharia de features em vez de reimplementá-la de forma independente.

Transformar todo pipeline de ML em duas peças reutilizáveis (features, modelo) descritas em um único arquivo YAML

Separar o Pipeline de Features do Pipeline de Modelo como entidades reutilizáveis significou que os 99% do trabalho de ML que não é modelagem precisaram ser resolvidos apenas uma vez.

Um esquema YAML declarativo, em vez de uma biblioteca de código, significou que engenheiros sem formação em ML podiam implantar e manter modelos sem escrever eles próprios o código do pipeline.

Treinamento e previsão compartilharem um único esquema significou que um desenvolvedor só precisava aprender um conjunto de conceitos para fazer ambos, em vez de ferramentas separadas para cada etapa.

Padronizar a engenharia de features (por exemplo, o tratamento de feriados em modelos de séries temporais) corrigiu de uma vez toda uma classe de bugs de inconsistência, em vez de corrigir cada modelo separadamente.

Quando a mesma forma de pipeline em duas etapas se repete entre sistemas, codifique-a uma vez como um esquema declarativo — isso transforma uma tarefa de vários meses, restrita a especialistas, em algo que qualquer engenheiro pode preencher.

Quando a Ramp escreveu sobre o Turbo, um novo modelo podia ser implantado em menos de 5 minutos com uma média de cerca de 40 linhas de YAML, contra 4 meses e mais de 3.000 linhas de código. Quase 20 modelos estavam em produção, construídos por 9 desenvolvedores diferentes, muitos dos quais nunca tinham treinado ou implantado um modelo de aprendizado de máquina antes de o Turbo existir.