Testar e avaliar cargas de trabalho de IA no Azure
O objetivo dos testes em cargas de trabalho de IA é ajudar a garantir a qualidade quando uma mudança é introduzida no sistema. Os testes podem validar se a carga de trabalho atende às metas identificadas e atende às expectativas do usuário. Também evita regressões de qualidade. Esse processo inclui a realização de testes em várias áreas funcionais e a avaliação da qualidade da funcionalidade, do manuseio de carga, da previsibilidade e de outros critérios com base nos requisitos da carga de trabalho.
Os resultados do teste fornecem pontos de dados críticos para decisões como se os componentes de IA estão prontos para lançamento e quais SKUs ou recursos são apropriados. Além disso, os testes podem servir como um sistema de notificação de falhas e ajudar a detetar problemas na produção por meio de testes de rotina ou sintéticos.
O Azure Well-Architected Framework descreve uma metodologia de teste abrangente. Você deve usar vários tipos de testes em diferentes estágios do ciclo de vida de desenvolvimento e em diferentes componentes e fluxos do sistema. Sem esses testes, as alterações implementadas podem degradar a qualidade do sistema. Por exemplo, pequenos erros de código podem se tornar grandes falhas do sistema. O comportamento do sistema pode se tornar imprevisível ou produzir resultados tendenciosos devido à natureza não determinística dos sistemas de IA. Além disso, a alocação de recursos pode ser ineficiente e os dados reais do usuário ou os recursos do sistema podem ser explorados porque esses sistemas são vulneráveis a abusos.
Você deve projetar e desenvolver ativos de carga de trabalho com testes em mente. Por exemplo, quando você executa a manipulação de dados e remodela os dados de origem para engenharia de recursos, siga as boas práticas de codificação e garanta que estrutura o código para dar suporte a testes. Essa estratégia inclui projetar o código para facilitar o teste de unidade eficaz e isolar os testes da funcionalidade do código e suas dependências. Neste exemplo, você deve projetar um sistema que possa ser executado em um ambiente de teste com dados de teste suficientemente representativos em termos de volume e semelhança.
Você deve implantar componentes de carga de trabalho na produção com segurança. Parte das práticas de implantação seguras de qualquer carga de trabalho é o teste estratégico para ajudar a garantir o comportamento correto antes que os usuários ou dados consumam o sistema. Os testes estratégicos são essenciais durante a implantação inicial e à medida que o sistema evolui e sofre alterações de código ou infraestrutura. Teste todas as alterações propostas no código e na infraestrutura relacionados à IA antes de implantar as alterações na produção.
Este artigo se concentra na aplicação dessa metodologia aos aspetos de IA da arquitetura. Como realizar esses testes não está no escopo.
Recomendações
Aqui está o resumo das recomendações fornecidas neste artigo.
| Recomendação | Description |
|---|---|
| Defina métricas de sucesso para sua estratégia de teste. | Como qualquer outro tipo de teste de carga de trabalho, você precisa capturar e analisar as métricas apropriadas para um determinado teste para garantir que seu teste forneça informações úteis sobre sua carga de trabalho de IA. ▪ Definir métricas de sucesso |
| Conduza testes de ponta a ponta de seus pipelines de ingestão e processamento de dados durante todo o ciclo de vida do desenvolvimento. | Os testes podem validar os dados e ajudá-lo a garantir que o processo de manipulação de dados funcione como pretendido. Incorpore testes no início da fase de projeto para garantir a qualidade dos dados e a tecnologia apropriada e as opções de dimensionamento. Desenvolva testes de unidade para código personalizado durante o desenvolvimento e conduza testes de produção em tempo real para detetar problemas e validar a funcionalidade. ▪ Ingestão de dados de teste |
| Execute testes para trabalhos de treinamento para garantir que os scripts sejam invocados e funcionem conforme o esperado. | Os testes de carga e desempenho podem fornecer informações sobre a escolha e o dimensionamento da computação adequada para executar os trabalhos. Os testes de unidade podem validar a utilidade do código e capturar regressões quando as dependências são atualizadas. ▪ Testar o fluxo de trabalho de treinamento |
| Avalie e teste o modelo para evitar duplicação nos dados de treinamento, avaliação e teste. | Para garantir que os dados de origem não sejam totalmente usados para treinamento, você deve reservar dados exclusivos para avaliação de modelo e teste final. Esses subconjuntos não estão incluídos no processo de treinamento real. ▪ Avaliar e testar o modelo |
| Teste o ponto de extremidade de inferência. | Realize testes de carga no ponto de extremidade que seu servidor de inferência hospeda e escolha SKUs de GPU com base nesses resultados de teste. Para endpoints hospedados em plataforma como serviço (PaaS), taxa de transferência de teste e possíveis falhas. Esses pontos de extremidade são acessíveis, portanto, realize testes de segurança adequados para evitar situações de jailbreak. ▪ Testar o ponto final de inferência |
| Teste a correção do design do índice para que as consultas produzam resultados relevantes. | Os testes funcionais e de integração ajudam a garantir que os dados sejam precisos e o teste de esquema de índice verifica a compatibilidade com versões anteriores. Você deve testar as etapas de pré-processamento quanto à qualidade. O teste de carga determina SKUs adequados para recursos e os controles de segurança protegem a confidencialidade dos dados. ▪ Testar os dados de aterramento |
| Teste o orquestrador para validar sua funcionalidade e segurança. | Conduza testes de unidade, funcionais, de integração e de tempo de execução, incluindo testes de modo de carga e falha, para garantir desempenho e confiabilidade. Os testes de segurança e de segurança de conteúdo também são cruciais para proteger o sistema e os dados. ▪ Teste o orquestrador |
| Teste de decaimento do modelo. | A deterioração do modelo é um problema inevitável que afeta a maioria das cargas de trabalho de IA. O teste de dados e desvio de conceito pode ajudá-lo a detetar o decaimento do modelo antecipadamente e mitigar o problema antes que ele afete adversamente sua carga de trabalho. ▪ Evitar a deterioração do modelo |
Definir métricas de sucesso
Recomendamos que você tenha uma linha de base e meça o poder preditivo do modelo usando métricas bem definidas. Aqui estão algumas métricas comuns.
A precisão representa a proporção de instâncias previstas corretamente para o total de instâncias no conjunto de dados de teste. É uma medida comum do desempenho geral do modelo.
Precisão é a relação entre previsões positivas verdadeiras e a soma de verdadeiros positivos e falsos positivos. É útil quando minimizar falsos positivos é importante, como em diagnósticos médicos, por exemplo.
A sensibilidade mede a proporção de verdadeiros positivos para a soma de verdadeiros positivos e falsos negativos. É valioso quando evitar falsos negativos, ou faltar casos relevantes, é fundamental.
A especificidade calcula a razão entre os verdadeiros negativos e a soma dos verdadeiros negativos e dos falsos positivos. É relevante quando você otimiza para previsões negativas precisas.
Nota
Ao definir métricas de sucesso para modelos de regressão, considere adicionar as seguintes métricas:
O Erro Absoluto Médio (MAE) mede a diferença absoluta média entre os valores previstos e os valores reais. Calcule-o tomando a média das diferenças absolutas entre cada valor real e seu valor previsto correspondente. O MAE é menos sensível a valores anómalos em comparação com as MPE e o RMSE.
O Erro Quadrático Médio (MPE) mede a diferença quadrática média entre os valores reais e os valores previstos. Calcule-o tomando a média das diferenças ao quadrado entre cada valor real e seu valor previsto correspondente. O MSE penaliza os erros maiores mais fortemente do que o MAE porque os erros são quadrados.
RMSE (Root Mean Squared Error) é a raiz quadrada do MSE. Fornece uma medida do erro absoluto médio entre os valores reais e previstos, mas nas mesmas unidades que os dados originais. O RMSE é mais sensível a valores atípicos em comparação com o MAE porque quadra os erros antes da média.
Ingestão de dados de teste
Pipelines de dados, como processos de extração, transformação e carregamento (ETL), movem e manipulam dados. Teste a parte ETL da carga de trabalho para certificar-se de que ela ingere dados de forma confiável e que os dados são de alta qualidade e aceitáveis para análise e engenharia de recursos. Certifique-se de que a limpeza e o processamento de dados incluam testes para confirmar se a manipulação de dados funciona como pretendido.
Os ensaios devem ser integrados ao longo de todo o ciclo de vida, incluindo as fases de conceção, desenvolvimento e produção.
Teste para facilitar as escolhas de design
Quando você reúne requisitos para a carga de trabalho, uma etapa importante para a tomada de decisão é escolher uma opção de tecnologia específica que seja viável para o seu projeto.
Com base em seus requisitos de ETL e critérios de aceitação, realize testes funcionais exploratórios para selecionar o produto mais adequado, suas SKUs e recursos que executam as tarefas pretendidas. Testes de prova de conceito, prova de tecnologia e prova de capacidades são essenciais para avaliar se você está escolhendo a tecnologia certa e se ela está dimensionada adequadamente.
Para cenários em que você incorpora IA em uma arquitetura existente, teste o quão bem a nova tecnologia pode se integrar ao sistema atual.
Os requisitos iniciais da carga de trabalho podem mudar. Suponha que a empresa antecipa o crescimento e o sistema precisa lidar com o dobro das consultas regulares dos usuários. Essa expectativa requer um planejamento de capacidade adequado. Recomendamos testes proativos para entender como o sistema responde aos dados extras e para fazer ajustes orientados por dados no dimensionamento existente ou fazer novas escolhas de produtos. Para testes de capacidade, recomendamos que você combine testes funcionais com testes de carga e desempenho e use sintéticos para simular condições realistas.
Teste para garantir a qualidade do código
Quando o código for incluído, certifique-se de que ele passe por testes de unidade e não seja liberado se falhar. Por exemplo, é comum ter código personalizado que é executado como parte da ingestão. Há também o código usado para limpeza e processamento de dados. Execute testes de unidade para garantir que o código se comporte de acordo com seu design e que a manipulação de dados funcione conforme o esperado.
Execute testes como parte de sua integração contínua e pipeline de entrega contínua.
Teste no sistema ao vivo
Os testes funcionais devem estender-se ao sistema ativo. Se esses testes falharem, considere acionar alertas para iniciar investigações imediatas, se necessário. Seguem-se alguns exemplos:
Execute testes agendados para verificar se o volume correto de dados foi coletado se os dados forem ingeridos em um cronograma definido com uma quantidade esperada.
Execute testes que detetam problemas de dados, como valores ausentes ou dados duplicados, e execute verificações básicas de integridade de dados. Se os dados contiverem informações temporais que indiquem sua atualização, esses testes poderão verificar essas informações e, potencialmente, impedir que processos a jusante usem dados obsoletos.
Verifique a disponibilidade de dependências externas. Por exemplo, um trabalho de limpeza de dados pode chamar outro serviço para extrair tabelas ou pré-processamento. Execute testes para garantir que eles estejam disponíveis porque sua indisponibilidade pode afetar o processo de ETL.
Outra maneira de testar a correção do sistema ETL na produção é através de testes sintéticos. Ter dados de teste conhecidos disponíveis em produção é altamente eficaz. Você pode usá-lo para validar o processamento de ponta a ponta comparando o estado inicial conhecido com o estado final esperado para esses dados. Por exemplo, um documento é obrigado a passar por inteligência documental e contém dados pessoais. Injetar um documento sintético pode testar se a carga de trabalho executa o trabalho de manipulação de dados conforme pretendido.
Além disso, experimente liberando diferentes experiências, também conhecidas como testes A/B, para aprender com as interações do usuário antes de se comprometer totalmente. Os testes A/B ajudam a evitar regressões de qualidade.
Dados de teste coletados durante a ingestão
Como parte do processo de ingestão de várias fontes de dados, inclua testes para validar se os dados de treinamento correspondem às suas expectativas.
Treinar um modelo de aprendizado de máquina com dados incompletos ou corrompidos pode ser contraproducente. Isso pode levar a esforços desperdiçados e resultar em um modelo que não consegue fazer previsões significativas. Seus pipelines de ingestão e pré-processamento de dados incluem testes de qualidade como pontos de verificação. Esses testes podem ajudá-lo a verificar se seus dados estão alinhados com as expectativas definidas durante a análise de dados e a engenharia de recursos.
A lista a seguir inclui alguns exemplos de casos de teste:
Teste de completude. Teste a quantidade esperada de dados de treinamento para verificar a integridade do conjunto de dados. Esse teste garante que você forneça dados suficientes para treinar o modelo.
Teste para obter informações críticas. Se o treinamento for baseado em entidades conhecidas, como registros ou identificadores específicos, teste o conjunto de dados para certificar-se de que essas entidades estão presentes. Essa validação garante que informações críticas não faltem.
Teste para dados irrelevantes. Os dados ingeridos não devem conter entradas irrelevantes ou incorretas. O processo de ingestão de dados deve filtrar esses dados.
Teste de frescura. A atualização dos dados ingeridos não deve afetar o poder preditivo do modelo. Valide se os dados refletem informações razoavelmente atuais e não estão desatualizados de execuções anteriores. Por exemplo, se você espera que os dados incluam registros da semana passada, mas não há esses registros depois de importar os dados, isso pode indicar uma falha na importação ou um problema de atualização de dados no sistema de origem.
Realizar testes de rotina
Uma preocupação significativa com a ingestão de dados é o volume de dados e a taxa de transferência. A avaliação contínua durante as operações é necessária para evitar gargalos de desempenho. Essa avaliação contínua deve fazer parte de seus processos operacionais e não apenas um teste único. O objetivo é garantir que a equipe de carga de trabalho não perca seus objetivos de nível de serviço.
Considere uma situação em que o monitoramento indique degradação do desempenho. Para mitigar tais condições, reavaliar e otimizar os processos de ETL. Depois de fazer alterações, os testes de desempenho podem ajudá-lo a garantir que as modificações atendam à taxa de transferência necessária.
Nota
Os testes e a monitorização servem diferentes propósitos. Realize testes para avaliar possíveis alterações no sistema, normalmente antes de implementar quaisquer alterações. Realizar monitoramento continuamente para avaliar a integridade geral do sistema.
Testar o fluxo de trabalho de treinamento
Treine um modelo usando código personalizado, como scripts PyTorch, que fazem o trabalho de treinamento real. Esses scripts são executados em computação, como em notebooks ou trabalhos do Azure Machine Learning, que também exigem memória e recursos de rede. Recomendamos testes de carga durante a fase de projeto para avaliar as necessidades de computação e garantir que as SKUs propostas sejam adequadas. Muitas vezes, você precisa de testes manuais para determinar a melhor configuração para executar eficientemente a carga de trabalho dentro do limite de tempo.
Escreva os scripts usando SDKs especializados, que lidam com a maioria das tarefas. No entanto, como os scripts ainda são código, você deve integrar o teste de unidade como parte do desenvolvimento. Esses testes ajudam a garantir que nenhuma regressão ocorra quando você atualiza dependências. Se o teste de unidade não for possível, o teste manual será necessário antes de implantar um novo código para evitar regressões de qualidade.
Esses scripts são executados como parte de um fluxo de trabalho, como o estúdio do Azure Machine Learning, que pode fornecer informações sobre quando e se o script foi executado. Mas recomendamos que você execute testes de integração para garantir que esses scripts sejam invocados de forma confiável.
Avaliar e testar o modelo
Nota
A avaliação e o teste de modelos são frequentemente usados de forma intercambiável, mas devem ser considerados processos separados que usam conjuntos de dados distintos. A avaliação é uma atividade iterativa que você faz durante a fase de desenvolvimento. Ele se concentra na experimentação para encontrar o melhor modelo com o nível certo de afinação. Inclui ajustar hiperparâmetros, configurações ou recursos e, em seguida, avaliar o modelo com base em várias métricas. Depois de identificar o melhor modelo, realize testes durante a implantação.
Os testes incluem a verificação de todo o sistema, incluindo o modelo ajustado e componentes não IA, para verificar se eles funcionam corretamente, se integram bem e entregam os resultados esperados de acordo com os padrões de qualidade. Avalie um modelo in situ juntamente com outros componentes da carga de trabalho. O processo inclui o envio de solicitações para o modelo, a avaliação de suas respostas e a tomada de uma decisão de ir ou não com base nos dados do teste. Embora o teste seja inegociável antes da produção, recomendamos que você também realize testes na produção usando dados reais e dados sintéticos.
Usar dados para avaliar e testar
Normalmente, há três conjuntos de dados principais particionados a partir dos dados de origem: treinamento, avaliação e teste.
Use o conjunto de dados de treinamento, que geralmente é o maior subconjunto, para treinar o modelo. Use outro conjunto de dados para avaliação para refinar o modelo através de um processo iterativo, avaliando diferentes permutações. Depois de encontrar uma permutação satisfatória, teste-a em relação ao conjunto de dados de teste.
Todos os conjuntos de dados devem conter dados de alta qualidade para minimizar o ruído. Seus casos de teste em pipelines de ingestão e pré-processamento de dados podem servir como pontos de verificação de qualidade. A falta de amostras também pode ser atribuída a dados de baixa qualidade. Use dados sintéticos para equilibrar e obter uniformidade no conjunto de dados. Essa abordagem é útil para treinar modelos como modelos de deteção de fraude, onde instâncias reais de fraude são raras, o que dificulta a obtenção de poder estatístico suficiente para previsões confiáveis.
Para evitar distorções nas previsões, mantenha todos os conjuntos de dados distintos. Você não deve usar dados de treinamento para avaliação e não deve usar dados de avaliação para testes. Reserve dados exclusivos para avaliação do modelo e teste final.
Usar métricas de avaliação
Treinar um modelo e selecionar o certo para a produção são processos interdependentes. Você precisa escolher um modelo inicialmente, mas ele pode mudar após experimentação e avaliação.
A avaliação de modelos segue como um loop de experimentação que avalia inúmeras permutações de modelos, parâmetros e recursos usando métricas. Essas métricas fornecem classificações científicas, que você deve comparar iterativamente em diferentes versões e configurações para determinar o melhor modelo. Para obter mais informações, consulte Métricas de avaliação.
Uma abordagem semelhante se aplica a modelos de IA generativa. Ter processos que avaliem e quantifiquem resultados da experiência do utilizador com base no desempenho do modelo. Por exemplo, a fundamentação é uma das principais métricas que quantifica o quão bem o modelo se alinha com os dados de origem. A relevância é outra métrica importante que indica o quão pertinente é a resposta à consulta. Por exemplo, métricas, consulte Métricas de avaliação e monitoramento para IA generativa.
Avalie diferentes tipos de modelos usando várias métricas. A importância de cada métrica pode variar dependendo do cenário. Priorize métricas com base no caso de uso. Por exemplo, a equidade é crucial numa IA responsável. Apesar dos bons testes, os modelos ainda podem apresentar preconceitos injustos devido a dados de origem tendenciosos. Os resultados podem ter uma pontuação alta em relevância, mas baixa em equidade. Integrar avaliações de equidade no processo para garantir resultados imparciais.
A IA generativa integra-se com código de orquestração, lógica de roteamento e um índice para geração aumentada de recuperação (RAG), o que complica a avaliação. Embora você deva avaliar os modelos individualmente usando métricas, também é importante avaliar outros componentes do sistema.
Testar o modelo
O ajuste fino é essencialmente um teste porque modifica um modelo pré-treinado para mudar seu comportamento. É necessário começar com uma linha de base para entender o desempenho inicial do modelo. Após o ajuste fino, reavalie o desempenho do modelo para garantir que ele atenda aos padrões de qualidade. Considere as seguintes métricas de avaliação comuns:
A fundamentação refere-se ao alinhamento do modelo com os dados de origem. Um modelo fundamentado gera respostas coerentes com a realidade.
A relevância indica a pertinência da resposta a uma determinada pergunta. Uma resposta altamente fundamentada pode não ter relevância se não abordar a questão diretamente.
A semelhança mede a semelhança entre um texto de dados de origem e a resposta gerada. O modelo utilizou uma formulação precisa? A falta de governança editorial pode diminuir a pontuação de similaridade.
A recuperação indica a eficácia das consultas de índice. Avalie o quão bem os dados do índice recuperados estão alinhados com a pergunta. Dados irrelevantes da pesquisa de índice diminuem essa pontuação. Pontuações de recuperação mais altas indicam menor variabilidade porque dependem apenas das consultas de índice.
A fluência está relacionada com o uso do vocabulário. Se o modelo aderir a um guia de estilo e apresentar conteúdo no formato apropriado, ele pode ser fluente, mesmo que não tenha fundamento ou relevância.
A coerência avalia se o discurso do modelo flui de forma natural e coerente. Ele avalia se a conversa parece uma troca genuína.
Hiperparâmetros de teste
Os parâmetros do modelo dependem de decisões de projeto específicas da aplicação. Como parte do design do aplicativo, escolha o modelo e os parâmetros com base nos casos de uso da carga de trabalho. O processo de teste tem um loop interno iterativo onde os dados de treinamento são comparados com os dados de teste para validar que o modelo está treinando no conjunto de dados pretendido. Além disso, os parâmetros são ajustados para que o modelo possa fazer previsões com um nível aceitável de precisão.
Compensação. O loop interno inclui os custos computacionais de treinamento do modelo e o custo de avaliá-lo através de testes. Você deve considerar o tempo que o treinamento e o teste do modelo exigem nesse ciclo. Espere que o processo de teste demore mais do que o processo de treinamento. Você pode fazer testes iniciais em um subconjunto de dados de treinamento para avaliar se o modelo produz resultados razoáveis. Você pode expandir gradualmente esse conjunto de testes para o conjunto de dados completo.
Testar o ponto final de inferência
Um ponto de extremidade de inferência é a API REST que permite o acesso a modelos para fazer previsões. É a interface onde você envia dados como parte da solicitação e obtém uma resposta que contém resultados do modelo. O ponto de extremidade é hospedado em computação, que pode ser PaaS como o Azure OpenAI Service ou um servidor de inferência que não seja da Microsoft, como NVIDIA Triton Inference Server, TorchServe e BentoML. Em cenários de PaaS, o provedor de serviços lida com o teste até certo ponto. No entanto, se você hospedar o endpoint, trate-o como qualquer outra API e teste-o completamente.
Embora você teste o modelo durante o treinamento e a avaliação, testar o ponto de extremidade de inferência envolve garantir que os mecanismos em torno desse modelo, como processamento de solicitação, criação de resposta, dimensionamento e coordenação entre instâncias, funcionem corretamente. Crie um plano de teste abrangente que cubra casos de uso com base em suas necessidades. Esta seção descreve alguns exemplos de casos de teste e tipos de teste a serem considerados.
Considerações de teste para servidores de hospedagem de inferência
É importante entender as características de carga da computação e validar o desempenho por meio de testes de carga. Essas ações ajudam você a escolher tecnologias ao projetar ou otimizar a arquitetura. Por exemplo, diferentes servidores de inferência têm características de desempenho variáveis. O código consome ciclos de CPU e memória à medida que o número de conexões simultâneas aumenta. Entenda como seu código e os recursos de computação funcionam em condições padrão e de pico de carga. O Teste de Carga do Azure é uma boa opção para testes de carga e pode gerar carga de alto volume. Outras opções de código aberto, como o Apache JMeter, também são populares. Considere invocar esses testes diretamente do seu ambiente. Por exemplo, o Machine Learning integra-se bem com o Teste de Carga.
Outra decisão importante é a escolha dos recursos da GPU. Muitos modelos requerem GPUs para inferência eficaz devido ao seu design. O teste de carga ajuda a entender os limites de desempenho de uma GPU SKU e evita o provisionamento excessivo, que são considerações financeiras significativas.
Para plataformas de hospedagem não-PaaS, a segurança é crucial porque a API é exposta publicamente. É importante garantir que o endpoint não seja explorado ou comprometido, o que pode comprometer todo o sistema. Inclua esse ponto de extremidade como parte de seus testes de segurança de rotina, juntamente com outros pontos de extremidade públicos. Considere a realização de testes, como testes de penetração, no sistema ao vivo. Outro aspeto da segurança é a segurança do conteúdo. Seu código pode chamar APIs especializadas que detetam conteúdo nocivo na carga útil de solicitação e resposta. A Segurança de Conteúdo de IA do Azure pode ser chamada a partir do seu teste para facilitar os testes de segurança de conteúdo.
Para obter as principais estratégias, consulte Recomendações para testes de segurança.
Considerações de teste para pontos de extremidade de inferência PaaS
O cliente deve esperar erros quando envia solicitações para o ponto de extremidade de inferência no serviço PaaS. Falhas podem ocorrer devido à sobrecarga do sistema, back-ends sem resposta e outras condições de erro. Conduza a análise do modo de falha no serviço e teste essas possíveis falhas. A análise do modo de falha é necessária para projetar e implementar estratégias de mitigação no código do cliente. Por exemplo, as APIs do Azure OpenAI limitam as solicitações retornando um código de resposta de erro HTTP 429. O cliente deve lidar com esse erro usando mecanismos de repetição e disjuntores. Para obter mais informações, consulte Recomendações para executar a análise do modo de falha.
O teste de serviços PaaS pode ajudá-lo a selecionar SKUs de serviço porque você entende os custos associados, como computação pré-provisionada ou pré-provisionada. Use as calculadoras de preços do Azure para avaliar cargas de trabalho, frequência e uso de token para determinar as melhores opções de cobrança e computação. Simule cargas de trabalho com SKUs de baixo custo e justifique opções high-end, como unidades de taxa de transferência provisionadas (PTUs) para o Azure OpenAI.
O teste de carga não é tão relevante para computação pré-paga porque, com capacidade infinita, você não encontra problemas. Os testes validam os limites e as quotas. Não recomendamos testes de carga para computação pré-paga porque é uma despesa financeira significativa. No entanto, você deve carregar o teste para verificar a taxa de transferência, que é medida em tokens por minuto ou solicitações por minuto. Ao contrário das APIs padrão que consideram métricas como o tamanho da solicitação, essa abordagem avalia cargas de trabalho com base em tokens para determinar o uso. A chave é entender o número de usuários ativos e medir a taxa de transferência de acordo. Para obter mais informações, consulte Medir sua taxa de transferência.
Utilizar controlos de segurança
Independentemente de você usar um servidor de inferência ou uma opção PaaS, a segurança é sua responsabilidade. Com os endpoints de API, é crucial testar o jailbreak e os controles de segurança de conteúdo. Certifique-se de que esses controles não podem ser ignorados e estão funcionando conforme o esperado. Por exemplo, enviar um item bloqueado conhecido pode ajudá-lo a verificar se os controles de segurança estão em vigor e funcionando corretamente antes da implantação. Considere executar esses testes conforme necessário ou integrá-los ao processo de liberação.
É importante testar se o sistema pode expor inadvertidamente informações que não deveria. Por exemplo, o sistema não deve expor informações pessoais na carga útil de resposta. Além disso, teste para certificar-se de que um cliente não pode acessar pontos de extremidade destinados a outras identidades. Realize testes de segurança para verificar se a API, com seus mecanismos de autenticação e autorização, não vaza informações confidenciais e mantém a segmentação adequada do usuário.
Testar os dados de aterramento
O design de dados influencia a eficiência de um modelo generativo, e os dados de aterramento são o componente crítico. Os dados de fundamentação fornecem mais contexto para aumentar a relevância da resposta. É indexado antes de chegar ao modelo. Este índice é acedido em tempo real enquanto o utilizador aguarda uma resposta.
Realize testes de ponta a ponta e incorpore esse processo como parte do design de dados. Implemente um processo de teste que avalie e quantifique os resultados da experiência do cliente com base no desempenho, orquestração, índice, pré-processamento e dados de origem do modelo. Monitore e meça as métricas de qualidade iterativamente. Aqui estão algumas considerações:
Teste completamente o processamento de dados usando testes funcionais e de integração. Verifique se os dados estão carregados conforme o esperado e se todos os dados estão presentes.
Teste o esquema de índice quanto à compatibilidade com versões anteriores. Você deve testar qualquer alteração em um documento ou campo para garantir que a nova versão ainda possa acomodar versões anteriores de dados.
Antes de serem indexados, os dados passam por uma preparação para reduzir o ruído e o enviesamento e permitir consultas eficientes. Esse processo inclui pré-processamento, fragmentação e cálculo de incorporações, e cada etapa salva dados no contexto ou nos arquivos do índice. Um pipeline de orquestração, como conjuntos de habilidades fornecidos pelo Azure AI Search, conduz essas etapas. Você deve testar o código de orquestração para garantir que nenhuma etapa seja perdida e que os dados processados sejam de alta qualidade.
Os testes devem verificar dados antigos, valores sintéticos, tabelas vazias, atualização de dados e processamento na versão mais recente. Se ocorrerem falhas de teste, talvez seja necessário ajustar a consulta de pesquisa e o índice. Este processo inclui o ajuste de filtros e outros elementos discutidos anteriormente. Você deve pensar no teste como uma atividade iterativa.
Os índices são complexos e o desempenho da consulta pode variar com base na estrutura do índice, o que requer estimativa de carga. O teste de carga adequado pode ajudar a determinar as diferentes SKUs para armazenamento, computação e outros recursos disponíveis para dar suporte às suas necessidades.
Você deve testar todos os controles de segurança. Por exemplo, os dados podem ser particionados em documentos separados. Cada partição tem controles de acesso. Você deve testar adequadamente esses controles para proteger a confidencialidade.
Teste o orquestrador
Um componente-chave de uma aplicação RAG é o orquestrador central. Esse código coordena várias tarefas que se relacionam com a pergunta inicial do usuário. As tarefas do orquestrador normalmente exigem uma compreensão da intenção do usuário, uma conexão com o índice para pesquisar dados de aterramento e chamar o ponto de extremidade de inferência. Se os agentes precisarem executar tarefas, como chamar APIs REST, esse código manipulará essas tarefas dentro do contexto.
Você pode desenvolver código de orquestração em qualquer idioma ou escrevê-lo do zero. No entanto, recomendamos que você use tecnologias como o fluxo de prompt no Azure AI Studio ou os DAGs (Directed Acyclic Graphs) do Apache Airflow para acelerar e simplificar o processo de desenvolvimento. O fluxo de prompt fornece uma experiência de tempo de design. Use-o para modularizar tarefas como unidades e conectar entradas e saídas de cada unidade, formando o código de orquestração, que representa todo o processo.
Isole seu código de orquestração. Desenvolva-o separadamente e implante-o como um microsserviço com um endpoint online e API REST para acesso. Essa abordagem garante modularidade e facilidade de implantação.
De uma perspetiva de teste, trate esse código como qualquer outro código e conduza testes de unidade. No entanto, o aspeto mais importante é sua funcionalidade, como sua lógica de roteamento, que você pode validar por meio de testes funcionais e de integração. Teste a engenharia de prompt para garantir que o código possa detetar a intenção do usuário e rotear chamadas adequadamente. Existem várias estruturas e bibliotecas para testes, como o Scikit-learn, o módulo torch.testing do PyTorch, o FairML para testes de viés e equidade e o TensorFlow Model Analysis para avaliação de modelos.
Além disso, conduza testes de tempo de execução, como testes de modo de falha. Por exemplo, teste possíveis falhas relacionadas a limitações de token.
Certos testes de tempo de execução podem ajudá-lo a tomar uma decisão. Execute testes de carga para entender como esse código se comporta sob estresse e use os resultados para o planejamento de capacidade. Como esse código está posicionado em um ponto crucial da arquitetura onde precisa alcançar outros serviços, ele pode ajudar a coletar telemetria de todas essas chamadas. Esses dados podem fornecer informações sobre quanto tempo é gasto no processamento local versus chamadas de rede e determinar o comportamento de outros componentes, como latência potencial. Tecnologias como o fluxo imediato têm recursos de telemetria integrados para facilitar esse processo. Caso contrário, incorpore a telemetria em seu código personalizado.
Nota
Testar este código tem implicações em termos de custos. Por exemplo, se você usar o Azure OpenAI para hospedar seu ponto de extremidade de inferência, o teste de esforço é uma prática comum que pode ajudá-lo a determinar os limites do sistema. No entanto, o Azure OpenAI cobra por cada chamada, o que pode tornar os testes de esforço extensivos caros. Uma maneira de otimizar as cobranças é usar PTUs não utilizadas do Azure OpenAI em um ambiente de teste. Como alternativa, você pode simular o ponto de extremidade de inferência.
As preocupações de segurança aplicam-se tanto ao código de orquestração como ao modelo. Inclua testes para jailbreaking, onde o objetivo é quebrar a segurança do modelo. Os atacantes não interagem diretamente com o modelo. Eles interagem com o código de orquestração primeiro. O código de orquestração recebe solicitações do usuário e as analisa. Se o código de orquestração receber uma solicitação mal-intencionada, ele poderá encaminhar essa solicitação para o modelo e potencialmente comprometer o modelo.
A segurança do conteúdo é outro aspeto importante. Em um aplicativo de chatbot, o código de orquestração recebe texto de bate-papo. No código, considere chamar um serviço de segurança de conteúdo. Envie o prompt do usuário e o contexto de aterramento para análise e receba uma avaliação do risco. O Prompt Shields é uma API unificada que analisa grandes entradas de modelos de linguagem e deteta ataques de prompt do usuário e ataques de documentos, que são dois tipos comuns de entradas adversárias.
O controle de segurança e a autenticação são cruciais para um ponto de extremidade RESTful. Você precisa gerenciar a autenticação e garantir testes completos.
Evitar a deterioração do modelo
Um problema comum a todos os modelos é algum grau de degradação ao longo do tempo. Alterações internas e externas à carga de trabalho acabam por causar uma degradação na qualidade do modelo e dos seus outputs. O decaimento do modelo ocorre de duas maneiras:
O desvio de dados ocorre quando os dados de entrada são alterados. A entrada de novos dados torna o modelo treinado desatualizado. Por exemplo, você pode ter um modelo que prevê padrões de votação de uma determinada área geográfica, como um distrito. Se o distrito for redesenhado e a demografia da população desse distrito mudar, seu modelo precisará ser atualizado para levar em conta as mudanças.
O desvio de conceito ocorre quando as condições externas à carga de trabalho e ao modelo mudam de tal forma que as saídas do modelo não correspondem mais à realidade. Por exemplo, você pode ter um modelo de previsão de vendas para um produto de tecnologia. Se um concorrente introduzir inesperadamente um produto concorrente mais avançado que chame a atenção significativa do público, você precisa atualizar seu modelo com base em como as tendências de consumo mudam.
Sempre que possível, use testes automatizados para detetar e avaliar o decaimento do modelo ao longo do ciclo de vida do modelo. Se o seu modelo prevê valores discretos, você pode criar testes para avaliar previsões em relação a esses valores ao longo do tempo e medir o desvio entre os resultados esperados e reais. Complemente este teste com monitoramento para detetar desvios ao longo do tempo, comparando estatísticas resumidas e métricas de distância.
Outra abordagem comum para identificar o decaimento do modelo é o feedback do usuário. Um exemplo de feedback do usuário é um mecanismo de resposta polegar para cima ou polegar para baixo. Acompanhar o feedback positivo versus negativo ao longo do tempo e criar um alerta quando você atinge um limite de feedback negativo pode ajudá-lo a saber quando investigar a qualidade do modelo.
Independentemente dos sinais que você usa para identificar o decaimento do modelo, a equipe de operações que é alertada sobre o potencial decaimento precisa envolver um cientista de dados para pesquisar o sinal e determinar se o decaimento está acontecendo e a causa raiz.
Implementar ferramentas
Use o coletor de dados do Azure Machine Learning para obter registro em tempo real de dados de entrada e saída de modelos implantados em pontos de extremidade online gerenciados ou pontos de extremidade online do Kubernetes. O Aprendizado de Máquina armazena os dados de inferência registrados no armazenamento de blobs do Azure. Em seguida, você pode usar esses dados para monitoramento, depuração ou auditoria de modelos, o que fornece observabilidade no desempenho de seus modelos implantados. Se você implantar um modelo fora do Machine Learning ou em um ponto de extremidade em lote do Machine Learning, não poderá aproveitar o coletor de dados e precisará operacionalizar outro processo de coleta de dados.
Use o monitoramento de modelo de Machine Learning para implementar o monitoramento. O Machine Learning adquire sinais de monitoramento através da realização de cálculos estatísticos em dados de inferência de produção em fluxo e dados de referência. Os dados de referência podem ser dados históricos de treinamento, dados de validação ou dados de verdade básica. Por outro lado, os dados de inferência de produção referem-se aos dados de entrada e saída do modelo coletados na produção.
- Consulte Monitoramento de modelo de Aprendizado de Máquina para saber mais sobre os recursos de monitoramento do Aprendizado de Máquina e as métricas que ele captura e analisa.
- Consulte as práticas recomendadas para obter mais recomendações para monitoramento.