Eén wijziging, van begin tot eind

Uw score ging omhoog na een wijziging. Deze pagina volgt één echte wijziging door elke vraag die Oloproof stelt voordat het die wijziging laat uitrollen: is de judge betrouwbaar, haalt de wijziging op zichzelf de lat, is ze beter dan wat ze vervangt volgens de judge en volgens mensen, en wat probeert u daarna. Het systeem is een kleine supportbot die antwoordt uit 40 documenten, gedraaid op uw machine met lokale modellen; elk getal hieronder is wat de engine afdrukte. Kopieer het uit examples/one_change en voer REVIEWER=yourname ./run_demo.sh uit.

De wijziging

De baselineprompt vraagt de bot de exacte cijfers, namen en eenheden te behouden. De kandidaat vraagt om één of twee warme, natuurlijke zinnen. Beide draaien op dezelfde 120 vragen, met een deterministische controle (answer_correct: bevat het antwoord het verwachte feit?) en een judge op een lokaal model (judge_correct: antwoordt het met hetzelfde feit?):

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

Juiste antwoorden gingen van 80.0% naar 82.5%, de slaagkans volgens de judge van 82.5% naar 83.3%. Dat is de schijnbare verbetering. Geen van beide runs beslist nog iets: de releaseregel leest de judge, en de judge is niet gecontroleerd, dus de regel zegt INSUFFICIENT_EVIDENCE met evaluator_not_validated.

Is de judge te vertrouwen?

Mensen labelen een blinde willekeurige steekproef van de antwoorden van de kandidaat, zonder het oordeel van de judge, en de engine meet de judge daartegen:

oloproof review CANDIDATE --criterion judge_correct --by you

In de vastgelegde sessie was de judge het eens op 77 van de 79 gelabelde cases (97.5%, ondergrens 91.2%) met een bias van -2.5 punten, binnen de standaardlatten (overeenstemming 0.70, bias 0.35), dus werd hij gevalideerd en mag hij beslissen. In die sessie werden de labels gegeven door een agent die een reviewer verving; dat toont de werkwijze en is geen oordeel van een mens. Wanneer u het draait, bent u de reviewer.

Haalt de kandidaat op zichzelf de lat?

release.yaml vraagt een slaagkans volgens de judge van minstens 80%:

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

83.3% met een bereik van 75.4% tot 89.6% overspant 80%, dus de regel is INSUFFICIENT_EVIDENCE, en de engine zegt dat ongeveer 592 cases het zouden beslissen. Een betrouwbare judge maakt een krappe uitslag niet duidelijk.

Is ze beter dan de baseline?

compare.yaml stelt twee vragen. Is de kandidaat beter volgens de judge, alleen behouden als mensen laten zien dat de judge zich op beide prompts gelijk vergist (judge_bias_bar: 0.10)? En is ze, volgens de eigen labels van mensen op beide antwoorden op dezelfde cases (people_pass_diff, een human_difference-metriek), niet meer dan 10 punten slechter?

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

De review toont beide antwoorden als A en B, in een volgorde bepaald door een munt, zonder de runs te noemen. In de vastgelegde sessie was het verschil volgens de judge +0.8 punten (-5.1 tot +7.3): INSUFFICIENT_EVIDENCE, en er zouden ongeveer 3,690 gepaarde cases nodig zijn om het te beslissen. Mensen keurden de kandidaat 36 keer en de baseline 35 keer goed in 40 paren: +2.5 punten (-11.1 tot +17.7), dus ook "niet meer dan 10 punten slechter" was INSUFFICIENT_EVIDENCE. De gate blokkeerde. De wijziging was een stijlwijziging die de scores nauwelijks merkten, en 120 cases kunnen een wijziging van 1 punt niet van geen wijziging onderscheiden.

Waarom faalt het waar het faalt?

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

De engine draaide de 21 mislukkingen opnieuw met de juiste passage aan het model gegeven, en nog eens zonder als controle. De controle herstelde er geen; de juiste passage herstelde er 14: 7 waarin retrieval de passage nooit vond, 7 waarin ze gevonden was maar onder de top 3 gerangschikt, en 7 die toch mislukten. Ze stelde een diepere top_k voor als hypothese en testte die daarna op dezelfde cases:

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

Alle 7 buiten de rangschikking gevallen cases herstelden, met een controle die er geen herstelde.

Het vervolg

followup.yaml is de kandidaat met top_k: 8, een nieuwe systeemversie die volledig gedraaid wordt:

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

De slaagkans volgens de judge was 90.0% (83.1% tot 94.8%), dus de ondergrens van 80% was PASS. Tegenover de kandidaat was meer juiste antwoorden (+3.3 punten) nog steeds INSUFFICIENT_EVIDENCE, en een slaagkans volgens de judge die niet meer dan 5 punten slechter is was PASS. De judge werd gecontroleerd op de antwoorden van de kandidaat, niet op die van het vervolg, en niemand labelde een paar van het vervolg, dus het verschil volgens mensen beslist daar niets.

Wat dit u niet kan vertellen

Eén kleine bot, één wijziging, 120 cases en lokale modellen. Het laat zien hoe de engine bij een echte wijziging tot elke beslissing komt; het zegt niets over een ander systeem. Een lokale steekproef is te goeder trouw: alleen een steekproef die een workspace trekt, wordt daar gecontroleerd. Het volledige verslag, met elke run-id, is docs/audits/DOGFOOD_LARKSPUR_2026-10-26.md. Zie Judges, Vergelijkingsregels, RAG-evaluatie en Wat een evaluatie je niet kan vertellen.