Model overengineering: precisamos sempre do melhor modelo?

Em uma semana repleta de lançamentos de novos modelos como GPT-6 Luna, GPT-6 Sol, Claude Opus 5.5, Grok 4.7, MiMo-V2.6 e provavelmente mais algum modelo chinês que eu esqueci no meio de tanta coisa, decidi trazer um ponto que considero importante e que ainda vejo pouca gente discutindo.

Será que realmente precisamos utilizar o melhor modelo disponível para tudo?

Antes de chegar nesse ponto, acho interessante entender um pouco melhor o que estamos chamando de “melhor modelo”.

De maneira bastante simplificada, uma LLM é um modelo treinado sobre grandes volumes de dados para aprender padrões e realizar tarefas envolvendo linguagem, código, interpretação de informações e, cada vez mais, interação com ferramentas e outros sistemas.

Mas quando colocamos dois modelos lado a lado, o que faz um ser “melhor” que o outro?

Vamos pegar como exemplo dois modelos de fronteira: GPT-6 Astra e Claude Fable 5.1.

Os dois estão inseridos em ecossistemas que oferecem recursos como reasoning, tool calling, prompt caching, system prompts, grandes janelas de contexto e integração com agentes.

E, claro, existe uma coisa que chama bastante atenção quando começamos a colocar IA em produção:

o preço dos tokens de entrada e saída.

Só que antes de falar sobre custo, precisamos entender algumas dessas camadas.

##Reasoning

Reasoning talvez seja uma das palavras que mais aparecem atualmente quando falamos sobre modelos.

Mas existe uma confusão aqui.

Reasoning não significa necessariamente que o modelo está mostrando para você todo o processo interno que utilizou para chegar até uma resposta.

Na prática, estamos falando da capacidade do modelo de trabalhar com problemas que exigem múltiplos passos, decomposição de tarefas, planejamento e avaliação de diferentes caminhos antes de produzir uma resposta.

Um bom modelo de reasoning consegue pegar algo como:

“Analise essa aplicação, encontre a origem do bug, proponha uma solução e valide se ela introduz algum problema em outro lugar.”

E transformar isso em etapas menores.

Investigar o contexto.

Levantar hipóteses.

Buscar evidências.

Executar ferramentas.

Validar resultados.

Só então produzir uma resposta.

Essa capacidade se torna ainda mais importante quando começamos a trabalhar com agentes e subagentes.

Quanto melhor o modelo consegue decompor um problema, maior tende a ser sua capacidade de trabalhar de forma autônoma em tarefas mais longas.

##Thinking

Aqui temos outro termo que costuma causar confusão.

Quando vemos algo como:

Thinking...

antes da resposta de um agente, isso não significa necessariamente que estamos vendo literalmente todos os pensamentos internos daquele modelo.

Existem mecanismos internos de raciocínio que podem consumir tokens adicionais antes da geração da resposta final.

O objetivo é permitir que o modelo dedique mais computação ao problema antes de responder.

Em alguns modelos, inclusive, podemos controlar algo semelhante a um reasoning effort, permitindo gastar mais ou menos computação dependendo da complexidade da tarefa.

Isso é extremamente útil.

Mas também nos leva diretamente ao problema que quero discutir neste artigo:

quanto mais raciocínio, mais contexto e mais chamadas, maior tende a ser o custo.

##Tool Calling

Esse aqui, nos últimos dias, deu bastante assunto.

Tool calling é basicamente a capacidade de um modelo escolher e chamar ferramentas externas durante a execução de uma tarefa.

Pode ser:

acessar um arquivo;

pesquisar na internet;

consultar um banco de dados;

executar código;

chamar uma API;

utilizar uma ferramenta exposta por um MCP;

ou delegar uma tarefa para outro agente.

O modelo recebe uma lista de ferramentas disponíveis e precisa decidir:

qual ferramenta chamar, quando chamar e com quais argumentos.

E isso parece simples até você começar a colocar agentes para rodar durante alguns minutos.

Uma escolha errada pode significar uma tool call desnecessária.

Uma tool call desnecessária pode adicionar mais contexto.

Mais contexto gera mais tokens.

Mais tokens geram mais custo.

E decisões ruins podem fazer o agente entrar em loops completamente desnecessários.

É justamente aqui que um lançamento recente chamou bastante minha atenção: Jev.

##Um agente para ajudar seu agente a decidir?

O Jev, da TypeSafe AI, propõe uma abordagem diferente.

Ele não foi criado para escrever um artigo, gerar código ou conversar com você.

Ele foi criado para tomar decisões estruturadas.

A aplicação envia um estado e perguntas com respostas possíveis previamente definidas. O Jev retorna escolhas, scores ou valores booleanos acompanhados de probabilidades.

A própria Vercel apresenta casos como classificação, routing, scoring, verificação de outputs e escolha do próximo passo de um agente.

