Como a CCC Intelligent Solutions criou uma abordagem personalizada para hospedar modelos complexos de IA usando o Amazon SageMaker

Este post foi co-escrito por Christopher Diaz, Sam Kinard, Jaime Hidalgo e Daniel Suarez da CCC Intelligent Solutions.

Neste post, discutimos como CCC Soluções Inteligentes (CCC) combinado Amazon Sage Maker com outros serviços da AWS para criar uma solução personalizada capaz de hospedar os tipos de modelos complexos de inteligência artificial (IA) previstos. A CCC é uma plataforma líder de software como serviço (SaaS) para a economia multibilionária de seguros de propriedades e acidentes, impulsionando operações para seguradoras, reparadores, montadoras, fornecedores de peças, credores e muito mais. A tecnologia de nuvem CCC conecta mais de 30,000 empresas digitalizando fluxos de trabalho de missão crítica, comércio e experiências do cliente. Líder confiável em IA, Internet das Coisas (IoT), experiência do cliente e gerenciamento de rede e fluxo de trabalho, a CCC oferece inovações que mantêm a vida das pessoas avançando quando mais importa.

O desafio

A CCC processa mais de US$ 1 trilhão em transações de sinistros anualmente. À medida que a empresa continua a evoluir para integrar a IA em seu catálogo de produtos novos e existentes, isso requer abordagens sofisticadas para treinar e implantar modelos de conjunto de aprendizado de máquina (ML) multimodais para resolver necessidades comerciais complexas. Essa é uma classe de modelos que encapsula algoritmos proprietários e experiência no domínio do assunto que o CCC aprimorou ao longo dos anos. Esses modelos devem ser capazes de ingerir novas camadas de dados diferenciados e regras do cliente para criar resultados de previsão únicos. Nesta postagem do blog, aprenderemos como o CCC aproveitou a hospedagem do Amazon SageMaker e outros serviços da AWS para implantar ou hospedar vários modelos multimodais em um pipeline de inferência de conjunto.

Conforme mostrado no diagrama a seguir, um conjunto é uma coleção de dois ou mais modelos que são orquestrados para serem executados de maneira linear ou não linear para produzir uma única previsão. Quando empilhados linearmente, os modelos individuais de um conjunto podem ser invocados diretamente para previsões e posteriormente consolidados para unificação. Às vezes, os modelos de conjunto também podem ser implementados como um pipeline de inferência serial.

Para nosso caso de uso, o pipeline de conjunto é estritamente não linear, conforme ilustrado no diagrama a seguir. Os pipelines de conjunto não lineares são, teoricamente, gráficos diretamente acíclicos (DAGs). Para nosso caso de uso, esse pipeline DAG tinha modelos independentes executados em paralelo (Serviços B, C) e outros modelos que usam previsões de etapas anteriores (Serviço D).

Uma prática que resulta da cultura voltada para a pesquisa na CCC é a revisão contínua de tecnologias que podem ser aproveitadas para agregar mais valor aos clientes. Como o CCC enfrentou esse desafio conjunto, a liderança lançou uma iniciativa de prova de conceito (POC) para avaliar minuciosamente as ofertas da AWS para descobrir, especificamente, se o Amazon SageMaker e outras ferramentas da AWS poderiam gerenciar a hospedagem de modelos individuais de IA em sistemas complexos e não lineares conjuntos.

Conjunto explicou: Nesse contexto, um conjunto é um grupo de 2 ou mais modelos de IA que trabalham juntos para produzir 1 previsão geral.

Questões que conduzem a pesquisa

O Amazon SageMaker pode ser usado para hospedar conjuntos complexos de modelos de IA que trabalham juntos para fornecer uma previsão geral? Em caso afirmativo, o SageMaker pode oferecer outros benefícios prontos para uso, como maior automação, confiabilidade, monitoramento, dimensionamento automático e medidas de redução de custos?

Encontrar maneiras alternativas de implantar os modelos de IA da CCC usando os avanços tecnológicos dos provedores de nuvem permitirá que a CCC leve soluções de IA ao mercado mais rapidamente do que a concorrência. Além disso, ter mais de uma arquitetura de implantação oferece flexibilidade ao encontrar o equilíbrio entre custo e desempenho com base nas prioridades de negócios.

Com base em nossos requisitos, finalizamos a seguinte lista de recursos como uma lista de verificação para uma arquitetura de implantação de nível de produção:

