A matriz de decisão

Comece pelo trabalho, não pelo catálogo de modelos. A mesma rota raramente otimiza qualidade, custo, latência e privacidade ao mesmo tempo.

“Sem LLM” é uma rota legítima. Se uma consulta ao banco, uma busca exata ou um template resolve o problema, chamar um modelo adiciona custo e incerteza sem criar valor.

Camadas como economy, balanced, quality e private devem ser papéis internos, não apelidos eternos para produtos comerciais. O catálogo liga esses papéis a modelos concretos por período de vigência. Assim, uma troca de fornecedor não exige reescrever a regra de negócio — e um nome de marketing novo não muda a política sem avaliação.

Fallback é outro produto

Fallback não significa “tente um modelo pior”. Significa executar uma alternativa previamente autorizada que ainda cumpre o contrato mínimo.

Cada aresta da cascata precisa declarar:

• quais erros a ativam;
• quais classes de dados podem atravessá-la;
• quais recursos continuam disponíveis, como JSON estruturado, contexto ou ferramentas;
• qual limite de qualidade ainda vale;
• quanto tempo e orçamento restam;
• o que o usuário verá se nenhuma rota for válida.

Uma regra útil é avaliar o fallback com o mesmo rigor da rota principal. Se quality → balanced nunca foi testado em casos difíceis, a seta no diagrama é esperança, não resiliência.

Retry, circuit breaker e fallback resolvem problemas diferentes. Retry pergunta se a mesma operação pode funcionar numa nova tentativa. O breaker impede que a aplicação continue pressionando uma dependência doente. Fallback escolhe outra execução compatível. A documentação do Azure Architecture Center também distingue retry de circuit breaker; o artigo da AWS sobre exponential backoff and jitter explica por que clientes sincronizados pioram uma recuperação.

Defina também um prazo total. Três tentativas de dez segundos mais um fallback de dez segundos não são uma rota interativa de baixa latência; são quarenta segundos escondidos atrás de uma configuração de retry.

Quatro falhas reais

Um roteador costuma falhar de maneira silenciosa. Estas quatro classes cobrem boa parte do risco operacional.

1. Roteamento incorreto e silencioso

O classificador envia tarefas difíceis para uma rota econômica. A chamada retorna 200, a latência melhora e nenhum alerta técnico dispara. O usuário recebe uma resposta pior.

Como detectar: matriz de confusão por intenção em eval offline, confiança calibrada, taxa de aceitação por rota, edição ou regeneração por coorte e amostra humana dos casos de baixa confiança.

Resposta: caminho conservador para incerteza, regras determinísticas para casos de alto impacto e rollback da versão de política — não apenas troca do modelo.

2. Fallback incompatível

A rota principal falha e a cascata escolhe um modelo sem o esquema, a ferramenta, a região ou a autorização exigida. A tentativa de “manter o serviço no ar” quebra o contrato.

Como detectar: contador de fallback_blocked_reason, testes de contrato por aresta, validação da saída antes do consumo e alerta para qualquer dado classificado que tente cruzar uma rota proibida.

Resposta: elegibilidade reavaliada em cada tentativa, fallback vazio para fluxos que devem falhar fechados e alternativa explícita para o usuário.

3. Tempestade de retries

Um provedor degrada, cada réplica repete chamadas e todas voltam juntas após o mesmo intervalo. Custo, fila e latência crescem enquanto a dependência tenta se recuperar.

Como detectar: tentativas por requisição, razão entre chamadas ao provedor e requisições de usuário, tempo total gasto em retry, 429/5xx, estado do breaker e saturação por rota.

Resposta: prazo total, jitter, respeito a Retry-After, limite de tentativas, circuit breaker e uma única sonda half-open por domínio de falha.

4. Economia que piora o produto

O custo por chamada cai, mas usuários corrigem mais respostas, abandonam o fluxo ou acionam suporte. O roteador otimizou a métrica mais fácil de medir.

Como detectar: custo por tarefa concluída, não só por chamada; taxa de resolução, edição, reabertura e conversão; comparação simultânea entre controle e canary; análise segmentada por intenção.

Resposta: qualidade e resultado do usuário como guardrails de promoção. Uma política mais barata que viola o mínimo não é otimização; é transferência de custo para o cliente e para a operação.

Orçamento antes e depois

Um teto por requisição evita apenas uma parte do problema. Antes da chamada, estime o pior caso permitido. Depois, reconcilie com o uso efetivo retornado pelo provedor.

estimated_max = input_units * input_rate + max_output_units * output_rate

authorize only when:
estimated_max <= request_reservation
AND estimated_max <= tenant_budget_remaining
AND route satisfies data, latency, and quality policy

after completion:
atomically replace reservation with actual usage

O catálogo de preço deve registrar moeda, unidade, versão, data de vigência e URL oficial. Preços e limites mudam; este artigo, verificado em 12 de agosto de 2026, deliberadamente não fixa números de fornecedores.

