Ajudando cada criança a ler com a Wadhwani AI

Ajudando cada criança a ler com a Wadhwani AI

Solução de IA para avaliar e melhorar as habilidades de leitura de crianças em comunidades carentes

A Wadhwani AI é uma organização sem fins lucrativos que trabalha em diversas soluções de IA prontas para uso voltadas a populações carentes em países em desenvolvimento.

Por meio do projeto Vachan Samiksha, a equipe está desenvolvendo uma solução de IA personalizada que professores na Índia rural podem usar para avaliar a fluência de leitura dos alunos e desenvolver um plano de contingência personalizado para melhorar as habilidades de leitura de cada aluno.

A equipe havia implantado a solução em escolas primárias para conduzir pilotos. No entanto, a equipe enfrentava os seguintes problemas, que precisavam ser resolvidos antes de o escopo do projeto ser expandido para mais escolas e alunos:

1. Custo de computação muito alto: O modelo da Vachan Samiksha precisava de GPUs para fazer inferências e, portanto, a equipe tinha de arcar com custos muito altos para manter instâncias de GPU provisionadas durante toda a duração do deployment.
2. O escalonamento era limitado: Pela cota de instâncias de ML com GPUs que a equipe conseguia obter no serviço gerenciado de ML, cujo processo era lento e envolvia apresentar uma justificativa de negócio. Obter instâncias de ML não gerenciadas em Kubernetes puro era muito mais fácil; a equipe construiu um modelo inclusivo de sotaques para avaliar a fluência em idiomas regionais e em inglês
3. Algumas requisições levavam muito tempo para responder: Os pilotos foram conduzidos em milhares de escolas e com milhões de alunos simultaneamente. Isso exigia que o sistema escalasse horizontalmente quando o throughput de requisições aumentava. No entanto, o serviço gerenciado de ML levava mais de 9 minutos para conseguir escalar, proporcionando uma experiência ruim ao usuário final

A equipe da TrueFoundry fez parceria com a equipe para resolver esses problemas. Usando a plataforma TrueFoundry, a equipe conseguiu:

1. Escalar a aplicação para lidar com 10X requisições por segundo em comparação com o serviço gerenciado de ML.
2. Reduzir o custo de nuvem incorrido em cerca de 55% com o mesmo nível de confiabilidade e desempenho.
3. Reduzir a latência das requisições em cerca de 80% quando os pods estão escalando horizontalmente.

‍

‍

Sobre a Wadhwani AI

A Wadhwani AI foi fundada por Romesh e Sunil Wadhwani (parte da lista Times100 AI) para aproveitar a IA na resolução de problemas enfrentados por comunidades carentes em nações em desenvolvimento. Eles firmam parcerias com órgãos governamentais e organizações sem fins lucrativos globais em todo o mundo para entregar valor por meio da solução. Como entidade sem fins lucrativos, a Wadhwani AI usa inteligência artificial para resolver problemas sociais nas áreas de agricultura, educação e saúde, entre outras. Alguns de seus projetos incluem:

• Manejo de pragas para fazendas de algodão: A solução ajuda a reduzir perdas de safra detectando e controlando pragas que afetam a planta de algodão.
• Previsão de adesão ao tratamento de tuberculose: Implantada em mais de 100 unidades de saúde pública, ajuda a identificar pacientes de alto risco, detectar resistência a medicamentos e auxiliar no diagnóstico de tuberculose usando dados de ultrassom.
• Antropometria de recém-nascidos: Uma solução que mede o peso do bebê usando a câmera de um smartphone e acompanha indicadores de crescimento.
• Previsão e diagnóstico de COVID-19: Uma solução que prevê a propagação da pandemia e detecta a infecção por COVID-19 usando sons de tosse.

A Wadhwani AI também trabalha com organizações parceiras para avaliar sua prontidão para IA, ou seja, sua capacidade de criar e usar soluções de IA de forma eficaz e sustentável. O trabalho da Wadhwani AI tem como objetivo usar a IA para o bem e melhorar a vida de bilhões de pessoas em países em desenvolvimento.

A ferramenta de Fluência de Leitura Oral da Wadhwani AI: Vachan Samiksha

