Escolher o sistema, não o placar

Modelo “melhor” não existe fora da tarefa

Seleção é uma decisão multiobjetivo. Qualidade, latência, custo, contexto, tool use, modalidade, região, retenção, privacidade, disponibilidade e risco de fornecedor competem. Um benchmark público mede uma distribuição e um harness específicos; não garante resultado no seu sistema.

Defina primeiro um conjunto representativo. Para o assistente de manutenção: perguntas simples, diagnóstico com manual, casos sem resposta, português imperfeito, anexos, tentativas de injeção, tool calls e autorizações negadas.

Funil de decisão

restrições eliminatórias
    ↓
shortlist por capacidade
    ↓
bake-off cego no golden set
    ↓
teste de custo, latência e segurança
    ↓
canário + fallback + revisão periódica

Restrições eliminatórias incluem modalidade necessária, residência de dados, acordo contratual, tamanho de contexto real, região e suporte a schema. Só depois compare qualidade.

Matriz verificável

Critério	Medição	Gate
correção	rubrica e casos determinísticos	≥ alvo do produto
abstenção	casos sem evidência	sem invenção crítica
trajetória	ferramentas e permissões	zero ação proibida
latência	p50/p95 fim a fim	SLO acordado
custo	por tarefa concluída	orçamento
privacidade	contrato/configuração	requisito obrigatório
estabilidade	repetições e versões	regressão aceitável

Pesos não devem esconder gates. Um modelo barato não compensa violar requisito de dados; um modelo preciso não compensa ação insegura.

Roteamento, fallback e portabilidade

Use o menor sistema que passa. Um classificador local pode rotear perguntas simples para modelo econômico e investigações para modelo mais capaz. Mas roteador adiciona erro e observabilidade. Fallback deve preservar semântica: outro provedor pode usar schema, janela ou política diferente.

const route = task.risk === "high" ? "capable" : "economical";
const result = await providers[route].run(task);
if (result.transientFailure && task.readOnly) {
  return providers.fallback.run(task);
}
return result;

Não faça fallback automático de ação com efeito colateral: o primeiro provedor pode ter concluído apesar do timeout. Use idempotência e consulta de estado.

Fechado, aberto, hospedado ou local

Modelo gerenciado reduz operação; modelo aberto oferece controle de pesos e implantação, não ausência de obrigações. Self-hosting exige serving, segurança, atualização, capacidade e pessoal. “Local” não garante privacidade se telemetria, logs ou dependências enviam dados.

Use ajuste ou modelo local quando evals, soberania, volume ou especialização justificarem. Evite por identidade ideológica. Calcule TCO: GPU ociosa, engenharia, plantão, energia e oportunidade.

Benchmarks e contaminação

SWE-bench, MMLU e outros ajudam a formar hipótese. Pergunte: dados públicos podem estar no treino? qual versão? qual scaffold/harness? quantas tentativas? qual custo? qual seleção de casos? O placar avalia modelo ou sistema completo? Reproduza uma amostra e mantenha teste privado.

Falhas, segurança e operação

• escolher pela demo mais impressionante;
• usar nome comercial sem versão/snapshot;
• ignorar limites e região;
• registrar conteúdo sensível no bake-off;
• adaptar prompt a um concorrente e não aos demais;
• trocar modelo sem regressão.

Mantenha model registry com proprietário, usos permitidos, versão, fontes, eval, data, custo, retenção, fallback e retirada. Alertas observam qualidade proxy, erro, latência e gasto. Revisão trimestral ou por mudança significativa evita congelar decisão num mercado volátil.

Exercício e aceite

Faça bake-off cego de três alternativas em 50 casos. O avaliador não vê o nome do provedor. Registre prompts equivalentes, repetições, intervalos, custo e erros. Escolha uma alternativa primária e uma estratégia de indisponibilidade.

Aceite: dataset versionado; critérios antes do teste; gates eliminatórios; análise de piores falhas; teste adversarial; custo por tarefa; rollback e data de revisão.

Fontes

• Stanford HELM
• SWE-bench
• NIST AI RMF
• OpenAI model guide
• Anthropic model overview

Laboratório e caderno de evidências

Este caderno transforma o conceito do livro em uma decisão de engenharia auditável. O cenário é Escolher modelo para o copiloto de manutenção. A regra é começar pelo sistema atual — modelo econômico vigente e processo humano — e só acrescentar complexidade quando uma avaliação previamente definida demonstrar ganho líquido.

1. Escreva o contrato da decisão

Registre em uma página: quem usa, qual decisão recebe apoio, quais entradas existem naquele instante, qual saída é permitida, qual efeito é proibido e quem responde pelo resultado. Separe sugestão, decisão e execução. Uma resposta textual pode sugerir; a API de domínio continua autorizando e registrando qualquer mudança.

Use critérios no formato dado/quando/então. Inclua caminho nominal, ausência de dados, conflito, outro tenant, dependência indisponível e tentativa adversarial. “Funciona bem” não é critério. Declare o limite de tempo, custo, dados e risco, além da condição de parada.

2. Construa o pacote mínimo de evidência