• Suporte para conjuntos complexos
• Tempo de atividade garantido para todos os componentes
• Dimensionamento automático personalizável para modelos de IA implantados
• Preservação da entrada e saída do modelo de IA
• Métricas de uso e logs para todos os componentes
• Mecanismos de redução de custos

Com a maioria das soluções de IA da CCC baseadas em modelos de visão computacional, uma nova arquitetura foi necessária para oferecer suporte a arquivos de imagem e vídeo que continuam a aumentar em resolução. Havia uma forte necessidade de projetar e implementar essa arquitetura como um modelo assíncrono.

Após ciclos de pesquisa e esforços iniciais de benchmarking, a CCC determinou que o SageMaker era perfeito para atender a maioria de seus requisitos de produção, especialmente o tempo de atividade garantido que o SageMaker fornece para a maioria de seus componentes de inferência. O recurso padrão dos endpoints de inferência assíncrona do Amazon SageMaker salvando entrada/saída no Amazon S3 simplifica a tarefa de preservar dados gerados de conjuntos complexos. Além disso, com cada modelo de IA sendo hospedado por seu próprio endpoint, o gerenciamento de políticas de dimensionamento automático no nível do modelo ou do endpoint torna-se mais fácil. Ao simplificar o gerenciamento, um possível benefício de economia de custos disso é que as equipes de desenvolvimento podem alocar mais tempo para ajustar as políticas de dimensionamento para minimizar o provisionamento excessivo de recursos de computação.

Tendo decidido continuar usando o SageMaker como o componente principal da arquitetura, também percebemos que o SageMaker pode fazer parte de uma arquitetura ainda maior, complementada com muitos outros serviços gerenciados pela AWS sem servidor. Essa escolha foi necessária para facilitar a orquestração de ordem superior e as necessidades de observabilidade dessa arquitetura complexa.

Em primeiro lugar, para remover as limitações de tamanho de carga útil e reduzir consideravelmente o risco de tempo limite durante cenários de alto tráfego, o CCC implementou uma arquitetura que executa previsões de forma assíncrona usando Pontos de extremidade de inferência assíncrona do SageMaker juntamente com outros serviços gerenciados pela AWS como os principais blocos de construção. Além disso, a interface do usuário para o sistema segue o padrão de design de fogo e esquecimento. Em outras palavras, uma vez que um usuário tenha carregado sua entrada no sistema, nada mais precisa ser feito. Eles serão notificados quando a previsão estiver disponível. A figura abaixo ilustra uma visão geral de alto nível de nossa arquitetura assíncrona orientada a eventos. Na próxima seção, vamos nos aprofundar no fluxo de execução da arquitetura projetada.

Solução passo a passo

Passo 1

Um cliente faz uma solicitação ao Gateway de API da AWS ponto final. O conteúdo da solicitação contém o nome do serviço de IA do qual eles precisam de uma previsão e o método de notificação desejado.

Este pedido é passado para um Lambda função chamada Nova previsão, cujas principais tarefas são:

• Verifique se o serviço solicitado pelo cliente está disponível.
• Atribua um ID de previsão exclusivo à solicitação. Esse ID de previsão pode ser usado pelo usuário para verificar o status da previsão durante todo o processo.
• Gere um Amazon S3 URL pré-assinado que o usuário precisará usar na próxima etapa para carregar o conteúdo de entrada da solicitação de previsão.
• Crie uma entrada em Amazon DynamoDB com as informações do pedido recebido.

A função do Lambda retornará uma resposta por meio do endpoint do API Gateway com uma mensagem que inclui o ID de previsão atribuído à solicitação e o URL pré-assinado do Amazon S3.

Passo 2

O cliente carrega com segurança o conteúdo de entrada de previsão para um bucket S3 usando o URL pré-assinado gerado na etapa anterior. O conteúdo de entrada depende do serviço AI e pode ser composto de imagens, dados tabulares ou uma combinação de ambos.

Passo 3

O bucket do S3 é configurado para acionar um evento quando o usuário carrega o conteúdo de entrada. Essa notificação é enviada para uma fila do Amazon SQS e tratada por uma função do Lambda chamada Entrada de Processo. O Entrada de Processo O Lambda obterá as informações relacionadas a esse ID de previsão do DynamoDB para obter o nome do serviço ao qual a solicitação deve ser feita.

