Uber Michelangelo (plataforma de ML → GenAI)

01 · CONTEXTO

Antes da plataforma

Este estudo combina dois posts do blog de engenharia da Uber: um publicado em 5 de setembro de 2017 e outro que percorre oito anos de trajetória do Michelangelo.

O Michelangelo é, nas palavras dos autores, uma plataforma interna de aprendizado de máquina como serviço, desenhada para cobrir o fluxo de ponta a ponta: gerenciar dados, treinar, avaliar e implantar modelos, fazer predições e monitorá-las.

Antes dela, cientistas de dados usavam uma grande variedade de ferramentas para criar modelos, enquanto times de engenharia separados construíam sistemas sob medida para usá-los em produção. Não havia caminho estabelecido para implantar um modelo: na maioria dos casos, o time de engenharia precisava criar um contêiner de serving específico para o projeto. Também não era possível treinar modelos maiores do que cabiam nas máquinas de mesa dos cientistas de dados, nem havia um lugar padrão para guardar os resultados dos experimentos ou compará-los.

Segundo o primeiro post, a construção começou em meados de 2015, com foco em treino escalável e em levar modelos a contêineres de serving; depois vieram os sistemas para gerenciar e compartilhar pipelines de features e, mais recentemente, a produtividade do desenvolvedor. O segundo post diz que o Michelangelo foi lançado no início de 2016.

02 · O CICLO DE VIDA

Seis etapas, uma plataforma

Os autores organizam o trabalho em seis etapas: gerenciar dados, treinar modelos, avaliar, implantar, fazer predições e monitorá-las. Segundo o post, o mesmo fluxo existe em quase todos os casos de ML da Uber, de classificação e regressão a previsão de séries temporais.

A plataforma é construída sobre a infraestrutura de dados e computação da empresa: um data lake com os dados transacionais e de log, brokers Kafka, um motor de streaming Samza e clusters Cassandra gerenciados. Os principais componentes abertos citados são HDFS, Spark, Samza, Cassandra, MLLib, XGBoost e TensorFlow.

O exemplo que guia o post é o tempo estimado de entrega do UberEATS: cientistas de dados usam modelos de regressão com árvores de decisão com gradient boosting, implantados em contêineres de serving do Michelangelo e chamados por requisições de rede pelos microsserviços do UberEATS.

1. Os dados transacionais e de log chegam a um data lake em HDFS, acessível por jobs Spark e Hive. Jobs regulares calculam features, que podem ser privadas de um projeto ou publicadas no Feature Store.

2. No caminho batch precompute, as features históricas são carregadas do HDFS para o Cassandra, de onde podem ser lidas com baixa latência na hora da predição.

3. No caminho quase em tempo real, métricas vão para o Kafka e jobs Samza geram features agregadas com baixa latência; elas são gravadas direto no Cassandra e registradas de volta no HDFS para treinos futuros.

4. Para o treino, o sistema junta os conjuntos de dados corretos do HDFS; os jobs usam datasets do Feature Store e do repositório de dados de treino e enviam o modelo ao repositório de modelos. Ao fim do treino, são salvos a configuração original, os parâmetros aprendidos e o relatório de avaliação.

5. Os artefatos do modelo são empacotados num arquivo ZIP e copiados para os hosts; os contêineres de serving carregam o novo modelo do disco e passam a atender predições.

6. Na predição online, o contêiner passa as features brutas pelas expressões DSL, busca features adicionais no Feature Store, com os valores lidos do Cassandra, e devolve a predição ao serviço cliente pela rede.

03 · FEATURES

Feature store e consistência entre treino e serving

Modelos implantados online não acessam dados guardados no HDFS. Por isso, as features de que eles precisam são pré-calculadas e guardadas no Cassandra, de onde podem ser lidas com baixa latência na hora da predição. Há duas formas de calculá-las:

A segunda peça da consistência é a DSL de seleção e transformação de features, um subconjunto de Scala. As expressões fazem parte da configuração do modelo e são aplicadas no treino e na predição, o que ajuda a garantir que o mesmo conjunto final de features seja gerado e enviado ao modelo nos dois casos. O segundo post acrescenta que empacotar a transformação com o modelo como um Spark PipelineModel elimina uma fonte de training-serving skew.

Sobre esses pipelines fica o feature store: para entrar nele, uma feature precisa de poucos metadados extras (dono, descrição, SLA e outros) e depois é consumida online e offline pelo nome canônico na configuração do modelo. O sistema junta os conjuntos de dados corretos do HDFS no treino e busca o valor certo no Cassandra na predição online.

