Mudar o modelo base de IA sem perder qualidade: Evals, Canary e Rollback

Um novo modelo base de IA promete frequentemente melhores respostas, custos mais reduzidos ou tempos de resposta mais curtos. Para um chatbot de site em produção, a alteração continua a não ser uma simples substituição de um pacote de software qualquer. Mesmo uma nova versão do modelo pode ponderar as instruções de forma diferente, formular respostas mais detalhadas, gerar dados estruturados de forma distinta ou chamar ferramentas numa ordem diferente. Por isso, uma migração só é bem-sucedida quando o chatbot cumpre as suas tarefas concretas pelo menos com a mesma fiabilidade de antes — e quando a equipa consegue reverter a alteração em minutos caso surjam problemas.

Os fornecedores descontinuam modelos regularmente. A documentação da OpenAI sobre descontinuações lista datas de desativação e modelos de substituição recomendados; a Anthropic distingue no seu ciclo de vida de modelos os estados “Active”, “Legacy”, “Deprecated” e “Retired”. Esses prazos são o motivo da migração, mas não a prova da sua qualidade. Esta é fornecida apenas por um procedimento de teste e rollout adequado ao seu próprio chatbot.

O que realmente muda na alteração do modelo base

Este processo deve ser claramente separado de uma migração do modelo de embedding . Na mudança de embedding, os documentos precisam de ser novamente vetorizados e os índices de pesquisa mantidos compatíveis. Na alteração do modelo base, o índice de recuperação normalmente permanece inalterado; o que muda é o modelo que gera a resposta a partir das instruções do sistema, da conversa, das fontes encontradas e dos resultados das ferramentas. Portanto, testam-se o comportamento de resposta, a fidelidade às fontes, o formato, a utilização de ferramentas, a segurança, a latência e os custos.

Também um teste geral em Shadow Mode antes do lançamento no site resolve apenas parte do problema. O tráfego shadow pode fornecer as mesmas entradas a dois modelos sem entregar a nova resposta ao utilizador. A alteração do modelo base aqui descrita vai mais longe: define previamente uma matriz de aceitação, direciona uma pequena percentagem do tráfego real para o candidato, monitoriza sinais dos utilizadores e do sistema e mantém preparada uma reversão testada.

Antes do teste: definir um contrato de migração claro

As comparações não têm valor se várias coisas mudarem ao mesmo tempo. Portanto, para a primeira ronda, mantenha o prompt do sistema, a configuração de recuperação, os esquemas de ferramentas, a temperatura, o comprimento máximo de saída e as regras de segurança constantes na medida do possível e documente as alterações inevitáveis de parâmetros, como opções de amostragem não suportadas. Documente o modelo atual como base e o novo modelo como candidato. Sempre que possível, utilize versões explícitas do modelo em vez de um alias móvel. Um alias pode apontar mais tarde para um snapshot diferente e alterar a comparação supostamente reprodutível.

O contrato de migração também inclui os grupos de utilizadores e funcionalidades que permanecem inicialmente excluídos. Por exemplo, um chatbot de FAQ pode ir para o canary mais cedo, enquanto os acessos de escrita a encomendas, consultas de contratos ou casos de suporte especialmente sensíveis permanecem por mais tempo no modelo base. Desta forma, o risco é limitado pelo impacto no negócio e não apenas pela complexidade técnica.

O conjunto de testes deve refletir o tráfego real

Um Golden Set não deve conter apenas perguntas padrão limpas. Reúna casos anonimizados ou sintetizados das intenções mais importantes: perguntas diretas, formulações ambíguas, perguntas de acompanhamento, documentos em falta, fontes contraditórias, erros de ferramentas e entradas que precisam de ser transferidas para um agente humano. Divida os casos por idioma, dispositivo, tipo de cliente e classe de risco. Isso permite ver se uma boa pontuação geral oculta subgrupos pequenos, mas críticos para o negócio.

O guia oficial da Anthropic sobre critérios de sucesso e evals recomenda critérios específicos, mensuráveis e alinhados com o caso de uso, bem como casos de limite realistas. Também o guia da OpenAI sobre evals descreve os testes como um elemento essencial de aplicações fiáveis, especialmente ao atualizar ou testar novos modelos. Como a OpenAI anuncia nessa mesma página a descontinuação da sua plataforma anterior de evals, o seu próprio Golden Set deve ser armazenado num formato portátil e não ficar preso a um único painel.

Uma matriz de avaliação em vez de uma única média

Os limites a seguir são um exemplo e não uma regra universal. Defina-os com base no desempenho atual em produção e no impacto de um erro. Um candidato não pode compensar um preço por token mais barato com uma pior fidelidade às fontes.

As verificações automáticas são adequadas para esquemas JSON, formulações obrigatórias, destinos de links, argumentos de ferramentas e regras de negócio determinísticas. Para o tom, a exaustividade e as explicações úteis, é necessária adicionalmente uma rúbrica clara; amostragens por especialistas ajudam a calibrar um avaliador baseado em LLM. Os resultados devem ser armazenados por intenção e classe de risco, e não apenas como uma pontuação única. Como estruturar esse conjunto é também demonstrado no nosso guia sobre qualidade de resposta com Golden Set.

Exemplo concreto: mudança de modelo no suporte B2B

