True ML Talks #8 - Plataforma de Machine Learning @ Intuit

Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
Estamos de volta com mais um episódio do True ML Talks. Neste, vamos aprofundar em da Intuit Plataforma de ML NumaFlow, e estamos conversando com Vigith Maurice.
Vigith é o engenheiro principal na Intuit para a plataforma de AIOps. Como qualquer pessoa que já usou TurboTax, Credit Karma, Mint, QuickBooks e Mailchimp, a Intuit é a plataforma de tecnologia global que ajuda você a alcançar confiança financeira.
📌
Nossas conversas com Vigith abordarão os seguintes aspectos:
- Casos de Uso de ML na Intuit
- Abordagem NUMA para Detecção de Anomalias em Tempo Real
- Insights sobre Argo Workflows
- Implantação de Modelos de ML com Kubernetes e Numaflow
- Sistemas de Retreinamento, Numaflow vs Flink
- Medidas de Segurança e Conformidade em AIOps na Intuit
- MLOps vs AIOps
- Teaser da Apresentação de Vigith na KubeCon
Assista ao episódio completo abaixo:
Casos de Uso de ML na Intuit
O Caso de Uso de ML Orientado à Operação
A equipe de AIOps da Intuit tem um caso de uso diferente para ML, que é focado no lado operacional do negócio. Este caso de uso visa detectar e resolver problemas de plataforma rapidamente, reduzindo o tempo médio de detecção e resolução. Alguns dos aspectos deste caso de uso incluem:
- Construção de um Data Lake Operacional: A equipe de Vigith construiu um data lake operacional que coleta dados em tempo real de todas as camadas do sistema de tempo de execução, com foco em métricas puras, anonimizadas e não-PII.
- Análise em Tempo Real: A equipe analisa esses dados com uma latência de menos de um minuto para detectar e criar alertas ou incidentes com base na gravidade do problema.
- Alta Vazão e Baixa Latência: A abordagem de ML utilizada pela equipe de Vigith é diferente do ML tradicional orientado ao cliente, já que eles lidam com uma alta escala de 250 clusters Kubernetes e um bilhão de eventos injetados diariamente para análise e processamento.
- Previsão de Eventos Anômalos: O sistema da equipe segue o princípio de data mesh e esquematiza todo o sistema para fornecer uma abordagem unificada para analisar dados em escala, ajudando-os a prever eventos anômalos de CPO de recursos, segurança e outras áreas
O Caso de Uso de ML Orientado ao Cliente
Na Intuit, vários casos de uso de ML focam em melhorar a experiência do cliente. Alguns desses casos de uso incluem:
- Detecção de Fraudes: Utilizando algoritmos de ML para detectar atividades fraudulentas, como roubo de identidade, faturas falsas e golpes de phishing.
- Digitalização de Documentos: Utilizando modelos de ML para digitalizar documentos e extrair informações importantes automaticamente, como recibos, faturas e formulários fiscais.
- Previsão: Utilizando técnicas de ML para prever tendências futuras, como vendas, demanda e receita.
- Pesquisa de Documentos: Utilizando algoritmos de ML para melhorar a precisão e relevância da pesquisa, facilitando para os clientes encontrarem o que procuram.
Construindo uma Plataforma Escalável para Detecção de Anomalias em Tempo Real: Uma Abordagem NUMA
Sistemas de detecção de anomalias em tempo real precisam processar grandes volumes de fluxos de dados ilimitados. Sistemas tradicionais de aprendizado de máquina (ML) operam em um modelo de solicitação-resposta, onde a carga útil é processada para produzir uma previsão. No entanto, um sistema de detecção de anomalias em tempo real requer um pipeline assíncrono, baseado em grafo acíclico direcionado (DAG), capaz de lidar com diferentes formatos de dados e operações agnósticas à linguagem.
A Intuit construiu uma plataforma escalável para detecção de anomalias em tempo real que utiliza uma abordagem NUMA (New, Unique, and Mature Architecture - Arquitetura Nova, Única e Madura). A abordagem NUMA inclui duas partes: Numalogic, um conjunto de modelos que foram verificados e são usados diariamente, e a plataforma NUMAflow, que executa os modelos Numalogic.
O pipeline baseado em DAG na plataforma NUMAflow inclui uma fonte (um fluxo de dados ilimitado), vértices (operações agnósticas à linguagem) e um coletor (saída de pontuação de anomalia). O pipeline inclui uma etapa de pré-processamento para engenharia de recursos, uma etapa de inferência e uma etapa de pós-processamento para normalizar as pontuações para um formato legível por humanos.
A plataforma é altamente escalável e econômica, utilizando cálculos de carga para determinar o número de unidades de processamento necessárias. O sistema pode escalar para cima ou para baixo até zero unidades de processamento com base no volume de dados de entrada. A plataforma é construída para lidar com migrações de nós e portas, autoescalonamento e falhas de sistema.
No geral, a abordagem NUMA e a plataforma NUMAflow fornecem uma solução altamente eficiente e eficaz para sistemas de detecção de anomalias em tempo real.
📌
Arquitetura para escalonamento para zero em sistemas AIOps:
Sistemas AIOps exigem a capacidade de escalar recursos para cima e para baixo com base na quantidade de dados processados em tempo real. Para conseguir isso, a lógica de agendamento e a lógica de processamento de dados são separadas. Isso é feito implantando um controlador Kubernetes personalizado que possui um algoritmo de autoescalonamento integrado. Este algoritmo é capaz de entender a taxa de processamento de um vértice e o tempo necessário para processar uma mensagem, e usa essas informações para ajustar automaticamente os recursos alocados ao sistema.
O uso de um controlador personalizado é diferente do Horizontal Pod Autoscaler (HPA) nativo do Kubernetes, que não consegue escalar para zero. Ao usar um controlador personalizado, o sistema AIOps é capaz de escalar para zero quando não está processando dados, o que ajuda a evitar o desperdício desnecessário de recursos.
Para permitir o escalonamento independente de cada vértice, o sistema utiliza um buffer entre dois vértices. Este buffer ajuda a garantir que os dados sejam processados de forma eficiente e permite que cada vértice seja escalado independentemente com base em seus requisitos específicos. Isso é importante porque diferentes processos em um sistema AIOps podem ter diferentes requisitos de recursos, e escalá-los independentemente ajuda a otimizar o uso dos recursos.
Uma das características mais interessantes é a capacidade de escalar para baixo e é essencial para nós. - Vigith
Ecossistema Open Source e AIOps: Insights sobre Argo Workflows
Os workflows Argo tornaram-se uma ferramenta popular para gerenciar fluxos de trabalho de aprendizado de máquina, com a Intuit contribuindo significativamente para seu desenvolvimento. O sucesso do Argo reside em sua natureza de código aberto, permitindo feedback e contribuições de usuários em todo o mundo. Ao abrir o software, ideias e inovações fluem da comunidade, permitindo que a Intuit melhore suas soluções com base no feedback dos usuários.
Quando comparado a outros orquestradores DAG como o Airflow, o Argo é adequado para tarefas de treinamento, mas é orientado a lotes. Os usuários solicitaram um sistema equivalente que pudesse lidar com dados de streaming. A Intuit respondeu criando o Numaflow, um sistema orientado a streaming. Os dois sistemas, Argo e Numaflow, podem se fundir para criar um sistema de inferência sempre ativo para processamento de dados em tempo real. Com o Numaflow, a empresa re-arquitetou o sistema Argo para incorporar mais recursos e melhorar sua funcionalidade. A abordagem de código aberto provou ser benéfica para a Intuit e para toda a comunidade, permitindo um esforço colaborativo para melhorar os workflows de AIOps.
Você pode ler mais sobre Argo Workflows aqui:
Implantação de Modelos de ML com Kubernetes e Numaflow
A implantação de modelos de machine learning (ML) com Kubernetes e Numaflow pode ser uma tarefa desafiadora, especialmente considerando a latência e os padrões de tráfego que variam significativamente. A Intuit utiliza um sistema de serviço único empregado na plataforma operacional de operações de IA. Quando os dados são recebidos, o processo de inferência é semelhante a qualquer outra função definida pelo usuário (UDF), independentemente de envolver a conversão de protobuf para dados ou a inferência. O Numaflow oferece um SDK para diferentes linguagens, sendo Python a mais complexa de suportar devido ao seu comportamento em alto throughput, que exige Python multiprocesso e procedural. Para outras linguagens, isso não é um problema.
Para criar uma função de manipulador, o usuário só precisa escrever uma função que especifique como lidar com uma mensagem fornecida pelo Numaflow. A função recebe uma mensagem e retorna um mapa plano (flat map), que serve como entrada e saída, respectivamente. A assinatura da função se aplica a qualquer vértice, independentemente da tarefa.
Quando se trata de modelos, eles são puxados e armazenados em cache com base na declaração do problema. Uma mensagem é recebida, processada e retornada como inferência, que é então enviada para o próximo vértice. Dependendo do caso de uso, o modelo pode ser armazenado de diferentes maneiras. Para arquiteturas de alto throughput e altamente descentralizadas, uma chave é utilizada. Para arquiteturas centralizadas, uma referência é colocada no DynamoDB para o S3. Em geral, o objetivo é simplificar o processo para um engenheiro de ML, que só precisa alterar o nome da classe, pois o restante é abstraído.
A plataforma utiliza gRPC em vez de REST e, dependendo da declaração do problema, uma combinação de técnicas é empregada para gerenciar o ciclo de vida do modelo. O MLflow é usado para gerenciar o ciclo de vida quando apropriado, enquanto outras técnicas são empregadas para uma arquitetura mais descentralizada onde o MLflow não é uma opção. A principal conclusão para um engenheiro de ML é escrever uma função de manipulador que receba entrada e saída e deixe o sistema cuidar do resto.
Você pode ler mais sobre o Numaflow aqui:
Sistemas de retreinamento, Numaflow vs Flink
O sistema de retreinamento utilizado pelo Numaflow varia dependendo do caso de uso. Para casos mais complexos, com 20 requisições por segundo, o Numaflow implanta um fluxo de trabalho Argo completo com múltiplas etapas para buscar dados e atualizar o armazenamento do modelo. Para sistemas mais leves, o Numaflow utiliza uma Função Definida pelo Usuário (UDF) que executa uma função para alcançar o resultado desejado.
Diferença entre Numaflow e Flink
- Velocidade de Processamento: O Numaflow prioriza o desacoplamento da velocidade de processamento de mensagens da latência, enquanto o Flink foca em alto throughput com baixa latência, tornando-o mais adequado para o processamento de dados de alto throughput.
Essa diferença no throughput se deve ao fato de que o Numaflow é projetado para processamento intensivo de números e atividades intensivas de entrada/saída (I/O), enquanto o Flink é mais adequado para o processamento de dados de alto throughput. - Formato de Serialização de Dados: O Flink utiliza seu próprio formato de serialização eficiente e bem definido, enquanto o Numaflow usa uma abordagem de caixa preta que dificulta a definição de hashcodes e equals para o armazenamento e recuperação eficiente de mensagens.
Você pode ler mais sobre o Apache Flink aqui:
Medidas de Segurança e Conformidade em AIOps na Intuit
- A Intuit tem medidas de segurança rigorosas em vigor, incluindo algoritmos de encriptação ao nível da aplicação.
- O sistema AIOps da Intuit segue uma abordagem de compartimentalização estanque, com cada namespace isolado e encriptado com TLS para dados em repouso e em trânsito.
- A equipa de AIOps da Intuit segue os princípios de segurança do Argo, um projeto de código aberto sob a CNCF, para encriptar dados em todas as camadas, incluindo os endpoints de métricas.
- O sistema AIOps para dados de clientes na Intuit tem restrições de segurança ainda mais rigorosas, com dados bem auditados e bem guardados que nem mesmo os utilizadores podem aceder. Os dados operacionais são desacoplados dos dados dos clientes por esta razão, mas as medidas de segurança continuam em vigor.
MLOps vs AIOps
Machine Learning Operations (MLOps) e Artificial Intelligence Operations (AI Ops) são dois termos que são frequentemente usados de forma intercambiável, mas que, na verdade, têm princípios e processos distintos.
O MLOps foca-se principalmente na gestão do ciclo de vida do modelo, enquanto o AI Ops está mais centrado no domínio operacional.
Em AI Ops, tipicamente usamos tecnologias como HyperLogLog e esboços baseados em latência, que são projetadas para trabalhar com dados operacionais. Estas tecnologias podem ter percentagens de erro de cerca de 0,89 e permitem aproximações. Também confiamos na significância estatística para detetar e isolar problemas, com o objetivo de reduzir o Tempo Médio de Resolução (MTTR).
Em contraste, MLOps aproveita diferentes tecnologias como ML Flow e outras heurísticas para gerir o ciclo de vida de um modelo. Na Intuit, também desenvolveram padrões como a gestão de funcionalidades futuras para otimizar o ciclo de vida do modelo. O seu objetivo no MLOps é gerir todo o ciclo de vida do modelo, desde o treino à implementação, monitorização e otimização.
Antevisão da Apresentação de Vigith na KubeCon: AI Ops Centradas no Cliente com Deteção de Anomalias
A próxima apresentação de Vigith na KubeCon é sobre AI Ops centradas no cliente e deteção de anomalias. O foco está em alertar com base na experiência do cliente, em vez da do sistema, o que significa construir grafos de dependência complexos baseados em dados de rastreamento e isolar anomalias em vez de apenas as detetar.
A plataforma utiliza um conjunto de dimensões e métricas para realizar a deteção de anomalias de chave composta em dados de séries temporais, permitindo identificar anomalias a um nível muito específico. O objetivo deste projeto é fornecer uma solução generalizada para a deteção de anomalias, tornando-o um sistema de "anomalias Faça Você Mesmo".
A apresentação de Vigith mostrará as capacidades da plataforma e demonstrará como foi implementada com sucesso na Intuit para AI Ops. Não perca esta oportunidade de aprender sobre os mais recentes avanços em AI Ops centradas no cliente e deteção de anomalias.
Leia a nossa publicação anterior na Série TrueML
Continue assistindo a TrueML série do YouTube e lendo a TrueML série de blog.
TrueFoundry é uma PaaS de Implantação de ML sobre Kubernetes para acelerar os fluxos de trabalho dos desenvolvedores, ao mesmo tempo que lhes permite total flexibilidade no teste e implantação de modelos, garantindo total segurança e controle para a equipe de Infraestrutura. Através da nossa plataforma, capacitamos as equipes de Machine Learning a implantar e monitorar modelos em 15 minutos com 100% de confiabilidade, escalabilidade e a capacidade de reverter em segundos - permitindo-lhes economizar custos e lançar Modelos em produção mais rapidamente, possibilitando a realização de valor de negócio real.
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.
The fastest way to build, govern and scale your AI














.webp)






.webp)

.webp)
.webp)





.png)



