Metodologia Baseline-vs-Floopy

A view de comparação Baseline-vs-Floopy responde uma pergunta sobre o tráfego próprio do cliente: a Floopy realmente entrega menor custo sem perder qualidade, comparada a uma baseline de modelo único default?

Esta página explica como a comparação é construída, o que conta como baseline, como os deltas são calculados e as ressalvas de metodologia — para que os números sejam interpretáveis e não sejam manipuláveis.

A view no dashboard da Floopy renderiza dois painéis empilhados para a mesma janela de tempo:

• Esquerda — Floopy: outcomes reais para requisições que rodaram pelo roteamento da Floopy.
• Direita — Baseline: outcomes contrafactuais calculados como se toda requisição na mesma janela tivesse sido enviada para o default_model da organização.

Cada painel reporta três números:

• custo médio por requisição (em micro-USD),
• p50 de latência (milissegundos),
• qualidade composta (uma média ponderada de scoring LLM-as-judge e NPS de sessão quando presente, normalizada para 0..=100).

O delta entre os dois painéis é o número de manchete: “Floopy entregou X% menos custo a Y pontos de qualidade composta vs. baseline.”

A baseline é o default_model da organização configurado na regra de roteamento que estava vigente para cada requisição na janela.

• Se múltiplas regras de roteamento se aplicaram durante a janela (ex.: uma mudança de config no meio da semana), cada requisição é comparada contra o default_model que estava ativo para aquela requisição.
• Se uma requisição não tinha regra de roteamento (caminho de legacy-model), ela é excluída da comparação — nenhum painel a conta.
• Se uma requisição foi um cache hit (outcome.cache_hit == true), ela também é excluída — não houve chamada ao provider para comparar custos.

A baseline não é:

• O modelo mais barato no catálogo da organização.
• Um simulado “o que o melhor modelo teria feito” — a Floopy nunca afirma saber o outcome contrafactual ótimo.
• Uma média de leaderboard entre todos os clientes da Floopy.

Os painéis de custo são diretos, não modelados.

• Painel Floopy: soma outcome.cost_micro_usd sobre as decisões com vencedor na janela, dividida pela contagem de requisições.
• Painel Baseline: para cada decisão na janela, busca o custo precificado de rodar o mesmo formato de tokens de prompt-e-resposta no default_model (usando as contagens de tokens de prompt e completion já registradas pelo caminho de logging da Floopy, e não uma chamada nova ao provider), depois agrega.

O painel Baseline usa o custo precificado do default_model no mesmo ponto no tempo da requisição original — mudanças de preço do provider durante a janela são refletidas igualmente em ambos os painéis.

O score de qualidade composta para a janela é uma média ponderada de:

• Scoring LLM-as-judge na resposta (quando o scoring está habilitado para a rota).
• Feedback de NPS de sessão (quando um floopy-session-id foi informado e a sessão tem uma linha de feedback em request_feedback).
• Overrides de admin na requisição (quando presentes).

O painel Floopy vê as respostas reais pontuadas. O painel Baseline não tem uma resposta contrafactual para pontuar — rodar o prompt no default_model após o fato seria caro e fora do contrato do gateway. Em vez disso, o número de qualidade da baseline é a qualidade composta histórica do default_model em requisições similares na mesma janela, ponderada pelo mesmo bucket de complexidade de tarefa que a camada de roteamento usou.

Esta é a ressalva de metodologia mais importante: a qualidade da baseline é um proxy histórico-agregado, não um contrafactual por requisição.

A comparação é honesta sobre o que ela não pode provar.

1. A qualidade da baseline é agregada, não por requisição. Não re-rodamos prompts contra o modelo baseline; confiamos no scoring histórico da baseline em tráfego da mesma classe de complexidade de tarefa. Um pequeno residual por requisição é inevitável.
2. Sem contrafactual em would_select. Não mostramos “se você tivesse pedido X em vez de Y, o resultado teria sido Z” — isso exigiria replay do prompt, o que explicitamente não fazemos.
3. Cache hits são excluídos de ambos os painéis. Um cache hit é uma economia de 100% de custo que não tem nada a ver com a seleção do modelo; incluí-lo inflaria o delta de custo do painel Floopy de forma enganosa.
4. Requisições de legacy-model são excluídas. Uma requisição que caiu no parsing legado não passou pelo roteamento da Floopy — não há nada para comparar.
5. Decisões de pool compartilhado de free-tier são sinalizadas, não excluídas. Quando used_shared_pool_prior == true para uma linha na janela, o painel renderiza um badge de “aviso de agregação” linkando para a metodologia de Confidence. Os números são mantidos; a procedência é visível.
6. Tamanho mínimo de amostra na janela. Quando a janela contém menos de N_MIN_COMPARE = 200 decisões em uma rota, os deltas da rota são escondidos atrás de uma affordance de “dados insuficientes” — o dashboard se recusa a expor um número em que não acredita.
7. A view não mostra um intervalo de confiança nos deltas. A v1 entrega estimativas pontuais. Uma iteração futura pode adicionar intervalos via bootstrap; não quisemos entregar um único IC enganoso na v1.