As habilidades de leitura são fundamentais para a base educacional de qualquer criança. Infelizmente, muitos alunos das regiões rurais e carentes da Índia e de outras nações em desenvolvimento não possuem essas habilidades. Para resolver esse problema em um nível fundamental, a equipe da Wadhwani AI desenvolveu uma ferramenta de Fluência de Leitura Oral baseada em IA chamada Vachan Samiksha.

A ferramenta usa IA para analisar o desempenho de leitura de cada criança. No momento, ela é voltada principalmente para regiões rurais e semiurbanas do país e está sendo usada em diferentes faixas etárias. Para tornar a solução generalizável para a maior parte do país, a equipe construiu um modelo inclusivo de sotaques para avaliar idiomas regionais e o inglês. A avaliação manual dessas habilidades tem seus vieses e é muitas vezes imprecisa.

A solução é entregue aos usuários (professores das escolas-alvo) por meio de um aplicativo que invoca o modelo implantado na nuvem. O aluno é levado a ler um parágrafo, que é gravado pela aplicação e enviado para a nuvem. Na nuvem, o modelo avalia a precisão de leitura, a velocidade, a compreensão e outros atrasos de aprendizagem complexos que poderiam passar despercebidos em uma avaliação normal. Além de avaliar essas habilidades, a aplicação também cria um plano de aprendizagem personalizado para cada aluno, a fim de facilitar seu aprendizado, e também gera relatórios demográficos para ações em nível macro pelas autoridades governamentais. A equipe havia implantado o modelo para o piloto com o serviço gerenciado de ML do provedor de nuvem

Quando começamos nossa colaboração com a equipe da Vachan Samiksha dentro da Wadhwani AI, a equipe vinha aproveitando a stack nativa de MLOps de seu provedor de nuvem para implantar o modelo em seu piloto com o Departamento de Educação de Gujarat.

A configuração de infraestrutura deles era a seguinte:

1. Endpoint assíncrono gerenciado: A equipe queria um motor de inferência assíncrono, já que o modelo podia levar algum tempo (~5-7 segundos) para inferir. Quando a aplicação recebia muito tráfego simultaneamente, era preciso armazenar as requisições de forma intermitente antes que um worker pudesse retirá-las e inferir sobre elas. O endpoint assíncrono do provedor de nuvem usa internamente sua fila nativa.
2. Serviço de container gerenciado: A equipe usava o serviço de container gerenciado para hospedar o serviço de backend da aplicação.
3. Queue workers: O serviço gerenciado de MLOps usava instâncias reservadas de ML para os queue workers retirarem requisições da fila e inferirem sobre elas.
4. Fonte de dados: A fila era escrita no sistema de armazenamento do provedor de nuvem e lida a partir dele
5. SNS: era usado como broker para publicar o caminho de saída e as mensagens de sucesso/falha da fila de mensagens de saída

Desafios que a equipe vinha enfrentando

A equipe enfrentou desafios com essa configuração ao tentar conduzir o primeiro piloto, o que a motivou a experimentar outras soluções:

‍

O escalonamento era limitado

Esperava-se que o piloto rodasse em uma escala enorme (~6 milhões de alunos em um mês). No entanto, a equipe não tinha confiança de que o serviço gerenciado de ML conseguiria suportar essa escala porque:

1. Cota separada: O serviço gerenciado de ML tem uma cota e uma alocação separadas para instâncias de ML, das quais era difícil conseguir mais.
2. Difícil obter cota de instâncias de ML: Conseguir cota extra é um processo lento, e a equipe precisava apresentar uma justificativa de negócio para ser elegível a mais cota. Mesmo quando a equipe recebia mais cota, era pouco mais de 1/10 da cota que a equipe esperava.
3. Obter instâncias não ML é muito mais fácil: A equipe achou muito mais fácil obter cota para instâncias não ML. No entanto, era difícil para a equipe usá-las em seu piloto sem as ferramentas gerenciadas de MLOps.

O suporte era lento

Durante o piloto, a equipe enfrentou problemas com a velocidade de escalonamento, e alguns pods não subiram como esperado. No entanto, para resolver o problema, a equipe contatava os representantes do provedor de nuvem, que então contatavam a equipe técnica. Isso gerava um atraso no sistema e causava atraso no piloto.

