Como decidir a rota de LLM com evidência de tráfego real

A empresa escolheu o melhor modelo na terça. Na quinta o preço mudou, o provedor degradou a latência de p95 e ninguém soube dizer se a rota ainda era a certa, porque a decisão original nunca teve um número para defendê-la. Escolher rota de LLM por intuição de bancada é fácil. Trocar de rota com evidência é o que quase ninguém organiza.

A tabela de preços de modelos mudou de forma previsível no último ano: a Anthropic lançou o Opus 5, a OpenAI publicou o GPT-6, e cada release reposicionou a relação entre custo por token e qualidade percebida. Uma decisão de rota tomada em março pode estar errada em setembro sem que um único gráfico tenha sido olhado.

Este guia não discute qual modelo é melhor. Ele descreve como uma empresa decide a própria rota com evidência: duplicando uma fatia do tráfego ao vivo, julgando as respostas às cegas e só promovendo a mudança quando a medição no tráfego da própria empresa autoriza. O método cabe em cinco passos e cabe na infraestrutura que a empresa já tem.

O que é shadow evaluation e por que ela decide melhor que benchmark

Shadow evaluation é rodar a rota candidata em paralelo com a rota titular, sobre o tráfego real, sem que ela responda ao usuário. O time duplica uma amostra das chamadas, envia para os dois caminhos, guarda as duas respostas e julga a diferença às cegas, antes de qualquer promoção.

A vantagem sobre um benchmark público é simples de enunciar e difícil de contestar: o benchmark mede o modelo, enquanto a sombra mede o modelo no seu tráfego, com os seus prompts, a sua distribuição de tarefas e as suas caudas. Um modelo pode vencer no agregado e ainda assim perder exatamente no caso que mais aparece na sua base. A diferença entre as duas medições costuma decidir a conta no fim do mês.

Benchmark é foto. Sombra é vídeo.

A decisão de rota é, no fundo, uma decisão de contabilidade vestida de engenharia. E contabilidade não se decide por reputação de fornecedor, decide-se por número próprio.

O erro que a sombra corrige é o da avaliação estática. A maior parte das empresas testa um modelo novo em algumas dezenas de prompts montados à mão, gosta do resultado e promove a rota. Isso mede a impressão de quem escreveu os prompts, não o desempenho na produção. A sombra troca o prompt de vitrine pela chamada que o usuário de fato fez.

Pré-requisitos antes do primeiro passo

Antes de duplicar qualquer coisa, três peças precisam existir, e sem elas a sombra vira custo sem leitura: cada chamada carrega um identificador de rota, de tenant e de tarefa, um store guarda a resposta de cada rota sob o mesmo identificador, e um juiz forte avalia os pares com rubrica escrita. Faltando qualquer uma, o experimento não começa.

Sem rastro, não há veredito.

• Tráfego identificável. Cada chamada carrega um identificador de rota, de tenant e de tarefa, para que a amostra possa ser segmentada depois.
• Registro das respostas. Um store que guarda a resposta de cada rota com o mesmo identificador de chamada.
• Um juiz confiável. Um modelo forte o bastante para avaliar, isolado da rota sob teste, mais uma rubrica de critérios.

Se faltar o identificador de tarefa, o experimento mede uma média que não orienta ninguém. Um ganho de qualidade agregado esconde regressão em uma classe inteira de chamadas, e é a regressão que dói em produção.

Qual é o custo de rodar as duas rotas ao mesmo tempo?

O custo da fase de sombra é o custo da rota candidata sobre a fatia duplicada, mais o custo do juiz sobre os pares. Não é o dobro da fatura, e o número exato depende de quanto tráfego você espelha.

A tentação é espelhar tudo. Espelhar 100% do tráfego duplica o gasto de inferência e transforma uma decisão de rota em um projeto de orçamento. A prática recomendada é espelhar uma fração que produza amostra suficiente para a decisão, e deixar o resto em paz.

Dobrar uma amostra não é o único jeito de controlar a conta. O roteamento por complexidade, que manda cada chamada para o modelo mais barato capaz de resolvê-la, corta o custo da rota candidata antes mesmo de a sombra começar.

A comparação abaixo resume o que o time ganha em cada abordagem de avaliação. As duas colunas medem coisas diferentes, e é por isso que elas se complementam em vez de competir.

