Quality gates para LLMs: transforme avaliações em decisões de lançamento

Por que isso importa

Uma nota melhor não respondeu “podemos lançar?”#

Imagine um assistente de atendimento cuja nota média melhora enquanto um pequeno conjunto de respostas ainda inventa regras de reembolso. O painel está mais verde, mas a pergunta de lançamento continua sem resposta: a melhora observada basta para aceitar a falha conhecida e quem responde por essa decisão?

Esse é o trabalho específico de um gate de qualidade. Ele transforma evidência de avaliação em uma decisão delimitada sobre o comportamento do modelo. O restante do artigo se concentra nessa camada — critérios, avaliadores, incerteza, política e evidência reproduzível —, não no processo operacional completo de lançamento.

Para responder à pergunta de lançamento, primeiro separe os tipos de evidência que o painel havia comprimido em uma única nota.

Modelo operacional

Quatro camadas, uma decisão de lançamento#

O caso do assistente de atendimento exige quatro camadas distintas. Cada uma responde a uma pergunta antes de alguém aprovar o lançamento.

1. 01

   Testes

   Esquemas, regras de política, casos fixos e invariantes capturam falhas que não exigem interpretação.

2. 02

   Avaliador

   Uma rubrica avalia qualidades como fundamentação (groundedness) ou conclusão da tarefa e retorna veredito, evidência e um estado explícito de incerteza.

3. 03

   Gate

   Uma política combina sinais, trata incerteza e produz PROMOTE, HOLD ou ROLLBACK.

4. 04

   Lançamento

   Uma pessoa responsável aceita a evidência, registra a decisão e monitora o resultado real.

Essas camadas só podem ser auditadas quando o avaliador devolve mais que um número.

Contrato do avaliador

Peça um veredito que possa ser auditado#

Um prompt de avaliação não é um sistema de qualidade. Trate o avaliador como componente versionado, com critério estreito, exemplos-âncora, saída estruturada e caminho de abstenção. Guarde a versão da rubrica junto de cada resultado.

O resultado mínimo útil não é um número solto. Preserve o veredito, a evidência que o sustenta, um estado de incerteza cujo significado esteja definido na rubrica e contexto de execução suficiente para reproduzir o caso. O G-Eval é um exemplo público inicial de uso de etapas explícitas de avaliação e estrutura de formulário no lugar de uma opinião livre.

{
  "policy_version": "release-policy@1",
  "required": ["schema", "critical_safety", "task_completion"],
  "hard_blockers": ["schema", "critical_safety"],
  "on_missing_evidence": "HOLD",
  "on_uncertain_evidence": "HOLD",
  "allowed_verdicts": ["PROMOTE", "HOLD", "ROLLBACK"]
}

const fs = require("fs");

const policy = JSON.parse(fs.readFileSync("release-policy.json", "utf8"));
const evidence = {
  schema: "pass",
  critical_safety: "fail",
  task_completion: "pass",
};
const missing = policy.required.filter(name => !(name in evidence));
const failed = policy.required.filter(name => evidence[name] === "fail");
const uncertain = policy.required.filter(name => evidence[name] === "uncertain");
const hardFailure = failed.some(name => policy.hard_blockers.includes(name));
const verdict = hardFailure ? "HOLD"
  : missing.length > 0 ? policy.on_missing_evidence
  : uncertain.length > 0 ? policy.on_uncertain_evidence
  : "PROMOTE";
if (!policy.allowed_verdicts.includes(verdict)) throw new Error("policy returned an unsupported verdict");

console.log(JSON.stringify({ verdict, failed, missing, uncertain, policy_version: policy.policy_version }, null, 2));

{
  "verdict": "HOLD",
  "failed": ["critical_safety"],
  "missing": [],
  "uncertain": [],
  "policy_version": "release-policy@1"
}

Depois que o veredito ganha uma justificativa visível, a equipe ainda precisa de uma política que diga o que essa evidência permite fazer.

Política do gate

Limiares são política, não verdade#

Não esconda riscos diferentes dentro de uma média. Um lançamento pode ter um agregado saudável e ainda falhar em um invariante crítico de segurança ou factualidade. Separe bloqueadores rígidos de sinais graduais e documente o que acontece perto do limiar.

