Em junho de 2026, a OpenAI notificou desenvolvedores que usavam versões mais antigas dos modelos GPT-5 e o3 sobre a descontinuação dessas versões na API. O prazo até a remoção definitiva: seis meses.
Para qualquer empresa com um agente de atendimento construído sobre esses modelos, a mensagem foi direta: migre, ou pare de funcionar. Não importa se a operação estava madura, validada e gerando resultado. O relógio começou a contar de qualquer forma.
Esse tipo de aviso vai se repetir. Provedores de IA lançam famílias de modelos com frequência e aposentam as anteriores em prazos curtos. A pergunta que toda empresa com agentes de IA em produção vai enfrentar, mais cedo ou mais tarde, é como trocar o modelo por trás do agente sem impacto no cliente. É o que chamamos de LLM-swap.
Trocar de modelo é mais simples do que parece. Mas não é automático
Numa arquitetura bem desenhada, o modelo de linguagem é só um componente entre vários: o fluxo de atendimento, as ferramentas que o agente pode acionar e a memória da conversa continuam os mesmos. Nesse desenho, não é necessário reescrever a lógica do agente para a troca de modelo, na maioria dos casos.
Porém, "na maioria dos casos" não é "em todos os casos", e vale ser honesto sobre isso.
Em um estudo que conduzimos testando 8 modelos sob a mesma arquitetura, encontramos três situações em que a troca exigiu ajustes técnico específicos:
O Gemini usa um formato próprio de mensagens e de chamada de ferramentas, diferente do padrão adotado pelos demais provedores. Por isso, foi necessária uma camada de tradução para que o resto do sistema nunca precisasse saber qual modelo respondeu.
A família GPT-5 recusa qualquer valor de temperatura diferente de 1 e exige um nome de parâmetro diferente para o limite de tokens de saída.
Um modelo de peso aberto que testamos usa um formato de resposta totalmente diferente do padrão do mercado, separando raciocínio interno e resposta final em canais distintos. Isso exigiu tratamento dedicado só para identificar se o modelo tinha decidido responder em texto ou acionar uma ferramenta.
A arquitetura de troca pode ser simples por desenho, mas a execução de uma troca específica depende do provedor e da família de modelo.
Por que o mesmo agente pode falhar de formas completamente diferentes
Existe uma suposição perigosa por trás do LLM-swap: já que o modelo ocupa o mesmo lugar na arquitetura, ele deveria se comportar de forma parecida. Mas isso não é bem o que acontece.
No mesmo estudo, testamos 8 modelos atrás da mesma interface, resolvendo os mesmos atendimentos, com as mesmas ferramentas disponíveis. Cada família falhou de um jeito próprio:
A maioria dos modelos de uma mesma família errava ao escolher uma ferramenta plausível, mas incorreta, para aquele passo do atendimento.
Um modelo tinha um padrão de falha totalmente diferente: em vez de escolher a ferramenta errada, ele simplesmente respondia em texto quando o fluxo esperava uma ação.
Outro modelo falhava não por limitação de raciocínio, mas por limitação de capacidade do provedor: mais de um quarto das sessões esbarrou em limitação de taxa de requisições.
Um modelo de peso aberto, por causa do formato de resposta diferente citado acima, terminou a maioria das sessões sem que a pipeline conseguisse identificar se ele tinha respondido ou acionado uma ferramenta.
A conclusão prática é que adotar uma arquitetura de LLM-swap não elimina a necessidade de monitorar cada família de modelo de perto. Torna a substituição mais simples de executar, não de validar.
O que validar antes de trocar o modelo de produção
Antes de colocar um modelo novo no lugar do atual, três perguntas precisam de respostas:
O novo modelo mantém a taxa de conclusão da tarefa?
Escrever bem não é o mesmo que resolver o atendimento até o fim. Um modelo pode ter fluência excelente e ainda assim abandonar o fluxo pela metade, ou acionar a ferramenta errada no passo decisivo.
O custo real por sessão é o mesmo, ou só parece?
Custo por token processado esconde o que realmente importa: o custo de uma sessão inteira, somando todos os ciclos de raciocínio até o atendimento terminar.
No nosso estudo, um modelo com a melhor nota de custo normalizada teve, na prática, o maior custo por sessão entre os oito candidatos, porque o preço de tabela do provedor por token de saída era quase quatro vezes mais alto que o de um modelo da mesma família.
A taxa de alucinação está dentro do aceitável?
Esse é o critério que mais separa um modelo aprovado de um reprovado. No mesmo estudo, três modelos tinham nota de qualidade competitiva e ainda assim foram reprovados só por excederem o limite de alucinação definido para o projeto.
Detalhamos os três critérios de decisão com mais profundidade no artigo sobre como escolher o modelo de IA certo para o seu agente de atendimento.
Como estruturar o agente para que essa troca seja realmente simples
A parte que está sob controle da empresa, diferente da descontinuação em si, é o desenho do agente. Duas decisões de arquitetura fazem a diferença entre uma troca tranquila e uma reconstrução do zero.
A primeira é separar o que o agente deve fazer de como o modelo decide fazê-lo. O fluxo de atendimento, o tom de voz e as ferramentas disponíveis ficam descritos fora do modelo. O modelo entra só como o componente que interpreta a mensagem e decide a próxima ação.
A segunda é ter um processo de validação repetível, não uma checagem manual feita às pressas quando o provedor anuncia uma descontinuação. Testar o modelo candidato contra uma referência de qualidade já validada, antes de qualquer decisão de troca, transforma uma migração forçada em uma decisão informada.
Criamos uma pipeline própria para fazer esse LLM-swap com segurança.
No estudo técnico completo, publicamos o processo de teste passo a passo, os critérios de decisão usados para aprovar ou reprovar cada modelo, e os resultados detalhados dos 8 modelos avaliados.
