Diretrizes para desenvolver soluções de ML preditivas de alta qualidade

Last reviewed 2024-07-08 UTC

Este documento reúne algumas diretrizes para ajudar a avaliar, garantir e controlar a qualidade na criação de soluções de aprendizagem automática (ML) preditivas. Fornece sugestões para cada passo do processo, desde o desenvolvimento dos seus modelos de ML até à implementação dos seus sistemas de preparação e sistemas de publicação em produção. O documento expande as informações abordadas no Guia prático de MLOps realçando e resumindo os aspetos de qualidade em cada processo do ciclo de vida do MLOps.

Este documento destina-se a qualquer pessoa envolvida na criação, implementação e operação de soluções de AA. O documento pressupõe que tem conhecimentos gerais sobre MLOps. Não pressupõe que tenha conhecimentos de nenhuma plataforma de ML específica.

Vista geral da qualidade da solução de aprendizagem automática

Na engenharia de software, foram desenvolvidos muitos padrões, processos, ferramentas e práticas para garantir a qualidade do software. O objetivo é garantir que o software funciona conforme previsto na produção e que cumpre os requisitos funcionais e não funcionais. Estas práticas abrangem tópicos como testes de software, validação de software e registo de software e monitorização. No DevOps, estas práticas são normalmente integradas e automatizadas nos processos de CI/CD.

MLOps é um conjunto de processos e capacidades padronizados para criar, implementar e operar sistemas de ML de forma rápida e fiável. Tal como acontece com outras soluções de software, as soluções de software de ML exigem que integre estas práticas de qualidade de software e as aplique ao longo do ciclo de vida do MLOps. Ao aplicar estas práticas, ajuda a garantir a fiabilidade e a previsibilidade dos seus modelos, bem como a conformidade dos modelos com os seus requisitos.

No entanto, as tarefas de criação, implementação e funcionamento dos sistemas de ML apresentam desafios adicionais que requerem determinadas práticas de qualidade que podem não ser relevantes para outros sistemas de software. Além das caraterísticas da maioria dos outros sistemas de software, os sistemas de ML têm as seguintes caraterísticas:

  • Sistemas dependentes de dados. A qualidade dos modelos preparados e das respetivas previsões depende da validade dos dados usados para a preparação e enviados para pedidos de previsão. Qualquer sistema de software depende de dados válidos, mas os sistemas de ML deduzem a lógica para a tomada de decisões a partir dos dados automaticamente, pelo que dependem particularmente da qualidade dos dados.

  • Sistemas de preparação e publicação duplos. Normalmente, as cargas de trabalho de ML consistem em dois sistemas de produção distintos, mas relacionados: o sistema de preparação e o sistema de publicação. Um pipeline de preparação contínuo produz modelos preparados recentemente que são, em seguida, implementados para a publicação de previsões. Cada sistema requer um conjunto diferente de práticas de qualidade que equilibram a eficácia e a eficiência para produzir e manter um modelo com bom desempenho em produção. Além disso, as inconsistências entre estes dois sistemas resultam em erros e um mau desempenho preditivo.

  • Propensos a ficarem desatualizados. Os modelos degradam-se frequentemente após a implementação em produção porque não se adaptam às alterações no ambiente que representam, como alterações sazonais no comportamento de compra. Os modelos também podem não se adaptar às alterações nos dados, como novos produtos e localizações. Assim, monitorizar a eficácia do modelo em produção é um desafio adicional para os sistemas de ML.

  • Sistemas de tomada de decisões automatizados. Ao contrário de outros sistemas de software, em que as ações são cuidadosamente codificadas manualmente para um conjunto de requisitos e regras empresariais, os modelos de ML aprendem regras a partir de dados para tomar uma decisão. A parcialidade implícita nos dados pode levar os modelos a produzir resultados injustos.

Quando um modelo de ML implementado produz previsões incorretas, a má qualidade de ML pode ser o resultado de uma vasta gama de problemas. Alguns destes problemas podem surgir devido aos erros típicos de qualquer programa. No entanto, os problemas específicos da AA também podem incluir distorções e anomalias nos dados, juntamente com a ausência de procedimentos adequados de avaliação e validação do modelo como parte do processo de preparação. Outro problema potencial é o formato de dados inconsistente entre a interface integrada do modelo e a API de publicação. Além disso, o desempenho do modelo degrada-se ao longo do tempo, mesmo sem estes problemas, e pode falhar silenciosamente se não for monitorizado corretamente. Por conseguinte, deve incluir diferentes tipos de testes e monitorização para modelos e sistemas de ML durante o desenvolvimento, a implementação e a produção.