Passo 1: definir a hipótese e o critério de promoção antes de medir

O primeiro passo não é técnico, é de método. Antes de ligar a sombra, escreva a hipótese e o critério que autoriza a promoção, porque sem esse pré-registro o experimento termina em discussão e qualquer resultado passa a servir para qualquer posição. Uma avaliação de endpoint e política de roteamento parte exatamente dessa disciplina.

Hipótese sem critério é palpite com carimbo.

A hipótese precisa nomear o que muda e o que se espera. "A rota candidata reduz o custo por tarefa em 20% sem reduzir a taxa de aprovação do juiz abaixo de dois pontos percentuais" é uma hipótese. "Testar o modelo novo" não é.

O critério de promoção é a linha que separa aprovar de não aprovar. Ele se escreve agora, não depois de ver o número, porque critério escrito com o resultado na mesa é justificativa, não critério.

Dois parâmetros merecem pré-registro explícito:

1. Tamanho de amostra mínimo. Quantas chamadas pareadas antes de qualquer leitura, para que o resultado não seja ruído de uma tarde.
2. Teto de custo. O valor por mil chamadas acima do qual a rota candidata reprova mesmo com qualidade igual.

O piso prático fica na ordem de algumas dezenas de pares por ciclo. Abaixo disso, o custo de montar o juiz não se paga e a revisão humana direta é mais eficiente que o placar automático.

O viés de novidade é o inimigo silencioso desta etapa. Times tendem a preferir a resposta do modelo mais novo e mais conhecido quando o julgamento não é cego, e a sombra existe justamente para remover esse atalho.

Passo 2: duplicar uma fatia representativa do tráfego vivo

O segundo passo é ligar a sombra sobre uma amostra que represente a distribuição real de chamadas, e a palavra que carrega o passo é "representativa", porque uma amostra enviesada produz uma decisão confiante e errada. Duplicar só a chamada mais comum mede a tarefa fácil e deixa de fora a cauda, onde moram as surpresas.

O caminho ingênuo é duplicar tudo. O caminho correto é duplicar por segmento. Separe as chamadas por classe de tarefa, por tenant relevante e por faixa de contexto, e espelhe dentro de cada segmento. Se você espelha só o caminho mais comum, o resultado não vale para a cauda, e a cauda é onde moram as surpresas.

A escolha do splitter também importa. O splitter fica na camada de gateway, no ponto onde a chamada já foi normalizada e ainda não foi despachada. Colocar a duplicação dentro da aplicação obriga cada serviço a conhecer o experimento, e o experimento morre na primeira refatoração.

Há um requisito de isolamento: a rota candidata não pode responder ao usuário. Se ela responde, você está rodando um canary, não uma sombra, e assumiu o risco de expor alguém à rota que ainda não foi aprovada.

Vale medir o desempenho dos provedores de LLM na sua própria carga antes de confiar em qualquer ranking. A latência de um provedor no p95 da sua distribuição pode ser bem pior que a média que ele publica, e a sombra é o instrumento que revela essa diferença.

Passo 3: julgar as respostas às cegas com um LLM judge

O terceiro passo é transformar pares de respostas em um veredito. Um LLM judge avalia as duas respostas sem saber qual rota as produziu, seguindo uma rubrica escrita, e o sigilo das etiquetas é o que dá valor ao julgamento.

O juiz deve ser forte o bastante para avaliar e independente das duas rotas sob teste. Se o juiz for o mesmo modelo de uma das rotas, ele carrega o viés daquela rota e o experimento mede a preferência do juiz por si mesmo.

A rubrica precisa ser específica. "Qualidade" não é critério. Uma rubrica útil separa pelo menos três dimensões:

• Correção factual, quando a tarefa tem uma resposta verificável.
• Aderência ao formato, quando o consumidor é um parser e não um humano.
• Utilidade para a tarefa, avaliada contra o objetivo declarado da chamada.
• Controle de verbosidade, para que o juiz não prefira por default a resposta mais longa e premie o preenchimento.

Um juiz sem controle de extensão tende a coroar a resposta mais longa, o que favorece justamente a rota nova e mais verbosa. Ou o comprimento é controlado no par, ou a rubrica penaliza o preenchimento. Uma das duas, escrita antes de medir.

