Provedores de IA descontinuam modelos com frequência, forçando empresas a substituí-los em prazos curtos, muitas vezes sem tempo hábil para validar se o modelo substituto possui um desempenho equivalente ao do modelo usado anteriormente, com o mesmo custo e latência. O risco não é abstrato: do lado do cliente final, é receber uma informação errada sobre um cancelamento, um prazo ou uma cobrança. Do lado da empresa, é o custo por sessão que sobe sem aviso, o SLA que não se sustenta em escala, ou a decisão de troca de modelo tomada sob pressão, sem dado que a sustente antes de ir para produção.
Este trabalho apresenta uma pipeline de avaliação construída sobre a plataforma Tech4AI, que testa modelos candidatos sob paridade operacional total com o ambiente de produção.
Em vez de benchmarks públicos, que testam respostas isoladas contra um usuário simulado por IA ou um gabarito construído especificamente para o teste, a pipeline reaplica conversas sintéticas baseadas nos atendimentos realizados, selecionadas e aprovadas como referência de qualidade (Base 0), reproduzindo o mesmo contexto operacional do produto: mesma memória, mesmas ferramentas, mesmo prompt. A única variável testada é o modelo por trás do agente (LLM-swap).
Oito modelos foram avaliados, das famílias GPT-4.1/5, Gemini 2.5 e modelos open-weight como Kimi-K2.5 e GPT-OSS-120B, em centenas de execuções cobrindo quatro instâncias de atendimento.
O critério de aprovação combina qualidade, conclusão de tarefas, precisão em ferramentas, latência e custo, com a taxa de alucinação operando como filtro eliminatório independente. Três modelos foram aprovados. O achado mais relevante está no motivo pelo qual outros cinco, com qualidade competitiva, foram reprovados.
O mercado de provedores de IA raramente atualiza um modelo existente: em geral, cria famílias inteiras novas e descontinua as anteriores. Um modelo em uso há dois anos, com margem de custo já validada, pode ter data de desligamento anunciada com poucos meses de antecedência. Dessa forma, migrar para o substituto recomendado pelo próprio provedor nem sempre preserva a mesma performance, o mesmo custo por sessão ou a mesma taxa de conclusão de tarefas.
O risco também não se limita ao modelo isolado: envolve toda a orquestração de múltiplos casos de uso de um agente, como cobrança, negociação e abertura de protocolo, além da precisão no acionamento de ferramentas e da manutenção de margem financeira em contratos já fechados com clientes.
O objetivo do teste é colocar um modelo candidato para atender as mesmas situações que o time já resolve hoje, e comparar o resultado contra uma referência de qualidade.
A dificuldade está em fazer essa comparação de forma justa, sem viés de contexto e sem depender de tráfego real de clientes. É para isso que existe a pipeline.
Antes de testar qualquer modelo, é preciso definir o que conta como "bom atendimento". Para isso, 106 sessões sintéticas foram revisadas manualmente, turno a turno, por um analista humano, contra um roteiro estruturado de roteamento, aderência a instruções e correção de chamadas de ferramenta.
Apenas 20 sessões sobreviveram a essa curadoria, distribuídas em quatro instâncias de atendimento diferentes. Essas 20 sessões formam a Base 0: a régua de qualidade mínima que todo modelo candidato precisa igualar ou superar, aceitando-se paráfrases e variações de linguagem, desde que preservem as informações essenciais e a conclusão do atendimento.
Cada sessão da Base 0 passa pelo mesmo fluxo:
Visualmente, esse fluxo completo, incluindo a seleção da sessão e o mascaramento, que já foram descritos acima, fica desse modo:
Para manter segurança e permitir repetir o mesmo teste várias vezes, a pipeline nunca aciona uma ferramenta real durante o replay: nenhuma cobrança, cancelamento ou alteração de cadastro acontece de fato. Quando o modelo candidato chama a ferramenta certa, no passo esperado do atendimento de referência, a pipeline devolve a mesma resposta que aquela ferramenta deu originalmente na Base 0.
Quando o modelo chama uma ferramenta diferente da esperada, ou fora da ordem do atendimento de referência, a pipeline devolve uma resposta simulada de falha, não de sucesso. Isso avisa ao modelo que a ação não funcionou, em vez de deixá-lo acreditar que deu certo, e, com esse sinal claro de falha, a pipeline desincentiva uma nova tentativa da mesma chamada, em vez de deixar o modelo repetir a ação como se ela pudesse funcionar da próxima vez. Combinada a um limite de repetições por turno, essa regra impede que uma chamada de ferramenta errada degenere num loop dentro da mesma sessão.
Essa escolha tem um efeito colateral conhecido: quando o modelo toma um caminho diferente do baseline, porém válido para resolver o atendimento, a resposta que ele recebe da ferramenta ainda é genérica, não a resposta real que esse caminho alternativo teria gerado.
Como a única variável que muda de um teste para outro é o modelo por trás do agente, qualquer diferença de performance, latência ou custo fica atribuível exclusivamente à troca de modelo, e não a diferenças de contexto ou viés de prompt. Esse mecanismo de simulação de execução de ferramentas, está resumido visualmente a seguir:
A cada chamada de ferramenta, o motor de replay decide: se ela bate com o passo esperado da Base 0, devolve a resposta real registrada; se diverge, devolve uma falha simulada e a sessão continua normalmente a partir daí, o modelo apenas segue o atendimento sabendo que aquela ação não funcionou.
A primeira camada usa regras de negócio inteiramente determinísticas, como formato de resposta e presença de campos obrigatórios.
A segunda combina duas métricas híbridas, o TCR (conclusão de tarefa) e o TCA (precisão de ferramentas), que partem de uma checagem determinística e ganham uma camada extra de julgamento contextual quando a resposta diverge do esperado.
A terceira é um painel de múltiplos juízes (LLM-as-a-Judge), que avalia a sessão completa de forma holística. Esses juízes têm arquitetura diferente da dos modelos avaliados, o que evita que um modelo favoreça respostas parecidas com o próprio estilo (viés de auto preferência).
Na prática, cada juiz retorna uma saída neste formato JSON, nunca apenas em texto livre:
{
"score": 0.82,
"verdict": "good",
"detailed_metrics": {
"quality_vs_base0": 3,
"tone_clarity": 4,
"hallucination_type": "none"
}
}
As notas de vários juízes são combinadas pela mediana para a nota de qualidade, mas usa a classificação mais grave entre eles para decidir alucinação: basta um único juiz apontar alucinação crítica para a sessão inteira ser marcada assim, mesmo que os demais não tenham percebido o problema.
Todas as conversas usadas na avaliação são datasets sintéticos, mascarados antes de qualquer chamada às APIs dos provedores.
A avaliação de agentes conversacionais hoje se apoia, em geral, em uma de três frentes, cada uma resolvendo um pedaço do problema, mas não o problema completo:
Nenhuma dessas três frentes, isoladamente, combina as três coisas que essa pipeline exige ao mesmo tempo: um corpus sintético de referência curado e aprovado por revisão humana, a troca controlada de modelo sob paridade operacional real, e um veredito que pondera qualidade, latência e custo em conjunto, com a taxa de alucinação funcionando como filtro de segurança independente, não diluída na média.
Depois de testado, cada modelo é avaliado em quatro frentes: custo por sessão, latência, capacidade de resolver a tarefa e qualidade comportamental.
Essas quatro frentes se combinam num Score Final, numa escala de 1 a 4, com pesos diferentes: 50% para qualidade, 30% para custo e 20% para latência. Quanto mais rápido e barato um modelo resolve o atendimento com qualidade, maior a nota.
Só que apenas a nota alta não é suficiente. A taxa de alucinação funciona como um filtro à parte, aplicado depois do Score Final: um modelo só é aprovado se, além de Score Final igual ou maior que 75% e Pass Rate igual ou maior que 70%, tiver 0% de alucinações críticas (informações inventadas com impacto direto na decisão do usuário) e no máximo 2% de alucinações gerais (imprecisões menores). Um modelo pode ter a melhor nota do estudo e ainda assim ser reprovado, se ultrapassar esse limite.
Gemini 2.5 Flash, GPT-4.1 nano e GPT-5 mini apresentaram Score Final acima de 79%, patamar competitivo o suficiente para aprovação caso o critério fosse apenas a média ponderada de qualidade, latência e custo.
Ainda assim, os três foram reprovados por excederem o limite de 2% de Hallucination Rate geral definido no projeto. A taxa de alucinação, não a qualidade da resposta, foi o fator eliminatório para esses três casos. O GPT-5 mini foi além: registrou a única ocorrência de alucinação crítica entre os oito candidatos (1,6% das sessões), o requisito eliminatório mais rígido da pesquisa.
Sem telemetria de custo contratado, a pipeline usa o volume de tokens processados por sessão como proxy de custo. Ao converter esse consumo para valor monetário, usando os preços públicos de tabela de cada provedor, o cenário muda: o GPT-5.4 mini, que recebe a melhor nota de custo normalizada entre os oito candidatos, tem na prática o maior Custo por Sessão estimado (cerca de US$ 0,093), cerca de 5,3 vezes o custo do GPT-5.4 nano (US$ 0,017) e 5,8 vezes o do GPT-4.1 nano (US$ 0,016, o mais barato da amostra).
A causa não está no volume de tokens processados, e sim no preço de tabela por token de saída do GPT-5.4 mini (US$ 4,50 por milhão), bem mais alto que o do GPT-5.4 nano (US$ 1,25 por milhão) na mesma família de modelos.
Como modelos de linguagem são probabilísticos, o mesmo modelo pode produzir resultados diferentes a cada rodada independente. Ao recalcular o veredito rodada a rodada, dois modelos reprovados no agregado (Gemini 2.5 Flash e GPT-5 mini) oscilaram entre aprovação e reprovação de forma quase equilibrada, o que sugere dependência da amostra específica de sessões, não uma limitação estrutural.
Já o GPT-OSS-120B teve leitura oposta: nunca atingiu aprovação em nenhuma das execuções, resultado consistente com uma causa estrutural identificada (o modelo usa nativamente o formato de saída Harmony, incompatível com o padrão do restante da pipeline, o que fez com que 87% das sessões terminassem sem decisão reconhecível).
Ordenando os oito modelos só pela pontuação composta (Score Final), o GPT-4.1 nano aparece em 3º lugar, à frente de Kimi-K2.5, Gemini 2.5 Flash e GPT-5 mini. Ainda assim, foi reprovado, porque a taxa de alucinação é avaliada à parte da pontuação. O ranking por score e o ranking por veredito final contam histórias diferentes, e é por isso que os dois são mostrados lado a lado nos gráficos abaixo.
Em conclusão, a recomendação final é a adoção do GPT-5.4 mini, sem nenhuma ressalva operacional identificada nos dados coletados. O GPT-5.4 nano segue como alternativa de menor custo e latência, com margem de segurança mais estreita. O Kimi-K2.5 é aprovado pelos critérios de qualidade e permanece como candidato secundário, condicionado à validação operacional do deployment junto ao provedor.
Este resumo cobre os principais achados, mas o estudo completo detalha pontos que não exploramos aqui: a estrutura do prompt usado pelo painel de juízes (LLM-as-a-Judge), a consistência do veredito execução por execução para os oito modelos, e a lista completa de limitações do estudo e critérios técnicos usados na matriz de decisão final.
