Um estudo com 17 combinações de modelo e esforço mostra por que avaliar a tarefa real importa mais do que escolher o modelo mais caro.
Uma pergunta como “Quais recursos gargalo estão causando as rupturas?” parece direta. Para respondê-la, um agente precisa identificar o cenário, encontrar os itens em falta, cruzar roteiros e recursos alternativos, interpretar a ocupação e distinguir uma restrição que causa a ruptura de uma que apenas aparece no mesmo plano. Uma consulta pode executar sem erro e ainda responder à pergunta errada.
Alexandre Erhart e Filipe Reolon organizaram uma bateria de avaliações no NPLAN para medir esse tipo de falha. Começou como comparação de modelos, e o resultado mais útil foi o processo: testar a correção, localizar a origem do erro e só então decidir quanto raciocínio, tempo e dinheiro a tarefa exige.
O achado central: Opus 5.5 no esforço máximo e Opus 5 no esforço máximo acertaram as mesmas 12 de 13 perguntas conferíveis. O primeiro explicou melhor, mas custou US$ 0,650 por pergunta, contra US$ 0,210 do segundo. Uma melhoria na explicação não é necessariamente uma melhoria no acerto.
O que são evaluations de agentes de IA?
Evaluations, ou evals, são testes que relacionam uma entrada a critérios explícitos de sucesso. Em um agente, isso envolve mais do que ler a resposta final: é necessário observar a interpretação, a escolha das ferramentas, a consulta executada, os dados usados e o resultado entregue.
No planejamento de Supply Chain, “parece uma boa resposta” é um critério insuficiente. Uma resposta elegante pode somar um déficit acumulado várias vezes, contar item × período quando a pergunta pede itens distintos ou ignorar a eficiência de um recurso. Esses erros mudam a análise operacional mesmo quando a linguagem é convincente.
A orientação da Anthropic sobre evals de agentes e as boas práticas da OpenAI tratam tarefa, critério e julgamento como elementos separados, e o teste aplica essa lógica a perguntas de planejamento.
- 01Escrever um prompt inicialInstruções, contexto e ferramentas do agente.
- 02Criar uma tabela de gabaritoRespostas conferíveis na base, com unidade e regra de agregação.
- 03Rodar na IA para ver como ficaMesma pergunta em cada modelo e nível de esforço.
- 04Avaliar o resultado por juizConferência mecânica do acerto e juízes às cegas para a qualidade.
- 05Mudar o prompt e repetirCada versão passa pela bateria antes de ir para produção.
Como o teste foi feito
Foram 17 configurações de modelo e esforço, 16 perguntas e 272 execuções, em agosto e outubro de 2026, com perguntas em português feitas pelo caminho real da aplicação. As perguntas com resposta conferível na base formam o placar de acertos; as demais entram só nos eixos de qualidade. O modelo gera SQL e a execução ocorre localmente no banco, sem envio dos dados ao modelo nesse desenho, como descreve o artigo sobre como funciona um Agent Harness para Supply Chain.
| Eixo | O que é medido | Peso no escore |
|---|---|---|
| Acerto conferível | Comparação com uma resposta verificada na base | 35% |
| Qualidade da resposta | Adequação da análise e da explicação à pergunta | 25% |
| Qualidade do SQL | Consulta, semântica e portabilidade entre bancos | 20% |
| Apresentação | Clareza e organização da informação | 15% |
| Estrutura | Conformidade mecânica do formato solicitado | 5% |
Acerto e estrutura são conferidos mecanicamente; qualidade da resposta, SQL e apresentação são julgados às cegas por juízes independentes, que comparam as respostas de cada pergunta sob letras sorteadas. Latência e custo são registrados à parte.
Onde os modelos erraram?
Foram criadas questões com “pegadinhas” nos evaluations para avaliar a capacidade dos modelos de responder a perguntas difíceis. Elas exploram situações em que uma resposta ingênua parece plausível, mas exige interpretar corretamente unidades, granularidade, regras de agregação e o contexto do planejamento. A tabela abaixo mostra quais configurações acertaram cada questão na rodada de agosto.
e dá número errado.
| Pergunta | GPT | S5.2·HI | S5.2·XH | S5.2·MX | O5·LO | O5·MD | O5·HI | O5·XH | O5·MX |
|---|---|---|---|---|---|---|---|---|---|
| Ocupação é razão, não percentual | |||||||||
| Recurso alternativo não é operação extra | |||||||||
| Linhas não são itens | |||||||||
| Agregar no SQL, não sobre as linhas | |||||||||
| Descobrir qual é o cenário atual | |||||||||
| O déficit é carregado, não somado | |||||||||
| O dado não existe: não inventar valor | |||||||||
| Um top 10 saturado não é ranking | |||||||||
| Itens distintos ao longo da janela | |||||||||
| Granularidade de item, não item×período | |||||||||
| Roteiro mestre, não a programação | |||||||||
| A eficiência já está aplicada | |||||||||
| O status é mais grosseiro que a condição |
Ocupação. O campo guarda uma fração, então a condição para mais de 100% é maior que 1. A consulta ingênua, com maior que 100, devolve zero linhas e sustenta a conclusão errada de que não há recursos sobrecarregados.
Grão. A pergunta sobre itens abaixo do estoque de segurança tem 628 itens distintos. A maioria das respostas erradas contou 1.112 ocorrências item × período, e só 3 das 17 configurações acertaram.
Eficiência. A pergunta pede as horas para produzir 4.500 unidades com taxa de 2.250 por hora e eficiência de 0,75. A referência é 4.500 / (2.250 × 0,75) = 2,667 horas, e todas as configurações responderam 2,0 horas. O campo process_time já incorpora a eficiência e a taxa isolada não. A correção é documentar o significado dos campos e reavaliar; mais raciocínio não resolveu.
Os evals também encontram bugs da aplicação. Na Q3, o Opus 5.5 gerou SQL correto, mas a aplicação cortou a consulta no ponto e vírgula usado como separador dentro do STRING_AGG. Foi erro do produto, não de raciocínio, e trocar de modelo não teria resolvido. Houve ainda uma regressão de portabilidade: casts ::, específicos do PostgreSQL, ficaram mais frequentes na geração 5.5, embora o sistema também rode em SQL Server.
Como escolher entre qualidade, latência e custo?
| Configuração | Escore | Latência | US$ / pergunta |
|---|---|---|---|
| Opus 5.5 · max12/13 | 8,18 | 258 s | 0,650 |
| Sonnet 5.5 · max11/13 | 7,85 | 110 s | 0,192 |
| Opus 5.5 · high11/13 | 7,76 | 39 s | 0,173 |
| Sonnet 5.5 · high10/13· custo e velocidade | 7,63 | 20 s | 0,053 |
| Sonnet 5.5 · medium10/13 | 7,51 | 16 s | 0,057 |
| Sonnet 5.5 · xhigh10/13· superada | 7,50 | 27 s | 0,073 |
| Opus 5.5 · xhigh10/13· superada | 7,41 | 66 s | 0,230 |
| Opus 5.5 · medium10/13· superada | 7,38 | 32 s | 0,151 |
| Sonnet 5.2 · xhigh10/13· superada | 7,26 | 47 s | 0,082 |
| Sonnet 5.2 · max9/13· superada | 7,03 | 99 s | 0,136 |
| Sonnet 5.2 · high9/13· superada | 6,83 | 24 s | 0,053 |
| GPT-5.47/13 | 5,50 | 12 s | 0,052 |
Opus 5.5 · max
Custos observados por pergunta; tempos em segundos por pergunta. GPT-5.4 medido sem controle de esforço e pelo caminho anterior da aplicação.
A escolha começa pelo requisito da tarefa: o que não pode errar, quanto o usuário pode esperar e quanto a pergunta pode custar. Entre as configurações que atendem a esse requisito, descarta-se a que é superada em escore, custo e tempo ao mesmo tempo.
A bateria inicial custou cerca de US$ 15. Economizar US$ 0,05 por pergunta paga isso em 300 perguntas, e US$ 0,10 em 150, sem contar o trabalho de preparar referências e investigar falhas. Entre os dois Opus no máximo esforço, a diferença é US$ 0,44 por pergunta, US$ 440 a cada mil. A economia só vale se a alternativa atende ao requisito, como discute o artigo sobre Build, Buy e customização de IA para Supply Chain.
O que muda no processo?
a ser versionado.
- 01
Qualquer mudança de prompt ou modelo novo entra na bateria antes de ir para produção.
- 02
Sem overkill: subir modelo e esforço por segurança custa mais e faz o usuário esperar.
- 03
Correção e apresentação em eixos separados. Resposta bem acabada é a que passa na revisão.
Perguntas que todas as configurações acertam continuam como teste de regressão. Perguntas novas devem ter uma resposta ingênua plausível, para discriminar configurações, e um conjunto reservado evita otimizar só para o que já se conhece. Cada execução registra versão do prompt, modelo, esforço, configuração da aplicação, cenário, saída, notas, custo e tempo.
O que este teste permite concluir?
Os resultados valem para esta tarefa, base, idioma, rubrica e caminho da aplicação, e não são uma comparação geral de inteligência entre modelos. Uma única pergunta muda o placar em cerca de 7,7 pontos percentuais, e não foi calculado intervalo de confiança; as notas de agosto foram reavaliadas na rubrica atual. No NPLAN, esse método se liga à interoperabilidade, extensibilidade e transparência da IA no planejamento e à discussão sobre quem assina a decisão de um agente.