Design para dar suporte a ciclos de vida do modelo de fundação

Os modelos de base são dependências com controle de versão que você usa em sua carga de trabalho de IA. Cada modelo de base tem um ciclo de vida que deve ser considerado. Assim como bibliotecas de código e outras dependências em sua carga de trabalho, os modelos de base recebem atualizações de versão secundárias que fornecem aprimoramentos de desempenho e otimizações. As principais atualizações de versão introduzem alterações substantivas nos recursos, desempenho ou atualização de dados de treinamento. Com o tempo, os modelos de base podem ser preteridos devido à obsolescência ou às preferências de host do seu modelo que estão além do seu controle.

Você deve projetar sua carga de trabalho para dar suporte aos ciclos de vida documentados dos modelos escolhidos como dependências. Se você não considerar os ciclos de vida dos modelos, poderá fazer atualizações arriscadas desnecessariamente, introduzir alterações de comportamento não testadas, fazer tempo de inatividade desnecessário da carga de trabalho ou experimentar interrupções devido à maneira como sua plataforma de hospedagem lida com modelos de fim de vida.

Uma carga de trabalho projetada para dar suporte aos ciclos de vida de seus modelos torna mais fácil experimentar e migrar com segurança para novos modelos de base à medida que entram no marketplace.

Tipos de atualizações de modelo

O escopo da atualização de modelo em sua solução de IA gerativa pode variar drasticamente, desde a atualização para uma pequena alteração de revisão até a escolha de uma nova família de modelos. Há vários motivos pelos quais você pode optar por atualizar o modelo em sua solução. A tabela a seguir lista diferentes escopos de atualização, juntamente com um exemplo e benefícios de fazer essa atualização.

Conforme ilustrado na tabela, os benefícios de migrar para um novo modelo normalmente são uma combinação dos seguintes fatores:

• Desempenho, como velocidade e latência

• Capacidade, como taxa de transferência medida em transações por minuto

• Disponibilidade de cotas

• Redução de custos

• Disponibilidade regional

• Funcionalidades multimodais

• Conhecimento de treinamento atualizado

• Correções

• Especialização ou desespecialização para se alinhar melhor ao seu caso de uso

• Evitar interrupções de cargas de trabalho devido a políticas de ciclo de vida do modelo de host

Comportamento de desativação do modelo

O comportamento de desativação do modelo depende da estratégia de implantação do modelo. Há três estratégias importantes para implantar modelos. É importante entender como cada estratégia lida com descontinuações de versões.

• Soluções maaS (modelo como serviço) são modelos pré-treinados expostos como APIs que fornecem escalabilidade e facilidade de integração. Eles têm a desvantagem de custos potencialmente mais altos e menor controle dos modelos. Exemplos de soluções MaaS incluem modelos implantados no OpenAI do Azure em modelos Foundry e modelos do catálogo de modelos implantados como APIs sem servidor.

• As soluções maaP (modelo como plataforma) são modelos implantados e gerenciados em uma plataforma maior, como modelos do catálogo de modelos do Azure implantados na computação gerenciada. Essa solução geralmente fornece maior controle de modelos, mas requer mais gerenciamento do que soluções maaS.

• Modelos de auto-hospedagem são modelos implantados em sua própria infraestrutura. Essa implantação fornece controle máximo sobre modelos, mas requer responsabilidade significativa por infraestrutura, gerenciamento e manutenção.

Estratégias MaaS e MaaP em modelos de origem no Azure provenientes do catálogo de modelos do Foundry. Os modelos no catálogo de modelos seguem um ciclo de vida em que os modelos são descontinuados e desativados. Você deve planejar essas eventualidades em sua carga de trabalho.

Quando você auto-hospeda modelos ou usa computação gerenciada, mantém o controle total e não é necessário atualizar modelos. Mas talvez você queira replicar um ciclo de vida do modelo para os benefícios adicionais que um modelo mais recente pode trazer para sua carga de trabalho.