Reserve orçamento em níveis diferentes: requisição, processo, usuário ou organização e janela temporal. Sem isso, mil chamadas individualmente válidas podem romper o limite diário. Para streaming, faça reserva antecipada e defina o comportamento quando o teto se aproxima: interromper, resumir, pedir confirmação ou enfileirar. “Descobrir no fechamento da fatura” não é um controle.

Meça custo por resultado útil. Custo por token pode cair enquanto o custo por ticket resolvido sobe.

Evals offline e online

Não avalie “qual é o melhor modelo”. Avalie a política inteira: classificação, elegibilidade, execução, fallback e resultado.

Offline

O conjunto offline deve representar cada intenção, idioma, classe de dados e consequência de erro. Inclua entradas ambíguas, limites de contexto, saídas malformadas, timeouts, 429, 5xx, circuito aberto e tentativas de injeção de prompt.

A eval precisa guardar entrada, resultado esperado, critério, severidade e rota máxima permitida. Casos de produção só entram no conjunto de dados depois de mascaramento e autorização compatíveis com a política de retenção.

Online

Evals offline não capturam toda a distribuição real nem o comportamento posterior do usuário. Em produção, acompanhe por intenção e versão de política:

• conclusão da tarefa e taxa de resolução;
• aceitação, edição, regeneração e abandono;
• erro de esquema e correção factual amostrada;
• latência de fila, primeiro token e conclusão;
• custo estimado, reservado e reconciliado;
• fallback, bloqueio por política e incidente de segurança.

Nem todo sinal é imediato. Uma resposta de suporte pode parecer aceita e ser reaberta dias depois. Preserve a ligação entre decisão e outcome sem transformar prompts brutos em telemetria padrão.

A documentação oficial da OpenAI descrevia, na verificação de 12 de agosto de 2026, evals como testes contra critérios definidos pela aplicação e alertava para uma transição da plataforma de Evals. Isso reforça um princípio: seus casos, rubricas e histórico de decisão devem pertencer ao seu sistema, não à interface de um fornecedor. Consulte a documentação atual de evals antes de escolher a integração.

Shadow antes de canary

Uma política nova não deveria começar atendendo usuários.

No shadow, a política candidata recebe uma cópia autorizada da entrada, mas sua resposta não é servida. Compare escolha de rota, elegibilidade, qualidade, latência e custo estimado com a política atual. O shadow revela divergências sem alterar a experiência, mas não é “grátis”: duplica processamento e pode ampliar exposição de dados. Amostragem, mascaramento, retenção e permissão continuam valendo.

No canary, uma fração controlada do tráfego recebe de fato a nova política. Defina antes:

• coorte e duração mínima;
• métricas de promoção ligadas ao usuário;
• guardrails de segurança, qualidade, latência e orçamento;
• limiar de rollback;
• dono com autoridade para interromper;
• versão exata para a qual voltar.

Compare canary e controle no mesmo período. Uma comparação “semana passada versus hoje” mistura a mudança do roteador com sazonalidade, campanha, incidentes e mudança de tráfego. O capítulo do Google SRE sobre canarying releases recomenda métricas representativas e atribuíveis e descreve estágios graduais para limitar impacto enquanto a confiança aumenta.

Só promova quando os resultados online confirmarem os gates definidos antes do experimento. Mudar o critério depois de ver os dados transforma avaliação em justificativa.

Observabilidade da decisão

O trace deve permitir reconstruir a rota sem registrar conteúdo sensível por padrão. Ligue o span do roteador ao span do provedor e capture, quando aplicável:

• route.id, policy.version e catalog.version;
• intenção, confiança e regras acionadas;
• modelo solicitado e modelo efetivo;
• classe de dados e decisão de autorização, sem o dado em si;
• estimativa, reserva, uso e custo reconciliado;
• prazo, fila, primeiro token e latência total;
• tentativa, status, request_id, breaker e motivo do fallback;
• versão de prompt, ferramentas permitidas e resultado da validação;
• identificador de experimento para shadow ou canary.

Prompts, respostas, documentos de RAG, chaves e PII não devem virar atributos comuns. Se conteúdo for indispensável para auditoria, use armazenamento separado com minimização, mascaramento, controle de acesso, justificativa e retenção definida.

As convenções de GenAI do OpenTelemetry estavam em migração para um repositório dedicado em 12 de agosto de 2026. Fixe a versão adotada e trate mudanças de nomes e estabilidade como migração de esquema, não como detalhe de painel.

Um painel útil responde perguntas operacionais:

• Qual versão de política explica o custo e a qualidade de hoje?
• Qual intenção concentra baixa confiança ou fallback?
• Quais arestas de fallback estão bloqueadas e por quê?
• Quanto retry amplifica cada requisição de usuário?
• A rota econômica mantém o resultado mínimo por segmento?
• Quanto tempo levaria para detectar e reverter a política atual?

Segurança não é uma camada

Mandar uma tarefa sensível para um modelo “mais forte” não resolve autorização. Segurança atravessa todas as rotas.

A política precisa controlar, antes da chamada:

