Ótimo relato empírico! Essa conclusão bate exatamente com um princípio fundamental de engenharia de software com IA: Model Routing por complexidade cognitiva.
Usar um modelo de fronteira (como o Opus) para fazer extração estrita de JSON e parsing de texto é usar uma britadeira para pregar um quadro. Modelos com alto poder de raciocínio são treinados para inferir contexto e preencher lacunas, o que vira um problema em tarefas que exigem apenas obediência mecânica a um schema.
A regra que adoto no meu fluxo de desenvolvimento é:
Modelos rápidos e econômicos (Haiku / Flash / Qwen) como padrão para 80% do trabalho: extração, CRUD, testes unitários, documentação e refatorações delimitadas.
Modelos pesados (Opus / Pro) reservados estritamente para o que exige raciocínio difícil: segurança, race conditions, arquitetura transacional, investigação forense e auditoria de contratos.
O erro mais comum é achar que o modelo mais caro deve ser o default para tudo. Tratar a escolha do modelo como uma decisão arquitetural por tarefa economiza muito dinheiro e evita o overthinking da IA. Parabéns pelos dados e pela transparência dos testes!
A britadeira pregando quadro descreve bem os 2 casos em que o Opus perdeu por excesso: ele adicionou um campo que eu não tinha pedido e ainda justificou dizendo que assumiu que eu ia querer as notas complementares. Capacidade sobrando virou defeito.
Onde meu número não bate com o seu é na proporção. Você fala em 80% para os modelos rápidos. No meu recorte o pequeno ganhou em 14 de 47, ou seja 30%. Deve ser mix de trabalho: boa parte do que eu faço é escrita técnica longa, e aí o Haiku entrega seções que parecem escritas por quatro pessoas diferentes.
Por isso meu eixo acabou não sendo complexidade cognitiva, e sim rigidez de formato: se a saída alimenta uma pipeline, vai no pequeno.
Fiquei curioso com os seus 80%. É medido ou é a impressão depois de reclassificar? Antes de rodar as 47 em paralelo minha estimativa era bem mais generosa com o pequeno do que o resultado.
Excelente ponto, e você matou a charada quando falou do mix de trabalho!
Os meus 80% vêm da minha rotina prática de desenvolvimento de software (é uma estimativa empírica do meu fluxo diário, e não um benchmark paralelo controlado como o seu teste).
No desenvolvimento de código, a maioria esmagadora das tarefas é muito atômica e delimitada: escrever um teste unitário, ajustar um schema de banco, alterar um endpoint ou refatorar uma função isolada. Como o escopo do arquivo é pequeno e a própria suíte de testes valida o resultado na hora, os modelos menores resolvem a maior parte do dia a dia sem engasgar. Eu só escalo pro modelo pesado quando a tarefa envolve concorrência, segurança, investigação de bug de causa desconhecida ou decisão de arquitetura.
Mas pro seu caso de escrita técnica longa, concordo 100% com a sua observação. Manter a mesma voz, coesão e linha de raciocínio ao longo de um texto extenso é onde os modelos menores mais pecam (essa descrição de "parecer escrito por quatro pessoas diferentes" foi perfeita).
E achei excelente o seu eixo de "rigidez de formato": se o objetivo é alimentar uma pipeline com dados estruturados, o modelo menor ganha de lavada porque ele não tem a tentação de "ser criativo" e colocar notas adicionais onde só se pedia um schema seco.