Este serviço pode ser um único modelo AI, caso em que o Entrada de Processo O Lambda fará uma solicitação ao terminal SageMaker que hospeda esse modelo (Etapa 3-A) ou pode ser um serviço de IA de conjunto, caso em que o Entrada de Processo O Lambda fará uma solicitação à máquina de estado das funções de etapa que hospeda a lógica do conjunto (Etapa 3-B).

Em qualquer uma das opções (modelo de IA único ou serviço de IA de conjunto), quando a previsão final estiver pronta, ela será armazenada no bucket S3 apropriado e o chamador será notificado por meio do método especificado na Etapa 1 (mais detalhes sobre notificações na Etapa 4).

Etapa 3-A

Se o ID de previsão estiver associado a um único modelo de IA, o Entrada de Processo O Lambda fará uma solicitação ao endpoint SageMaker que atende ao modelo. Nesse sistema, há suporte para dois tipos de endpoints do SageMaker:

• Assíncrono: O Entrada de Processo O Lambda faz a solicitação ao endpoint assíncrono do SageMaker. A resposta imediata inclui o local do S3 onde o SageMaker salvará a saída da previsão. Essa solicitação é assíncrona, seguindo o padrão disparar e esquecer e não bloqueia o fluxo de execução da função Lambda.
• Síncrono: O Entrada de Processo O Lambda faz a solicitação ao endpoint síncrono do SageMaker. Como é uma solicitação síncrona, o Process Input aguarda a resposta e, uma vez obtida, armazena-a no S3 de maneira análoga que os endpoints assíncronos do SageMaker fariam.

Em ambos os casos (endpoints síncronos ou assíncronos), a previsão é processada de forma equivalente, armazenando a saída em um bucket S3. Quando o endpoint assíncrono do SageMaker conclui uma previsão, um evento do Amazon SNS é acionado. Esse comportamento também é replicado para endpoints síncronos com lógica adicional na função Lambda.

Etapa 3-B

Se o ID de previsão estiver associado a um conjunto de IA, o Entrada de Processo O Lambda fará a solicitação para a função de etapa associada a esse AI Ensemble. Como mencionado acima, um AI Ensemble é uma arquitetura baseada em um grupo de modelos de IA trabalhando juntos para gerar uma única previsão geral. A orquestração de um conjunto de IA é feita por meio de uma função de etapa.

A função de etapa possui uma etapa por serviço de IA que compreende o conjunto. Cada etapa invocará uma função do Lambda que preparará a entrada do serviço de IA correspondente usando diferentes combinações do conteúdo de saída das chamadas de serviço de IA anteriores das etapas anteriores. Em seguida, ele faz uma chamada para cada serviço de IA que, nesse contexto, pode ser um único modelo de IA ou outro conjunto de IA.

A mesma função do Lambda, chamada ObterTransformCall usado para lidar com as previsões intermediárias de um AI Ensemble é usado em toda a função de etapa, mas com diferentes parâmetros de entrada para cada etapa. Esta entrada inclui o nome do serviço AI a ser chamado. Também inclui a definição de mapeamento para construir a entrada para o serviço AI especificado. Isso é feito usando uma sintaxe personalizada que o Lambda pode decodificar, que em resumo, é um dicionário JSON onde os valores devem ser substituídos pelo conteúdo das previsões de IA anteriores. O Lambda fará o download dessas previsões anteriores do Amazon S3.

Em cada passo, o ObterTransformCall O Lambda lê no Amazon S3 as saídas anteriores necessárias para criar a entrada do serviço de IA especificado. Em seguida, invocará o Nova previsão O código Lambda usado anteriormente na Etapa 1 e fornece o nome do serviço, o método de retorno de chamada (“função de etapa”) e o token necessário para o retorno de chamada na carga útil da solicitação, que é salvo no DynamoDB como um novo registro de previsão. O Lambda também armazena a entrada criada desse estágio em um bucket do S3. Dependendo se esse estágio é um único modelo de IA ou um conjunto de IA, o Lambda faz uma solicitação para um endpoint SageMaker ou uma função de etapa diferente que gerencia um conjunto de IA que é uma dependência do conjunto pai.