O dashboard renderiza um sumário curto de metodologia acima dos painéis o tempo todo — não há hover-para-revelar. A intenção é que um revisor consiga ler o painel e a metodologia juntos, em uma única tela, sem precisar clicar para outra página. O conteúdo completo aqui é para onde o blurb leva.

Para auditores externos que queiram recalcular o painel Floopy a partir dos exports brutos:

1. Puxe a janela via GET /v1/export/decisions.
2. Filtre para linhas onde winner != null e outcome.cache_hit == false e routing_strategy != "legacy_model".
3. Some outcome.cost_micro_usd e divida pela contagem de linhas para o painel de custo.
4. Agregue por p50 outcome.latency_ms para o número de latência.
5. O número de qualidade composta exige as tabelas de scoring LLM-as-judge e de NPS de sessão; essas são expostas pelo caminho de logging do gateway e visíveis no dashboard Floopy, mas não fazem parte do formato de wire do export hoje.

O painel Baseline não pode ser reproduzido apenas a partir do export — ele requer as tabelas históricas de scoring do default_model da org, que a Floopy renderiza dentro do dashboard.

No v2 a view Baseline-vs-Floopy do dashboard tambem expoe um card de Verification Status para cada regra de roteamento. O card responde uma pergunta estrita e estreita: dados os ultimos 7 dias de trafego desta regra na propria conta do cliente, temos evidencia suficiente para chama-la de verificada?

A mesma resposta e exposta programaticamente por GET /v1/optimization/verification.

As constantes que definem os quatro estados estao fixadas em codigo, nao configuraveis pelo cliente:

• SAMPLE_FLOOR = 100. Cada painel precisa de pelo menos 100 linhas na janela de 7 dias para que o veredito seja elegivel a verified ou not_verified. Abaixo desse piso a resposta e sempre insufficient_data. O piso existe porque deltas de custo e qualidade calculados em dezenas de linhas sao ruidosos demais para acionar.
• QUALITY_TOLERANCE = 0.03. O veredito e not_verified quando (baseline.composite_quality − floopy.composite_quality) > 0.03 na escala de qualidade composta [0.0, 1.0]. Abaixo desse delta o veredito e verified. A tolerancia e conservadora de proposito — a Floopy pode estar um fio abaixo da baseline em qualidade se esta significativamente abaixo da baseline em custo.

O estado regression_detected dispara sempre que o sinal bucketizado recent_regressions sobre a rota e qualquer coisa diferente de Exact { exact: 0 }. Isto e: qualquer contagem exata diferente de zero, qualquer AtLeast{10}, qualquer AtLeast{50} — o veredito vira para regression_detected.

Os limites dos buckets (<10, >=10, >=50) e o arredondamento de 5 minutos em last_regression_at estao documentados em Metodologia de Confianca.

O veredito de verificacao e calculado em uma agregacao por tenant sobre o log de requisicoes, com timeout duro de 5 s, e depois armazenado em Redis por (organization_id, route_id, window) durante 60 segundos. O card no dashboard e a chamada GET /v1/optimization/verification batem no mesmo cache; o cabecalho HTTP Cache-Control: max-age=60 e ecoado no caminho da API para que intermediarios HTTP respeitem o mesmo TTL.

Numeros de verificacao mudam devagar. Um cache de 60 segundos e curto o suficiente para que um cliente que conserta uma rota mal-configurada nao espere 30 minutos para ver o veredito atualizar, e longo o suficiente para que a camada de analytics nao seja consultada a cada render do dashboard.

O veredito de verificacao e separado do delta de custo/qualidade renderizado no resto da pagina. As duas views respondem perguntas diferentes:

• O delta de custo/qualidade diz: aqui esta a diferenca rolante entre a Floopy e a baseline, em micro-USD por requisicao e em pontos de qualidade composta.
• O veredito de verificacao diz: temos evidencia suficiente para afirmar que esta regra esta cumprindo seu lado do trato?

Uma regra pode mostrar 45 % de economia de custo e ainda ler not_verified se o delta de qualidade ultrapassa a tolerancia, ou regression_detected se um evento de regressao esta em curso. Ambos os numeros sao honestos; o veredito e a leitura mais estrita e conservadora.

• GET /v1/export/decisions — fonte de dados para o painel Floopy.
• GET /v1/optimization/verification — a API por tras do card de Verification Status.
• Metodologia de Confidence — para a flag used_shared_pool_prior que decora a view de comparação, e para o sinal evidence/bucket-de-regressao que dispara regression_detected.
• Smart Cost Routing — a camada de roteamento que produz essas decisões em primeiro lugar.