O primeiro post fala em cerca de 10 mil features no Feature Store. O segundo dá o nome Palette ao feature store construído para gerenciar e compartilhar pipelines de features entre times, com suporte a cálculo em lote e quase em tempo real, e diz que ele hospeda mais de 20 mil features.

04 · REGISTRO E DEPLOY

Registro de modelos e implantação

Cada modelo treinado vira um objeto versionado no repositório de modelos, guardado no Cassandra. O registro inclui quem treinou o modelo, a configuração completa (features usadas, valores de hiperparâmetros e outros), a referência aos conjuntos de treino e teste e as métricas de acurácia; a interface web e a API servem tanto para inspecionar um modelo quanto para compará-lo com outros.

No segundo post, o Gallery aparece como o registro de modelos e de metadados de ML, com uma API de busca para todos os tipos de entidade de ML.

O Michelangelo oferece três modos de implantação:

Em todos os casos, os artefatos do modelo (arquivos de metadados, de parâmetros e expressões DSL compiladas) são empacotados num arquivo ZIP e copiados para os hosts relevantes nos data centers; os contêineres de predição carregam os novos modelos do disco automaticamente.

Mais de um modelo pode estar implantado ao mesmo tempo no mesmo contêiner, o que permite transições seguras do modelo antigo para o novo e testes A/B lado a lado. Em tempo de serving, o modelo é identificado pelo UUID e por uma tag opcional definida no deploy. Se os dois modelos têm a mesma assinatura (esperam o mesmo conjunto de features), o novo pode ser implantado na mesma tag do antigo: o contêiner passa a usá-lo imediatamente, sem exigir mudança no código do cliente.

05 · PREDIÇÃO E MONITORAMENTO

Servir, escalar e vigiar

Na predição, as features brutas passam pelas expressões DSL compiladas, que podem modificá-las e buscar outras no Feature Store. Modelos online devolvem a predição ao serviço cliente pela rede; modelos offline gravam as predições no Hive, onde jobs em lote ou usuários com ferramentas SQL podem consumi-las.

Como os modelos são stateless e não compartilham estado, escalar é simples: no modo online, basta adicionar hosts ao cluster e deixar o balanceador distribuir a carga; no offline, adicionar executores Spark. O post de 2017 relata latência P95 típica menor que 5 ms para modelos que não precisam do Cassandra e menor que 10 ms para os que precisam, e modelos de maior tráfego servindo mais de 250 mil predições por segundo.

Treino e avaliação usam sempre dados históricos. Por isso é crítico monitorar as predições: para garantir que os pipelines continuam enviando dados corretos e que o ambiente de produção não mudou a ponto de o modelo deixar de ser preciso. O Michelangelo pode registrar e, opcionalmente, reter um percentual das predições e depois juntá-las aos resultados observados; para regressão, publica R-quadrado, RMSLE, RMSE e erro absoluto médio nos sistemas de séries temporais da Uber, onde os usuários analisam gráficos e definem alertas.

Por cima fica a camada de API: uma aplicação de gerenciamento que serve a interface web e a API de rede e abriga o sistema de workflow, que orquestra pipelines de dados em lote, jobs de treino, jobs de predição em lote e a implantação de modelos em contêineres de lote e online.

Para comparar com o post de 2017: o segundo post reporta cerca de 400 projetos de ML ativos, mais de 20 mil jobs de treino por mês, mais de 5 mil modelos em produção e 10 milhões de predições em tempo real por segundo no pico.

06 · MICHELANGELO 2.0

Planos, qualidade e experiência do desenvolvedor

Segundo o segundo post, até o fim de 2019 a maioria das linhas de negócio da Uber já havia integrado ML, e o foco do Michelangelo começou a passar de habilitar ML em todo lugar para dobrar a aposta em projetos de ML de alto impacto.

O post lista limitações do Michelangelo 1.0 para esses projetos: falta de uma definição abrangente de qualidade de ML e de tiering de projetos; suporte insuficiente a modelos de aprendizado profundo; suporte inadequado ao desenvolvimento colaborativo de modelos; e ferramentas e experiência de desenvolvedor fragmentadas.

O Michelangelo 2.0 organiza o sistema em três planos. O plano de controle define as APIs voltadas ao usuário e gerencia o ciclo de vida das entidades; o plano de dados offline faz o trabalho pesado de processamento, como cálculo de features, treino e avaliação de modelos e inferência em lote; o plano de dados online cuida da inferência em tempo real e do serviço de features, usados por outros microsserviços.