Imagine que seu agente tenha cinco ferramentas disponíveis.

Em vez de simplesmente jogar todas elas para um modelo extremamente caro decidir o próximo passo, você poderia utilizar uma camada especializada para avaliar:

Qual ferramenta possui maior probabilidade de ser útil neste momento?

Ou:

O agente deve continuar, tentar novamente, pedir ajuda ao usuário ou encerrar a tarefa?

Ou até:

Esse output atende aos critérios necessários para seguirmos para a próxima etapa?

Essa é uma maneira muito interessante de pensar arquitetura de agentes.

Não apenas:

LLM → tool → LLM → tool → LLM

Mas algo mais próximo de:

LLM → decisão → ação → validação → próxima decisão

A Vercel inclusive descreve o Jev dentro de agent loops justamente dessa maneira: como uma camada de decisão capaz de selecionar modelos ou revisar uma tool call proposta, enquanto a aplicação continua responsável pela execução e pelas regras de segurança.

E isso nos leva a outro ponto importante.

##Harness e System Prompt

Quando utilizamos Codex, Claude Code ou qualquer outro agente de desenvolvimento, não estamos utilizando apenas um modelo.

Existe todo um sistema ao redor dele.

System prompts.

Ferramentas.

Gerenciamento de contexto.

Regras para execução.

Estratégias de compactação.

Permissões.

Loops de agente.

Subagentes.

Essas camadas fazem parte do que normalmente chamamos de agent harness.

E isso muda MUITO a experiência.

Durante bastante tempo utilizei bastante Claude.

Mais recentemente migrei boa parte do meu workflow para o Codex.

Não necessariamente porque acredito que um modelo seja universalmente melhor que o outro.

Mas porque, para o meu fluxo de trabalho, percebi que a combinação dos modelos da OpenAI com o harness do Codex estava me entregando resultados melhores.

E acredito que esse é um detalhe que muitas comparações de benchmark ignoram.

Você raramente utiliza apenas o modelo.

Você utiliza:

modelo + contexto + ferramentas + system prompt + harness + sua própria forma de trabalhar.

Agora finalmente chegamos ao ponto que eu queria discutir.

##Model Overengineering

É quando escolhemos o modelo mais poderoso disponível simplesmente porque ele é o mais poderoso disponível.

A tarefa poderia ser resolvida por um modelo pequeno.

Mas usamos o modelo de fronteira.

A classificação poderia ser resolvida por algo especializado.

Mas usamos um modelo de reasoning.

O agente precisa decidir entre três ferramentas.

Mas enviamos 50 mil tokens de contexto para o modelo mais caro disponível.

Por quê?

Porque ele é melhor.

Só que ser melhor não significa ser necessário.

A própria OpenAI hoje posiciona modelos diferentes para necessidades diferentes: GPT-6 Astra para trabalhos complexos, GPT-6 Sol para equilibrar capacidade e custo e GPT-6 Luna para workloads de alto volume sensíveis a preço.

Esse posicionamento, por si só, já diz bastante coisa.

Se todo problema precisasse do modelo mais poderoso, modelos menores simplesmente não precisariam existir.

##O melhor modelo pode ser o modelo suficiente

Acho que essa deveria ser uma mudança importante na nossa mentalidade.

Em vez de perguntar:

Qual é o melhor modelo disponível?

Talvez devêssemos começar perguntando:

Qual é o modelo mais simples e barato que consegue resolver essa tarefa com a qualidade que eu preciso?

Classificação simples?

Talvez um modelo pequeno ou especializado já seja suficiente.

Extração estruturada?

Provavelmente você não precisa utilizar um modelo de fronteira.

Routing de agentes?

Talvez um modelo como o Jev seja muito mais interessante.

Implementação complexa envolvendo diversos arquivos, regras de negócio e bastante contexto?

Agora sim talvez faça sentido chamar um Astra ou Fable.

Arquitetura, debugging complexo ou uma tarefa que realmente exige bastante reasoning?

Modelo de fronteira novamente.

A questão não é parar de utilizar os melhores modelos.

Muito pelo contrário.

É utilizar os modelos mais poderosos onde o poder deles realmente gera retorno.

##No fim, ainda é uma decisão de engenharia

E aqui está um ponto que considero extremamente importante.

Hoje, pelo menos, essa escolha ainda precisa ser nossa.

Como engenheiros, precisamos entender qual modelo utilizar, quando utilizar e por que utilizar.

Não deveríamos simplesmente olhar para o benchmark da semana, descobrir qual modelo está no topo e colocar ele para resolver absolutamente tudo.

Escolher um modelo também é uma decisão de arquitetura.

Precisamos olhar para a tarefa e começar a fazer algumas perguntas.

Qual é a complexidade desse problema?

Quanto contexto ele realmente precisa?

