Testar e avaliar cargas de trabalho de IA no Azure
O objetivo do teste em cargas de trabalho de IA é ajudar a garantir a qualidade quando uma alteração é introduzida no sistema. O teste pode 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, manuseio de carga, previsibilidade e outros critérios com base nos requisitos de 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, o teste pode servir como um sistema de notificação de falhas e ajudar a detectar 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 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, ao executar a manipulação de dados e remodelar os dados de origem para engenharia de recursos, siga as boas práticas de codificação e certifique-se de estruturar o código para dar suporte ao teste. 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 funcionar 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 segura 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. O teste estratégico é essencial durante a implantação inicial e à medida que o sistema evolui e passa por 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 aspectos de IA da arquitetura. Como conduzir esses testes não está no escopo.
Recomendações
Aqui está o resumo das recomendações fornecidas neste artigo.
| Recomendação | Descrição |
|---|---|
| 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 insights úteis sobre sua carga de trabalho de IA. ▪ Defina métricas de sucesso |
| Realize 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 conforme o esperado. 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 detectar 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 a duplicação de 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 do modelo e teste final. Esses subconjuntos não sã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 o servidor de inferência hospeda e escolha SKUs de GPU com base nesses resultados de teste. Para pontos de extremidade hospedados em PaaS (plataforma como serviço), teste a taxa de transferência e as possíveis falhas. Esses endpoints são acessíveis, portanto, realize testes de segurança adequados para evitar situações de jailbreak. ▪ Testar o ponto de extremidade de inferência |
| Teste a exatidã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 os testes de esquema de índice verificam a compatibilidade com versões anteriores. Você deve testar a qualidade das etapas de pré-processamento. O teste de carga determina SKUs adequados para recursos e os controles de segurança protegem a confidencialidade dos dados. ▪ Teste os dados de aterramento |
| Teste o orquestrador para validar sua funcionalidade e segurança. | Realize 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 segurança de conteúdo também são cruciais para proteger o sistema e os dados. ▪ Testar o orquestrador |
| Teste o 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 descompasso de conceito pode ajudá-lo a detectar a deterioração do modelo antecipadamente e mitigar o problema antes que ele afete negativamente sua carga de trabalho. ▪ Evitar a deterioração do modelo |
Defina 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 em relação ao total de instâncias no conjunto de dados de teste. É uma medida comum do desempenho geral do modelo.
Precisão é a proporção de previsões verdadeiras positivas para 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 casos relevantes ausentes é fundamental.
A especificidade calcula a proporção de verdadeiros negativos para a soma de verdadeiros negativos e falsos positivos. É relevante quando você otimiza para previsões negativas precisas.
Observação
Ao definir métricas de sucesso para modelos de regressão, considere adicionar as seguintes métricas:
O Erro Médio Absoluto (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 outliers em comparação com o MSE e o RMSE.
O erro quadrático médio (MSE) mede a diferença quadrada média entre os valores reais e os valores previstos. Calcule-o tomando a média das diferenças quadradas entre cada valor real e seu valor previsto correspondente. O MSE penaliza erros maiores mais fortemente do que o MAE porque os erros são elevados ao quadrado.
O erro quadrático médio (RMSE) é a raiz quadrada do MSE. Ele fornece uma medida do erro absoluto médio entre os valores reais e previstos, mas nas mesmas unidades dos dados originais. O RMSE é mais sensível a valores discrepantes em comparação com o MAE porque eleva os erros ao quadrado 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 garantir que ela assimile dados de forma confiável e que os dados sejam 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 conforme o esperado.
Os testes devem ser integrados ao longo do ciclo de vida, incluindo os estágios de projeto, desenvolvimento e produção.
Teste para facilitar as escolhas de design
Quando você reúne requisitos para a carga de trabalho, uma etapa importante da tomada de decisão é escolher uma opção de tecnologia específica que seja viável para seu design.
Com base em seus requisitos de ETL e critérios de aceitação, realize testes funcionais exploratórios para selecionar o produto mais adequado, seus SKUs e recursos que executam as tarefas pretendidas. Testes de prova de conceito, prova de tecnologia e prova de recursos 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 de carga de trabalho podem mudar. Suponha que a empresa antecipe o crescimento e o sistema precise 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 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, verifique se ele passa por testes de unidade e não é liberado se falhar. Por exemplo, é comum ter um código personalizado que é executado como parte da ingestão. Também há 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 seu pipeline de integração contínua e entrega contínua.
Teste no sistema ao vivo
O teste funcional deve se estender ao sistema ativo. Se esses testes falharem, considere disparar alertas para iniciar investigações imediatas, se necessário. Veja alguns exemplos:
Execute testes agendados para verificar se o volume correto de dados foi coletado se os dados forem ingeridos em um agendamento definido com uma quantidade esperada.
Execute testes que detectam 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 downstream 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é-processar. Execute testes para garantir que eles estejam disponíveis porque sua indisponibilidade pode afetar o processo de ETL.
Outra maneira de testar a exatidão do sistema ETL em produção é por meio de testes sintéticos. Ter dados de teste conhecidos disponíveis na 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 de documentos e contém dados pessoais. A injeção de um documento sintético pode testar se a carga de trabalho executa o trabalho de manipulação de dados conforme o esperado.
Além disso, experimente lançar experiências diferentes, também conhecidas como testes A/B, para aprender com as interações do usuário antes de se comprometer totalmente. O teste A/B ajuda 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 a integridade. 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 de informações críticas. Se o treinamento for baseado em entidades conhecidas, como registros ou identificadores específicos, teste o conjunto de dados para garantir que essas entidades estejam presentes. Essa validação garante que informações críticas não estejam faltando.
Teste 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 o frescor. 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 em relação a 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 importação com falha ou um problema de atualização de dados no sistema de origem.
Realize 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 indica degradação do desempenho. Para mitigar tais condições, reavalie e otimize 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.
Observação
O teste e o monitoramento servem a propósitos diferentes. Realize testes para avaliar possíveis alterações no sistema, normalmente antes de implementar qualquer alteração. Realize o 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 na computação, como em notebooks ou trabalhos do Azure Machine Learning, que também exigem recursos de memória e rede. Recomendamos o teste de carga durante a fase de design para avaliar as necessidades de computação e garantir que os SKUs propostos sejam adequados. Muitas vezes, você precisa de testes manuais para determinar a melhor configuração para executar com eficiência 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 o 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
Observação
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 ajuste. Inclui o ajuste de hiperparâmetros, configurações ou recursos e, em seguida, a avaliação do modelo com base em várias métricas. Depois de identificar o melhor modelo, realize testes durante a implantação.
O teste inclui a verificação de todo o sistema, incluindo o modelo ajustado e os componentes não de IA, para verificar se eles funcionam corretamente, se integram bem e fornecem os resultados esperados de acordo com os padrões de qualidade. Avalie um modelo in situ junto com outros componentes da carga de trabalho. O processo inclui o envio de solicitações ao modelo, a avaliação de suas respostas e a tomada de uma decisão de ir ou não com base nos dados de teste. Embora o teste não seja negociável antes da produção, recomendamos que você também realize testes na produção usando dados reais e dados sintéticos.
Use dados para avaliar e testar
Normalmente, há três conjuntos de dados principais particionados 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 por meio de um processo iterativo, avaliando diferentes permutações. Depois de encontrar uma permutação satisfatória, teste-a no 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 detecção de fraude, em que casos reais de fraude são raros, o que dificulta a obtenção de poder estatístico suficiente para previsões confiáveis.
Para evitar vieses 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 teste. Reserve dados exclusivos para avaliação do modelo e teste final.
Usar métricas de avaliação
Treinar um modelo e selecionar o modelo certo para produção são processos interdependentes. Você precisa escolher um modelo inicialmente, mas ele pode mudar após a experimentação e a avaliação.
A avaliação do modelo segue como um loop de experimentação que avalia várias 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. Tenha processos que avaliem e quantifiquem os resultados da experiência do usuário com base no desempenho do modelo. Por exemplo, a fundamentação é uma das principais métricas que quantificam o quão bem o modelo se alinha com os dados de origem. A relevância é outra métrica importante que indica a pertinência da resposta à consulta. Para obter métricas de exemplo, 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 as métricas com base no caso de uso. Por exemplo, a justiça é crucial na IA responsável. Apesar dos bons testes, os modelos ainda podem exibir viés injusto devido a dados de origem tendenciosos. Os resultados podem ter uma pontuação alta em relevância, mas baixa em justiça. Integre avaliações de justiça ao processo para garantir resultados imparciais.
A IA generativa se integra ao código de orquestração, lógica de roteamento e um índice para geração aumentada por 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 alterar seu comportamento. Requer 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 consistentes 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 similaridade mede a semelhança entre um texto de dados de origem e a resposta gerada. O modelo usou palavras precisas? 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 de índice recuperados se alinham com a pergunta. Dados irrelevantes da pesquisa de índice reduzem essa pontuação. Pontuações de recuperação mais altas indicam menor variabilidade porque dependem exclusivamente das consultas de índice.
A fluência está relacionada ao uso do vocabulário. Se o modelo aderir a um guia de estilo e apresentar conteúdo no formato apropriado, ele poderá ser fluente mesmo que não tenha base ou relevância.
A coerência avalia se a fala 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 das decisões de design específicas do aplicativo. 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 em que os dados de treinamento são comparados com os dados de teste para validar se 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.
Dilema. O loop interno inclui custos computacionais de treinamento do modelo e o custo de avaliá-lo por meio de testes. Você deve fatorar o tempo que o treinamento e o teste do modelo exigem nesse loop. 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 escalar gradualmente esse conjunto de testes para o conjunto de dados completo.
Testar o ponto de extremidade 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 para a qual você envia dados como parte da solicitação e obtém uma resposta que contém resultados do modelo. O ponto de extremidade é hospedado na 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ções, criação de respostas, dimensionamento e coordenação entre instâncias, funcionem corretamente. Crie um plano de teste abrangente que abranja casos de uso com base em seus requisitos. Esta seção descreve alguns casos de teste de exemplo 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 variadas. 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 são executados em condições de carga padrão e de pico. O Teste de Carga do Azure é uma boa opção para teste 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 se integra bem ao Teste de Carga.
Outra decisão importante é a escolha dos recursos da GPU. Muitos modelos exigem GPUs para inferência eficaz devido ao seu design. O teste de carga ajuda você a entender os limites de desempenho de um SKU de GPU 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 endpoint como parte de seus testes de segurança de rotina junto com outros endpoints públicos. Considere a realização de testes, como testes de penetração, no sistema ativo. Outro aspecto da segurança é a segurança do conteúdo. Seu código pode chamar APIs especializadas que detectam conteúdo prejudicial na carga útil de solicitação e resposta. A Segurança de Conteúdo de IA do Azure pode ser chamada em seus testes 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 de PaaS
O cliente deve esperar erros ao enviar solicitações para o ponto de extremidade de inferência no serviço de PaaS. As falhas podem ocorrer devido à sobrecarga do sistema, back-ends sem resposta e outras condições de erro. Realize 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 OpenAI do Azure 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 uma análise de modos de falha.
Testar os serviços de PaaS pode ajudá-lo a selecionar SKUs de serviço porque você entende os custos associados, como pagamento conforme o uso ou computação 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 de ponta, como PTUs (unidades de produtividade provisionadas) para o Azure OpenAI.
O teste de carga não é tão relevante para a computação paga conforme o uso porque, com capacidade infinita, você não encontra problemas. O teste valida os limites e as cotas. Não recomendamos o teste de carga para computação paga conforme o uso porque é uma despesa financeira significativa. No entanto, você deve fazer o teste de carga 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 as 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.
Usar controles de segurança
Independentemente de você usar um servidor de inferência ou uma opção de PaaS, a segurança é sua responsabilidade. Com endpoints de API, é crucial testar os controles de jailbreak e segurança de conteúdo. Verifique se 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 lançamento.
É 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 de resposta. Além disso, teste para garantir que um cliente não possa 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 de usuários.
Teste 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 base fornecem mais contexto para aumentar a relevância da resposta. Ele é indexado antes de chegar ao modelo. Este índice é acessado em tempo real enquanto o usuário 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. Estas são algumas considerações:
Teste minuciosamente 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 para 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 os dados serem indexados, eles passam por uma preparação para reduzir o ruído e o viés e permitir consultas eficientes. Esse processo inclui pré-processamento, agrupamento 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 se há 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. Esse 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 os diferentes SKUs para armazenamento, computação e outros recursos disponíveis para dar suporte aos seus requisitos.
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.
Testar o orquestrador
Um componente chave de um aplicativo RAG é o orquestrador central. Esse código coordena várias tarefas relacionadas à pergunta inicial do usuário. As tarefas do Orchestrator 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 realizar tarefas, como chamar APIs REST, esse código manipulará essas tarefas dentro do contexto.
Você pode desenvolver código de orquestração em qualquer linguagem ou escrevê-lo do zero. No entanto, recomendamos que você use tecnologias como fluxo de prompt no Azure AI Studio ou 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 uma API REST para acesso. Essa abordagem garante modularidade e facilidade de implantação.
De uma perspectiva de teste, trate esse código como qualquer outro código e conduza testes de unidade. No entanto, o aspecto 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 detectar a intenção do usuário e rotear chamadas adequadamente. Existem várias estruturas e bibliotecas para teste, como Scikit-learn, módulo torch.testing do PyTorch, FairML para testes de viés e imparcialidade e TensorFlow Model Analysis para avaliação de modelos.
Além disso, realize testes de tempo de execução, como teste 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 planejamento de capacidade. Como esse código está posicionado em um ponto crucial da arquitetura em que precisa alcançar outros serviços, ele pode ajudar a coletar telemetria de todas essas chamadas. Esses dados podem fornecer insights 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 de prompt têm recursos de telemetria integrados para facilitar esse processo. Caso contrário, incorpore a telemetria em seu código personalizado.
Observação
Testar esse código tem implicações de custo. Por exemplo, se você usar o Azure OpenAI para hospedar seu ponto de extremidade de inferência, o teste de estresse será 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 caro o teste de estresse extensivo. Uma maneira de otimizar os encargos é 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 se aplicam ao código de orquestração e ao modelo. Inclua testes para jailbreak, onde o objetivo é quebrar a segurança do modelo. Os invasores 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 aspecto importante. Em um aplicativo de chatbot, o código de orquestração recebe texto de chat. 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. Os Módulos de Prompt são uma API unificada que analisa grandes entradas de modelo de linguagem e detecta 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 endpoint RESTful. Você precisa gerenciar a autenticação e garantir testes completos.
Evitar a deterioração do modelo
Um problema comum para todos os modelos é algum grau de degradação ao longo do tempo. As alterações internas e externas à carga de trabalho acabam causando uma degradação na qualidade do modelo e de suas saídas. O decaimento do modelo ocorre de duas maneiras:
O desvio de dados ocorre quando os dados de entrada são alterados. A nova entrada de 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 os dados demográficos da população desse distrito mudarem, seu modelo precisará ser atualizado para levar em conta as alterações.
O descompasso de conceito ocorre quando as condições externas à carga de trabalho e ao modelo são alteradas de forma que as saídas do modelo não correspondam 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 atraia atenção significativa do público, você precisará atualizar seu modelo com base em como as tendências do consumidor mudam.
Quando possível, use testes automatizados para detectar e avaliar o decaimento do modelo ao longo do ciclo de vida do modelo. Se o modelo prevê valores discretos, você pode criar testes para avaliar as previsões em relação a esses valores ao longo do tempo e medir o desvio entre os resultados esperados e reais. Complemente esse teste com monitoramento para detectar 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 de polegar para cima ou para baixo. Acompanhar os comentários positivos versus negativos ao longo do tempo e criar um alerta quando você atingir um limite de comentários negativos 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 decaimento potencial 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 o 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 Machine Learning 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 do modelo do Machine Learning para implementar o monitoramento. O Machine Learning adquire sinais de monitoramento executando cálculos estatísticos em dados de inferência de produção transmitidos e dados de referência. Os dados de referência podem ser dados históricos de treinamento, dados de validação ou dados verídicos básicos. 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 do Machine Learning para saber mais sobre os recursos de monitoramento do Machine Learning e as métricas que ele captura e analisa.
- Consulte as práticas recomendadas para obter mais recomendações de monitoramento.