"Qual é o melhor modelo?" é a pergunta mais feita e a que menos ajuda. O modelo que lidera o ranking hoje não lidera em seis meses, o preço muda antes disso, e o que é melhor para redigir uma resposta é desperdício para classificar um pedido. Times que escolhem um modelo e constroem tudo sobre ele descobrem o custo dessa decisão na primeira troca, quando percebem que a troca não é possível.
A pergunta que tem resposta é outra: qual modelo para cada tarefa, com que fallback, testado contra que casos, e trocável a que custo. Este texto trata de cada parte.
Por tarefa, não por projeto
Um agente em produção executa tarefas de natureza diferente numa mesma conversa. Classificar a intenção do cliente. Decidir qual especialista recebe o pedido. Extrair campos de um texto. Redigir a resposta final. Resumir o histórico para não estourar o contexto.
Classificar e rotear são tarefas de decisão curta: um modelo pequeno e barato faz bem, e faz rápido. Redigir a resposta final para um cliente é onde a qualidade aparece, e onde vale pagar mais. Usar o modelo mais caro para tudo multiplica o custo sem melhorar o resultado onde ele não importa; usar o mais barato para tudo economiza onde não deveria. O desenho certo roteia: cada tarefa vai para o modelo que a resolve com a qualidade necessária ao menor custo.
Os seis critérios, por tarefa
| Critério | Pergunta |
|---|---|
| Qualidade na tarefa específica | Nos meus casos reais, não no benchmark público, ele acerta o que precisa? |
| Custo por chamada | Com o contexto que essa tarefa carrega de verdade, quanto custa cada execução? |
| Latência | O cliente está esperando? Classificação pode levar segundos; resposta no WhatsApp, não. |
| Janela de contexto | O histórico e os documentos cabem? Se não, a tarefa precisa de resumo antes. |
| Onde processa | A região atende à exigência de dado pessoal do meu setor? Existe opção sem retenção? |
| Disponibilidade | Quando ele cai, o que acontece? Existe segundo modelo pronto para assumir? |
O primeiro critério é o que mais engana. Ranking público mede tarefa genérica em inglês; a sua tarefa é específica, em português, com o seu vocabulário. A única medida que vale é a taxa de acerto nos seus casos, e isso exige ter os casos.
Como testar antes de subir
- Monte um conjunto de casos reais. Cinquenta a cem exemplos tirados da operação, com a resposta esperada. Incluindo os difíceis: o cliente que escreve tudo em maiúscula, o pedido com dois itens, o campo vazio. É o ativo mais valioso do projeto e o que ninguém quer montar.
- Rode cada candidato contra o conjunto. Taxa de acerto, custo total, latência média. Três números por modelo, por tarefa.
- Versione a instrução junto com o modelo. A mesma instrução se comporta diferente em modelos diferentes. O teste é do par instrução mais modelo, e o par precisa ter versão.
- Teste ao vivo com as integrações reais antes de promover. Modelo que acerta com dado de teste e erra com o retorno real do ERP não passou.
- Mantenha o conjunto vivo. Cada caso que saiu errado em produção entra no conjunto. É assim que a próxima troca de modelo é testada contra o que já deu problema.
Regra prática: se você não consegue dizer a taxa de acerto do modelo atual nos seus casos, você não tem base para dizer que o próximo é melhor. Ranking não substitui isso.
Fallback não é opcional
Provedor de modelo fica indisponível, degrada, limita volume. Quando isso acontece às 14h de uma segunda-feira, o agente que depende de um único modelo para de atender. O desenho de produção tem um segundo modelo pronto para cada tarefa crítica, e a troca acontece sozinha, por regra: custo, qualidade e disponibilidade.
Isso exige que o segundo modelo também tenha sido testado contra o conjunto de casos, e que a instrução funcione nos dois. É mais trabalho no começo, e é o que separa uma operação de uma dependência.
O lock-in silencioso
O lock-in de modelo raramente vem de contrato. Vem de instrução escrita e ajustada durante meses contra os vícios de um modelo específico, de formato de saída que só aquele modelo produz do jeito esperado, de ferramentas declaradas no dialeto de um provedor. Quando chega a hora de trocar, o time descobre que trocar significa reescrever, e não troca.
Três decisões que mantêm a troca possível:
- Camada de abstração entre agente e provedor. O agente chama "o modelo de redação", não um provedor específico. Quem resolve qual é o roteador.
- Ferramentas definidas de forma neutra, com tipo, e traduzidas para o formato de cada provedor pela plataforma. Padrões como o MCP existem para isso.
- Instrução com versão e rollback, para que a adaptação a um modelo novo seja uma versão nova, testada, e não uma edição sobre a que está no ar.
Como a Runflow trata isso
O SDK é multi-LLM: o agente define a tarefa, e o modelo é escolhido por configuração, não por código. O LLM Hub faz o roteamento entre provedores, com fallback automático por custo, qualidade e disponibilidade, e controle de custo por área e usuário, sem que cada time precise contratar API por conta própria. Você decide por onde o dado passa: provedores sem retenção, ou modelo próprio na sua infraestrutura.
O Prompt Studio mantém as instruções versionadas, com variáveis e rollback, sem deploy de código, e o teste ao vivo com os conectores reais acontece antes de promover para produção. É o que permite tratar a troca de modelo como uma versão nova testada, e não como uma reescrita.
Perguntas frequentes
Qual o melhor modelo de IA para usar em produção?
A pergunta não tem resposta útil, porque o melhor muda em meses e o que é melhor para redigir é desperdício para classificar. A pergunta que tem resposta é qual modelo para cada tarefa: classificação e roteamento vão bem com modelo pequeno e barato; a resposta final ao cliente é onde vale pagar mais. A escolha se faz por seis critérios avaliados nos seus casos reais: qualidade na tarefa específica, custo com o contexto real, latência, janela de contexto, região de processamento e disponibilidade com fallback.
Como testar um modelo de IA antes de colocar em produção?
Montando um conjunto de cinquenta a cem casos reais da operação com a resposta esperada, incluindo os difíceis; rodando cada modelo candidato contra o conjunto e medindo taxa de acerto, custo e latência; versionando a instrução junto com o modelo, porque o teste é do par; testando ao vivo com as integrações reais antes de promover; e alimentando o conjunto com cada caso que sair errado em produção.
Por que usar mais de um modelo de IA no mesmo agente?
Porque um agente executa tarefas de natureza diferente numa mesma conversa: classificar intenção, rotear, extrair campos, redigir, resumir. Cada uma tem exigência de qualidade e custo diferente. Usar o modelo mais caro para tudo multiplica custo sem ganho onde a qualidade não importa; usar o mais barato para tudo economiza onde não deveria. O roteamento manda cada tarefa para o modelo que a resolve ao menor custo.
O que é fallback de modelo e por que é necessário?
É ter um segundo modelo pronto para assumir cada tarefa crítica quando o provedor principal fica indisponível, degrada ou limita volume, com a troca acontecendo por regra de custo, qualidade e disponibilidade. Exige que o segundo modelo também tenha sido testado contra o conjunto de casos e que a instrução funcione nos dois. Sem fallback, o agente para de atender quando o provedor cai.
Como evitar lock-in de provedor de modelo de IA?
O lock-in raramente vem de contrato; vem de instrução ajustada durante meses aos vícios de um modelo, de formato de saída que só ele produz e de ferramentas declaradas no dialeto de um provedor. Evita-se com uma camada de abstração entre agente e provedor, ferramentas definidas de forma neutra e traduzidas pela plataforma, e instrução com versão e rollback, para que a adaptação a um modelo novo seja uma versão testada e não uma edição sobre a que está no ar.