Como escolher o modelo de IA para produção (e por que quase sempre são vários)

Um agente faz várias tarefas diferentes

Pense num agente que cuida de pedidos que chegam por e-mail. Ele precisa identificar se a mensagem é um pedido, uma dúvida ou uma reclamação. Depois, extrair dados de um anexo: cliente, produtos, quantidades. Em seguida, consultar estoque e preço. Por fim, escrever uma resposta clara para o cliente e, em casos ambíguos, decidir se chama uma pessoa.

Cada uma dessas etapas tem exigências diferentes. Classificar a mensagem é simples e acontece muitas vezes por dia. Extrair dados de um PDF bagunçado exige precisão. Decidir um caso ambíguo exige raciocínio mais cuidadoso. Usar o modelo mais caro e mais capaz em todas elas é desperdício. Usar o mais barato em todas é risco.

Os critérios que importam

Para cada tarefa do agente, avalie os modelos candidatos por cinco critérios:

• Qualidade na sua tarefa. Não na comparação pública, mas com os seus documentos, as suas mensagens e o seu vocabulário.
• Custo por tarefa. Calcule quanto custa processar uma tarefa típica, considerando o tamanho médio da entrada e da saída, e multiplique pelo volume esperado.
• Tempo de resposta. Num atendimento em tempo real, alguns segundos fazem diferença. Num processamento noturno, quase nada.
• Onde os dados são processados. Verifique a política do fornecedor sobre retenção e uso dos dados enviados, e se há opção de processamento em região compatível com as exigências da sua operação.
• Estabilidade do fornecedor. Limites de uso, histórico de indisponibilidade, aviso prévio antes de descontinuar versões.

O melhor modelo para o seu agente é o que acerta a sua tarefa pelo menor custo aceitável, e não o primeiro do ranking.

Teste com os seus dados, não com exemplos genéricos

A única forma confiável de escolher é testar. E o teste só vale se usar casos reais da sua operação. Um caminho prático:

• Separe de 50 a 200 exemplos reais de cada tarefa, incluindo casos difíceis e casos que já deram problema.
• Escreva, para cada exemplo, qual seria a resposta certa ou aceitável. Esse conjunto vira o seu gabarito.
• Rode cada modelo candidato sobre o mesmo conjunto, com as mesmas instruções.
• Compare acertos, custo e tempo. Olhe com atenção os erros: um modelo que erra pouco mas erra feio pode ser pior do que outro que erra mais em detalhes.
• Guarde esse conjunto. Ele vai servir toda vez que você pensar em trocar de modelo ou ajustar instruções.

Esse conjunto de testes é um dos ativos mais valiosos de um agente em produção. Com ele, qualquer mudança vira uma comparação objetiva em vez de uma impressão.

Para tarefas em que a resposta certa não é única, como escrever uma mensagem ao cliente, combine com o time critérios simples de avaliação: está correta, está no tom da empresa, tem tudo que o cliente precisa saber. Peça para duas pessoas avaliarem uma parte das respostas sem saber qual modelo gerou cada uma.

Por que ter um modelo de reserva

Fornecedores de IA ficam fora do ar. Às vezes por minutos, às vezes por horas. Também mudam limites de uso, alteram preços e descontinuam versões. Se o agente depende de um único modelo, qualquer uma dessas coisas para a sua operação.

Ter um modelo de reserva significa que, se o principal falhar ou demorar demais, o agente passa a usar outro automaticamente, de preferência de um fornecedor diferente. A reserva não precisa ser tão boa quanto o principal em tudo. Precisa ser boa o suficiente para manter a operação rodando enquanto o problema se resolve.

Algumas decisões que valem ser tomadas antes:

• Quais tarefas podem cair para a reserva e quais devem esperar ou ir para uma pessoa.
• Quanto tempo de espera dispara a troca.
• Como você fica sabendo que a reserva entrou em ação.
• Se a reserva já foi testada com o mesmo conjunto de exemplos do modelo principal.

Como trocar sem refazer tudo

Novos modelos surgem o tempo todo, e alguns são melhores ou mais baratos para tarefas que você já tem. A capacidade de trocar com rapidez vira vantagem. Para isso, o agente precisa ter sido desenhado pensando nisso:

• Uma camada entre o agente e os modelos. O agente pede "classifique esta mensagem" e uma peça intermediária decide qual modelo atende. Trocar o modelo vira mudar uma configuração.
• Instruções separadas do código. As instruções de cada tarefa ficam guardadas com versão, e podem ser ajustadas para cada modelo quando necessário.
• Saídas em formato estruturado. Quando o modelo devolve dados num formato definido, o resto do agente não depende do estilo de escrita de cada fornecedor.
• O conjunto de testes sempre à mão. Antes de qualquer troca, roda-se o teste. Se o novo modelo for melhor ou igual, troca. Se não, fica como está.
• Troca gradual. Mande uma parte pequena das tarefas para o novo modelo, compare os resultados nos registros e aumente aos poucos.

Com essa estrutura, trocar de modelo deixa de ser um projeto e passa a ser rotina de manutenção.

Erros comuns na escolha

• Escolher pelo ranking público sem testar com casos próprios.
• Usar o modelo mais caro em tudo "para garantir", e descobrir o custo só na primeira fatura.
• Escrever as instruções tão amarradas a um modelo que qualquer troca exige reescrever tudo.
• Não ter reserva e descobrir a dependência no dia em que o fornecedor fica fora do ar.
• Trocar de modelo porque saiu uma versão nova, sem rodar os testes antes.

Todos esses erros têm a mesma raiz: tratar a escolha do modelo como uma decisão única, tomada uma vez. Em produção, ela é uma decisão contínua, revisada com dados.