Diretrizes de qualidade para o desenvolvimento de modelos

Quando desenvolve um modelo de ML durante a fase de experimentação, tem os dois conjuntos de métricas de destino seguintes que pode usar para avaliar o desempenho do modelo:

  • As métricas de otimização do modelo. Esta métrica reflete a eficácia preditiva do modelo. A métrica inclui a precisão e a medida F em tarefas de classificação, erro percentual absoluto médio em tarefas de regressão e previsão, ganho cumulativo com desconto em tarefas de classificação e perplexidade e BLEU em modelos de linguagem. Quanto melhor for o valor desta métrica, melhor é o modelo para uma determinada tarefa. Em alguns exemplos de utilização, para garantir a equidade, é importante alcançar uma eficácia preditiva semelhante em diferentes segmentos dos dados, por exemplo, em diferentes dados demográficos dos clientes.
  • As métricas satisfatórias do modelo. Esta métrica reflete uma restrição operacional que o modelo tem de satisfazer, como a latência de previsão. Define um limite de latência para um valor específico, como 200 milissegundos. Qualquer modelo que não cumpra o limite não é aceite. Outro exemplo de uma métrica satisfatória é o tamanho do modelo, que é importante quando quer implementar o modelo em hardware de baixo consumo, como dispositivos móveis e incorporados.

Durante a experimentação, desenvolve, prepara, avalia e depura o modelo para melhorar a respetiva eficácia em relação às métricas de otimização, sem violar os limites das métricas satisfatórias.

Diretrizes para experimentação

  • Ter limites predefinidos e fixos para otimizar métricas e para métricas satisfatórias.
  • Implemente uma rotina de avaliação simplificada que recebe um modelo e dados e produz um conjunto de métricas de avaliação. Implemente a rotina para que funcione independentemente do tipo de modelo (por exemplo, árvores de decisão ou redes neurais) ou da framework do modelo (por exemplo, TensorFlow ou Scikit-learn).
  • Certifique-se de que tem um modelo de referência para comparar. Esta base pode consistir em heurísticas codificadas ou pode ser um modelo simples que preveja o valor alvo médio ou o valor alvo mais frequente. Use o modelo de base para verificar o desempenho do modelo de AA. Se o modelo de AA não for melhor do que o modelo de base, existe um problema fundamental no modelo de AA.
  • Monitorize todas as experiências realizadas para ajudar na reprodutibilidade e na melhoria incremental. Para cada experiência, armazene valores de hiperparâmetros, seleção de funcionalidades e sementes aleatórias.

Diretrizes para a qualidade de dados

  • Resolva quaisquer classes desequilibradas no início das suas experiências escolhendo a métrica de avaliação certa. Além disso, aplique técnicas como a ponderação excessiva de instâncias de classes minoritárias ou a subamostragem de instâncias de classes maioritárias.
  • Certifique-se de que compreende a origem de dados em questão e execute o pré-processamento de dados e a engenharia de funcionalidades relevantes para preparar o conjunto de dados de preparação. Este tipo de processo tem de ser repetível e automatizável.
  • Certifique-se de que tem uma divisão de dados de teste separada (retenção) para a avaliação final do modelo. A divisão de teste não deve ser vista durante a preparação e não deve ser usada para o ajuste de hiperparâmetros.
  • Certifique-se de que as divisões de preparação, validação e teste são igualmente representativas dos seus dados de entrada. A amostragem de uma divisão de teste deste tipo depende da natureza dos dados e da tarefa de ML em questão. Por exemplo, a divisão estratificada é relevante para tarefas de classificação, enquanto a divisão cronológica é relevante para tarefas de séries cronológicas.
  • Certifique-se de que as divisões de validação e teste são pré-processadas separadamente da divisão de dados de preparação. Se as divisões forem pré-processadas numa mistura, isso leva a uma fuga de dados. Por exemplo, quando usa estatísticas para transformar dados para normalização ou para agrupar características numéricas, calcule as estatísticas a partir dos dados de preparação e aplique-as para normalizar as divisões de validação e teste.
  • Gerar um esquema do conjunto de dados que inclua os tipos de dados e algumas propriedades estatísticas das caraterísticas. Pode usar este esquema para encontrar dados anómalos ou inválidos durante a experimentação e a preparação.
  • Certifique-se de que os dados de preparação são devidamente misturados em lotes, mas que continuam a cumprir os requisitos de preparação do modelo. Por exemplo, esta tarefa pode aplicar-se a distribuições de instâncias positivas e negativas.
  • Ter um conjunto de dados de validação separado para o ajuste de hiperparâmetros e a seleção de modelos. Também pode usar o conjunto de dados de validação para realizar a paragem antecipada. Caso contrário, pode permitir que o modelo seja preparado durante todo o conjunto de iterações máximas indicado. No entanto, só guarde um novo instantâneo do modelo se o respetivo desempenho no conjunto de dados de validação melhorar relativamente ao instantâneo anterior.

