«Qual é o melhor modelo?» é a pergunta de quem ainda não pôs nenhum em produção
A conversa começa sempre igual. Alguém abre um ranking, aponta o primeiro lugar e pergunta se montamos o agente com esse. É uma pergunta razoável e está mal feita, porque assume que um agente usa um modelo. Os agentes que aguentam produção não usam um: usam vários. E a decisão que de facto importa não é qual, é o repartimento.
O motivo é de arquitetura e é aborrecido. Um agente não faz uma tarefa: faz uma cadeia. Lê um e-mail e percebe do que trata. Procura na tua documentação e tira três excertos. Redige uma resposta que um cliente teu vai ler. Decide se aquilo sai sozinho ou passa por uma pessoa. Quatro passos com quatro exigências diferentes: classificar um e-mail em seis categorias é um problema resolvido há anos; escrever o que o teu cliente lê é onde pões a cara. Pagar o modelo mais caro para os quatro passos é pôr o teu melhor advogado a tirar fotocópias.
Não é opinião nossa. O guia da OpenAI para construir agentes di-lo sem rodeios: os modelos têm forças e compromissos diferentes em complexidade da tarefa, latência e custo, e nem todas as tarefas precisam do modelo mais inteligente. O exemplo deles é exatamente o de cima: uma recuperação simples ou uma classificação de intenção pode ser tratada por um modelo mais pequeno e rápido, ao passo que decidir se se aprova um reembolso beneficia de um mais capaz. E recomendam considerar vários modelos para tarefas diferentes do mesmo fluxo em vez de um para tudo. Fonte: A practical guide to building agents, OpenAI, consultado a 12 de setembro de 2026.
Este guia trata de tomar essa decisão com critério: os três eixos que decidem mesmo, a ordem por que se percorrem, como se reparte e que camada é preciso montar para que mudar de modelo não seja uma obra. O que não é: uma tabela dos «melhores LLM de 2026» — essa caduca antes de a publicarmos — nem a fatura de operar IA em produção, que é outra conversa com outros números.
Os três eixos que decidem mesmo
Tirado o ruído, a escolha assenta em três perguntas. Nenhuma das três se responde a ler a ficha do modelo: as três respondem-se a medir em tua casa.
| Eixo | A pergunta a que responde | Como se mede no teu caso |
|---|---|---|
| Acerto na tua tarefa | Quantos dos meus casos reais resolve bem? | Uma bateria de 30-50 casos teus com a resposta correta escrita ao lado |
| Latência | Aguenta o canal onde o agente vive? | O percentil 95 do tempo de resposta, nunca a média |
| Custo por caso resolvido | Quanto custa resolver um de ponta a ponta? | Custo do fluxo completo a dividir pelos casos resolvidos, não preço por milhão de tokens |
O acerto é o eixo que mais gente salta, porque é o que dá trabalho. «Acerto» não é uma nota geral: é a percentagem dos TEUS casos que saem bem. Para o ter é preciso a parte aborrecida — trinta ou cinquenta casos reais, e-mails a sério com as suas gralhas e os seus anexos esquisitos, com a resposta correta escrita ao lado. Sem essa bateria não estás a escolher modelo: tens uma opinião sobre modelos, que é outra coisa e não se defende numa reunião.
A latência não é um número absoluto: é um número contra um canal. Um chat no teu site tem um orçamento de segundos porque há uma pessoa a olhar para o ecrã. Um processo noturno que concilia faturas tem a noite toda. O mesmo modelo é rápido num e lento no outro, por isso «é rápido?» não significa nada enquanto não disseres onde. A Anthropic apresenta-o pelo que é, uma troca: os sistemas agênticos trocam latência e custo por melhor desempenho na tarefa, e há que decidir quando essa troca compensa. Fonte: Building effective agents, Anthropic, 19 de dezembro de 2024, consultado a 12 de setembro de 2026.
O preço por milhão de tokens é um preço de tabela, não a tua fatura. Um modelo barato que precisa de três tentativas, deixa metade dos campos por preencher e acaba a escalar para uma pessoa sai-te mais caro do que um caro que acerta à primeira. A unidade correta é o caso resolvido: custo total do fluxo — todas as chamadas, todas as repetições, incluindo as do passo que falhou — a dividir pelos casos que saíram bem sem ninguém lhes tocar.
O ranking público não sabe nada do teu trabalho
Com os três eixos em cima da mesa percebe-se porque é que o ranking não decide. Um ranking público mede um exame padronizado: perguntas de concurso, problemas de código de brincar, enigmas de lógica. A tua tarefa não é isso. A tua tarefa são os e-mails dos teus clientes, o teu jargão interno, os teus PDF mal digitalizados e a tua política de devoluções, e nenhuma destas quatro coisas aparece em tabela nenhuma. Desenvolvemo-lo na altura: os benchmarks de LLM não preveem o teu resultado.
Para o que um ranking público serve é o contrário do que se faz com ele: serve para descartar, não para escolher. Diz-te que modelos estão na conversa e quais ficaram duas gerações para trás, e isso poupa-te avaliar quinze candidatos. A partir daí, a lista curta — dois, três — ordena-se com a tua bateria de casos. Essa ordem quase nunca coincide com a do ranking, e quando coincide é uma casualidade com que não podes contar da próxima vez.
O repartimento: barato para classificar, caro para decidir
O padrão tem nome e está documentado. A Anthropic chama-lhe encaminhamento: um primeiro passo classifica a entrada e dirige-a ao tratamento especializado que lhe compete. A utilidade, explicam, é separar responsabilidades e poder escrever prompts mais especializados, porque sem esse repartimento otimizar para um tipo de entrada piora o desempenho nos restantes. E um dos exemplos que dão é literalmente o repartimento por custo: mandar as perguntas fáceis e comuns para modelos pequenos e económicos, e as difíceis ou invulgares para modelos mais capazes. Fonte: Building effective agents, Anthropic, 19 de dezembro de 2024, consultado a 12 de setembro de 2026.
Traduzido para os passos de um agente típico, o repartimento costuma ficar assim. A coluna da direita é um ponto de partida, não uma lei:
| Passo do agente | O que exige mesmo | Onde costuma cair |
|---|---|---|
| Classificar a entrada e encaminhar | Consistência e velocidade sobre um conjunto fechado de categorias | Modelo pequeno |
| Extrair campos de um documento | Formato estável; o erro deteta-se com validação | Modelo pequeno com contrato de saída |
| Procurar e resumir nos teus documentos | Fidelidade à fonte; manda a qualidade da recuperação | Modelo intermédio |
| Decidir sobre dinheiro, pessoas ou dados regulados | Juízo e nuance; o erro paga-se em euros ou em reputação | Modelo mais capaz |
| Redigir o que um cliente vai ler | Tom, precisão e zero invenção | Modelo mais capaz |
O único que pode confirmar essa tabela é o teu conjunto de casos. Há classificações com vinte categorias sobrepostas onde o modelo pequeno se afunda, e redações tão delimitadas — um aviso de receção com três variáveis — que o pequeno vai de sobra. Por isso o repartimento decide-se a medir e revê-se quando muda o catálogo de modelos ou muda o teu volume.
Uma nuance que poupa dissabores: encaminhar só compensa quando as categorias são mesmo distintas e a classificação se pode fazer com precisão. É a condição que a própria Anthropic põe a este padrão, e é a que falha quando alguém mete um encaminhador onde não fazia falta. Se o classificador erra, não poupaste nada: puseste um ponto de falha novo à frente de tudo o resto, e ainda por cima silencioso, porque uma entrada mal encaminhada não dá erro — dá uma resposta confiante do tipo errado.
A ordem certa: começa pelo caro e desce até se notar
Com o repartimento claro fica o como. O guia da OpenAI propõe uma receita que vai contra o instinto de toda a gente: construir o protótipo com o modelo mais capaz em cada tarefa para fixar uma linha de base de desempenho, e a partir daí experimentar substituí-lo por modelos mais pequenos para ver se continuam a dar um resultado aceitável. Os seus princípios, por esta ordem: montar avaliações para fixar a linha de base, atingir o objetivo de acerto com os melhores modelos disponíveis e só depois otimizar custo e latência substituindo grandes por pequenos onde der. Fonte: A practical guide to building agents, OpenAI, consultado a 12 de setembro de 2026.
- Monta a bateria de casos antes de tocares no agente. Trinta ou cinquenta, reais, com a resposta correta ao lado. É o passo que toda a gente salta e o que decide se o resto serve de alguma coisa.
- Constrói o agente inteiro com o melhor modelo disponível em cada passo. Ainda não estás a otimizar: estás a descobrir se o teu objetivo de acerto é sequer alcançável.
- Mede contra a bateria. Se aqui não chegas ao objetivo, o problema não é o modelo: é o prompt, os teus dados, a recuperação ou a tarefa — e descer de modelo só o vai esconder.
- Atingido o objetivo, desce um degrau de cada vez e volta a passar a bateria. Uma mudança, uma medição. Duas mudanças ao mesmo tempo e já não sabes qual foi.
- Para no degrau anterior ao que parte. E deixa escrito que passo usa que modelo e com que acerto medido, porque daqui a três meses ninguém se vai lembrar.
A razão para não fazer ao contrário é de diagnóstico, não de purismo. Se começas pelo modelo barato e o agente não funciona, tens quatro suspeitos e nenhuma forma de os separar: pode ser o modelo, o prompt, os teus dados ou uma tarefa que nunca foi bem definida. Começando por cima, quando algo parte ao descer sabes exatamente o que o partiu, porque só mudaste uma coisa.
A camada que te deixa mudar de modelo sem tocar no agente
Tudo o que vem acima tem prazo de validade. O catálogo de modelos muda de poucos em poucos meses, os preços mexem-se e os fornecedores descontinuam versões. Se a decisão de hoje está escrita dentro do agente — o nome do modelo repetido em sete sítios do código —, daqui a seis meses não a vais poder refazer, e acabas com o problema que descrevemos em como mudar de modelo sem partir as tuas automações: o fluxo não parte com um erro, parte com outro formato e outro tom, em silêncio.
A camada que o evita são cinco peças, e nenhuma é sofisticada:
- Uma só função que chama o modelo. Todas as chamadas passam por ali. Se há sete sítios no código com o nome de um modelo lá dentro, já tens dívida.
- O identificador do modelo, em configuração. Um ficheiro com o modelo de cada passo. Mudar de modelo tem de ser mudar uma linha, não abrir o agente.
- Um contrato de saída validado. Antes de o resultado tocar em qualquer sistema, verifica-se que tem a forma combinada. É o que transforma uma mudança silenciosa de formato num erro visível.
- A bateria de casos, executável com um comando. Se experimentar um modelo novo custa meia manhã de trabalho manual, não se vai experimentar.
- Um registo de que modelo atendeu que caso. Sem isto não podes comparar o antes e o depois de uma mudança, nem explicar porque é que na semana passada corria melhor.
Isto não é uma otimização opcional que se deixa para a fase dois. É a diferença entre escolher um modelo hoje e poder voltar a escolher daqui a seis meses. Quando essa camada não existe, a decisão de modelo toma-se uma vez e herda-se para sempre, que é exatamente a forma errada para um sistema que vive num mercado que se mexe todos os trimestres.
A tabela de repartimento: uma página, com dono e data
O fecho é o mesmo que em as instruções de um agente de IA: se a decisão não está escrita, não existe. Uma página chega, e tem de responder a estas cinco coisas.
- Que modelo usa cada passo, com uma linha de porquê e o acerto medido contra a bateria no dia em que se decidiu.
- O que se experimentou e se descartou. O candidato que não entrou e o motivo. Sem isto, alguém vai voltar a testá-lo do zero daqui a quatro meses.
- Quem assina. Uma pessoa com nome. Uma tabela sem dono nunca se revê.
- O que dispara uma revisão: aparecer um modelo novo relevante, o fornecedor descontinuar o que usas, o volume mudar de ordem de grandeza ou o acerto medido descer.
- Próxima revisão. Uma data, mesmo que não tenha acontecido nada. A decisão caduca sozinha e ninguém avisa.
Se o teu agente já está em produção e esta página não existe, começa pelos passos que tocam em dinheiro: que modelo decide um reembolso, que modelo redige o que o teu cliente lê e com que acerto medido. O resto pode esperar uma semana.
Nós montamos essa camada antes do agente: chamada isolada, modelo em configuração, contrato de saída e bateria de casos executável, como parte da infraestrutura de IA para empresas sobre a qual depois se constroem os empregados IA. É a parte que ninguém mostra numa demo e a única que decide se daqui a um ano mudas de modelo numa tarde ou tens de refazer o sistema. A lógica completa está em criar um agente de IA que aguente produção.