1. O plano de controle define as APIs voltadas ao usuário e gerencia o ciclo de vida de todas as entidades; as APIs seguem as convenções da API do Kubernetes e padronizam operações sobre Project, Pipeline, Model, Deployment e outras entidades.

2. O plano de dados offline faz o trabalho pesado, como cálculo de features, treino e avaliação de modelos e inferência em lote; seus pipelines são definidos como DAGs de passos.

3. O Gallery é o registro de modelos e de metadados de ML, com uma API de busca para todos os tipos de entidade de ML.

4. O plano de dados online cuida da inferência em tempo real e do serviço de features, usados por outros microsserviços; ele gerencia serviços RPC e jobs de streaming para predição online, acesso a features e cálculo quase em tempo real.

5. O Model Excellence Score (MES) mede e monitora dimensões e métricas de qualidade em cada etapa do ciclo de vida do modelo, usando o conceito de SLA comum entre SREs.

Para medir qualidade, o post descreve o Model Excellence Score (MES), um framework para medir e monitorar dimensões e métricas em cada etapa do ciclo de vida do modelo, baseado no conceito de SLA usado por SREs. Para priorizar, há um esquema de tiering com quatro níveis, com o nível 1 como o mais alto; os projetos de nível 1 reúnem modelos que atendem funções críticas dos fluxos centrais de viagens e de pedidos, como cálculo de ETA, segurança e detecção de fraude.

Em 2020 foi lançado o Project Canvas, que aplica boas práticas de engenharia de software ao desenvolvimento de ML; um de seus componentes é o ML Monorepo, repositório central que guarda como código as fontes de verdade do desenvolvimento de ML, com controle de versão. O MA Studio unifica as ofertas existentes e as novas num único fluxo e inclui uma pilha moderna de implantação, com rollout zonal seguro e incremental, gatilhos automáticos de rollback e validação em runtime de produção.

Para aprendizado profundo, a transformação de features, que no 1.0 era empacotada com o modelo e eliminava uma fonte de training-serving skew, ganhou no 2.0 uma solução nativa com operadores Keras ou PyTorch. Os treinadores de XGBoost e de DL baseados em Spark foram trocados por treinadores baseados em Ray, o serving passou a integrar o Triton ao Online Prediction Service, e a adoção de DL em projetos tier-1 foi de quase zero para mais de 60%.

07 · DO PREDITIVO AO GENAI

Gateway, LLMOps e lições

O segundo post divide a trajetória em três fases: a primeira, de 2016 a 2019, foi de ML preditivo para dados tabulares; a segunda, de 2019 a 2023, empurrou a adoção de DL e o desenvolvimento colaborativo de modelos em projetos de alto impacto; a terceira começa em 2023, com a nova onda de IA generativa.

Para IA generativa, a Uber criou o Gen AI Gateway, uma interface unificada para acessar LLMs externos e hospedados internamente. Entre suas capacidades estão log e auditoria, guardrails de custo e atribuição, guardrails de segurança e política e redação de PII antes de enviar a entrada a LLMs externos. Os dois tipos de modelo coexistem porque, segundo o post, os externos têm desempenho superior em conhecimento geral e raciocínio complexo, enquanto modelos abertos ajustados com dados próprios atendem tarefas específicas da Uber a uma fração do custo e com menor latência.

O Michelangelo foi estendido para cobrir as capacidades de LLMOps: preparação de dados de ajuste fino, engenharia de prompts, ajuste fino e avaliação, implantação e serving, e monitoramento de desempenho em produção. O Model Catalog reúne LLMs prontos para uso, e um treinador para LLMs baseado em Ray usa os modelos abertos do Hugging Face Hub; os LLMs ajustados e seus metadados ficam no repositório de modelos, acessível à infraestrutura de inferência.

1. As aplicações chamam o Gen AI Gateway, que oferece uma interface unificada para acessar LLMs externos e LLMs hospedados internamente, respeitando padrões de segurança e protegendo a privacidade.

2. O gateway reúne log e auditoria, guardrails de custo e atribuição, guardrails de segurança e política e redação de PII antes de enviar a entrada a LLMs externos.

3. Os dois destinos coexistem: segundo o post, modelos externos têm desempenho superior em conhecimento geral e raciocínio complexo, enquanto modelos abertos ajustados com dados próprios atendem tarefas específicas da Uber a uma fração do custo e com menor latência.

4. O ajuste fino roda num treinador baseado em Ray sobre LLMs abertos do Hugging Face; os LLMs ajustados e seus metadados ficam no repositório de modelos, acessível à infraestrutura de inferência.