Amplitude da mudança nas atualizações de modelos

Você precisa avaliar como uma atualização de modelo afeta sua carga de trabalho para que você possa planejar a transição do modelo antigo para o novo modelo. A extensão da alteração da carga de trabalho depende das diferenças funcionais e não funcionais entre os modelos antigos e novos. O diagrama mostra uma arquitetura de chat simplificada que tem seções numeradas que realçam áreas em que uma atualização de modelo pode ter um efeito.

Para cada uma dessas áreas, considere o tempo de inatividade causado por atualizações e como você lida com as solicitações que o sistema está processando. Se as janelas de manutenção estiverem disponíveis para sua carga de trabalho, use essas janelas quando o escopo da alteração for grande. Se as janelas de manutenção não estiverem disponíveis, aborde as alterações nessas áreas para garantir a funcionalidade da carga de trabalho e o cumprimento dos objetivos de nível de serviço durante a atualização do modelo.

1. O modelo: A mudança óbvia está no próprio modelo. Você implanta o novo modelo usando sua estratégia de implantação de modelo escolhida. Você deve avaliar as compensações das atualizações no local em relação à implantação lado a lado.

   Ao mudar para uma nova revisão de um modelo afinado, você precisará afinar novamente a nova versão do modelo antes de usá-la. Ao atualizar para usar um modelo diferente, você precisa determinar se o ajuste fino é necessário.

2. A configuração do modelo: Ao atualizar o modelo de base em sua solução de IA, talvez seja necessário ajustar hiperparâmetros ou configurações para otimizar o desempenho da arquitetura e dos recursos do novo modelo. Por exemplo, mudar de um modelo baseado em transformador para uma rede neural recorrente pode exigir diferentes taxas de aprendizagem e tamanhos de lote para obter resultados ideais.

3. O prompt: ao alterar os modelos de base em sua carga de trabalho, talvez seja necessário ajustar os prompts do sistema em seus orquestradores ou agentes para se alinhar com os pontos fortes e as funcionalidades do novo modelo.

   Além de atualizar a configuração do modelo, atualizar o prompt é uma das alterações mais comuns ao atualizar modelos. Ao avaliar um novo modelo, mesmo que seja uma atualização de versão menor, teste as alterações no prompt caso ele não atenda aos seus requisitos. Essa abordagem garante que você resolva problemas de desempenho antes de explorar outras modificações. Você precisa abordar o prompt ao mudar para novos modelos. Também é provável que você precise lidar com o prompt ao fazer grandes revisões.

4. A lógica de orquestração: Algumas atualizações de modelo, especialmente quando você aproveita os novos recursos, exigem que você faça alterações na lógica de orquestração ou agente.

   Por exemplo, se você atualizar seu modelo para GPT-4 para aproveitar a chamada de função, precisará alterar sua lógica de orquestração. Seu modelo antigo retornou um resultado que você poderia devolver ao chamador. Com a chamada de função, o chamado ao modelo retorna uma função que sua lógica de orquestração deve chamar. No Azure, é comum implementar a lógica de orquestração no Serviço do Foundry Agent ou usando soluções baseadas em código, como o Microsoft Agent Framework, o Kernel Semântico ou o LangChain hospedado no Azure.

5. Os dados de base: Algumas atualizações de modelo e alterações de escopo maiores podem exigir que você faça mudanças nos seus dados de base ou que ajuste o processo de como você recupera esses dados.

   Por exemplo, quando você passa de um modelo generalizado para um modelo específico de domínio, como um modelo focado em finanças ou medicina, talvez você não precise mais passar dados de aterramento específicos do domínio para o modelo. Outro exemplo é quando um novo modelo pode lidar com uma janela de contexto maior. Nesse cenário, talvez você queira recuperar outras partes relevantes ou ajustar o tamanho de suas partes. Para obter mais informações, consulte Projetar e desenvolver uma solução de Geração Aumentada de Recuperação (RAG).

