Implantações graduais de IA: como lançar alterações de modelo, prompt ou ferramenta sem transformar os utilizadores na experiência

Uma alteração de IA não é apenas trocar de modelo

Numa aplicação de IA em produção, uma modificação pode estar no identificador ou na versão do modelo, no prompt de sistema, nos exemplos incluídos, nos parâmetros de geração, na cadeia de orquestração, na política de recuperação de informação, no índice consultado, na definição de uma ferramenta externa, nas permissões concedidas a essa ferramenta ou na lógica de tentativas. Embora a alteração pareça local, pode mudar a resposta final, o custo, a latência, o comportamento de segurança e a probabilidade de executar uma ação externa.

A unidade que deve ser implantada e avaliada não é necessariamente o modelo isolado. Numa aplicação generativa, o comportamento resulta da combinação de modelo, instruções, contexto recuperado, ferramentas e regras da aplicação. Por exemplo, substituir um modelo num assistente com recuperação pode mudar a forma como interpreta as instruções e usa os documentos recuperados. Alterar o esquema de uma ferramenta pode fazer com que uma resposta antes válida deixe de poder ser executada, embora o texto gerado pareça correto.

Por isso, o objetivo de uma implantação gradual não é demonstrar que uma versão nova funciona em alguns casos. É reduzir a incerteza antes de expor uma população ampla a uma regressão. A equipa formula uma hipótese verificável, compara a variante com uma linha de base congelada, limita inicialmente o raio de impacto e toma decisões predefinidas com dados operacionais e avaliação de qualidade.

Este guia trata da alteração controlada depois de a aplicação já estar em operação. Não substitui a conceção de um conjunto de avaliação, a instrumentação inicial de observabilidade nem a seleção estratégica de um fornecedor ou de um modelo. É útil como complemento dos recursos de aprendizagem, comparação e descoberta disponíveis nas rotas internas learn.index, compare.index e discover.index.

Antes de mover tráfego: hipótese, linha de base e tipos de métricas

Um canary não corrige uma decisão mal formulada. Antes de o ativar, descreva a alteração de forma concreta: que artefactos mudam, o que se mantém fixo, que população pode ser afetada e que resultado se espera melhorar. Uma hipótese útil evita expressões como «o modelo será melhor». Em vez disso: «a variante B aumentará a taxa de resolução validada em consultas de faturação sem elevar a taxa de chamadas erradas à ferramenta nem ultrapassar o orçamento de latência».

Em seguida, congele uma linha de base. Registe uma janela temporal, o tráfego incluído, as versões exatas da configuração e os indicadores observados. Se forem comparados dados de períodos com procura, mistura de casos ou disponibilidade de ferramentas muito diferentes, atribuir um resultado à alteração será incerto. Quando possível, atribua controlo e tratamento em simultâneo para reduzir essa diferença; quando não for possível, declare a limitação e adote uma interpretação prudente.

Classifique as métricas em três grupos. As métricas de promoção determinam se o tráfego pode crescer: por exemplo, sucesso validado por tarefa, cumprimento de um formato ou exatidão revista numa amostra. As métricas de vigilância detetam efeitos que não devem piorar de forma relevante, como latência de fila, custo por tarefa concluída, abandono ou taxa de fallback. As métricas de reversão são limites de segurança, privacidade, ações incorretas ou degradação operacional que obrigam a parar sem esperar pelo fim da análise estatística.

Não use uma média global como único critério. Uma melhoria agregada pode esconder uma deterioração grave em consultas longas, idiomas menos frequentes, contas com permissões limitadas ou tarefas que invocam uma ferramenta. Desagregue as métricas por segmento de utilização, complexidade, rota de ferramenta e resultado. A necessidade de participação representativa e a prudência ao extrapolar resultados de avaliação para o contexto real são particularmente relevantes em IA generativa.

Classifique a alteração antes de escolher o mecanismo

A classificação não pretende certificar que uma alteração é segura; serve para decidir quanta evidência adicional é necessária. Uma modificação menor preserva o modelo, o contrato de entrada e saída, as ferramentas, as permissões e a fonte de contexto, e altera um aspeto delimitado, como uma instrução de formato. Pode avançar com replay offline, uma amostra de revisão e um canary pequeno se não afetar ações sensíveis.

Uma alteração comparável substitui um componente, mas preserva uma tarefa, uma interface, um conjunto de permissões e uma definição de sucesso equivalentes. Um modelo alternativo para resumir documentos, com o mesmo prompt, recuperação e saída estruturada, pode integrar esta categoria. Ainda assim, a equipa deve medir custo, latência, variação e falhas de formato; a equivalência é uma hipótese que deve ser testada, não uma propriedade declarada pelo fornecedor.

