Uma mudança, do início ao fim

Sua pontuação subiu depois de uma mudança. Esta página acompanha uma mudança real por cada pergunta que o Oloproof faz antes de deixá-la ir para produção: o juiz é confiável, a mudança atinge o limite por si só, ela é melhor do que aquilo que substitui segundo o juiz e segundo as pessoas, e o que tentar em seguida. O sistema é um pequeno bot de suporte que responde a partir de 40 documentos, executado na sua máquina com modelos locais; cada número abaixo é o que o mecanismo imprimiu. Copie-o de examples/one_change e execute REVIEWER=yourname ./run_demo.sh.

A mudança

O prompt de base pede ao bot que mantenha os valores, nomes e unidades exatos. O candidato pede uma ou duas frases calorosas e naturais. Ambos são executados nas mesmas 120 perguntas, com uma verificação determinística (answer_correct, a resposta contém o fato esperado) e um juiz de modelo local (judge_correct, ela responde com o mesmo fato):

oloproof run --policy release.yaml
oloproof run --config candidate.yaml --policy release.yaml

As respostas certas passaram de 80.0% para 82.5%, a taxa de aprovação do juiz de 82.5% para 83.3%. Essa é a melhoria aparente. Nenhuma das execuções decide nada ainda: a regra de release lê o juiz, e o juiz não foi verificado, então a regra diz INSUFFICIENT_EVIDENCE com evaluator_not_validated.

O juiz é confiável?

Pessoas rotulam uma amostra aleatória cega das respostas do candidato, sem o veredito do juiz, e o mecanismo mede o juiz contra elas:

oloproof review CANDIDATE --criterion judge_correct --by you

Na sessão registrada, o juiz concordou em 77 de 79 casos rotulados (97.5%, limite inferior 91.2%) com um viés de -2.5 pontos, dentro dos limites padrão (concordância 0.70, viés 0.35), então foi validado e pode decidir. Nessa sessão os rótulos foram dados por um agente no lugar de um revisor, o que mostra o fluxo de trabalho e não é o julgamento de uma pessoa; quando você o executa, o revisor é você.

O candidato atinge o limite por si só?

release.yaml pede uma taxa de aprovação do juiz de pelo menos 80%:

oloproof gate CANDIDATE --policy release.yaml --config candidate.yaml

83.3% com um intervalo de 75.4% a 89.6% abrange 80%, então a regra é INSUFFICIENT_EVIDENCE, e o mecanismo diz que cerca de 592 casos a decidiriam. Um juiz confiável não torna claro um resultado apertado.

Ele é melhor do que a base?

compare.yaml faz duas perguntas. O candidato é melhor segundo o juiz, mantido apenas se as pessoas mostrarem que o juiz erra da mesma forma nos dois prompts (judge_bias_bar: 0.10)? E segundo os próprios rótulos das pessoas nas duas respostas aos mesmos casos (people_pass_diff, uma métrica human_difference), ele não fica mais de 10 pontos abaixo?

oloproof review CANDIDATE --against BASELINE --criterion judge_correct --by you --sample 40
oloproof compare CANDIDATE BASELINE --policy compare.yaml --config candidate.yaml

A revisão mostra as duas respostas como A e B, numa ordem definida por uma moeda, sem nomear as execuções. Na sessão registrada, a diferença do juiz foi de +0.8 pontos (-5.1 a +7.3): INSUFFICIENT_EVIDENCE, e cerca de 3,690 casos pareados seriam necessários para decidir. As pessoas aprovaram o candidato 36 vezes e a base 35 vezes em 40 pares: +2.5 pontos (-11.1 a +17.7), então "não pior que 10 pontos" também foi INSUFFICIENT_EVIDENCE. O gate bloqueou. A mudança era de estilo, as pontuações mal a notaram, e 120 casos não distinguem uma mudança de 1 ponto de nenhuma.

Por que ele falha onde falha?

oloproof diagnose CANDIDATE --intervention gold-context --criterion answer_correct --config candidate.yaml

O mecanismo reexecutou as 21 falhas entregando ao modelo a passagem certa, e de novo sem ela como controle. O controle não recuperou nenhuma; a passagem certa recuperou 14: 7 em que a recuperação nunca encontrou a passagem, 7 em que ela foi encontrada mas ficou abaixo das 3 primeiras, e 7 que falharam mesmo assim. Ele propôs um top_k maior como hipótese e depois o testou nos mesmos casos:

oloproof diagnose CANDIDATE --intervention top-k --top-k 8 --criterion answer_correct --config candidate.yaml

Todos os 7 casos fora do ranking foram recuperados, com um controle que não recuperou nenhum.

O passo seguinte

followup.yaml é o candidato com top_k: 8, uma nova versão do sistema executada por completo:

oloproof run --config followup.yaml --policy release.yaml
oloproof compare FOLLOWUP CANDIDATE --policy followup_compare.yaml --config followup.yaml

Sua taxa de aprovação do juiz foi de 90.0% (83.1% a 94.8%), então o piso de 80% deu PASS. Contra o candidato, mais respostas certas (+3.3 pontos) ainda foi INSUFFICIENT_EVIDENCE, e a taxa de aprovação do juiz não pior em mais de 5 pontos foi PASS. O juiz foi verificado nas respostas do candidato, não nas do passo seguinte, e ninguém rotulou um par do passo seguinte, então a diferença das pessoas ali não decide nada.

O que isto não pode dizer

Um pequeno bot, uma mudança, 120 casos e modelos locais. Mostra como o mecanismo chega a cada decisão numa mudança real; não diz nada sobre outro sistema. Uma amostra local é de boa-fé: só uma amostra sorteada por um workspace é verificada lá. O registro completo, com cada id de execução, é docs/audits/DOGFOOD_LARKSPUR_2026-10-26.md. Veja Juízes, Regras de comparação, Avaliação de RAG e Limites.