6. Hardware: Para modelos executados no MaaP, uma alteração de modelo pode exigir um novo hardware. Apenas SKUs de computação específicas são permitidas para modelos do catálogo. Além disso, o hardware pode ser descontinuado, o que exige que você execute o modelo em novo hardware.

Design para alteração

Provavelmente você atualizará modelos em sua carga de trabalho. Se você usar a estratégia de implantação do MaaS no Azure, os modelos serão desativados e você precisará atualizar para uma versão mais recente. Você também pode optar por migrar para diferentes modelos ou versões de modelo para aproveitar novos recursos, preços mais baixos ou desempenho aprimorado. De qualquer forma, sua arquitetura deve dar suporte à atualização do modelo que sua carga de trabalho de IA gerativa usa.

A seção anterior discutia as diferentes amplitudes de alteração. Você deve seguir as práticas adequadas de operações de aprendizado de máquina (MLOps), operações de dados (DataOps) e operações de IA generativas (GenAIOps) para criar e manter pipelines automatizados para ajuste fino de modelos, engenharia de prompts, alteração de hiperparâmetros e gerenciamento da lógica de orquestração.

Atualizações para hiperparâmetros e prompts são comuns na maioria das atualizações de modelo. Como essas alterações são tão comuns, sua arquitetura deve dar suporte a um mecanismo de alteração controlado para essas áreas. Uma consideração importante é que prompts e hiperparâmetros são desenvolvidos para versões de modelo específicas. Você precisa garantir que os prompts e hiperparâmetros sejam sempre usados com o modelo e a versão corretos.

Pipelines automatizados

Implemente pipelines automatizados para testar e avaliar os diferentes aspectos do aplicativo de IA generativo:

• MLOps: Siga as diretrizes do Azure MLOps para criar pipelines para ajuste fino do modelo, se aplicável.

• GenAIOps: implemente pipelines GenAIOps para testar e avaliar alterações no modelo, hiperparâmetros de modelo, prompt e lógica de orquestração.

• DataOps: Implemente pipelines de DataOps para testar e avaliar alterações nos dados-base do RAG.

Você deveria implementar pipelines pelos seguintes motivos:

• Para ajudá-lo em seu desenvolvimento iterativo e experimentação (ciclo interno)
• Para implantar e operacionalizar com segurança sua solução de IA generativa (loop externo)

Quando possível, use os mesmos dados de linha de base que você usa com o aplicativo de produção para testar as alterações em seu aplicativo de IA generativo. Essa abordagem pode não ser possível se o aplicativo atualizado usar novos recursos de modelo que exigem uma alteração nos dados.

Considerações sobre a arquitetura

Em arquiteturas básicas, como a arquitetura a seguir, o cliente chama diretamente o modelo com a versão e a configuração corretas do prompt. Se houver alterações no prompt, um novo cliente será implantado com o novo prompt e então chamará o novo modelo. Vincular as versões de prompt, configuração e modelo não é um desafio.

As arquiteturas de produção não são simples. Você geralmente implementa um orquestrador ou agente cuja responsabilidade é gerenciar o fluxo das interações entre qualquer banco de dados de conhecimento e os modelos. Sua arquitetura também pode implementar uma ou mais camadas de abstração, como um roteador ou um gateway:

• Roteador: Um roteador direciona o tráfego para diferentes implementações de orquestrador. Um roteador é útil em estratégias de implantação, como implantações azul-verde, em que você pode optar por rotear uma porcentagem específica de tráfego para uma nova versão do orquestrador como parte de suas práticas de implantação seguras. Esse componente também pode ser usado para testes A/B ou espelhamento de tráfego para avaliar alterações testadas, mas não validadas, com tráfego de produção.

