Primeiro, a conclusão: o consumo excessivo de recursos de um chatbot de atendimento, em oitenta por cento dos casos, não se deve ao preço unitário elevado do modelo, mas sim a problemas na forma de invocação. Um chatbot interno de perguntas e respostas de pós-venda, com alguns milhares de usuários ativos diários, teve sua fatura no primeiro mês disparando para três vezes o orçamento. Após investigação, o preço unitário do modelo não mudou em nada — tudo eram custos ocultos na estrutura de invocação. Este artigo documenta o processo de revisão; quem estiver lidando com otimização de custos de API de grandes modelos pode conferir a própria fatura item por item.
Como se manifesta uma fatura anômala
A característica da anomalia não é "valor total alto", mas sim "estrutura estranha". Extraímos o detalhamento diário de chamadas e identificamos três pontos fora do normal: nos dias de maior volume de chamadas, a média de tokens por requisição estava subindo; a proporção de retentativas se aproximava de vinte por cento; para a mesma pergunta de usuário, ora eram algumas centenas de tokens, ora passava de dez mil, com variância extremamente alta. Esses três fatores juntos basicamente indicam que o problema não está no lado do modelo, mas na nossa própria cadeia de invocação.
Quatro custos ocultos, cada um mais insidioso que o outro
Primeiro, modelo de ponta fazendo trabalho braçal. No início, por conveniência, todas as requisições passavam pelo modelo de ponta. Mas no cenário de atendimento, mais de setenta por cento são tarefas como "onde está meu pedido" ou "como faço para devolver", que envolvem reconhecimento de intenção e respostas com scripts fixos — tarefas para as quais um modelo leve é totalmente suficiente, com diferença de custo de uma ordem de magnitude. Usar um modelo de ponta para responder "qual o horário de funcionamento" é como usar um caminhão para entregar comida.
Segundo, expansão descontrolada do contexto. Em conversas multi-turno, colocávamos todo o histórico de mensagens de volta. Quando o usuário chegava à décima rodada, só o histórico já consumia a maior parte dos tokens. Pior ainda: muito do histórico não tinha relação alguma com a pergunta atual — puro peso morto. Contexto não é "quanto mais longo, mais inteligente"; ultrapassado certo comprimento, o ganho de precisão é limitado, mas o custo cresce linearmente.
Terceiro, tempestade de retentativas. Configuramos uma retentativa simples em caso de falha, mas sem backoff nem circuit breaker. Quando ocorriam timeouts esporádicos no upstream, o mesmo lote de requisições era reenviado repetidamente: falha uma vez, retenta uma vez; a retentativa falha, retenta de novo. Essas chamadas na fatura eram puro desperdício, e o usuário continuava vendo erro.
Quarto, cobrança duplicada de streaming e não-streaming. Esse é o mais fácil de passar despercebido. Algumas cadeias nossas, para obter o resultado completo e fazer pós-processamento, chamavam em modo não-streaming; e o frontend, para ter o efeito de máquina de escrever, chamava de novo em streaming. Mesma pergunta, duas cobranças. Depois unificamos para recebimento em streaming com montagem local, e esse custo duplicado foi eliminado.
Como implementar o roteamento em camadas
A ideia não é complicada: dividir o fluxo por dificuldade da tarefa. Reconhecimento de intenção, extração de slots, scripts fixos — vão para modelos leves; conversas complexas que realmente exigem raciocínio, julgamento multi-etapa e acolhimento emocional — só essas vão para o modelo de ponta. Adiciona-se uma camada de gateway de modelos para fazer a triagem: a requisição entra, passa pelo classificador, recebe uma etiqueta de tarefa e só então decide para qual modelo rotear.
Usamos a lógica de seleção automática do melhor modelo por tarefa e rodamos uma rodada comparativa no roteamento multi-modelo do SiCore TokenWorks. Após migrar tarefas simples para modelos leves, o custo geral caiu visivelmente e a resposta ficou mais rápida. A chave aqui não é "qual modelo usar", mas sim que a tabela de mapeamento "qual tarefa combina com qual modelo" precisa de ajuste contínuo. No início, configuramos por experiência; após duas semanas, recalibramos com base na taxa de acerto real, e o resultado foi muito melhor do que configurar no achismo. A vantagem da integração unificada multi-modelo também se evidencia nesse momento: trocar a estratégia de roteamento não exige alterar o código de negócio, basta ajustar na camada de gateway.
Comparação da fatura antes e depois da otimização
Não informamos números específicos, mas proporções. O volume total de chamadas não mudou, pois a base de usuários não mudou. O custo total caiu cerca de sessenta por cento, sendo que a proporção de chamadas ao modelo de ponta caiu de quase cem por cento para cerca de trinta por cento, com o restante redistribuído para modelos leves. As chamadas relacionadas a retentativas caíram de quase vinte por cento para um dígito percentual. A média de tokens por requisição reduziu aproximadamente quarenta por cento, principalmente devido ao corte de contexto. A cobrança duplicada de streaming foi zerada. No cômputo geral, saímos de três vezes acima do orçamento para dentro do orçamento, com margem.
Como configurar monitoramento e alertas
O dinheiro economizado precisa ser protegido com monitoramento, não com boa vontade. Configuramos quatro alertas: disparo quando o número de tokens por requisição ultrapassa o limite, para prevenir descontrole de contexto; disparo quando a taxa de retentativas ultrapassa a proporção definida, para prevenir tempestade de retentativas; disparo quando a proporção de chamadas ao modelo de ponta sobe anormalmente, indicando possível falha no roteamento; disparo quando a variação percentual do custo diário ultrapassa o limite. Esses quatro não precisam ser complexos — agregação diária e alerta ao ultrapassar a linha já bastam. No modelo de cobrança por Token, o custo acumula em tempo real; esperar até o fim do mês para olhar a fatura e otimizar significa que o dinheiro já foi gasto.
Em uma frase: o grande custo do chatbot de atendimento está na estrutura de invocação, não no preço unitário do modelo. Fazendo bem as quatro coisas — roteamento em camadas, corte de contexto, controle de retentativas e unificação de streaming —, a fatura cai naturalmente. Como extensão: se o seu cenário também envolve recuperação RAG, vale a pena verificar o número de resultados recuperados do banco vetorial seguindo a mesma linha de raciocínio.