Suponha que um fornecedor de software B2B opera um chatbot para dúvidas sobre produtos, gestão de contas e preparação de tickets de suporte. A equipa cria 240 casos de teste: 120 perguntas de conhecimento frequentes, 40 perguntas de acompanhamento ambíguas, 30 casos com fontes em falta, 25 simulações de ferramentas e 25 casos de segurança ou transferência para atendimento humano. Ambos os modelos recebem exatamente os mesmos prompts, trechos de documentos recuperados e saídas simuladas de ferramentas.

O candidato responde a perguntas padrão de forma mais rápida e económica, mas perde a referência à mensagem anterior em cinco perguntas de acompanhamento. A pontuação geral ainda assim seria melhor. No entanto, a avaliação por segmento mostra uma quebra de qualidade clara. A equipa não adiciona uma exceção arbitrária, mas refina a regra de conversa, expande o conjunto de testes com casos semelhantes e testa novamente ambos os modelos. Apenas depois de o candidato cumprir todos os gates rigorosos é que o canary em produção é iniciado.

Para começar, dois por cento das novas conversas elegíveis são atribuídas ao candidato. A atribuição é derivada no início da conversa, por exemplo a partir do hash do ID da conversa, e mantida para toda a interação; fases canary mais elevadas aplicam-se apenas a novas conversas. As chamadas de ferramentas com escrita e as intenções de alto risco permanecem inicialmente no modelo base. Após uma janela de observação suficientemente ampla, seguem-se dez, 25, 50 e finalmente 100 por cento — mas apenas se todos os gates continuarem verdes. As fases e os tamanhos mínimos de amostra são definidos com antecedência para evitar que a pressão do tempo enfraqueça as regras à posteriori.

Sinais online que realmente contam

No canary, erros HTTP e latência média não são suficientes. Monitorize a taxa de ausência de resposta, o abandono após a primeira resposta, as perguntas repetidas, a taxa de transferência para atendimento humano, os cliques em fontes, os erros de esquema e as interrupções de ferramentas separadamente para o modelo base e para o candidato. Um rastreio comum liga a versão do modelo, a versão do prompt, os resultados de recuperação e os passos das ferramentas, sem armazenar dados pessoais desnecessários. O nosso artigo sobre observabilidade em chatbots explica este registo em detalhe.

Compare também os custos por caso resolvido com sucesso em vez de apenas o custo por milhão de tokens. Um modelo mais barato que gere mais pedidos de esclarecimento ou intervenção humana pode ser operacionalmente mais dispendioso. Por outro lado, um pequeno aumento na latência pode ser aceitável se vier acompanhado de respostas comprovadamente mais precisas numa classe de risco importante.

Rollback é uma funcionalidade, não um documento

O caminho de regresso deve ser tecnicamente testado antes da primeira fase canary. O ID do modelo e os respetivos parâmetros pertencem a uma configuração versionada ou a um feature flag controlado. Enquanto o fornecedor continuar a suportar a versão anterior, esta permanece disponível como alvo de fallback durante o canary; antes da sua data de desativação, é necessário ter um fallback adicional suportado. As conversas existentes devem permanecer de forma consistente no seu modelo original ou mudar de acordo com uma regra expressamente testada.

Defina gatilhos rigorosos: por exemplo, um erro de esquema numa ação de escrita, uma degradação numa intenção relevante para a segurança, um aumento claro na taxa de erros ou o incumprimento do orçamento de latência. Ao surgir esse sinal, a reversão é efetuada automaticamente ou por uma equipa de piquete claramente designada. Depois disso, os logs, a versão do candidato e a amostra afetada são preservados para analisar a causa raiz. Um processo preparado é muito mais robusto do que um deploy de código improvisado; adicionalmente, ajuda ter um playbook de resposta a incidentes.

Lista de verificação para aprovação

• Registar a data de desativação, o modelo de substituição e os endpoints afetados a partir da documentação oficial do fornecedor.
• Fixar a base e o candidato com configurações inalteradas de prompt, recuperação e ferramentas.
• Dividir o Golden Set por intenção, idioma e classe de risco; adicionar casos de limite e padrões de erro reais.
• Definir gates rigorosos para fidelidade às fontes, saídas estruturadas, ferramentas, segurança e transferência para atendimento humano.
• Medir latência, taxa de erros, tokens e custo por caso resolvido.
• Manter a atribuição canary estável para conversas completas e excluir inicialmente funcionalidades sensíveis.
• Documentar fases, amostragem mínima, duração de observação e limites de cancelamento antes do rollout.
• Testar tecnicamente o rollback, atribuir responsáveis e manter disponível um alvo de fallback suportado pelo fornecedor.
• Após atingir 100 por cento, continuar a monitorizar e expandir o Golden Set com novos casos descobertos em produção.

Conclusão: O nome do modelo é apenas o início

Uma mudança controlada do modelo base combina qualidade do produto e segurança operacional. Avisos oficiais do ciclo de vida definem o prazo, evals fornecem provas de adequação, o tráfego canary limita o impacto de erros desconhecidos e um rollback testado reduz o tempo de resposta. Quem estabelece estes quatro pilares como um processo repetível pode adotar novos modelos sem transformar o chatbot do seu site num teste em tempo real para todos os utilizadores.

Quer planear de forma estruturada a versão do modelo, os gates de qualidade e o rollout do chatbot do seu site? O ChatReact ajuda-o a configurar a base de conhecimento, o comportamento de resposta e as transferências para atendimento humano, para que todas as alterações permaneçam mensuráveis e sob controlo.