• Gateway: É comum usar um proxy para acessar modelos de IA por vários motivos. Por exemplo, você pode balancear a carga ou habilitar o failover entre várias instâncias de back-end, implementar autenticação e autorização personalizadas ou implementar o registro em log e monitoramento para seus modelos.

Devido às camadas de intermediação envolvidas, sua arquitetura deve ser projetada para dar suporte ao envio de versões específicas de instruções para modelos específicos ou versões de modelo. Por exemplo, você pode ter um prompt em produção, como prompt1, que foi desenvolvido para um modelo, como model1. Se você atualizar para model1.1, talvez seja necessário atualizar o prompt1 para prompt2. Neste exemplo, sua arquitetura precisa sempre usar prompt1 com model1 e prompt2 com model1.1.

Roteador

O diagrama a seguir ilustra uma arquitetura que usa um roteador para rotear solicitações para várias implantações. Outro exemplo dessa arquitetura inclui o Foundry e utiliza um endpoint online gerenciado como roteador. E as diferentes versões do orquestrador são implantadas em computação gerenciada.

O fluxo abaixo descreve como diferentes implementações de um orquestrador acionam o modelo correto. Cada implantação tem sua própria versão de configuração de modelo e um prompt:

1. Um usuário emite uma solicitação de um aplicativo inteligente e essa solicitação é enviada a um roteador.

2. O roteador direciona o tráfego para a Implantação 1 ou a Implantação 2 do orquestrador, conforme a lógica estabelecida.

3. Cada implantação tem sua própria versão do prompt e da configuração.

4. O orquestrador é configurado com o modelo e a versão específicos. Ele usa essas informações para chamar diretamente o modelo e a versão apropriados.

5. Como a versão específica do prompt é implantada junto com o orquestrador configurado com o modelo e a versão específicos, o prompt correto é enviado para a versão correta do modelo.

Porta de entrada

O diagrama a seguir ilustra uma arquitetura que usa um roteador para rotear solicitações para várias implantações. No entanto, nessa arquitetura, todas as solicitações de modelo são roteadas por meio de um gateway. É comum o uso de proxy para acessar modelos de IA por vários motivos, incluindo balanceamento de carga, habilitação de failover entre várias instâncias de back-end em uma única região ou várias regiões, e implementação de uma unidade de produtividade provisionada com uma estratégia de transbordo de pagamento conforme o uso.

O fluxo a seguir descreve como diferentes implantações de um orquestrador chamam o modelo correto por meio de um gateway. Cada implantação tem sua própria versão de configuração de modelo e um prompt:

1. Um usuário emite uma solicitação de um aplicativo inteligente e essa solicitação é enviada a um roteador.

2. O roteador roteia para a Implantação 1 ou a Implantação 2, dependendo de sua lógica.

3. Cada implantação tem sua própria versão do prompt.

4. O orquestrador é configurado com o modelo e a versão específicos. Ele usa essas informações para definir um cabeçalho HTTP que indica o modelo e a versão corretos para chamar.

5. O orquestrador chama o gateway. A solicitação contém o cabeçalho HTTP que indica o nome e a versão do modelo a ser usado.

6. O gateway usa o cabeçalho HTTP para rotear a solicitação para o modelo e a versão apropriados. Ele também pode aplicar a configuração definida no gateway.

Externalizar configuração

O padrão de design de nuvem do Repositório de Configuração Externa é uma boa maneira de lidar com o armazenamento de prompts e a configuração. No caso de alguns escopos de alterações de modelo, você poderá coordenar a implantação do modelo com o prompt do sistema e as alterações de configuração se elas forem armazenadas em um local atualizável fora do código do seu orquestrador ou agente. Essa abordagem não funciona se você tiver lógica de orquestração para ajustar, mas será útil em muitas atualizações de modelos de escopo menor.

Opção de computação

Para hospedagem maaP, os modelos geralmente são limitados a um subconjunto de recursos de computação fornecidos pelo host. Todos os recursos de computação estão sujeitos a cotas, restrições de disponibilidade e anúncios de descontinuação. Use os padrões de roteamento para dar suporte à transição para um novo hardware quando o hardware atual não tiver mais suporte ou houver restrições que impeçam a expansão extra.

