Un changement, de bout en bout

Votre score a augmenté après un changement. Cette page suit un vrai changement à travers chaque question qu'Oloproof pose avant de le laisser partir en production : le juge est-il digne de confiance, le changement atteint-il le seuil à lui seul, est-il meilleur que ce qu'il remplace selon le juge et selon des personnes, et que tenter ensuite. Le système est un petit bot de support qui répond à partir de 40 documents, exécuté sur votre machine avec des modèles locaux ; chaque nombre ci-dessous est celui que le moteur a affiché. Copiez-le depuis examples/one_change et lancez REVIEWER=yourname ./run_demo.sh.

Le changement

Le prompt de référence demande au bot de garder les chiffres, les noms et les unités exacts. Le candidat demande une ou deux phrases chaleureuses et naturelles. Les deux sont exécutés sur les mêmes 120 questions, avec une vérification déterministe (answer_correct : la réponse contient-elle le fait attendu) et un juge par modèle local (judge_correct : répond-elle avec le même fait) :

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

Les réponses justes sont passées de 80.0% à 82.5%, le taux de réussite du juge de 82.5% à 83.3%. Voilà l'amélioration apparente. Aucune des deux exécutions ne décide encore quoi que ce soit : la règle de release lit le juge, et le juge n'a pas été vérifié, donc la règle dit INSUFFICIENT_EVIDENCE avec evaluator_not_validated.

Peut-on faire confiance au juge ?

Des personnes étiquettent un échantillon aléatoire à l'aveugle des réponses du candidat, sans le verdict du juge, et le moteur mesure le juge par rapport à elles :

oloproof review CANDIDATE --criterion judge_correct --by you

Dans la session enregistrée, le juge était d'accord sur 77 des 79 cas étiquetés (97.5%, borne basse 91.2%) avec un biais de -2.5 points, à l'intérieur des seuils par défaut (accord 0.70, biais 0.35) ; il a donc été validé et peut décider. Dans cette session, les étiquettes ont été données par un agent tenant le rôle d'un relecteur, ce qui montre le déroulement et n'est pas le jugement d'une personne ; quand vous le lancez, c'est vous le relecteur.

Le candidat atteint-il le seuil à lui seul ?

release.yaml demande un taux de réussite du juge d'au moins 80% :

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

83.3% avec un intervalle de 75.4% à 89.6% chevauche 80%, donc la règle est INSUFFICIENT_EVIDENCE, et le moteur indique qu'environ 592 cas la trancheraient. Un juge fiable ne rend pas clair un résultat serré.

Est-il meilleur que la référence ?

compare.yaml pose deux questions. Le candidat est-il meilleur selon le juge, retenu seulement si des personnes montrent que le juge se trompe de la même façon sur les deux prompts (judge_bias_bar: 0.10) ? Et selon les propres étiquettes des personnes sur les deux réponses aux mêmes cas (people_pass_diff, une métrique human_difference), n'est-il pas pire de plus de 10 points ?

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

La relecture montre les deux réponses comme A et B, dans un ordre tiré à pile ou face, sans nommer les exécutions. Dans la session enregistrée, la différence du juge était de +0.8 point (-5.1 à +7.3) : INSUFFICIENT_EVIDENCE, et environ 3,690 cas appariés seraient nécessaires pour trancher. Les personnes ont validé le candidat 36 fois et la référence 35 fois sur 40 paires : +2.5 points (-11.1 à +17.7), donc « pas pire de 10 points » était aussi INSUFFICIENT_EVIDENCE. Le gate a bloqué. Le changement était un changement de style que les scores ont à peine remarqué, et 120 cas ne peuvent pas distinguer un changement de 1 point d'aucun changement.

Pourquoi échoue-t-il là où il échoue ?

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

Le moteur a relancé les 21 échecs en donnant au modèle le bon passage, et de nouveau sans lui comme contrôle. Le contrôle n'en a récupéré aucun ; le bon passage en a récupéré 14 : 7 où la recherche n'a jamais trouvé le passage, 7 où il a été trouvé mais classé sous les 3 premiers, et 7 qui ont échoué quand même. Il a proposé un top_k plus profond comme hypothèse, puis l'a testé sur les mêmes cas :

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

Les 7 cas classés trop bas ont tous été récupérés, avec un contrôle qui n'en a récupéré aucun.

La suite

followup.yaml est le candidat avec top_k: 8, une nouvelle version du système exécutée en entier :

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

Son taux de réussite du juge était de 90.0% (83.1% à 94.8%), donc le plancher de 80% était PASS. Face au candidat, plus de réponses justes (+3.3 points) restait INSUFFICIENT_EVIDENCE, et un taux de réussite du juge pas pire de plus de 5 points était PASS. Le juge a été vérifié sur les réponses du candidat, pas sur celles de la suite, et personne n'a étiqueté de paire de la suite, donc la différence selon les personnes n'y décide rien.

Ce que cela ne peut pas vous dire

Un petit bot, un changement, 120 cas et des modèles locaux. Cela montre comment le moteur atteint chaque décision sur un vrai changement ; cela ne dit rien d'un autre système. Un échantillon local est de bonne foi : seul un échantillon tiré par un workspace y est vérifié. Le dossier complet, avec chaque identifiant d'exécution, est docs/audits/DOGFOOD_LARKSPUR_2026-10-26.md. Voir Juges, Règles de comparaison, Évaluation RAG et Limites.