Uma alteração que exige uma nova avaliação muda o que o sistema pode fazer, a informação a que acede ou o dano potencial. Inclui adicionar uma ferramenta que cria tickets, ampliar permissões, mudar para um corpus com dados diferentes, permitir ações irreversíveis, alterar a população atendida ou introduzir uma política de recuperação que transforma material sensível. Nestes casos, o tráfego aleatorizado pode ser insuficiente ou inadequado. Pode ser necessária aprovação específica, testes controlados sem efeitos externos e revisão dos requisitos aplicáveis.

A documentação dos artefactos faz parte da classificação. Para cada pacote, conserve o identificador do modelo, prompt e modelos de prompt, parâmetros de inferência, versão de código, cadeia de orquestração, configuração de recuperação e índice ou instantâneo do corpus, definição e versão de cada ferramenta, permissões, esquemas de entrada e saída, política de tentativas e regras da feature flag. Sem esta informação, não é possível reproduzir de forma razoável uma resposta nem confirmar o que foi revertido.

Escolha replay, shadow, canary, A/B ou implantação por segmentos

O replay offline volta a executar pedidos históricos, com as devidas restrições de privacidade, contra a variante candidata. É barato e reproduzível para comparar formato, recuperação, custo estimado e decisões de encaminhamento. Não reproduz perfeitamente a interação real, as alterações de estado nem o comportamento de ferramentas externas. Deve ser usado para eliminar falhas evidentes, não para declarar que o impacto em produção está demonstrado.

No modo shadow, a variante recebe uma cópia de pedidos reais, mas o seu resultado não é mostrado ao utilizador nem executa efeitos externos. É adequado para observar latência, custo, estabilidade de saída, seleção de ferramentas e divergência em relação ao sistema ativo. Para manter a segurança, as chamadas a ferramentas devem ser simuladas, redirecionadas para um ambiente isolado ou bloqueadas. O shadow deixa de ser representativo se o utilizador tivesse fornecido um esclarecimento depois de ver a resposta, se a variante precisar de um contexto que não recebe em paralelo ou se uma ferramenta depender de estado mutável criado durante a conversa.

Um canary encaminha uma fração limitada do tráfego para a versão nova e aumenta-a por fases se as verificações forem cumpridas. É útil quando a resposta pode ser apresentada ao utilizador com risco delimitado e existe um caminho de reversão rápido. O tamanho inicial não deve ser definido por hábito: deve permitir detetar sinais operacionais relevantes dentro de um limite de exposição aceitável. A duração deve abranger padrões representativos, incluindo horas de maior carga, sem manter a experiência aberta mais tempo do que o necessário perante um sinal adverso.

Um teste A/B pode estimar diferenças entre variantes se a atribuição for estável, as populações forem comparáveis e a métrica estiver bem definida. Não é sinónimo de canary: um canary dá prioridade à limitação do risco durante a entrega, enquanto um A/B procura atribuir uma diferença a uma variante. Podem ser combinados, mas não é necessário forçar a aleatorização quando existem restrições éticas, regulatórias ou de segurança. A implantação por segmentos, por sua vez, permite começar por casos de menor criticidade ou utilizadores internos, mas pode introduzir viés: um bom resultado aí não garante o mesmo resultado no resto da população.

Conceba um canary que produza evidência e limite o dano

Antes de começar, defina quem pode iniciar, pausar, promover e reverter. Estabeleça uma equipa responsável de prevenção durante cada fase e um canal de escalonamento. Cada aumento de tráfego deve ter uma janela de observação, verificações automáticas e uma revisão explícita dos sinais relevantes. Não promova automaticamente apenas porque não houve alertas: a ausência de alerta pode refletir uma métrica mal instrumentada, volume insuficiente ou falta de cobertura de um segmento importante.

A atribuição deve ser estável para a mesma unidade, como conta, organização ou conversa, salvo se existir um motivo documentado para usar outra. Mudar de variante a meio de uma conversa complica a experiência e o diagnóstico. Do mesmo modo, evite incluir inicialmente populações vulneráveis, processos de elevado impacto ou contas cuja configuração torne impossível uma reversão limpa. Esta exclusão reduz a exposição, mas também reduz a representatividade; o plano deve indicar quando e sob que controlos esses segmentos serão avaliados.