Um exemplo de um anúncio de fim de vida útil é o Anúncio da série de computadores NC A100 v4. Se você hospeda modelos neste hardware, precisa migrar para outro SKU com suporte, que não esteja no fim da vida útil e que tenha mais disponibilidade. Essa transição também pode exigir simultaneamente uma alteração de modelo se a nova SKU não oferecer suporte ao modelo atual.

Recomendações

• Adicione camadas de abstração e indireção para habilitar modificações controladas em áreas específicas da carga de trabalho. Essas áreas incluem o cliente, a API de aplicativo inteligente, a orquestração, a hospedagem de modelos e o conhecimento fundamental.

• Todas as alterações em versões de modelo, prompts, configurações, lógica de orquestração e recuperação de conhecimento básico devem ser testadas antes do uso em produção. Verifique se as combinações testadas estão fixadas juntas na produção, o que significa que elas permanecem fortemente vinculadas quando implantadas. O teste A/B, o balanceamento de carga e as implantações azul-verde não devem misturar componentes para evitar expor os usuários a combinações não testadas.

• Teste e avalie novas versões e novos modelos usando pipelines automatizados. Você deve comparar os resultados com os resultados da linha de base para garantir que obtenha os resultados necessários.

• Seja intencional quanto à atualização de modelos. Evite usar recursos de plataforma que atualizem automaticamente modelos de produção para novas versões sem a oportunidade de testar. Você precisa estar ciente de como cada atualização de modelo afeta sua carga de trabalho. Se você usar a API de Modelos do Foundry, defina suas implantações com uma versão específica e não forneça uma política de atualização. Essa configuração requer uma atualização manual se uma nova versão for lançada. Para o Azure OpenAI, defina implantações como Sem Atualização Automática para desativar atualizações automáticas.

• Verifique se sua solução de observação e registro em log coleta metadados suficientes para correlacionar o comportamento observado com a solução específica de prompt, configuração, modelo e recuperação de dados envolvida. Essa correlação permite identificar regressões inesperadas no desempenho do sistema.

Resumo

Há vários motivos para atualizar o modelo fundamental em sua carga de trabalho de geração. Esses motivos vão desde atualizações de versão necessárias quando os modelos são desativados até a decisão de mudar para um modelo diferente. Dependendo do escopo da atualização do modelo, talvez seja necessário implementar e avaliar as alterações no modelo, incluindo alterações no prompt, configuração do modelo, lógica de orquestração ou pipeline de dados. Você deve seguir as diretrizes de MLOps, DataOps e GenAIOps para criar fluxos de trabalho automatizados para os diferentes aspectos da solução. Os fluxos de trabalho automatizados permitem testar, avaliar e implantar novas versões. Você também precisa garantir que sua arquitetura dê suporte à execução de várias versões de um orquestrador em que cada versão vincula sua configuração e versão de prompt a uma versão de modelo específica.

Sua arquitetura deve dar suporte a atualizações para modelos novos ou diferentes e quaisquer alterações necessárias na configuração de prompt ou modelo, sem a necessidade de modificações no aplicativo inteligente ou na experiência do usuário. Essas atualizações devem ser encapsuladas em seus componentes apropriados e suas operações devem automatizar o teste, a avaliação e a implantação dessas alterações.

Contribuidores

A Microsoft mantém este artigo. Os colaboradores a seguir escreveram este artigo.

• Ritesh Modi | Engenheiro de software líder

Para ver perfis não públicos no LinkedIn, entre no LinkedIn.

Próxima etapa

• Descontinuações e desativações de modelo do OpenAI do Azure

Recursos relacionados

• Arquitetura de referência de chat do Baseline Foundry
• MLOps
• GenAIOps para profissionais do MLOps