Fluxo de Decisão de Roteamento

A regra efetiva define os targets (provider, model) aprovados. Quando Feedback-driven e Smart Cost estão ativos, Feedback-driven controla a qualidade e a exploração. Smart Cost só pode introduzir um modelo externo nas faixas de exploração.

O gateway aplica floopy-routing-rule antes de carregar candidatos, histórico ou preços da baseline. O header seleciona uma regra da organização autenticada; sem ele, vale a regra correspondente à API key. Os dois recursos usam a mesma regra.

A resolução inicial do modelo continua: model da request → floopy-model-override → Smart Selector ou prompt de A/B → modelo/provider do prompt → default do provider. Smart Selector tem precedência sobre A/B; prompt_overwrite preserva o modelo do cliente e remove o provider do prompt. Uma regra de roteamento despacha seus próprios targets. Sem regra, o modelo resolvido usa a cascata legada: provider explícito → catálogo e chaves disponíveis → provider configurado.

O agente MCP mantém precedência sobre a cadeia normal. floopy-mcp-disabled: true permite desativá-lo por request. Cada rodada de LLM do agente usa a política normal de roteamento.

Um recurso está ativo quando o plano o permite e o switch efetivo está ligado. O switch geral do grupo Feedback-driven tem default ligado para planos elegíveis; desligá-lo permite Smart Cost independente ou a estratégia declarada. Ausência de feedback não desliga o recurso nem ativa outro automaticamente.

flowchart TD
    A[Resolver regra efetiva e modelo] --> B{Agente MCP ativo?}
    B -->|sim| C[Loop do agente]
    B -->|não| D{Existe regra?}
    D -->|não| E[Cascata legada de providers]
    D -->|sim| F{Feedback-driven ativo?}
    F -->|sim| G[Ranking de qualidade e um sorteio de exploração]
    G --> H{Faixa sorteada}
    H -->|Exploit| I[Somente targets aprovados]
    H -->|Explore| J[Testados com qualidade suficiente]
    H -->|ExploreUntested| K[Menos de 10 requests]
    J --> L[Smart Cost pode contribuir candidatos externos elegíveis]
    K --> L
    I --> M[Despachar vencedor e fallbacks aprovados]
    L --> M
    F -->|não| N{Smart Cost independente seleciona?}
    N -->|sim| M
    N -->|bypass ou desligado| O[Estratégia declarada]
    O --> M

F contém os targets habilitados da regra, aprovados pelo cliente. C contém os pares habilitados no Smart Cost dessa mesma regra. Um candidato externo pertence a C e não a F. Não há descoberta automática de todos os modelos do catálogo.

Qualidade tem precedência sobre economia. A exploração usa Thompson sampling com sucessos e falhas HTTP; não escolhe deterministicamente o mais barato ou menos testado. Aprender que um externo é bom não o adiciona a F: o cliente precisa incluí-lo nos targets para permitir exploit.

Externos exigem o tier de complexidade configurado, chave do provider, suporte catalogado a tools/formato estruturado solicitado, preços conhecidos de entrada/saída e custo médio por token estritamente menor que a baseline do Feedback-driven. Constraints da organização, incluindo validação shadow, continuam valendo. Request complexa faz bypass de Smart Cost e segue com Feedback-driven entre F.

Um sorteio baseado no request ID define a faixa. Com taxa r e parcela de não testados p:

Com r = 20% e p = 50%, até 10% das requests testam modelos não testados e até 10% exploram testados. Smart Cost não faz outro sorteio no modo conjunto. Os ajustes efetivos do Feedback-driven controlam esse orçamento.

r = 0 desliga exploração, inclusive no cold start. p = 0 desliga exploração de não testados. Pool exploratório vazio retorna ao exploit sem redistribuir o orçamento. Falha na consulta de histórico desliga exploração e mantém a baseline configurada; é diferente de uma consulta bem-sucedida sem amostras. Baixa confiança também pode forçar a baseline aprovada.

F contém A e B; C contém B e C. C é externo.

1. Em exploit, C não pode ser escolhido, mesmo barato e bem avaliado.
2. Se A tiver melhor qualidade no Feedback-driven, A vence. Se A e B empatarem e B tiver custo conhecido menor, Smart Cost pode favorecer B.
3. C recebe tentativa em explore com pelo menos 10 requests e qualidade aprendida suficiente, ou em explore_untested com menos de 10 requests.
4. Se C falhar, o despacho segue pelos targets aprovados elegíveis. Outros externos não entram na cadeia de fallback.

Uma regra por API key que falha pode recorrer aos targets explicitamente configurados na regra default da organização. Elegibilidade e constraints são reavaliadas; pares já tentados são removidos.

O audit conjunto mantém strategy_id: "feedback_driven". smart_cost registra participação e baseline. exploration_draw mostra a faixa sorteada; exploration mostra a seleção efetiva. history_available e winner_origin identificam evidência indisponível e exploração externa.

Floopy-Provider e Floopy-Model identificam o par despachado. Floopy-Smart-Cost-Decision usa exploit, explore, explore_untested, bypass ou complex_tier quando Smart Cost foi avaliado. Fallback aprovado após falha da otimização indica bypass. A economia usa os tokens efetivamente despachados e preços conhecidos.

• Estratégias de roteamento
• Smart Cost Routing
• Feedback
• Explicar uma decisão