Diretrizes para a qualidade do modelo

  • Certifique-se de que os seus modelos não têm problemas fundamentais que os impeçam de aprender qualquer relação entre as entradas e as saídas. Pode alcançar este objetivo preparando o modelo com muito poucos exemplos. Se o modelo não atingir uma elevada precisão para estes exemplos, pode existir um erro na implementação do modelo ou na rotina de preparação.
  • Quando estiver a preparar redes neurais, monitorize os valores NaN na perda e a percentagem de ponderações com valores zero durante a preparação do modelo. Estes valores NaN ou zero podem ser indicações de cálculos aritméticos errados ou de gradientes que desaparecem ou explodem. A visualização das alterações na distribuição dos valores de ponderação ao longo do tempo pode ajudar a detetar as mudanças de covariáveis internas que atrasam a preparação. Pode aplicar a normalização em lote para aliviar esta redução na velocidade.
  • Compare o desempenho do modelo nos dados de preparação e nos dados de teste para perceber se o modelo está a ser demasiado específico ou demasiado geral. Se vir qualquer um destes problemas, faça as melhorias relevantes. Por exemplo, se houver um ajuste insuficiente, pode aumentar a capacidade de aprendizagem do modelo. Se houver sobreajuste, pode aplicar a regularização.
  • Analise as instâncias classificadas incorretamente, especialmente as instâncias com uma elevada confiança na previsão e as classes mais confusas na matriz de confusão de várias classes. Estes erros podem ser um indicador de exemplos de preparação com etiquetas incorretas. Os erros também podem identificar uma oportunidade para o pré-processamento de dados, como a remoção de valores atípicos, ou para a criação de novas funcionalidades que ajudem a discriminar entre essas classes.
  • Analise as pontuações de importância das funcionalidades e limpe as funcionalidades que não melhoram suficientemente a qualidade do modelo. Os modelos parcimoniosos são preferíveis aos complexos.

Diretrizes de qualidade para a implementação do pipeline de preparação

À medida que implementa o seu modelo e pipeline de preparação de modelos, tem de criar um conjunto de testes numa rotina de CI/CD. Estes testes são executados automaticamente à medida que envia novas alterações de código ou são executados antes de implementar o pipeline de preparação no ambiente de destino.

Diretrizes

  • Teste unitário da funcionalidade de engenharia de funcionalidades.
  • Teste de unidade a codificação das entradas para o modelo.
  • Testar as unidades dos módulos implementados pelo utilizador (personalizados) dos modelos de forma independente, por exemplo, testar as unidades da convolução de grafos personalizada e as camadas de agrupamento ou as camadas de atenção personalizadas.
  • Teste de unidade quaisquer funções de avaliação ou perda personalizadas.
  • Teste as formas e os tipos de saída do seu modelo em relação às entradas esperadas.
  • Teste de unidade que a função fit do modelo funciona sem erros num par de pequenos lotes de dados. Os testes devem garantir que a perda diminui e que o tempo de execução do passo de formação é o esperado. Faz estas verificações porque as alterações no código do modelo podem introduzir erros que atrasam o processo de preparação.
  • Teste de unidade a funcionalidade de guardar e carregar do modelo.
  • Teste de unidade as interfaces de fornecimento de modelos exportadas em relação a entradas não processadas e em relação a saídas esperadas.
  • Teste os componentes dos passos do pipeline com entradas simuladas e com artefactos de saída.
  • Implemente a pipeline num ambiente de teste e faça testes de integração da pipeline ponto a ponto. Para este processo, use alguns dados de teste para se certificar de que o fluxo de trabalho é executado corretamente e produz os artefactos esperados.
  • Use a implementação oculta quando implementar uma nova versão do pipeline de preparação no ambiente de produção. Uma implementação oculta ajuda a garantir que a versão da pipeline implementada recentemente é executada em dados em direto em paralelo com a versão da pipeline anterior.