O juiz também tem custo e tem erro. Um juiz mal calibrado aprova quase tudo ou reprova quase tudo, e o time lê isso como resultado da rota. Vale medir o acordo entre o juiz e uma amostra julgada por pessoas, antes de confiar no placar automático.

O julgamento cego resolve o problema que a revisão por gosto pessoal não resolve. Não dá para o engenheiro saber qual resposta era da rota nova quando a ordem das respostas é randomizada, e é essa ignorância que produz um placar honesto.

Passo 4: aplicar o critério estatístico e ler o resultado por segmento

O quarto passo é olhar o número. Aqui a decisão deixa de ser opinião e passa a ser leitura de um resultado medido contra o critério pré-registrado no Passo 1, segmento por segmento, porque a média agregada apenas esconde a perda que importa.

A leitura começa pelo agregado e não termina nele. Um ganho médio de qualidade pode esconder uma perda severa em um segmento pequeno e crítico. Leia o resultado por classe de tarefa, por faixa de contexto e por tenant, e trate a média como resumo, nunca como conclusão.

Uma diferença pequena dentro do ruído não autoriza promoção. Se o intervalo de confiança do ganho pareado por segmento cruza o zero, o honesto é dizer que o experimento não encontrou diferença, não escolher o lado que agrada. Um time que promove com base em ruído vai promover e reverter em ciclo, e cada reversão custa mais que o experimento.

Três leituras condenam a rota candidata, mesmo quando o agregado agrada:

1. O custo por tarefa estourou o teto pré-registrado.
2. Um segmento relevante regrediu além da margem tolerada.
3. A latência de cauda piorou de forma que o usuário vai sentir.

O ponto contraintuitivo é que o critério estatístico não existe para provar que a rota nova é melhor. Ele existe para impedir a promoção da rota nova quando a evidência é fraca. O ônus da prova fica com quem quer mudar.

Passo 5: promover a rota e manter a leitura depois da promoção

O quinto passo é promover, e a promoção é uma mudança de configuração, não um projeto. A rota candidata vira titular porque a medição no tráfego real a habilitou, e a rota antiga permanece disponível como fallback, de modo que a mudança continua sendo uma decisão reversível e não um compromisso de longo prazo.

A promoção precisa ser reversível. Promover sem caminho de volta transforma uma aposta em compromisso. A rota anterior fica no fallback configurado, e o gatilho de reversão fica escrito com o mesmo cuidado do critério de promoção.

Depois da promoção, a medição não para. A distribuição de tráfego muda, o preço do modelo muda e a qualidade do provedor muda. Uma rota promovida em setembro merece uma nova leitura em novembro, porque a evidência tem prazo de validade.

O gate de promoção cabe em uma leitura simples. A rota nova é promovida quando a qualidade julgada é igual ou melhor que a titular, o custo por tarefa fica dentro do teto, e nenhum segmento crítico regrediu além da margem. Fora disso, mantém-se a titular e o ciclo recomeça com nova hipótese.

Como verificar se a sombra está funcionando

A verificação é direta e não depende de fé. O pipeline está correto quando os pares de respostas chegam ao store com o mesmo identificador de chamada, quando o juiz recebe as duas respostas sem as etiquetas de rota, e quando o placar por segmento bate com a amostra espelhada.

Uma sombra saudável deixa três rastros.

O sinal de que a infraestrutura está errada aparece rápido. Se a taxa de respostas pareadas é baixa, o splitter perdeu chamadas. Se o juiz concorda com quase tudo, a rubrica está frouxa. Se o custo da fase de sombra encosta no custo de produção, a amostra é grande demais para o que se pretende decidir.

O trace de chamada de LLM é o instrumento que fecha a verificação. Cada chamada duplicada precisa ser auditável do prompt até o veredito do juiz, com o identificador de rota preservado em toda a cadeia, porque sem essa cadeia completa o placar do juiz vira uma caixa-preta que ninguém consegue contestar depois.

Erros comuns e como corrigi-los

Os erros abaixo aparecem repetidamente em implantações reais, e cada um tem uma correção específica que nenhuma quantidade de tráfego resolve. O padrão comum entre eles é que a decisão de rota foi tomada sem um número próprio para defendê-la, e não existe volume de tráfego que corrija a ausência de critério escrito antes da medição.

