Quatro Sinais, Um Loop: Como o Roteamento Multi-Fonte por Feedback Realmente Funciona

Todo sistema de roteamento por feedback acaba enfrentando a mesma pergunta: em qual sinal a gente confia? As respostas que aparecem por aí são variações de uma única fonte — um joinha, uma nota numérica, um score de benchmark, um avaliador LLM. Cada uma soa razoável isoladamente. Cada uma desmorona sob a pressão de produção.

Este post é a versão longa do motivo pelo qual desistimos de escolher uma só. Ele percorre as quatro fontes de sinal que a Floopy usa, os modos de falha específicos de cada uma quando usada sozinha, o problema de pesos que as conecta e o loop autocorretivo que torna a combinação estável. Se você está avaliando plataformas de otimização de agentes, ou construindo a sua, este é o conteúdo que você realmente precisa antes de escrever código.

Por que feedback de fonte única é frágil

As quatro fontes de sinal sobre as quais você poderia construir um sistema de roteamento — NPS de sessão, auto feedback (LLM-as-judge), avaliação de admin e benchmarks públicos — cada uma tem um modo de falha grave o suficiente para que rodar um roteador em produção sobre uma delas sozinha seja um risco. Não um caso de canto. O modo normal de operação de cada fonte produz decisões de roteamento erradas.

NPS de sessão sozinho é frágil

Feedback de usuário final no nível de sessão (uma nota NPS de 0–10 enviada após uma conversa) é o sinal mais significativo da pilha. É por isso que o produto é realmente avaliado. Mas se você tratá-lo como sua única entrada de roteamento, você obtém um roteador que:

• Atrasa a realidade em horas. Usuários finais não avaliam conversas no momento em que elas terminam. O feedback sobre o qual você está roteando hoje reflete o que aconteceu ontem.
• É esparso em modelos de baixo tráfego. Um modelo mais barato roteado para 2% das sessões produz 2% do volume de feedback. A nota dele oscila em N minúsculo por semanas.
• Tende para quem responde. Os usuários dispostos a enviar NPS não são uma amostra aleatória. São desproporcionalmente irritados ou desproporcionalmente encantados. O meio silencioso nunca aparece.
• Quebra no cold start. Um modelo novo adicionado hoje de manhã tem zero feedback de sessão. Roteamento só por NPS de sessão ou o trata como médio (otimismo demais) ou o exclui (pessimismo demais).

NPS de sessão é o sinal mais forte que você pode coletar. Também é lento demais, esparso demais e enviesado demais para ser o único sinal.

Auto feedback (LLM-as-judge) sozinho é enviesado

Auto feedback — um modelo avaliador barato pontuando respostas do seu modelo de produção em cada requisição — é rápido, denso e disponível desde a primeira requisição. Soa como a entrada dos sonhos. Ele tem uma patologia específica e bem documentada quando usado sozinho:

• Viés do juiz. Scores de LLM-as-judge correlacionam mais com as preferências do próprio juiz do que com verdade de campo. Um juiz treinado em saídas de uma família sistematicamente superpontua aquela família. Isso é replicado em todo estudo público de avaliação.
• Recompensa por características superficiais. Juízes recompensam saídas longas, com tom confiante e bem formatadas — mesmo quando estão erradas. “Confiantemente errado” bate “corretamente incerto” na maioria dos rubricas de juiz.
• Sem acesso ao resultado real. O juiz vê a resposta. Ele não vê se o usuário obteve o que queria, voltou ou desistiu.
• Deriva silenciosamente. Quando o modelo juiz é atualizado, seus scores mudam sem nenhuma alteração na sua pilha de produção. Você acorda e o “bom” de ontem é o “mediano” de hoje.

Auto feedback é o melhor sinal rápido. Também é estruturalmente enviesado de formas que o tornam um proxy ruim para qualidade quando usado sozinho.

Benchmarks sozinhos são defasados

Benchmarks públicos (MMLU, HumanEval, SWE-bench, MT-Bench e seus descendentes) são o único sinal que você tem no dia zero, antes de qualquer requisição chegar ao seu gateway. Isso é enormemente útil como um prior. Como única entrada de roteamento, eles falham por motivos estruturais:

• Defasados. O número de benchmark no model card reflete o desempenho no lançamento. Um provedor sobe silenciosamente uma mudança de quantização três semanas depois e o benchmark não é reexecutado. Seu roteador não sabe.
• Genéricos. MMLU mede conhecimento amplo. Seu produto pode estar roteando 90% de conversas de suporte ao cliente. MMLU não avalia isso e não vai avaliar.
• Gameáveis. Benchmarks vazam para dados de treino mais rápido do que são rotacionados. Um modelo que liderou o ranking em janeiro pode ter memorizado metade dele em junho.
• Indiferentes aos seus usuários. Nenhum benchmark público sabe se seus prompts, seu tom, seu orçamento de latência ou sua base de usuários são bem servidos por qualquer modelo específico.

Benchmarks são um prior útil. Não são um sinal vivo de roteamento.

Avaliação de admin sozinha é inescalável

Avaliação de admin — um joinha/deslike que operadores clicam em um dashboard para marcar requisições individuais — é o sinal de maior confiança da pilha quando existe. Um engenheiro humano deliberadamente olhou a saída e julgou. Isso é ouro. Também é fundamentalmente inescalável:

• Não escala com tráfego. Um time avaliando 50 respostas por dia não consegue cobrir um gateway com 50 mil requisições por dia. Você está roteando sobre 0,1% da realidade.
• Fadiga do operador. As primeiras cem avaliações são cuidadosas. As próximas mil não são. A qualidade da avaliação decai mais rápido do que o volume.
• Viés de seleção. Operadores avaliam o que aparece na frente deles — recente, sinalizado ou em tela. Amostragem aleatória sobre a distribuição de produção não acontece na prática.
• Enviesada para modos de falha conhecidos. Times avaliam o que já suspeitam ser ruim. Falhas novas não recebem joinha.

Avaliação de admin tem alta confiança quando existe. Simplesmente nunca há o suficiente dela para rotear sozinha.

A defesa de combinar os quatro

Cada sinal falha sozinho. Cada sinal cobre os modos de falha dos outros de formas específicas e previsíveis:

Isso não é preferência filosófica. É a única combinação em que todo modo de falha tem um contra-sinal. Um roteador que ignora qualquer um dos quatro tem uma fraqueza previsível que a produção vai encontrar.

O leitor cético pode tentar o oposto: escolha uma única fonte, descreva um modo de falha realista de produção e acompanhe o que o roteador faz. Ele trava, reage em excesso ou entrega viés. Combinar os quatro é a arquitetura mínima viável, não um luxo.

O problema de transição de pesos

Somar quatro sinais não resolve o roteamento — cria um problema novo. Qual sinal importa quando?

No dia zero, o único sinal que você tem é benchmarks. Ponderar os outros três nesse momento não faz sentido; estão vazios. Depois de algumas centenas de requisições, auto feedback começa a se acumular, mas o NPS de sessão ainda está esparso. Depois de alguns milhares de sessões com NPS real de usuário final voltando, o feedback de sessão é o sinal mais informativo que você tem — benchmarks agora são, no máximo, um prior fraco.

Um esquema fixo de pesos (digamos, 40/30/20/10 entre os quatro) erra em todos esses regimes:

• No dia zero, pondera sinais vazios em 60%, produzindo scores-lixo.
• No regime só-auto, sub-pondera o único sinal que você realmente tem.
• Quando o NPS de sessão chega, continua ponderando benchmarks como se ainda carregassem informação.

Os pesos precisam mudar com a disponibilidade de dados. Não como uma migração única — como uma função contínua do que existe de dado por modelo por janela de tempo. Essa é a mecânica central que sistemas de fonte única não têm e não conseguem acoplar depois.

A ponderação dinâmica da Floopy

O roteador da Floopy resolve o problema de transição de pesos com uma função de ponderação de três regimes, guiada pelo quanto de dado acumulou para cada modelo no conjunto candidato. Os pesos mudam dinamicamente com base no que há disponível:

O sistema começa com scores de benchmark no dia zero, transita para auto feedback conforme requisições acumulam e converge para feedback de sessão assim que usuários finais começam a enviar notas NPS. Quanto mais sinal do mundo real disponível, menos o sistema depende de benchmarks sintéticos.

Essa tabela está embutida nos docs em /docs/features/feedback/ e é a mesma tabela que o roteador lê em runtime. Sem desvio entre documentação e comportamento. Os valores de peso ficam fixados em uma única fonte, e tanto a documentação quanto a decisão de roteamento herdam dela.