O escalonamento era lento

Quando o tráfego de requisições aumentava durante o piloto, os pods precisavam escalar horizontalmente (subir novos nodes que pudessem retirar e processar parte das requisições da fila). Esse processo levava cerca de 9-10 minutos para cada novo pod que era criado, resultando em respostas atrasadas e em uma experiência ruim para o usuário final.

Custos insustentavelmente altos

As instâncias de GPU são muito caras devido à escassez global de chips. Some a isso o markup de 20-40% para instâncias de ML que o provedor de nuvem aplica. Isso tornava o custo das instâncias muito alto e inviável para a equipe na escala em que queriam rodar o projeto.

O sistema estava pronto para deployment com a TrueFoundry em menos de uma semana

Quando conhecemos a equipe da Vachan Samiksha, eles estavam no período entre o primeiro piloto e o segundo. O piloto estava a menos de uma semana de distância e tínhamos de:

1. Configurar a plataforma TrueFoundry em sua infraestrutura de nuvem (já que os dados são muito sensíveis e nenhum dado podia sair da VPC do projeto)
2. Fazer o onboarding da equipe e guiá-la pelas diferentes funcionalidades da plataforma.
3. Migrar a aplicação Vachan Samiksha para a plataforma
4. Fazer o teste de carga da aplicação e o benchmark do escalonamento horizontal

‍

Durante o período anterior ao piloto:

Instalação da plataforma

‍Nossa equipe ajudou a equipe da Wadhwani AI a instalar a plataforma em seu próprio Kubernetes puro. O control plane e o cluster de workload foram ambos instalados em sua própria infraestrutura. Todos os dados, os elementos de UI para interagir com a plataforma e os processos de workload para treinar/implantar os modelos permaneceram dentro de sua própria VPC. A plataforma também cumpriu todas as regras e práticas de segurança da empresa.

Treinamento e onboarding

Ajudamos a equipe a entender como os diferentes componentes interagem durante o processo de treinamento e onboarding. Nós os guiamos sobre como configurar recursos, configurar o autoscaling e implantar o modelo.

Migração

A equipe da Wadhwani AI conseguiu migrar a aplicação por conta própria com ajuda mínima da equipe da TrueFoundry. Isso foi feito em uma chamada de 1 hora com a equipe.

Testes

‍Depois que a aplicação foi implantada, a equipe começou a testar carga de nível de produção nela. A equipe escalou de forma independente a aplicação para mais de 100 nodes por meio de um simples argumento na UI da TrueFoundry, o que é 5X a maior escala que conseguiam atingir anteriormente. Eles também tentaram fazer o benchmark da velocidade de escalonamento de nodes, que foi muito (3-4X) mais rápida do que a fornecida pelo serviço anterior.

Entrega

Com os testes de carga concluídos, a equipe implantou a aplicação do piloto e se preparou para lançá-la na segunda fase do piloto, que foi disponibilizada para 1.000 escolas, 9.000 professores e mais de 200 mil alunos.

Mais controle a um custo muito menor com a TrueFoundry

Com um esforço mínimo de menos de 10 horas, a equipe da Wadhwani AI conseguiu obter uma melhora significativa em velocidade, controle e custos. Algumas das principais mudanças que obtiveram foram:

Mais controle e visibilidade e independência para os desenvolvedores

Os cientistas de dados e engenheiros de machine learning conseguiram configurar vários elementos que antes eram difíceis de fazer pelo console do provedor de nuvem ou para os quais tinham de depender da equipe de engenharia:

Configurar a política de auto-scaling de nodes de GPU

Com base no comprimento da fila e aumentando o número máximo de réplicas/nodes para 70, em vez do limite anterior de 20

Configurar o auto-scaling baseado em tempo

Como a maior parte do tráfego do piloto chegava durante o horário escolar, quando os professores interagiam com os alunos, havia poucas requisições, se é que havia, durante a noite. A equipe conseguiu configurar uma agenda de escalonamento com a qual os pods reduziam ao mínimo durante as horas de baixo movimento (noite). Isso economizou cerca de 15-20% do custo do piloto.