Erro de rota quase nunca é erro de modelo.

Julgamento sem cegueira. Quando o time sabe qual resposta é da rota nova, a preferência pelo modelo da moda contamina o placar. A correção é randomizar a ordem das respostas e remover as etiquetas antes de enviar ao juiz.

Amostra enviesada. Espelhar só as chamadas de maior volume mede a tarefa fácil e ignora a cauda. A correção é segmentar a duplicação por classe de tarefa e por faixa de contexto.

Juiz fraco ou único. Um juiz do mesmo provedor da rota candidata carrega viés embutido. A correção é escolher um juiz forte e, quando possível, julgar com dois juízes e medir o desacordo.

Critério escrito depois do resultado. Promover com base em um critério que nasceu depois de ver o número é justificar, não decidir. A correção é o pré-registro do Passo 1 e a disciplina de não movê-lo.

Promoção sem observabilidade. Rota promovida sem leitura contínua vira dívida silenciosa. A correção é manter a medição por segmento depois da promoção, com o mesmo painel que decidiu a mudança.

Perguntas frequentes sobre decidir a rota com tráfego real

Shadow evaluation substitui o benchmark público? Não, ela complementa, e a divisão de trabalho entre as duas é justamente o ponto. O benchmark público filtra candidatos rápido e descarta o que nem merece um teste caro, enquanto a sombra decide no seu tráfego; a sequência eficiente é usar o benchmark para escolher o que vale testar e a sombra para autorizar a promoção.

Quanto de tráfego precisa ser duplicado? O suficiente para que a leitura por segmento pare de depender de um punhado de chamadas, porque uma amostra pequena mas bem segmentada vale mais que espelhar tudo sem critério. O custo da sombra cresce direto com a fração espelhada, então a decisão é sempre um equilíbrio entre confiança estatística e conta no fim do mês.

Um LLM judge é confiável para decidir rota? Confiável o bastante quando a rubrica é específica, o julgamento é cego e o acordo com julgamento humano é medido em uma amostra antes de o placar virar decisão. Um juiz sem rubrica escrita produz um placar que ninguém consegue auditar depois, e a rota acaba promovida por um número que não se sustenta em reunião.

Quando reverter uma rota promovida? Quando a leitura contínua mostra regressão além da margem que autorizou a promoção original. O gatilho de reversão se escreve junto com o critério de promoção, nunca depois que o problema apareceu, porque reverter no meio da crise obriga o time a improvisar exatamente quando falta calma para decidir.

A sombra serve para rota de custo ou só para qualidade? Serve para as duas, desde que o critério combine as duas dimensões no mesmo gate e não trate custo como desempate. Uma rota mais barata que piora a qualidade em um segmento crítico reprova no mesmo teste que uma rota cara que não melhora nada.

Referências e Leitura Complementar

• Como uma avaliação de endpoint muda a política de roteamento de uma empresa
• Roteamento por complexidade: qualidade sem desperdício
• Como medir o desempenho de provedores de LLM
• Trace de chamada de LLM: o que é e por que auditar
• Google SRE Book, capítulo sobre liberação gradual e canários: sre.google/sre-book/release-engineering
• NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0): nist.gov/itl/ai-risk-management-framework

O próximo passo é instrumentar a decisão, não escolher um modelo

A rota certa hoje não é a rota certa em três meses. O que sobrevive à mudança de preço, de latência e de release é o método que transforma uma decisão de rota em um experimento com critério escrito antes da medição, porque escolher o melhor modelo é fácil e instrumentar a troca separa quem decide de quem aposta.

É aqui que o Nexforce Router entra como infraestrutura, não como resposta pronta. Uma API única, uma chave, 300+ modelos, com roteamento inteligente, failover automático e fallback configurável para quando a rota titular cai. O trace de cada chamada sustenta a sombra com o identificador de rota preservado. O budget por chave, por agente ou por projeto impede que a fase de espelhamento estoure o teto sem aviso. E a economia de até 50% no custo por token reportada pela própria Nexforce, com nota fiscal em BRL, muda a conta que a rota candidata precisa bater.

O método é o seu. A camada que o executa pode ser uma só.