Depois que a solicitação é feita, a função de etapa entra em um estado pendente até receber o token de retorno de chamada indicando que pode passar para o próximo estágio. A ação de enviar um token de retorno de chamada é executada por uma função do Lambda chamada notificações (mais detalhes na Etapa 4) quando a previsão intermediária estiver pronta. Este processo é repetido para cada estágio definido na função degrau até que a previsão final esteja pronta.

Passo 4

Quando uma previsão está pronta e armazenada no bucket do S3, uma notificação do SNS é acionada. Este evento pode ser acionado de diferentes maneiras, dependendo do fluxo:

1. Automaticamente quando um endpoint assíncrono do SageMaker conclui uma previsão.
2. Como a última etapa da função de etapa.
3. By Entrada de Processo or ObterTransformCall Lambda quando um endpoint síncrono do SageMaker retornou uma previsão.

Para B e C, criamos uma mensagem SNS semelhante à que A envia automaticamente.

Uma função do Lambda chamada notificações está inscrita neste tópico do SNS. As notificações do Lambda obterão as informações relacionadas ao ID de previsão do DynamoDB, atualizarão a entrada com o valor do status para “concluído” ou “erro” e executarão a ação necessária, dependendo do modo de retorno de chamada salvo no registro do banco de dados.

Se esta previsão for uma previsão intermediária de um AI ensemble, conforme descrito na etapa 3-B, o modo de callback associado a essa previsão será “step function” e o registro do banco de dados terá um token de callback associado à etapa específica no função passo. As notificações do Lambda farão uma chamada para a API do AWS Step Functions usando o método “SendTaskSuccess” ou “SendTaskFailure”. Isso permitirá que a função de etapa continue para a próxima etapa ou saia.

Se a previsão for a saída final da função de etapa e o modo de retorno de chamada for “Webhook” [ou e-mail, corretores de mensagens (Kafka) etc.], as notificações do Lambda notificarão o cliente da maneira especificada. A qualquer momento, o usuário pode solicitar o status de sua previsão. A solicitação deve incluir o ID de previsão que foi atribuído na Etapa 1 e apontar para a URL correta no API Gateway para rotear a solicitação para a função do Lambda chamada resultados.

Com os resultados, o Lambda fará uma solicitação ao DynamoDB, obtendo o status da solicitação e retornando as informações ao usuário. Se o status da previsão for erro, os detalhes relevantes sobre a falha serão incluídos na resposta. Se o status da previsão for sucesso, um URL pré-assinado do S3 será retornado para o usuário baixar o conteúdo de previsão.

Focados no Negócio

Os resultados preliminares dos testes de desempenho são promissores e apóiam o caso da CCC para estender a implementação dessa nova arquitetura de implantação.

Observações notáveis:

• Os testes revelam força no processamento de solicitações em lote ou simultâneas com alto rendimento e uma taxa de falha de 0% durante cenários de alto tráfego.
• As filas de mensagens fornecem estabilidade dentro do sistema durante influxos repentinos de solicitações até que os gatilhos de dimensionamento possam fornecer recursos de computação adicionais. Ao aumentar o tráfego em 3x, a latência média da solicitação aumentou apenas 5%.
• O preço da estabilidade é o aumento da latência devido à sobrecarga de comunicação entre os vários componentes do sistema. Quando o tráfego do usuário está acima do limite da linha de base, a latência adicionada pode ser parcialmente mitigada ao fornecer mais recursos de computação se o desempenho for uma prioridade mais alta do que o custo.
• Os endpoints de inferência assíncrona do SageMaker permitem que a contagem de instâncias seja dimensionada para zero enquanto mantém o endpoint ativo para receber solicitações. Essa funcionalidade permite que as implantações continuem em execução sem incorrer em custos de computação e aumentem de zero quando necessário em dois cenários: implantações de serviço usadas em ambientes de teste inferiores e aquelas com tráfego mínimo sem exigir processamento imediato.

Conclusão

Conforme observado durante o processo de POC, o design inovador criado em conjunto pela CCC e pela AWS fornece uma base sólida para usar o Amazon SageMaker com outros serviços gerenciados pela AWS para hospedar conjuntos complexos de IA multimodal e orquestrar pipelines de inferência de maneira eficaz e contínua. Aproveitando as funcionalidades prontas para uso do Amazon SageMaker, como a inferência assíncrona, o CCC tem mais oportunidades de se concentrar em tarefas críticas especializadas para os negócios. No espírito da cultura orientada para a pesquisa da CCC, essa nova arquitetura continuará a evoluir à medida que a CCC lidera o caminho a seguir, ao lado da AWS, no lançamento de novas e poderosas soluções de IA para os clientes.