Métricas de utilização e sugestões

A equipe podia monitorar facilmente o tráfego, a utilização de recursos e as respostas diretamente pela UI da TrueFoundry. Eles também recebiam sugestões pela plataforma sempre que havia um superprovisionamento ou subprovisionamento de recursos

‍

A TrueFoundry ajudou a equipe a escalar enquanto reduzia custos

Escalonamento 5X mais rápido

Para testar o escalonamento com a TrueFoundry, a equipe enviou uma rajada de 88 requisições à aplicação e fez o benchmark do desempenho do serviço gerenciado de ML do provedor de nuvem vs. a TrueFoundry. Todas as configurações do sistema foram mantidas iguais, como a lógica de escalonamento (com base no comprimento da fila de backlog, o número inicial de nodes, o tipo de instância etc.)

Percebemos que a TrueFoundry conseguia escalar 78% mais rápido do que o serviço gerenciado de ML, o que dava ao usuário respostas muito mais rápidas. O tempo de ponta a ponta para responder à consulta foi 40% menor com a TrueFoundry.

Custo 50% menor

O custo que a equipe estava tendo com o piloto foi reduzido em cerca de 50% ao migrar para a TrueFoundry; isso foi viabilizado pelos seguintes fatores contribuintes:

1. ~25-30% de redução - Uso de Kubernetes puro: As instâncias gerenciadas de ML vêm com um acréscimo de 25-40% para a mesma instância quando provisionada diretamente em Kubernetes puro. Como a TrueFoundry roda diretamente sobre K8s, a equipe economizou muitos custos aqui
2. ~15-20% de redução - Autoscaling baseado em tempo: A equipe agendou a redução de escala dos pods quando esperavam menor tráfego para a aplicação. Isso economizou à equipe 15-20% dos custos de nuvem.
3. ~20-30% de redução - Uso de instâncias spot: As instâncias spot fazem parte da infraestrutura não utilizada dos provedores de nuvem, que eles disponibilizam com descontos de 50-60%. Ao habilitar uma simples flag na UI, a equipe pode usar uma combinação de instâncias spot e on-demand. As instâncias spot correm o risco de serem desprovisionadas, mas a TrueFoundry construiu uma camada de confiabilidade que garante que, mesmo com instâncias spot, a combinação de instâncias on-demand e spot seja gerenciada para fornecer aos usuários um nível confiável de disponibilidade.

Alta disponibilidade de GPU com custos menores

Enquanto o serviço gerenciado de ML era limitado pela disponibilidade de instâncias de GPU na mesma região do provedor de nuvem, a TrueFoundry pode adicionar worker nodes ao sistema que podem estar em qualquer região ou provedor de nuvem.
Isso significa que:

1. Alta disponibilidade de GPU de múltiplos provedores de nuvem/regiões: Os usuários podem subir nodes em uma região diferente da nuvem que tenha maior disponibilidade de GPU ou com outros provedores de nuvem como AWS, E2E Networks, RunPod, Azure, GCP ou outros. Isso é crítico, já que toda empresa enfrenta limitações de cota de GPU e, para garantir a confiabilidade do sistema, é necessário ter esse tipo de backup.
2. Redução de custos: Diferentes provedores de nuvem têm preços diferentes para instâncias de GPU. Isso pode variar de 40-80% entre um provedor e outro. A TrueFoundry permite que o usuário conecte qualquer provedor de GPU a um único control plane e possibilita o escalonamento fluido entre esses fornecedores de nuvem, com a opção de escolher um fornecedor de menor custo caso tenha disponibilidade, para economizar nos custos.

Use as melhores ferramentas sem nenhuma limitação

A TrueFoundry oferece integração fluida com qualquer ferramenta que a equipe queira usar. Com o provedor de nuvem, isso era limitado pelas escolhas de design feitas pelo provedor e por suas integrações nativas. Por exemplo, a equipe queria usar o NATS para publicar mensagens, o que o serviço nativo do provedor de nuvem não oferecia no momento. A TrueFoundry tornou trivial para a equipe da Wadhwani AI fazer esse tipo de escolha.

‍