Use PROMOTE quando os invariantes obrigatórios passam e a evidência está dentro do domínio operacional validado. Use HOLD quando a evidência é ausente, conflitante ou incerta. Use ROLLBACK quando evidências de produção cruzam um limite predefinido de segurança ou confiabilidade. Não existe corte universal; calibre com casos rotulados e o custo de cada erro.

Essa política só é confiável se o avaliador também for; por isso, a próxima verificação se volta ao próprio avaliador.

Avalie o avaliador

Avaliadores baseados em LLM precisam dos próprios testes#

O MT-Bench documenta vieses de posição, verbosidade e autopreferência em avaliações feitas por LLMs. Combata-os com inversão de posição, casos de tamanho controlado, identidade do modelo ocultada, exemplos adversariais e comparação periódica com rótulos humanos.

Acompanhe discordância e abstenção, não apenas taxa de aprovação. Um avaliador que sempre parece seguro pode ser mais perigoso que outro capaz de expor incerteza. Quando a rubrica, o modelo avaliador ou o prompt mudar, reproduza um conjunto estável de calibração antes de promover.

Os testes de viés mostram se o veredito é estável; um registro de evidências permite então reproduzir a falha.

Trilha de evidências

Reproduza falhas sem armazenar todos os prompts e respostas#

Conecte o registro da avaliação à execução, às versões de modelo e prompt, aos resultados de ferramentas, à latência, ao custo e ao contexto relevante de recuperação. Convenções semânticas comuns ajudam a correlacionar evidências entre serviços, mas elas evoluem — fixe a versão adotada.

Não grave prompts e respostas por padrão. O OpenTelemetry alerta explicitamente que atributos de mensagens GenAI podem conter informações sensíveis. Aplique mascaramento ou remoção de dados sensíveis, controle de acesso, limites de retenção e captura de conteúdo por adesão antes de armazenar os dados.

Falhas reproduzíveis ajudam além de um lançamento quando o atrito confirmado do produto entra no próximo conjunto de avaliação.

Uso interno sistemático

Transforme atrito real no próximo caso de regressão#

Antes que usuários encontrem a falha, percorra as jornadas críticas do próprio produto: o prompt estranho, a ferramenta que falha, a resposta parcial, a troca de idioma e o caminho de recuperação. Converta cada falha confirmada em um caso mínimo e reproduzível.

Assim o ciclo se fecha: produção e uso interno sistemático (dogfooding) geram evidências; a triagem gera rótulos; os rótulos ampliam o conjunto de avaliação; o conjunto protege o próximo lançamento. O gate é útil quando aprende com a falha sem mudar silenciosamente o significado de sucesso.

Mesmo um conjunto de regressão crescente tem limites: passar nos casos conhecidos não garante o comportamento futuro.

Checklist de lançamento

Um gate pequeno que a equipe consegue manter#

Use os itens para reconstruir a decisão de uma versão candidata, não como uma lista genérica de conformidade.

• ✓Versione conjunto de dados, rubrica, avaliador, prompt e política.
• ✓Execute verificações determinísticas dos invariantes antes da avaliação probabilística.
• ✓Retorne veredito, evidência, estado de incerteza definido e abstenção.
• ✓Valide com casos rotulados e teste vieses conhecidos do avaliador.
• ✓Separe bloqueadores críticos de indicadores agregados.
• ✓Mascare ou remova dados sensíveis dos rastros de execução e defina a retenção.
• ✓Atribua uma pessoa responsável e registre a decisão.
• ✓Reproduza falhas de produção antes da próxima promoção.

Quando cada item tem evidência e responsável, a decisão final deixa de depender apenas de uma média verde.

Conclusão

Um gate é uma decisão com responsável, não uma nota#

A conclusão prática é simples: uma avaliação só se torna gate de qualidade quando evidência versionada muda uma decisão de lançamento com responsável. Uma nota alta sem bloqueadores críticos, regra para incerteza, pessoa responsável e resposta como HOLD ou ROLLBACK ainda é um painel — não um controle de lançamento.

Comece por uma jornada de alto risco. Versione casos, rubrica, avaliador, prompt e política; separe falhas determinísticas de qualidades julgadas; registre a evidência e quem responde pelo resultado. Amplie somente depois que o time conseguir reproduzir tanto uma aprovação quanto uma falha. O menor gate útil é aquele que o time consegue explicar e operar em todo lançamento.