Diretrizes de qualidade para a formação contínua

O processo de preparação contínua consiste em orquestrar e automatizar a execução de pipelines de preparação. Os fluxos de trabalho de preparação típicos incluem passos como a ingestão e a divisão de dados, a transformação de dados, a preparação de modelos, a avaliação de modelos e o registo de modelos. Alguns pipelines de preparação consistem em fluxos de trabalho mais complexos. As tarefas adicionais podem incluir a realização de preparação de modelos autossupervisionados que usam dados não etiquetados ou a criação de um índice de vizinho mais próximo aproximado para incorporações. A principal entrada de qualquer pipeline de preparação são os novos dados de preparação, e a principal saída é um novo modelo candidato para implementação em produção.

O pipeline de preparação é executado automaticamente na produção com base num horário (por exemplo, diário ou semanal) ou num acionador (por exemplo, quando estão disponíveis novos dados etiquetados). Por conseguinte, tem de adicionar passos de controlo de qualidade ao fluxo de trabalho de preparação, especificamente passos de validação de dados e passos de validação de modelos. Estes passos validam as entradas e as saídas dos pipelines.

Adiciona o passo de validação de dados após o passo de carregamento de dados no fluxo de trabalho de preparação. O passo de validação de dados cria perfis dos novos dados de preparação de entradas que são carregados para o pipeline. Durante a criação de perfis, o pipeline usa um esquema de dados predefinido, que foi criado durante o processo de desenvolvimento de ML, para detetar anomalias. Consoante o exemplo de utilização, pode ignorar ou simplesmente remover alguns registos inválidos do conjunto de dados. No entanto, outros problemas nos dados carregados recentemente podem interromper a execução do pipeline de preparação, pelo que tem de identificar e resolver esses problemas.

Diretrizes para a validação de dados

  • Verifique se as caraterísticas dos dados de preparação extraídos estão completas e se correspondem ao esquema esperado, ou seja, não existem caraterísticas em falta nem adicionadas. Verifique também se as funcionalidades correspondem aos volumes projetados.
  • Valide os tipos de dados e os formatos das caraterísticas no conjunto de dados que são carregados no pipeline de preparação.
  • Verifique se os formatos de determinadas caraterísticas (por exemplo, datas, horas, URLs, códigos postais e endereços IP) correspondem às expressões regulares esperadas. Verifique também se as funcionalidades estão dentro dos intervalos válidos.
  • Valide a fração máxima dos valores em falta para cada funcionalidade. Uma grande fração de valores em falta numa determinada funcionalidade pode afetar a preparação do modelo. Normalmente, os valores em falta indicam uma origem de elementos não fiável.
  • Valide os domínios das caraterísticas de entrada. Por exemplo, verifique se existem alterações num vocabulário de caraterísticas categóricas ou alterações no intervalo de caraterísticas numéricas e ajuste o pré-processamento de dados em conformidade. Por exemplo, os intervalos das caraterísticas numéricas podem mudar se uma atualização no sistema a montante que preenche as caraterísticas usar diferentes unidades de medida. Por exemplo, o sistema a montante pode alterar a moeda de dólares para ienes ou alterar as distâncias de quilómetros para metros.
  • Verifique se as distribuições de cada funcionalidade correspondem às suas expetativas. Por exemplo, pode testar se o valor mais comum de uma funcionalidade para o tipo de pagamento é cash e se este tipo de pagamento representa 50% de todos os valores. No entanto, este teste pode falhar se houver uma alteração no tipo de pagamento mais comum para credit_card. Uma alteração externa como esta pode exigir alterações no seu modelo.