Para obter etapas detalhadas sobre como criar, invocar e monitorar pontos de extremidade de inferência assíncrona, consulte o documentação, que também contém um caderno de amostra para ajudá-lo a começar. Para informações sobre preços, visite Preços do Amazon SageMaker.

Para obter exemplos sobre o uso de inferência assíncrona com dados não estruturados, como visão computacional e processamento de linguagem natural (NLP), consulte Execute a inferência de visão computacional em vídeos grandes com endpoints assíncronos do Amazon SageMaker e Melhore a pesquisa de alto valor com os endpoints de inferência assíncrona Hugging Face e Amazon SageMaker, Respectivamente.

---

Sobre os autores

Cristóvão Diaz é engenheiro líder de P&D na CCC Intelligent Solutions. Como membro da equipe de P&D, ele trabalhou em uma variedade de projetos, desde ferramentas ETL, desenvolvimento web de back-end, colaborando com pesquisadores para treinar modelos de IA em sistemas distribuídos e facilitando a entrega de novos serviços de IA entre equipes de pesquisa e operações. Seu foco recente tem sido a pesquisa de soluções de ferramentas em nuvem para aprimorar vários aspectos do ciclo de vida de desenvolvimento do modelo de IA da empresa. Em seu tempo livre, ele gosta de experimentar novos restaurantes em sua cidade natal, Chicago, e colecionar tantos conjuntos de LEGO quantos cabem em sua casa. Christopher obteve seu bacharelado em Ciência da Computação pela Northeastern Illinois University.

Vencedor do Emmy Award Sam Kinard é gerente sênior de engenharia de software da CCC Intelligent Solutions. Com sede em Austin, Texas, ele comanda a AI Runtime Team, que é responsável por atender os produtos de IA da CCC em alta disponibilidade e grande escala. Em seu tempo livre, Sam gosta de ficar sem dormir por causa de seus dois filhos maravilhosos. Sam é bacharel em Ciência da Computação e Bacharel em Ciências em Matemática pela Universidade do Texas em Austin.

Jaime Hidalgo é Engenheiro de Sistemas Sênior na CCC Intelligent Solutions. Antes de ingressar na equipe de pesquisa de IA, ele liderou a migração global da empresa para a arquitetura de microsserviços, projetando, construindo e automatizando a infraestrutura na AWS para oferecer suporte à implantação de produtos e serviços em nuvem. Atualmente, ele constrói e dá suporte a um cluster de data center local criado para treinamento de IA e também projeta e constrói soluções em nuvem para o futuro da pesquisa e implantação de IA da empresa.

Daniel Suarez é engenheiro de ciência de dados na CCC Intelligent Solutions. Como membro da equipe de AI Engineering, ele trabalha na automação e preparação de AI Models na produção, avaliação e monitoramento de métricas e outros aspectos das operações de ML. Daniel é mestre em Ciência da Computação pelo Illinois Institute of Technology e mestre e bacharel em Engenharia de Telecomunicações pela Universidad Politecnica de Madrid.

Arunprasath Shankar é um arquiteto de soluções especialista em IA/ML sênior da AWS, ajudando clientes globais a dimensionar suas soluções de IA de maneira eficaz e eficiente na nuvem. Em seu tempo livre, Arun gosta de assistir a filmes de ficção científica e ouvir música clássica.

Justin McWhirter é gerente de arquitetura de soluções da AWS. Ele trabalha com uma equipe de arquitetos de soluções incríveis que ajudam os clientes a ter uma experiência positiva ao adotar a plataforma AWS. Quando não está no trabalho, Justin gosta de jogar videogame com seus dois filhos, hóquei no gelo e fazer off-road em seu jipe.

• Conteúdo com tecnologia de SEO e distribuição de relações públicas. Seja amplificado hoje.
• Platoblockchain. Inteligência Metaverso Web3. Conhecimento Ampliado. Acesse aqui.
• Fonte: https://aws.amazon.com/blogs/machine-learning/how-ccc-intelligent-solutions-created-a-custom-approach-for-hosting-complex-ai-models-using-amazon-sagemaker/