• identidade, organização e finalidade;
• classificação e residência dos dados;
• provedores, regiões e retenção permitidos;
• ferramentas e ações disponíveis;
• limite de contexto e de saída;
• tratamento de entrada não confiável;
• fallback permitido ou falha fechada.

Multi-provedor aumenta opções de recuperação, mas também amplia chaves, contratos, subprocessadores, superfícies de exfiltração e trabalho de incidente. Uma rota alternativa só existe se foi aprovada para aquela classe de dados.

Transforme ameaças em casos de teste. A edição 2026 do OWASP GenAI LLM Top 10, publicada em 3 de agosto de 2026, é uma fonte atual para revisar riscos; adapte a taxonomia ao seu fluxo e ao poder real das ferramentas. Para decisões de governança e risco, o NIST AI RMF Generative AI Profile oferece uma referência primária complementar.

Donos e rollback

Política sem dono envelhece em silêncio. Distribua responsabilidades concretas:

Separe política, catálogo e adaptadores. A política diz que trabalho pode usar qual papel. O catálogo mapeia o papel para um modelo vigente. O adaptador fala com o fornecedor. Essa separação permite trocar um modelo, reverter uma regra ou isolar um provedor sem lançar tudo ao mesmo tempo.

Toda decisão deve carregar policy.version. Mantenha a versão anterior implantável, uma chave de desligamento fora do caminho do LLM e um procedimento operacional ensaiado. Rollback que depende de editar código sob incidente não é reversibilidade; é esperança com acesso ao repositório.

Exercícios

Use o artefato do início como laboratório.

1. Prove a barreira de privacidade

Marque a requisição como restricted, faça mock/private retornar 503 e rode novamente.

Sucesso: nenhuma rota pública é chamada, o erro final é no_policy_compliant_route e o evento de bloqueio registra o motivo sem incluir a entrada.

2. Adicione um prazo total

Implemente um orçamento total de tempo compartilhado entre retries e fallback. Não reinicie o relógio ao mudar de rota.

Sucesso: um teste com adaptadores lentos termina dentro da tolerância definida e registra deadline_exhausted; o número de chamadas não supera o limite.

3. Crie uma eval de política

Monte ao menos um caso para cada célula da matriz de decisão e injete 429, saída inválida e orçamento insuficiente.

Sucesso: o teste falha quando uma rota viola dados, esquema, custo ou fallback, mesmo que o adaptador retorne 200.

4. Simule shadow e rollback

Execute duas versões da política sobre o mesmo conjunto autorizado, sem servir a candidata. Depois promova a candidata para uma coorte local e force um guardrail a falhar.

Sucesso: você consegue explicar cada divergência por policy.version e restaurar a versão anterior sem alterar o código do adaptador.

Você entendeu o sistema quando consegue prever a rota, provar por que os fallbacks restantes são proibidos e reverter uma mudança usando evidência — não intuição.

Checklist de produção

• Toda requisição recebe tarefa, impacto, classe de dados, orçamento e prazo.
• A rota “sem LLM” é considerada antes de gastar.
• Política, catálogo, prompts e adaptadores têm versões independentes.
• Cada fallback declara gatilho, compatibilidade e resposta quando bloqueado.
• Retry respeita taxonomia de erro, Retry-After, jitter e prazo total.
• Circuit breaker tem domínio de falha e sonda half-open definidos.
• Orçamento é reservado antes e reconciliado depois em todos os níveis relevantes.
• Evals offline cobrem qualidade, resiliência, custo e segurança por intenção.
• Métricas online medem resultado do usuário, não só custo por chamada.
• Shadow respeita privacidade; canary tem controle simultâneo e gates prévios.
• Telemetria reconstrói a decisão sem conteúdo sensível por padrão.
• Cada política tem dono, aprovador, chave de desligamento e rollback ensaiado.

O objetivo não é encontrar um modelo barato que “quase sempre funciona”. É construir uma política que saiba quando economizar, quando escalar, quando esperar e quando se recusar a continuar. O roteador maduro não esconde incerteza atrás de disponibilidade. Ele transforma cada escolha em uma decisão limitada, observável e reversível.

Fontes primárias

Links voláteis foram verificados em 12 de agosto de 2026.

• OpenAI API: error codes — taxonomia de erros para separar retry, fallback e falha permanente.
• OpenAI API: working with evals — critérios, datasets e ciclo de avaliação; consulte o aviso de transição vigente.
• AWS Architecture Blog: Exponential Backoff and Jitter — análise de estratégias de backoff e jitter.
• Microsoft Azure Architecture Center: Circuit Breaker — estados, recuperação e relação com retry.
• Google SRE Workbook: Canarying Releases — seleção de métricas, controle e rollout gradual.
• OpenTelemetry: GenAI Semantic Conventions — esquema em evolução para spans, métricas e eventos de GenAI.
• OWASP GenAI LLM Top 10 2026 — ameaças e mitigações para aplicações com LLM.
• NIST AI 600-1: Generative AI Profile — perfil de gestão de riscos para IA generativa.