Monitoramento de drift de modelo

A resposta curta

Sistemas degradam sem ninguém encostar neles. Seu código é idêntico, seus prompts são idênticos, e as respostas estão piores que em março.

Isso é normal e esperado. A falha não é derivar, é que a maioria dos times não tem como detectar e descobre por uma reclamação.

Três tipos de drift

Drift de fornecedor. O modelo por trás da API é atualizado, descontinuado ou reajustado sutilmente. O comportamento muda e você não foi consultado.

Drift de dado. Seu acervo cresce, políticas mudam, versões antigas permanecem no índice. O sistema agora está ancorado em material que se contradiz.

Drift de requisito. Seu produto mudou, seus usuários perguntam outras coisas, um concorrente lançou. O sistema continua respondendo bem as perguntas antigas e mal as novas.

Por que nada dá erro

Nenhum desses produz exceção, health check falho ou pico de latência. A disponibilidade continua perfeita enquanto a qualidade cai, e é por isso que monitoramento padrão dá falso conforto.

O único sinal é conteúdo, e sinal de conteúdo precisa ser construído de propósito. É esse o argumento de observabilidade.

Fixar versão e o trade-off

Fixe a versão do modelo onde o fornecedor permitir. Isso converte uma surpresa numa decisão agendada, o que vale muito.

Mas fixar não é segurança permanente. Versões são descontinuadas, e um sistema fixado por dois anos acumula uma atualização que vira projeto em vez de mudança. Fixe de propósito, e planeje a atualização em vez de adiar até ser forçado.

A suíte de regressão é a rede de proteção

Um conjunto de referência com casos reais e respostas boas conhecidas, rodando automaticamente, é o que transforma drift de descoberta em alerta. Sem isso não há linha de base, e sem linha de base não há drift, só opinião.

Rode com periodicidade, não só em deploy, porque drift de fornecedor acontece sem deploy. É essa a diferença entre a suíte descrita em evals de LLM e uma que de fato pega isso.

O que monitorar continuamente

Taxa de ancoragem, para pegar resposta se afastando da fonte. Taxa de recusa, nas duas direções. Taxa de escalonamento, que costuma ser o sinal humano mais precoce. Distribuição de tamanho da saída, que muda de forma perceptível quando o modelo muda. E notas de recuperação, que caem conforme o acervo cresce.

Observe a tendência, não o ponto. Um dia ruim é ruído. Três semanas de queda é um sistema mudando de caráter.

Rollout faseado para troca de modelo

Trate atualização de modelo como deploy, porque é um. Rode a versão nova contra a suíte de regressão primeiro. Depois roteie uma porcentagem do tráfego real para ela e compare em entradas de verdade.

Mantenha a capacidade de voltar rápido para a versão anterior. Time que atualiza tudo de uma vez num prazo do fornecedor descobre as regressões em produção sem caminho de volta, que é uma posição evitável.

Alertar sem ruído

Alerte em taxa cruzando limiar e em mudança sustentada de tendência, nunca em resposta isolada. Em sistema probabilístico uma resposta ruim é esperada, e acionar por isso ensina todo mundo a ignorar o alerta.

Encaminhe os alertas de qualidade para quem é dono do resultado, não só para engenharia. Queda na taxa de ancoragem é sinal de negócio antes de ser técnico.

Uma cadência prática

Suíte de regressão a cada mudança e semanalmente de qualquer forma. Revisão de amostra de produção semanal. Uma olhada deliberada em notas de versão e cronograma de descontinuação do fornecedor mensalmente. E renovação completa do conjunto de referência trimestralmente, porque um conjunto que descreve o produto do ano passado para de proteger o deste ano.

Nada disso é exótico. É a disciplina comum de operar software, aplicada a um componente que muda por baixo de você, e é parte do que faz IA em produção, ponta a ponta ser algo que você opera em vez de algo que você lançou.