A atualização que você não pediu

Quando as atualizações quebram o que funcionava

Seu sistema trabalhou na sexta-feira. Na segunda-feira, ele ainda fornece respostas, ainda responde em menos de dois segundos e passa em todos os testes de saúde do painel. No entanto, as respostas são sutilmente diferentes — mais longas, com formatação que confunde os analisadores downstream ou com informações incorretas sobre políticas que antes eram corretas.

Nada falhou. Seu provedor enviou uma atualização do modelo.

Este é o modo de falha que surpreende as equipes de liderança mais, pois não parece um problema. Não há luzes vermelhas. O sistema se declara saudável, enquanto a qualidade de sua saída mudou sob seus pés. Seus clientes percebem antes que os sistemas de monitoramento.

Por que as atualizações quebram coisas que funcionavam

Um modelo mais novo é melhor em média e diferente em particular. Os provedores otimizam para benchmarks agregados; você implantou contra sua própria fatia restrita da realidade. Quando o modelo muda, os comportamentos que você ajustou ao redor também mudam — a formulação em que seu prompt confiava, a estrutura JSON que sua integração espera, a limitação de recusa que sua equipe de conformidade aprovou, o comprimento que se encaixava na sua interface do usuário.

As atualizações chegam de três maneiras: o provedor retira uma versão do modelo e migra você; você usa um alias flutuante que resolve silenciosamente para a nova versão; ou você atualiza intencionalmente para reduzir custos ou latência e assume que a qualidade só melhoraria. Todas resultam no mesmo problema: o comportamento mudou, e ninguém mediu o que mudou.

Construa a coisa que lhe diz

O único controle importante é um conjunto fixo de casos de teste com respostas conhecidas — um conjunto dourado. 200 exemplos reais do seu tráfego, cobrindo seus casos comuns, os casos de borda e as situações em que estar errado é caro. Cada um com a resposta que sua empresa considera correta.

Execute esse conjunto contra o modelo atual e registre os resultados. Essa gravação é sua linha de base. Quando uma nova versão aparecer, execute o mesmo conjunto novamente e compare. A comparação é todo o produto: agora você tem evidências, não apenas impressões.

Construir isso leva alguns dias e requer que seus operadores, não seus engenheiros, definam o que significa "correto". A maioria das organizações pula essa etapa porque parece sobrecarga antes do lançamento. É a apólice de seguro mais barata do sistema inteiro.

Controle quando a mudança chega até você

Fixe versões explícitas de modelos em todas as configurações de produção. Uma versão fixada transforma uma emboscada em uma decisão agendada. Trate cada atualização como um pequeno projeto:

• Execute o conjunto dourado contra a nova versão e compare, caso a caso, com a linha de base
• Peça ao proprietário do negócio para revisar todos os casos em que a resposta mudou, não apenas os piores; melhorias também podem quebrar sistemas downstream
• Envie uma pequena parcela do tráfego ao vivo para a nova versão e observe as sinais operacionais: taxa de escalada, tempo médio de tratamento, quantas vezes a equipe edita o rascunho do sistema antes de enviá-lo, cliques "desaprovo".
• Mantenha a versão antiga acessível por um período de reversão e saiba quem tem autoridade para puxar o gatilho.
• Registre a decisão, a data e as evidências, para que a próxima atualização comece em um estado conhecido.

Observe o que não está nessa lista: uma demonstração. Ver um novo modelo responder cinco perguntas impressionantemente não lhe diz nada sobre o 20º percentil do seu tráfego, de onde vêm suas reclamações.

Acompanhe os sinais que sua empresa já gera

Entre as atualizações, o drifte de qualidade aparece nos números que você provavelmente já coleta. Escaladas para humanos. Tempo médio de tratamento. Quantas vezes a equipe edita o rascunho do sistema antes de enviá-lo. Contatos repetidos sobre o mesmo problema em uma semana. Qualquer um desses valores aumentando 3 ou 4 pontos em duas semanas merece uma olhada no que mudou na camada do modelo.

Dê a uma pessoa a tarefa permanente de revisar essas métricas semanalmente contra a versão do modelo em produção. Não um comitê, nem uma revisão trimestral. Um proprietário designado e uma verificação de 15 minutos.

Inclua isso no contrato

Peça ao seu provedor por notificação escrita antes da retirada de uma versão, um período mínimo de suporte para versões fixadas e acesso à versão anterior durante a migração. Fornecedores que atendem a indústrias reguladas geralmente oferecem isso. Aqueles que não oferecem informarão você, e essa resposta é útil antes de construir sobre eles do que depois.

A posição honesta

Você não pode impedir que seu provedor melhore seus modelos, e você não gostaria de fazer isso. O que você pode fazer é garantir que a melhoria aconteça nos termos você: medida, em etapas, revertível e de responsabilidade de alguém.

Essa é a parte pouco glamorosa de executar AI em produção, em vez de pilotá-la — e é o que fazemos pelos clientes que preferem gastar sua atenção no negócio. De qualquer forma, construa o conjunto dourado. Tudo mais depende dele.