Defina limites de custo e capacidade. Uma variante pode gerar respostas mais longas, fazer mais chamadas ou ativar tentativas que elevem o custo, mesmo que a qualidade aparente melhore. Observe tanto o custo por pedido como o custo por tarefa concluída, pois reduzir o custo unitário à custa de mais abandonos não constitui necessariamente uma melhoria. Meça também filas, erros de dependências, latência nos percentis elevados e saturação de serviços de recuperação ou ferramentas.

Em sistemas não determinísticos, uma única execução não basta para caracterizar um caso crítico. Repita um subconjunto de entradas com a mesma configuração e meça a dispersão dos resultados relevantes: validade da estrutura, decisão de usar uma ferramenta, cumprimento de políticas ou pontuação humana. Esta dispersão não deve ser interpretada como uma probabilidade exata se a amostragem for pequena ou as condições mudarem; serve como sinal para ampliar testes e estabelecer salvaguardas.

Promover, pausar, reverter ou retirar: decisões explícitas

Promover não significa declarar que a alteração é universalmente melhor. Significa que, para o segmento e a fase observados, a evidência cumpre os limiares definidos e não existem sinais que aconselhem parar. Registe que dados foram revistos, que segmentos faltam e que incertezas são aceites. Isto evita que uma promoção gradual se transforme, por inércia, numa expansão sem responsável.

Pause quando houver um sinal ambíguo: volume insuficiente, distribuição de tráfego inesperada, indisponibilidade de uma dependência ou uma diferença que exige revisão humana. Pausar preserva o limite de exposição enquanto a causa é esclarecida. Não deve ser usado para ignorar um alerta de elevado impacto; perante um limiar de reversão, a ação é reverter ou desativar a capacidade afetada.

Um rollback eficaz é executado através de uma referência conhecida e testada ao pacote anterior, e não reconstruindo prompts ou configurações sob pressão. A reversão deve abranger todos os componentes ligados: modelo, prompt, parâmetros, recuperação, ferramentas, esquemas, permissões, regras de tentativa e flag. Se uma migração de dados ou uma ação externa não puder ser desfeita, essa irreversibilidade deve fazer parte da análise anterior à implantação e dos controlos de aprovação.

Depois de reverter, preserve evidência suficiente para investigar: versão atribuída, hora, segmento, pedido com minimização ou pseudonimização adequada, contexto de recuperação permitido, saída, chamadas a ferramentas, resultado dos validadores, latência, custo e decisão tomada. O acesso a estes registos deve respeitar os controlos de segurança e retenção aplicáveis. Registar mais dados do que o necessário pode criar riscos de privacidade; registar menos pode impedir o diagnóstico.

A retirada definitiva de uma variante também é uma decisão válida. Se a alteração não demonstrar benefício operacional, aumentar persistentemente o risco ou exigir controlos desproporcionados, documente o resultado e encerre a experiência. Uma aprendizagem útil também inclui saber que hipóteses não se confirmaram.

Limites e questões que devem permanecer em aberto

Nenhum protocolo elimina a incerteza própria de uma aplicação generativa. Os resultados de um canary podem não se generalizar a períodos de maior carga, novos tipos de consulta, idiomas diferentes ou alterações posteriores nas dependências. Os benchmarks e os testes internos também não substituem a observação no contexto operacional. Por isso, convém manter monitorização e capacidade de rollback depois de atingir cem por cento do tráfego.

A significância estatística, quando aplicável, não substitui o juízo operacional. Uma alteração pequena, mas estatisticamente detetável, pode não ter importância prática; um evento de segurança raro pode exigir reversão mesmo sem volume suficiente para cálculos conclusivos. Os limiares devem refletir a gravidade do dano, a reversibilidade e o contexto de utilização, e não apenas uma diferença numérica.

Também existe incerteza quanto ao comportamento de serviços e modelos geridos por terceiros: atualizações, limites de capacidade, alterações de latência ou variação das saídas podem influenciar o resultado. Versionar o que a equipa controla e registar as versões ou identificadores que o fornecedor disponibiliza melhora a rastreabilidade, mas não torna o ambiente inteiramente determinístico. O plano deve indicar que dependências externas existem e como as suas alterações serão detetadas.

O critério final é simples de enunciar e exigente de aplicar: ampliar apenas quando a alteração demonstra valor suficiente dentro dos limites de risco acordados; pausar quando a evidência não permite interpretar o resultado; reverter quando é ultrapassado um limite de dano; e conservar o pacote anterior até que o novo comportamento seja suficientemente compreendido. Assim, o utilizador deixa de ser o principal mecanismo de descoberta de falhas e passa a estar protegido por um processo deliberado de entrega.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.