Prompts devem ser tratados como deploys de código

O problema: prompts mudam comportamento sem sinal de erro

A maioria dos times que operam features com LLM não publicaria uma mudança de código sem testes e CI. Mas ajustam um prompt, olham uma saída, e mandam direto para produção. O problema é que uma mudança ruim de prompt não gera erro HTTP, timeout ou build quebrado - ela degrada tom, desvia do formato, alucina de forma nova ou fica sutilmente menos precisa, e tudo isso retorna um HTTP 200 com texto plausível. Nada no ciclo request/response distingue uma boa saída de uma degradada.

O padrão: eval gate

A solução proposta é um "eval gate": uma verificação obrigatória entre "alguém editou um prompt" e "esse prompt é o que produção chama", análogo ao CI entre commit e deploy. Princípios de design:

• Fail closed: se não existe eval para aquela versão do prompt, o gate bloqueia por padrão.
• Checar o último run, não qualquer run: um prompt que passou há três edições não pode usar esse resultado antigo.
• Status sem promoção: dashboards podem inspecionar estado sem acidentalmente promover.
• Motivo acionável: "Bloqueado: eval mais recente falhou em 3/40 casos de factualidade" dá ao autor um ponto de partida.

Maturidade em quatro níveis

1. Sem processo: mudanças vão direto para produção; regressões são descobertas por tickets de suporte.
2. Revisão manual: uma segunda pessoa lê o diff. Pega problemas óbvios, perde sutis, não escala.
3. Eval gate automatizado: um test set fixo roda contra cada prompt candidato antes da promoção.
4. Eval contínuo em produção: amostra tráfego ao vivo, roda avaliação, e alimenta regressões de volta no test set do passo 3.

A maioria dos times está entre 1 e 2. Chegar ao 3 não exige infraestrutura customizada.

Implementação no Microsoft Foundry

• Versionamento é a unidade de promoção: cada save cria uma versão imutável; promoção é mover tráfego da versão N para N+1.
• Avaliadores embutidos: Groundedness, Relevance (para RAG), Coherence, Fluency (para formato/tom), Intent Resolution, Tool Call Accuracy, Task Adherence (para agentes), além de avaliadores de risco e segurança.
• Mecanismo de CI: a GitHub Action microsoft/ai-agent-evals (preview) compara versão candidata contra baseline, roda ambos contra um dataset com os avaliadores escolhidos, e retorna scores com intervalos de confiança e teste de significância - distinguindo ruído de melhoria real.
• Caveat: não existe uma API de "promote" que bloqueie automaticamente com base em threshold. A decisão de promover ainda é humana ou de CI, informada pela comparação.

O risco de o gate virar decoração

Um gate lento, opaco ou ruidoso será contornado. Três mitigadores: loops de eval rápidos (minutos, não dezenas de minutos), output de falha claro e detalhado, e um escape hatch auditado - o override existe, mas é logado, atribuído e visível.