A otimização de custos em sistemas de IA virou um dos temas mais quentes dos últimos tempos, e por um bom motivo: as contas de inferência crescem rápido, e qualquer engenheiro que consegue cortar esse número pela metade em poucas semanas vira herói da empresa.
Só que tem um detalhe que essa história toda costuma deixar de fora.
Uma equipe fez exatamente isso, cortou mais da metade da conta de inferência em oito semanas de trabalho limpo de engenharia, levou um agradecimento por escrito do CFO, apresentou o resultado no all-hands da empresa e seguiu em frente para a próxima prioridade do trimestre.
Três meses depois, a satisfação dos clientes estava caindo, o churn estava subindo, e a economia de custos estava estruturalmente amarrada à perda de qualidade.
O problema não estava no código.
Estava no que ninguém estava medindo. 👀
Esse artigo conta essa história em detalhes, desde a arquitetura da camada de roteamento que foi construída até o post-mortem que revelou onde o custo real estava escondido, passando por outras duas implementações auditadas em setores diferentes que repetiram exatamente o mesmo padrão.
Se você trabalha com IA em produção, ou está pensando em implementar algum tipo de roteamento entre modelos de IA para reduzir custos, esse caso vai te fazer repensar algumas premissas bem comuns no mercado.
Como a Camada de Roteamento Foi Construída
A equipe operava um agente de suporte ao cliente baseado em IA para um produto SaaS com cerca de 4 milhões de usuários ativos mensais. O agente rodava em um único modelo capaz, o de raciocínio mais avançado disponível na stack na época. O volume de inferência era alto o suficiente para que a conta mensal do provedor já tivesse entrado na casa dos seis dígitos e continuasse subindo conforme a adoção crescia.
A ideia por trás da camada de roteamento era simples e, no papel, bastante elegante. Um pequeno modelo classificador, treinado de forma customizada com cerca de 200 mil consultas históricas de suporte com rótulos de qualidade, ficava na frente do agente principal e marcava cada requisição como simples ou complexa. As consultas simples eram redirecionadas para um modelo mais barato da mesma família do provedor. As complexas continuavam indo para o modelo capaz. O classificador era um encoder ajustado, leve o bastante para rodar em menos de 30 milissegundos com custo praticamente irrelevante.
A taxonomia de classificação foi construída a partir da observação real da produção. As consultas simples eram aquelas que a equipe via repetidamente: consultas de conta, dúvidas de status de cobrança, redefinições de senha, rastreamento de pedidos e perguntas sobre horário de funcionamento. As consultas complexas eram as que historicamente exigiam raciocínio nuançado e em várias etapas: disputas de reembolso, comparações entre planos, resolução de problemas de integração e anomalias de ciclo de cobrança. A divisão ficou em torno de 65% simples e 35% complexa numa semana representativa de tráfego.
O modelo mais barato escolhido custava cerca de um quarto do preço por token do modelo capaz. Para as consultas simples enviadas a ele, uma avaliação lado a lado mostrou qualidade equivalente em 94% de um conjunto de teste de 5 mil consultas. O gap de 6% era visível, mas a equipe julgou aceitável diante da redução de custo.
O resultado imediato foi exatamente o que a equipe esperava: a conta mensal de inferência caiu para cerca de 40% do nível anterior em oito semanas. As métricas de adoção dentro do agente ficaram estáveis ou levemente positivas. O que ninguém percebeu naquele momento é que o sistema combinado tinha criado um buraco de qualidade que a arquitetura de medição existente simplesmente não conseguia enxergar.
- E-BOOK GRATUITO
Um guia prático para avaliar, comparar e implementar inteligência artificial com clareza — sem desperdício de tempo ou dinheiro.
Pare de contratar ferramentas sem direção. Criamos um método estruturado para decidir qual IA realmente faz sentido para o seu negócio.
Entrega em PDF no seu e-mail · Sem spam · LGPD
🔒 Seus dados são protegidos conforme a LGPD. Você pode descadastrar a qualquer momento.
O Que os Números Escondiam
A arquitetura de avaliação que a equipe tinha antes da camada de roteamento foi construída sobre a premissa de que eles rodavam um único modelo. O sinal de qualidade vinha de três fontes: uma amostra diária de revisão humana de cerca de 200 respostas, uma suíte de regressão offline com aproximadamente 12 mil consultas rotuladas rodando semanalmente, e um sinal de satisfação vindo do widget de feedback dentro do produto, onde os usuários davam joinha ou descurtiam a resposta.
Quando a camada de roteamento entrou no ar, a equipe manteve a amostra de revisão humana, mas não separou por nível de roteamento. Adicionou o modelo barato à suíte de regressão, onde ele pontuou dentro do limite aceitável. E deixou o widget de feedback intocado, porque ele não tinha como saber qual modelo tinha servido cada resposta.
Em retrospecto, essas três escolhas de medição foram a semente do problema. Tudo o que a equipe conseguia ver estava verde. O que eles não estavam vendo apareceu em três camadas diferentes.
A amostra de revisão humana, tirada sem consciência de nível, era na prática uma média ponderada, com 65% das revisões no modelo barato. Como o modelo barato era equivalente nos casos fáceis, ele puxava a média agregada para cima. Os problemas de qualidade na borda mais difícil da distribuição de consultas simples ficavam diluídos a ponto de ficarem invisíveis.
A suíte de regressão offline testava os dois modelos, mas a curadoria era estática, montada seis meses antes do deploy, quando ninguém pensava em roteamento. Ela refletia uma distribuição idealizada, não a distribuição real de produção que o modelo barato agora precisava encarar.
E o widget de feedback tinha um problema estrutural conhecido havia mais de um ano: o feedback era escasso. Os clientes descurtiam respostas cerca de 3 vezes a cada mil interações, e esses votos negativos estavam enviesados para clientes que já estavam frustrados com outra coisa. A relação sinal-ruído era baixa demais para detectar qualquer mudança que não fosse uma regressão gigante.
Nenhuma dessas falhas era específica da camada de roteamento. Elas estavam latentes na arquitetura de medição. A camada de roteamento apenas as expôs. Enquanto o sistema rodava em um único modelo, os gaps de medição não produziam leituras falsas, porque havia apenas uma distribuição de qualidade para medir. O roteamento introduziu duas distribuições, e a arquitetura existente não conseguia observá-las separadamente.
A deriva de qualidade no nível do modelo barato começou na terceira semana após o rollout total. Na sexta semana já era mensurável na suíte de regressão, mas a equipe interpretou a pequena queda como deriva de versão do provedor, e não como algo relacionado ao roteamento. Na décima semana o impacto cumulativo na satisfação já estava visível nas métricas de produto. Na décima terceira, o churn já rastreava acima da linha de base anterior. Foi nesse ponto que a equipe pediu ajuda.
O Que Quebrou e Como Foi Descoberto
O diagnóstico levou duas semanas. A solução foi reconstruir as decisões de roteamento a partir dos logs de instrumentação, cruzá-las com os eventos de feedback dentro do produto e montar uma visão de qualidade por nível que a equipe nunca tinha tido antes.
O padrão apareceu na hora no nível do modelo barato. Ele performava bem em cerca de 80% das consultas que recebia, o que batia com o achado original do conjunto de teste. Mas os outros 20% em produção eram estruturalmente diferentes do conjunto de teste, de um jeito que o classificador não conseguia detectar no momento da decisão.
O exemplo mais claro eram as consultas de cobrança. O classificador tinha aprendido a reconhecer padrões como de onde vem essa cobrança ou fui cobrado duas vezes como consultas simples. Em teste, isso era verdade. Em produção, uma parte relevante dessas consultas escondia intenções bem mais complexas. Um usuário perguntando de onde vem essa cobrança às vezes estava perguntando sobre uma cobrança fraudulenta real, às vezes sobre uma reconciliação atrasada entre dois sistemas, às vezes sobre uma mudança de ciclo de cobrança da qual ele não tinha sido avisado. O modelo capaz vinha lidando com essas intenções aninhadas corretamente porque tinha folga para acompanhar a complexidade da conversa. O modelo barato tratava cada uma como a intenção de superfície e respondia uma pergunta que o cliente não tinha feito.
Os clientes que recebiam essas respostas erradas nem sempre descurtiam. Muitos simplesmente abandonavam o agente e ligavam para o suporte. O sinal de joinha negativa, portanto, subrepresentava a falha. O custo da falha era empurrado para a equipe de suporte humano, que atendia a mesma consulta uma segunda vez, com o custo humano saindo de outro orçamento. A taxa de deflexão medida do agente permanecia estável enquanto o volume real de atendimentos humanos começava a subir.
Quando os números foram somados, o impacto de custo da perda de qualidade era, de forma conservadora, de quatro a cinco vezes a economia gerada pela camada de roteamento. A equipe tinha cortado cerca de 100 mil dólares por mês em inferência e incorrido entre 400 e 500 mil dólares mensais em custos de retenção e suporte. A conta, vista por inteiro, era inequívoca.
Essa é a propriedade estrutural daquilo que pode ser chamado de armadilha de Pareto. A economia na camada de inferência é medida pela equipe que construiu o sistema de roteamento. O custo da perda de qualidade é pago pela experiência do cliente, pela equipe de suporte humano e pela função de retenção, nenhuma das quais é dona da otimização. Cada time otimiza o próprio orçamento. A otimização combinada é negativa.
Por Que Modelos Baratos Quebram na Cauda Longa
Vale a pena desacelerar para entender por que esse padrão é estrutural e não situacional. Não é sobre o modelo específico escolhido, sobre o provedor ou sobre o classificador treinado. É sobre a geometria do espaço do problema.
As consultas de clientes em qualquer deploy de IA em produção seguem uma distribuição de dificuldade em lei de potência. Uma grande massa de consultas se agrupa no centro fácil. Uma massa menor se estende numa cauda longa de consultas mais difíceis, ambíguas e dependentes de contexto. Os modelos de fronteira são superdimensionados para o centro fácil. Eles têm muito mais capacidade do que o necessário para responder que horas vocês abrem. É exatamente esse superdimensionamento que torna a oportunidade de otimização real.
O problema é que os classificadores não conseguem separar de forma confiável o centro fácil da cauda longa no momento da decisão. O classificador vê apenas a forma de superfície da consulta. A cauda longa fica escondida sob formas de superfície que parecem fáceis. Uma consulta que se lê como de onde vem essa cobrança pode ser uma busca trivial de conta ou a primeira frase de uma investigação de fraude. O classificador vê as mesmas palavras. O modelo barato dá a mesma resposta de superfície.
Esse é o problema de compressão da cauda longa. A forma de superfície é um péssimo previsor da profundidade da intenção justamente nas consultas que mais importam. O classificador é bem calibrado exatamente onde não precisa ser, e mal calibrado exatamente onde precisa.
Há um segundo mecanismo. Modelos de fronteira tendem a ter modos de falha recuperáveis. Eles às vezes hesitam, pedem esclarecimento ou expõem a própria incerteza de formas que fazem um humano intervir. Modelos menores costumam falhar com confiança. Eles produzem uma resposta completa, plausível e coerente na superfície, que está errada sobre a intenção real. A resposta errada é mais difícil de o cliente reconhecer como errada, o que faz a falha passar despercebida por mais tempo.
E há um terceiro mecanismo: a deriva. As distribuições de consultas em produção evoluem. Novos produtos são lançados, novas coortes de clientes entram, novos modos de falha surgem. O classificador treinado em seis meses de tráfego histórico passa a rotear errado uma fatia crescente de consultas conforme a distribuição se afasta do conjunto de treino. A economia permanece estável, mas o custo de qualidade cresce silenciosamente.
Dois Outros Times Auditados Depois Desse Caso
Depois desse caso, o mesmo padrão começou a aparecer em outros deploys de IA. Dois surgiram rapidamente.
O primeiro era uma empresa SaaS de médio porte com um assistente de IA de sucesso do cliente. Escala menor, gasto mensal de inferência na casa dos cinco dígitos baixos. Mesmo padrão arquitetural. Tinham construído uma camada de roteamento quatro meses antes que enviava consultas simples, definidas por um classificador de similaridade de embeddings, para um modelo mais barato. A economia girava em torno de 50%. Quando o sinal de feedback foi segmentado por nível, o nível do modelo barato tinha satisfação significativamente menor nas consultas de cauda longa. A equipe estava cega para o gap porque o dashboard agregado juntava os dois níveis num único número.
O segundo era um caso de indústria regulada em fintech, com gasto mensal de inferência na casa dos seis dígitos altos. Tinham construído uma camada de roteamento mais conservadora, enviando apenas o que consideravam consultas informativas, como saldo de conta e histórico de transações, para o modelo barato. A economia era menor, em torno de 20%. Mas a falha de cauda longa no modelo barato tinha implicações de compliance, porque algumas consultas que pareciam informativas na verdade carregavam peso regulatório. Uma pergunta como qual é a minha taxa de juros às vezes tinha um desdobramento que dependia da primeira resposta ter sido entregue com precisão. A equipe de compliance pegou o problema numa auditoria manual antes que virasse uma questão regulatória, mas o quase incidente fez reverter o roteamento por completo.
O caso da fintech foi especialmente esclarecedor. Ele deixou óbvio que o tradeoff entre custo e qualidade não é simétrico entre setores. No suporte ao cliente, uma resposta errada é recuperável. Em indústrias reguladas, uma resposta errada pode ser uma violação.
Como Detectar a Armadilha Antes de Três Meses
A metodologia de diagnóstico que teria pego qualquer um desses casos mais cedo é direta, mas exige mudar a arquitetura de medição antes da camada de roteamento ir ao ar. São três adições concretas à stack de observabilidade.
Monitoramento de qualidade por nível
Esse é o fundamental. Todo sinal de qualidade da arquitetura existente precisa ser dividido por nível de roteamento, com o rótulo do nível propagado de ponta a ponta. Amostras de revisão humana devem ser estratificadas para que cada nível receba revisão proporcional. Suítes de regressão offline devem ser divididas em subconjuntos por nível. Eventos de feedback dentro do produto devem ser cruzados com o log de decisão de roteamento. O número agregado de qualidade, sozinho, é estruturalmente incapaz de revelar uma deriva específica de nível.
Receba o melhor conteúdo de inovação em seu e-mail
Todas as notícias, dicas, tendências e recursos que você procura entregues na sua caixa de entrada.
Ao assinar a newsletter, você concorda em receber comunicações da Método Viral. A gente se compromete a sempre proteger e respeitar sua privacidade.
Amostragem de satisfação na cauda longa
Como o problema de cauda longa é invisível no agregado, a arquitetura precisa sobreamostrar a cauda para torná-la visível. Isso significa amostrar mais pesado as consultas sobre as quais o classificador teve menos confiança, ou que ficam fora do centro da distribuição de treino. A meta é dar mais peso às consultas onde a escolha do modelo realmente importa.
Deriva de confiança do roteamento
O próprio classificador é uma fonte de sinal de qualidade que a maioria dos times não monitora. A distribuição dos scores de confiança em produção deve ser comparada com a distribuição observada no treino. Quando a produção desvia, o classificador opera fora da faixa calibrada, e as decisões ficam cada vez menos confiáveis. O sinal de deriva antecede o sinal de qualidade em semanas, que é o tempo de reação que a equipe precisa.
Implantar essas medições de forma retroativa é muito mais difícil do que construí-las junto com a camada de roteamento. Fazer antes do lançamento custa talvez três semanas de engenharia. Fazer depois que o problema apareceu muitas vezes exige reconstruir dados que nunca foram capturados. A arquitetura de medição importa mais do que a própria decisão de roteamento.
Como É a Alternativa
Se o playbook de consenso de pré-rotear por classificador é uma armadilha de Pareto, a pergunta óbvia é qual é a alternativa. Existe uma, e ela é significativamente melhor, embora carregue seus próprios tradeoffs.
O padrão é uma cascata roteada por incerteza. Em vez de pré-classificar uma consulta como simples ou complexa antes de qualquer modelo tocá-la, toda consulta começa no modelo mais barato. O modelo barato produz uma resposta com um score de confiança calibrado, seja por uma estimativa interna de incerteza, seja por uma etapa explícita de autoavaliação. Quando a confiança é alta, a resposta volta direto para o usuário. Quando a confiança cai abaixo de um limite, a consulta é escalada para o modelo capaz.
Esse padrão inverte o modo de falha. O modelo barato agora decide por si mesmo em vez de ser decidido por um classificador. As consultas difíceis, que o modelo barato responderia errado com confiança, em vez disso aparecem como baixa confiança e disparam a escalação. No estudo do caso de suporte, a economia modelada ficou na mesma faixa da abordagem de pré-roteamento, com qualidade materialmente melhor na cauda longa.
Dois aprimoramentos somam à cascata. O shadow scoring roda o modelo capaz em paralelo numa pequena porcentagem do tráfego para detectar deriva em condições reais. E o roteamento ponderado por qualidade incorpora o sinal de satisfação observado de volta na calibração do limite ao longo do tempo.
A cascata tem tradeoffs que o pré-roteamento não tem. A latência nas consultas escaladas é praticamente a soma das duas latências. O custo é mais difícil de prever antecipadamente. E a complexidade de implementação é moderadamente maior. Mas são tradeoffs contra o piso de qualidade que a cascata mantém e o pré-roteamento não.
A Camada de Otimização Importa Mais do Que a Otimização
A primeira equipe eventualmente chegou a uma arquitetura estável que combinava cascatas roteadas por incerteza com observabilidade por nível. O custo mensal de inferência se estabilizou em cerca de 35% abaixo da linha de base original, menos economia do que o pré-roteamento tinha alcançado no papel. A satisfação do cliente voltou aos níveis anteriores ao experimento. O valor líquido de produto do deploy, considerando as duas camadas, ficou significativamente positivo.
A lição que a equipe tirou não foi que a otimização de custos é errada. Foi que a otimização de custos é uma escolha sobre qual camada do sistema você confia para fazer o tradeoff certo. O pré-roteamento confia em um classificador que não consegue ver o que importa. A cascata confia no próprio modelo para saber o que ele não sabe.
A otimização barata é a que quebra o produto silenciosamente. A otimização arquiteturalmente honesta é a que sobrevive à cauda longa. Em IA de produção, a diferença geralmente é um trimestre de satisfação do cliente. 🎯
Trabalhar com camada de roteamento entre modelos de IA de diferentes capacidades e custos é uma estratégia válida e, quando bem implementada, pode oferecer um equilíbrio genuíno entre eficiência econômica e qualidade de entrega. A chave está em não tratar o classificador como uma caixa preta que resolve tudo sozinha após a configuração inicial. Ele precisa ser monitorado continuamente, ajustado com dados reais de produção e avaliado não apenas pela precisão técnica da classificação, mas pelo impacto que essa classificação tem na qualidade da resposta e na experiência do usuário final. É exatamente esse tipo de atenção contínua que separa os sistemas de IA que criam valor de verdade daqueles que apenas parecem eficientes nos dashboards de custo.