O sinal de qualidade que essa tabela produz é uma das três entradas no score final de seleção de modelo:

performance_score = (success_rate × 0.4) + (quality × 0.4) + (cost_savings × 0.2)

Taxa de sucesso (parcela de HTTP 2xx) e economia de custo são objetivas. Qualidade é onde os quatro sinais de feedback colapsam num único número de 0,0 a 1,0, usando os pesos acima. Esse número — e só esse número — carrega a opinião dos seus usuários, dos seus operadores, dos seus juízes e das avaliações públicas para dentro da decisão de roteamento.

Degradação e recuperação: o loop inteiro num cenário

Abstração só vai até certo ponto. O teste mais claro de um sistema de roteamento por feedback é o que ele faz quando a realidade muda no meio do voo. Aqui está o cenário dos docs de Feedback, sem alteração — é a narrativa que usamos internamente para validar o loop.

Degradação

Veja como o sistema responde quando um provedor degrada, sem nenhuma intervenção manual em nenhum passo:

O Modelo A é excluído completamente. Sem alerta necessário, sem pager de on-call, sem mudança de configuração.

Recuperação

O sistema também se recupera automaticamente quando um provedor corrige o problema:

A fase de exploração é o que torna a recuperação possível. Sem ela, um modelo excluído em T=3h ficaria excluído para sempre. A taxa de 10% de exploração é a apólice de seguro que mantém o sistema autocurável.

As duas metades desse cenário só funcionam porque os quatro sinais estão ativos. NPS de sessão é o que detecta a degradação (usuários reportando má qualidade). Auto feedback confirma rápido e denso. Avaliação de admin pode intervir se operadores pegarem antes dos usuários. O piso de benchmark evita que o roteador reaja demais a uma única sessão ruidosa. Remova qualquer um dos sinais e o loop manca.

O que acontece com apenas um sinal

O mesmo cenário, com o roteador reescrito para usar só um sinal de cada vez:

• Só benchmarks. O score de benchmark do Modelo A não mudou — o provedor degradou silenciosamente o modelo implantado, não o número publicado de avaliação. O roteador nunca percebe. O tráfego permanece 90/10. Usuários saem.
• Só auto feedback. O juiz percebe a regressão, mas o juiz tem vieses sistemáticos — recompensa saídas longas e confiantes. Se a degradação do Modelo A o tornar mais verboso (um modo de falha comum em modelos quantizados), o juiz pode premiar a versão quebrada. O tráfego se mantém ou aumenta para A.
• Só NPS de sessão. Usuários detectam a regressão — mas as primeiras notas NPS chegam duas horas atrasadas, sobre uma amostra esparsa. O roteador ou reage em 5 sessões (correção excessiva) ou espera 50 (lento demais). De qualquer forma, usuários são prejudicados antes do roteador agir.
• Só avaliação de admin. Operadores podem perceber, se calhar de estarem olhando as requisições certas no dashboard naquele dia. A maioria dos times não olha, e mesmo quando olham, um joinha de admin num dia de 50 mil requisições é fino demais para mover o roteador.

A versão multi-fonte, com os pesos acima, pega a regressão em T=2h e exclui o modelo em T=3h. Isso não é porque a matemática da Floopy é mágica. É porque quatro sinais cobrindo os modos de falha uns dos outros é a única configuração em que o roteador enxerga o problema.

Experimente no tier gratuito

O loop de quatro sinais está ativo em toda conta Floopy, incluindo o tier Free. Você não precisa fazer upgrade para ver a função de ponderação operar sobre seu próprio tráfego — aponte o baseURL do seu SDK da OpenAI para https://api.floopy.ai/v1, comece a enviar requisições com um header floopy-session-id, e os três primeiros regimes (benchmark → auto → sessão) se desbloqueiam conforme seus dados acumulam.

A Feedback API — POST /v1/feedback para enviar notas NPS de sessão — está incluída no plano Starter com 500 envios/mês, o que cobre a maioria dos times durante o onboarding. Acesso de maior volume (ilimitado no Pro, nível enterprise além) segue a mesma forma.

Comece em app.floopy.ai, leia os docs de Feedback, ou veja o preço completo.

Quatro sinais. Um loop. Um roteador que realmente aprende.