Aprendizagem Automática em Big Data

Desenhamos plataformas de ML com base num pequeno conjunto de princípios: as características devem ser definidas uma vez e reutilizadas; as experiências devem ser reproduzíveis por padrão; os modelos devem ser versionados e registados antes de chegarem à produção; e os caminhos de inferência devem ser observáveis da mesma forma que os serviços subjacentes. As opiniões não são novas; a disciplina de as aplicar consistentemente é o que distingue plataformas que se desenvolvem de plataformas que calcificam.

O nosso conjunto de ferramentas preferido varia por ambiente. Construímos em torno de ofertas geridas como Databricks, SageMaker, Vertex AI e Azure ML, em torno de pilhas de código aberto (MLflow, Feast, Ray, Kubeflow, Argo) em Kubernetes, e em torno de híbridos dos dois. A escolha é ditada pelos seus investimentos existentes, pelo conforto operacional da sua equipa e pelo perfil de latência das cargas de trabalho em questão.

Em todas estas insistimos em alguns aspetos inegociáveis: cada artefacto (conjunto de dados, conjunto de características, modelo) é identificado por um hash endereçável por conteúdo; cada promoção entre ambientes é registada com a linhagem das entradas e os resultados dos testes que a justificaram; e cada modelo em produção é emparelhado com um monitor que sabe o que é um bom desempenho.

• Pipelines de treino reproduzíveis
• Feature stores com paridade online e offline
• Vector stores para recuperação e similaridade
• Registo de modelos, faseamento e reversão
• Monitorização de desvio, desempenho e custos
• Treino e inferência com consciência de custos

O treino distribuído é justificado com menos frequência do que é tentado. Muitos dos nossos clientes chegam convencidos de que precisam de um cluster multi-nó, apenas para descobrir que um modelo de gradiente-impulsionado bem ajustado numa única máquina grande supera-o por menos dinheiro e menos dor operacional. Começamos por estabelecer uma linha de base forte de uma única máquina, e escalamos apenas quando os dados, a arquitetura do modelo ou os alvos de latência o exigem claramente.

Quando a distribuição é genuinamente necessária — para afinação de modelos de base, para recomendadores profundos distribuídos, ou para espaços de características muito grandes — usamos Ray, PyTorch DDP, DeepSpeed, Spark MLlib ou Horovod conforme apropriado, e prestamos muita atenção ao caminho dos dados. O treino distribuído que é estrangulado pelo armazenamento ou shuffle é um modo de falha comum e deprimente, e cuja cura raramente envolve mais GPUs.

A reprodutibilidade é tratada como uma propriedade do pipeline de treino, não como uma aspiração esperançosa. Sementes aleatórias, versões de biblioteca, definições de ambiente, snapshots de dados e hiperparâmetros são todos capturados automaticamente e ligados ao artefacto do modelo resultante. Três meses depois, quando um regulador ou um analista pergunta por que o modelo se comporta da forma como se comporta, o rasto está intacto.

“Mais GPUs raramente são a resposta; uma melhor canalização de dados geralmente é.”

A arquitetura de inferência é ditada pelo consumidor, não pelo modelo. Uma pontuação de risco que informa uma decisão em lote uma vez por dia quer uma plataforma diferente de uma recomendação em tempo real servida no noventa e nono percentil em dezenas de milissegundos. Desenhamos caminhos de serviço em torno dos requisitos de latência, débito e atualização do consumidor, e somos insensíveis à reutilização de infraestruturas em casos de uso quando faz sentido.

Para inferência em tempo real, usamos tipicamente uma combinação de um feature store com serviço online, um servidor de modelos (Triton, BentoML, KServe ou equivalente gerido) e um cache do lado do pedido quando apropriado. Para inferência em lote, contamos com o mesmo cluster de treino, com janelamento determinístico e os mesmos controlos de linhagem que os pipelines a montante. Para inferência de streaming, integramos o modelo diretamente na topologia de processamento de streaming, pontuando eventos em voo.

Prestamos muita atenção ao custo nesta camada porque é onde os projetos de ML mais fiávelmente se tornam caros. Quantização, destilação, agrupamento, agregação de pedidos, dimensionamento automático em sinais de demanda reais e a vontade de usar modelos menores quando suficientes rotineiramente reduzem o custo de inferência em uma ordem de magnitude sem perda mensurável de precisão.

Um modelo em produção é um artefacto vivo. Os dados mudam, os conceitos mudam, os serviços a montante alteram-se, e os consumidores a jusante encontram novas formas de usar o output. Desenhamos sistemas de ML com a expectativa de que serão retreinados dezenas de vezes ao longo da sua vida útil, com cada retreino seguindo o mesmo caminho controlado e auditável da primeira implementação.

A deteção de desvio é integrada por padrão — tanto o desvio de características como o desvio de rótulos, onde os rótulos estão disponíveis — e é combinada com limiares explícitos para ação. Alguns modelos retreinam-se numa programação; outros retreinam-se num sinal; a escolha depende de como os rótulos chegam e quão caro é um modelo obsoleto. De qualquer forma, o retreino produz um novo candidato que compete com o incumbente no mesmo arnês de avaliação, e o vencedor é promovido sob os mesmos controlos de lançamento usados originalmente.

Onde os modelos são expostos a condições adversas — fraude, abuso, jogos — adicionamos testes de equipa vermelha e implementação sombra como prática padrão. O tráfego de produção flui tanto para o modelo em tempo real como para um candidato, e o comportamento do candidato é comparado em detalhe antes da promoção. A disciplina é mundana e a segurança que proporciona é substancial.

Em todos os nossos projetos, o resultado mais consistente não é um único modelo — é uma aceleração mensurável do ciclo de vida do ML. Clientes que precisavam de meses para levar um modelo do notebook à produção conseguem fazê-lo de forma fiável em semanas. Modelos que anteriormente exigiam uma equipa dedicada para operar funcionam silenciosamente entre revisões de rotina. A capacidade que costumava ser consumida mantendo o que já existe é libertada para construir o que vem a seguir.

O segundo resultado consistente é uma curva de custo defensável. Porque o trabalho de características é reutilizado, porque a inferência tem o tamanho certo, porque o cálculo é monitorizado como uma preocupação de primeira classe, o custo marginal do próximo caso de uso de ML diminui. Esta é a propriedade que distingue uma plataforma de um portfólio de pilotos.