Adiciona um passo de validação do modelo antes do passo de registo do modelo para garantir que apenas os modelos que passam nos critérios de validação são registados para implementação em produção.

Diretrizes para a validação de modelos

  • Para a avaliação final do modelo, use uma divisão de teste separada que não tenha sido usada para a preparação do modelo nem para o ajuste de hiperparâmetros.
  • Classifique o modelo candidato em comparação com a divisão de dados de teste, calcule as métricas de avaliação relevantes e verifique se o modelo candidato ultrapassa os limites de qualidade predefinidos.
  • Certifique-se de que a divisão dos dados de teste é representativa dos dados como um todo para ter em conta os diferentes padrões de dados. Para dados de séries cronológicas, certifique-se de que a divisão de teste contém dados mais recentes do que a divisão de preparação.
  • Teste a qualidade do modelo em segmentações de dados importantes, como utilizadores por país ou filmes por género. Ao testar dados segmentados, evita um problema em que os problemas de desempenho detalhados são ocultados por uma métrica de resumo global.
  • Avalie o modelo atual (campeão) em comparação com a divisão de dados de teste e compare-o com o modelo candidato (desafiador) produzido pelo pipeline de preparação.
  • Validar o modelo em relação aos indicadores de equidade para detetar preconceitos implícitos. Por exemplo, os preconceitos implícitos podem ser induzidos por uma diversidade insuficiente nos dados de preparação. Os indicadores de equidade podem revelar problemas de causa raiz que tem de resolver antes de implementar o modelo na produção.

Durante a preparação contínua, pode validar o modelo em função das métricas de otimização e das métricas satisfatórias. Em alternativa, pode validar o modelo apenas em função das métricas de otimização e adiar a validação em função da métrica de satisfação até à fase de implementação do modelo. Se planeia implementar variações do mesmo modelo em diferentes ambientes de publicação ou cargas de trabalho, pode ser mais adequado adiar a validação em função da métrica de satisfação. Diferentes ambientes de publicação ou cargas de trabalho (como ambientes na nuvem versus ambientes no dispositivo, ou ambientes em tempo real versus ambientes de publicação em lote) podem exigir limites de métricas de satisfação diferentes. Se estiver a fazer a implementação em vários ambientes, o pipeline de preparação contínua pode preparar dois ou mais modelos, em que cada modelo é otimizado para o respetivo ambiente de implementação de destino. Para mais informações e um exemplo, consulte o artigo Implementações duplas na Vertex AI.

À medida que implementa mais pipelines de formação contínua com fluxos de trabalho complexos, tem de acompanhar os metadados e os artefactos que as execuções do pipeline produzem. O acompanhamento destas informações ajuda a rastrear e depurar qualquer problema que possa surgir na produção. A monitorização das informações também ajuda a reproduzir os resultados dos pipelines para que possa melhorar a respetiva implementação em iterações de desenvolvimento de ML subsequentes.

Diretrizes para acompanhar os metadados e os artefactos de ML

  • Acompanhe a linhagem do código fonte, dos pipelines implementados, dos componentes dos pipelines, das execuções de pipelines, do conjunto de dados em utilização e dos artefactos produzidos.
  • Acompanhe os hiperparâmetros e as configurações das execuções do pipeline.
  • Acompanhe as principais entradas e artefactos de saída dos passos do pipeline, como estatísticas do conjunto de dados, anomalias do conjunto de dados (se existirem), dados transformados e esquemas, pontos de verificação do modelo e resultados da avaliação do modelo.
  • Monitorize se os passos do pipeline condicional são executados em resposta às condições e garanta a observabilidade adicionando mecanismos de alteração caso os passos principais não sejam executados ou falhem.

Diretrizes de qualidade para a implementação de modelos

Suponha que tem um modelo preparado que foi validado do ponto de vista das métricas de otimização e que o modelo foi aprovado do ponto de vista da gestão de modelos (conforme descrito mais adiante na secção gestão de modelos). O modelo é armazenado no registo de modelos e está pronto para ser implementado na produção. Neste ponto, tem de implementar um conjunto de testes para verificar se o modelo está adequado para publicação no respetivo ambiente de destino. Também tem de automatizar estes testes numa rotina de CI/CD de modelos.