Ele necessita de reasoning?

Precisa utilizar ferramentas?

Qual é o impacto de uma resposta errada?

Qual latência eu considero aceitável?

Qual nível de qualidade eu realmente preciso?

E principalmente:

Quanto estou disposto a pagar para resolver essa tarefa?

Porque existe uma diferença muito grande entre o melhor modelo disponível e o melhor modelo para aquele problema.

E acho que estamos deixando isso passar um pouco.

Temos modelos ficando cada vez melhores, benchmarks crescendo, context windows gigantescas, reasoning cada vez mais sofisticado e novos modelos de fronteira aparecendo praticamente toda semana.

Naturalmente queremos utilizar tudo isso.

Mas nem toda task precisa disso.

Um modelo excelente em reasoning pode ser um desperdício para uma classificação binária.

Um modelo extremamente bom em programação pode não trazer nenhum ganho relevante para uma extração simples de informações.

Um modelo pequeno pode resolver 90% das chamadas de uma aplicação por uma fração do custo e ainda assim não ser suficiente para os outros 10%.

E é justamente nesses 10% que podemos escalar para algo mais poderoso.

Para mim, essa começa a ser uma habilidade cada vez mais importante para quem trabalha com IA.

Não apenas saber utilizar modelos.

Mas conhecer suficientemente os modelos disponíveis para saber onde cada um faz sentido dentro da arquitetura.

E isso exige teste.

Não adianta simplesmente assumir que um modelo menor vai funcionar porque ele é mais barato.

Precisamos medir.

Testar qualidade.

Latência.

Quantidade de tokens.

Taxa de erro.

Capacidade de tool calling.

Comportamento em diferentes tipos de tarefa.

E colocar esses dados na balança.

Porque no fim das contas não existe simplesmente:

Qual é o melhor modelo?

Existe:

Qual é o melhor modelo para este problema, dentro deste contexto e destas restrições?

E essa diferença parece pequena, mas muda completamente a forma como construímos produtos com IA.

##O futuro talvez seja menos sobre escolher um modelo

No futuro, provavelmente veremos cada vez mais sistemas capazes de tomar parte dessas decisões automaticamente.

Routers escolhendo modelos.

Modelos pequenos classificando tarefas.

Um modelo decidindo qual ferramenta utilizar.

Outro modelo mais poderoso sendo chamado apenas quando necessário.

Uma camada especializada validando o output antes de avançar.

O próprio Jev aponta bastante para esse caminho.

Mas existe um detalhe importante aqui.

Mesmo que o sistema passe a escolher o modelo dinamicamente, alguém ainda precisa projetar essa arquitetura.

Quem define quais modelos estão disponíveis?

Quando podemos escalar para um modelo mais caro?

Qual nível de confiança é suficiente?

Quando uma resposta precisa passar por validação?

Quanto estamos dispostos a gastar naquela operação?

Quando o sistema deveria tentar novamente?

E quando simplesmente deveria parar?

Hoje, essas continuam sendo decisões nossas.

O Jev pode ajudar seu agente a decidir entre caminhos.

Um router pode escolher entre diferentes modelos.

Um sistema pode automaticamente escalar uma tarefa quando percebe que ela é mais complexa.

Mas nós ainda precisamos definir as regras do jogo.

E talvez esse seja justamente o ponto mais interessante dessa nova fase.

Estamos deixando de simplesmente integrar uma API de IA e começando a realmente projetar sistemas utilizando diferentes níveis de inteligência.

Em vez de um único modelo tentando resolver tudo, começamos a trabalhar com arquiteturas de modelos.

Um modelo pequeno pode classificar uma tarefa.

Outro pode escolher qual ferramenta utilizar.

Um modelo de fronteira pode entrar apenas quando a complexidade justificar.

E outra camada pode validar se o resultado está dentro dos critérios esperados.

Porque, no final das contas, engenharia continua sendo engenharia.

Não deveríamos colocar Kubernetes em um projeto que roda perfeitamente em uma VPS.

Não deveríamos criar um microsserviço para uma aplicação que possui três endpoints.

E talvez também não devêssemos gastar milhões de tokens em um modelo de fronteira para resolver algo que um modelo muito menor conseguiria fazer tranquilamente.

Modelos mais poderosos são incríveis.

A questão não é evitar utilizá-los.

É saber quando realmente precisamos deles.

Talvez uma das habilidades mais importantes para quem está construindo com IA daqui para frente não seja apenas saber trabalhar com os melhores modelos.

Vai ser saber qual modelo utilizar, como utilizar e, principalmente, por que utilizar.

A inteligência não precisa ser máxima o tempo inteiro.

Ela precisa ser suficiente para o problema que estamos tentando resolver.

E talvez seja justamente quando ignoramos isso que entramos no que eu gosto de chamar de:

Model Overengineering.