Crie um conjunto pequeno, porém representativo, antes de alterar o sistema. Cada caso tem identificador estável, origem, resposta ou comportamento esperado, risco, tags e razão da inclusão. O conjunto de desenvolvimento ajuda a iterar; um holdout separado impede otimizar contra a própria prova. Dados reais exigem minimização, controle de acesso e retenção. Quando usar casos sintéticos, identifique-os e confirme que não substituem a distribuição real.

A comparação deve manter constantes as partes que não estão sendo avaliadas. Se trocar modelo e prompt ao mesmo tempo, você não saberá a causa. Registre versões, configurações, ambiente, seeds quando aplicável e data. Preserve os piores erros como artefatos, não apenas a média.

3. Desenhe a fronteira operacional

entrada validada → componente candidato → validação externa
                 → autorização/policy → resultado observável
                 → feedback curado → avaliação de regressão

Marque onde conteúdo não confiável entra, onde identidade e permissões são resolvidas, onde segredos ficam e qual componente pode produzir efeito. O modelo não é fonte de verdade nem mecanismo de autorização. Use schema, consulta ao sistema de registro, allowlists, limites e confirmação proporcional ao risco.

Para cada dependência defina timeout, retry, idempotência, fallback e circuit breaker. Retry não é padrão para efeitos: um timeout pode ocorrer depois do sucesso. Modo degradado precisa preservar segurança e deixar claro ao usuário o que perdeu.

4. Faça uma pré-mortem

As falhas prioritárias deste livro são: benchmark contaminado; versão silenciosa; lock-in; fallback incompatível. Para cada uma, escreva gatilho, impacto, detecção, contenção, recuperação e teste do controle. Inclua falha acidental e abuso deliberado. Se a única defesa é “o modelo provavelmente recusará”, o controle ainda não existe.

Execute tabletop: uma pessoa opera, outra injeta a falha e uma terceira observa. O operador deve diagnosticar usando dashboards, traces e runbook, sem depender do autor. Registre lacunas e transforme recorrência em teste, política, alerta ou mudança arquitetural.

5. Meça o sistema completo

O painel mínimo acompanha qualidade cega; p95; custo por sucesso; violações críticas. Faça cortes por versão, tipo de tarefa, risco e população relevante. Latência fim a fim inclui fila, retrieval e ferramentas. Custo é dividido por tarefa concluída, não por chamada. Qualidade em produção usa sinais curados; clique ou concordância do usuário não prova correção.

Defina SLO e orçamento de erro quando houver operação contínua. Alertas precisam de owner e ação. Telemetria passa por redaction antes de sair do processo; prompt, documento, memória ou trace completo podem conter informação pessoal, segredo ou conteúdo malicioso.

6. Libere em degraus

A sequência segura é offline, shadow, equipe interna, canário, aumento gradual e produção. Cada degrau possui gate e rollback. Feature flag separa deploy de liberação. A reversão deste cenário é: rotear para alternativa homologada ou processo manual. Treine a reversão antes do incidente e verifique que dados derivados, filas e caches também retornam a estado compatível.

Mudança de modelo, prompt, índice, ferramenta, policy ou dataset é mudança de sistema. Rode regressão proporcional. Um fornecedor atualizar silenciosamente comportamento não remove sua obrigação de testar.

Matriz de aceite

Dimensão	Evidência exigida	Falha que bloqueia
valor	ganho sobre baseline em casos representativos	demo isolada sem comparação
correção	golden set, holdout e análise dos piores casos	métrica média sem cauda
segurança	testes negativos de identidade, dados e efeitos	policy apenas no prompt
privacidade	minimização, finalidade, retenção e exclusão	dado sensível em trace
operação	SLO, alerta, runbook e rollback exercitado	dependência sem timeout
governança	owner, versão, usos permitidos e revisão	sistema órfão

Exercício de competência

Entregue um repositório ou pacote reproduzível contendo contrato, diagrama de fronteiras, casos de avaliação, script de execução, relatório comparativo, threat model, dashboard mínimo e runbook. Introduza deliberadamente duas falhas da pré-mortem e demonstre detecção e recuperação. Outra pessoa deve conseguir repetir o resultado sem explicação oral.

A aprovação exige: baseline preservado; critérios definidos antes do resultado; pelo menos um caso em que o sistema se abstém; efeito sensível protegido fora do modelo; custos medidos; rollback testado; limitações e usos proibidos escritos. Se o candidato não superar o baseline com segurança, documentar “não adotar” é um resultado tecnicamente correto.

Perguntas de recuperação ativa

1. Qual afirmação deste sistema depende de evidência externa?
2. O que o modelo pode propor, mas jamais autorizar?
3. Qual mudança invalidaria o holdout?
4. Como detectaríamos a pior falha antes do usuário?
5. Qual é o caminho de retirada em menos de uma hora?

Relações

Use este caderno junto ao livro de evals para desenho estatístico, ao de segurança para cenários adversariais, ao de observabilidade para sinais e ao de UX para supervisão. A profundidade nasce da conexão entre decisão, implementação, medição e recuperação — não da quantidade de ferramentas citadas.