Diretrizes

  • Verifique se o artefacto do modelo pode ser carregado e invocado com êxito com as respetivas dependências de tempo de execução. Pode fazer esta validação ao preparar o modelo numa versão de sandbox do ambiente de publicação. Esta validação ajuda a garantir que as operações e os ficheiros binários usados pelo modelo estão presentes no ambiente.
  • Valide as métricas satisfatórias do modelo (se existirem) num ambiente de preparação, como o tamanho e a latência do modelo.
  • Teste as interfaces de fornecimento de artefactos do modelo numa fase de preparação em relação a entradas não processadas e em relação a resultados esperados.
  • Teste de unidade o artefacto do modelo num ambiente de preparação para um conjunto de casos típicos e extremos de pedidos de previsão. Por exemplo, teste de unidade para uma instância de pedido em que todas as funcionalidades estão definidas como None.
  • Teste rapidamente a API do serviço de modelo depois de implementada no respetivo ambiente de destino. Para realizar este teste, envie uma única instância ou um lote de instâncias para o serviço de modelo e valide a resposta do serviço.
  • Teste canário da versão do modelo recém-implementada numa pequena stream de dados de publicação em direto. Este teste garante que o novo serviço de modelo não produz erros antes de o modelo ser exposto a um grande número de utilizadores.
  • Teste num ambiente de preparação que lhe permita reverter para uma versão anterior do modelo de publicação de forma rápida e segura.
  • Realize experiências online para testar o modelo recém-formado com um pequeno subconjunto da população de publicação. Este teste mede o desempenho do novo modelo em comparação com o atual. Depois de comparar o desempenho do novo modelo com o desempenho do modelo atual, pode decidir lançar totalmente o novo modelo para atender a todos os seus pedidos de previsão em direto. As técnicas de experimentação online incluem testes A/B e Multi-Armed Bandit (MAB).

Diretrizes de qualidade para o fornecimento de modelos

O desempenho preditivo dos modelos de AA implementados e em serviço na produção degrada-se normalmente ao longo do tempo. Esta degradação pode dever-se a inconsistências introduzidas entre as funcionalidades de publicação e as funcionalidades esperadas pelo modelo. Estas inconsistências são denominadas divergência entre a preparação e a publicação. Por exemplo, um modelo de recomendação pode estar à espera de um valor de entrada alfanumérico para uma funcionalidade, como o código de um produto visto mais recentemente. No entanto, o nome do produto, em vez do código do produto, é transmitido durante a publicação devido a uma atualização da aplicação que está a consumir o serviço do modelo.

Além disso, o modelo pode ficar desatualizado à medida que as propriedades estatísticas dos dados de publicação mudam ao longo do tempo e os padrões aprendidos pelo modelo implementado atual já não são precisos. Em ambos os casos, o modelo deixa de poder fornecer previsões precisas.

Para evitar esta degradação do desempenho preditivo do modelo, tem de monitorizar continuamente a eficácia do modelo. A monitorização permite-lhe verificar regularmente e de forma proativa se o desempenho do modelo se degrada.

Diretrizes

  • Registe uma amostra dos payloads de pedido-resposta de publicação num repositório de dados para análise regular. O pedido é a instância de entrada e a resposta é a previsão produzida pelo modelo para essa instância de dados.
  • Implemente um processo automatizado que crie perfis dos dados de pedido-resposta armazenados através do cálculo de estatísticas descritivas. Calcular e armazenar estas estatísticas de serviço a intervalos regulares.
  • Identifique a discrepância entre a preparação e a publicação causada pela mudança e pela deriva dos dados comparando as estatísticas dos dados de publicação com as estatísticas de base dos dados de preparação. Além disso, analise a forma como as estatísticas dos dados de publicação se alteram ao longo do tempo.
  • Identifique a deriva de conceitos analisando como as atribuições de funcionalidades para as previsões mudam ao longo do tempo.
  • Identifique instâncias de dados de publicação que são consideradas valores atípicos relativamente aos dados de preparação. Para encontrar estes valores atípicos, use técnicas de deteção de novidades e acompanhe a forma como a percentagem de valores atípicos nos dados de publicação muda ao longo do tempo.
  • Defina alertas para quando o modelo atingir os limites da pontuação de desequilíbrio nas principais funcionalidades preditivas no seu conjunto de dados.
  • Se as etiquetas estiverem disponíveis (ou seja, exatidão), junte as etiquetas verdadeiras às etiquetas previstas das instâncias de publicação para fazer uma avaliação contínua. Esta abordagem é semelhante ao sistema de avaliação que implementa como testes A/B durante a experimentação online. A avaliação contínua pode identificar não só o poder preditivo do seu modelo em produção, mas também identificar com que tipo de pedido tem um bom desempenho e com que tipo de pedido tem um mau desempenho.
  • Defina objetivos para as métricas do sistema que são importantes para si e meça o desempenho dos modelos de acordo com esses objetivos.
  • Monitorize a eficiência do serviço para se certificar de que o modelo pode ser publicado em produção em grande escala. Esta monitorização também ajuda a prever e gerir o planeamento da capacidade, e ajuda a estimar o custo da sua infraestrutura de publicação. Monitorize as métricas de eficiência, incluindo a utilização da CPU, a utilização da GPU, a utilização de memória, a latência do serviço, as taxas de transferência e a taxa de erro.

Gestão de modelos

A governação de modelos é uma função essencial nas empresas que fornece diretrizes e processos para ajudar os funcionários a implementar os princípios de IA da empresa. Estes princípios podem incluir evitar modelos que criem ou apliquem preconceitos e ser capazes de justificar as decisões tomadas pela IA. A função de gestão do modelo garante que existe um humano no circuito. A revisão humana é particularmente importante para cargas de trabalho sensíveis e de alto impacto (muitas vezes, orientadas para o utilizador). As cargas de trabalho como estas podem incluir a avaliação do risco de crédito, a classificação de candidatos a emprego, a aprovação de apólices de seguro e a propagação de informações nas redes sociais.

Diretrizes

  • Ter uma matriz de atribuição de responsabilidades para cada modelo por tarefa. A matriz deve considerar equipas multifuncionais (linhas de negócio, engenharia de dados, ciência de dados, engenharia de AA, risco e conformidade, entre outras) ao longo de toda a hierarquia da organização.
  • Mantenha a documentação e os relatórios do modelo no registo de modelos associado à versão de um modelo, por exemplo, através de cartões de modelo. Esses metadados incluem informações sobre os dados que foram usados para preparar o modelo, sobre o desempenho do modelo e sobre quaisquer limitações conhecidas.
  • Implemente um processo de revisão para o modelo antes de o aprovar para implementação em produção. Neste tipo de processo, mantém versões da lista de verificação do modelo, documentação suplementar e quaisquer informações adicionais que as partes interessadas possam solicitar.
  • Avalie o modelo em conjuntos de dados de referência (também conhecidos como conjuntos de dados de ouro), que abrangem casos padrão e casos extremos. Além disso, valide o modelo em relação aos indicadores de equidade para ajudar a detetar preconceitos implícitos.
  • Explicar aos utilizadores do modelo o comportamento preditivo do modelo como um todo e em instâncias de entrada de amostra específicas. O fornecimento destas informações ajuda a compreender as funcionalidades importantes e o possível comportamento indesejável do modelo.
  • Analise o comportamento preditivo do modelo através de ferramentas de análise de hipóteses para compreender a importância de diferentes caraterísticas dos dados. Esta análise também pode ajudar a visualizar o comportamento do modelo em vários modelos e subconjuntos de dados de entrada.
  • Teste o modelo em relação a ataques adversariais para ajudar a garantir que o modelo é robusto contra a exploração na produção.
  • Monitorize alertas sobre o desempenho preditivo dos modelos em produção, sobre mudanças no conjunto de dados e sobre a deriva. Configure os alertas para notificar os intervenientes do modelo.
  • Faça a gestão da experimentação, implementação e reversão online dos modelos.

O que se segue?

Colaboradores

Autor: Mike Styer | Arquiteto de soluções de IA generativa

Outro colaborador: Amanda Brinhosa | Customer Engineer