Un cambio, de principio a fin

Su puntuación subió después de un cambio. Esta página sigue un cambio real a través de cada pregunta que Oloproof hace antes de dejar que ese cambio se publique: si el juez es fiable, si el cambio alcanza el umbral por sí solo, si es mejor que lo que reemplaza según el juez y según personas, y qué probar después. El sistema es un pequeño bot de soporte que responde a partir de 40 documentos, ejecutado en su máquina con modelos locales; cada número de abajo es lo que imprimió el motor. Cópielo de examples/one_change y ejecute REVIEWER=yourname ./run_demo.sh.

El cambio

El prompt de referencia le dice al bot que conserve las cifras, los nombres y las unidades exactos. El candidato pide una o dos frases cálidas y naturales. Ambos se ejecutan sobre las mismas 120 preguntas, con una comprobación determinista (answer_correct: ¿contiene la respuesta el hecho esperado?) y un juez de modelo local (judge_correct: ¿responde con el mismo hecho?):

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

Las respuestas correctas pasaron de 80.0% a 82.5%, la tasa de aprobación del juez de 82.5% a 83.3%. Esa es la mejora aparente. Ninguna de las dos ejecuciones decide nada todavía: la regla de release lee al juez, y el juez no ha sido comprobado, así que la regla dice INSUFFICIENT_EVIDENCE con evaluator_not_validated.

¿Se puede confiar en el juez?

Personas etiquetan una muestra aleatoria a ciegas de las respuestas del candidato, sin el veredicto del juez, y el motor mide al juez frente a ellas:

oloproof review CANDIDATE --criterion judge_correct --by you

En la sesión grabada el juez coincidió en 77 de 79 casos etiquetados (97.5%, extremo inferior 91.2%) con un sesgo de -2.5 puntos, dentro de los umbrales por defecto (acuerdo 0.70, sesgo 0.35), así que fue validado y puede decidir. En esa sesión las etiquetas las dio un agente en lugar de un revisor, lo que muestra el flujo de trabajo y no es el juicio de una persona; cuando usted lo ejecute, usted es el revisor.

¿Alcanza el candidato el umbral por sí solo?

release.yaml pide una tasa de aprobación del juez de al menos 80%:

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

83.3% con un rango de 75.4% a 89.6% abarca 80%, así que la regla es INSUFFICIENT_EVIDENCE, y el motor dice que unos 592 casos la decidirían. Un juez fiable no vuelve claro un resultado ajustado.

¿Es mejor que la referencia?

compare.yaml hace dos preguntas. ¿Es el candidato mejor según el juez, válido solo si las personas muestran que el juez se equivoca igual con ambos prompts (judge_bias_bar: 0.10)? ¿Y según las propias etiquetas de las personas sobre ambas respuestas a los mismos casos (people_pass_diff, una métrica human_difference), no es peor por más de 10 puntos?

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

La revisión muestra ambas respuestas como A y B, en un orden fijado por una moneda, sin nombrar las ejecuciones. En la sesión grabada la diferencia del juez fue de +0.8 puntos (-5.1 a +7.3): INSUFFICIENT_EVIDENCE, y harían falta unos 3,690 casos emparejados para decidirla. Las personas aprobaron al candidato 36 veces y a la referencia 35 veces en 40 pares: +2.5 puntos (-11.1 a +17.7), así que «no peor por 10 puntos» también fue INSUFFICIENT_EVIDENCE. El gate bloqueó. El cambio era un cambio de estilo que las puntuaciones apenas notaron, y 120 casos no pueden distinguir un cambio de 1 punto de ninguno.

¿Por qué falla donde falla?

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

El motor volvió a ejecutar los 21 fallos dándole al modelo el pasaje correcto, y otra vez sin él como control. El control no recuperó ninguno; el pasaje correcto recuperó 14: 7 en los que la recuperación nunca encontró el pasaje, 7 en los que se encontró pero quedó por debajo de los 3 primeros, y 7 que fallaron de todos modos. Propuso un top_k más profundo como hipótesis y luego lo probó en los mismos casos:

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

Los 7 casos que quedaban fuera del ranking se recuperaron todos, con un control que no recuperó ninguno.

El seguimiento

followup.yaml es el candidato con top_k: 8, una nueva versión del sistema ejecutada completa:

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

Su tasa de aprobación del juez fue de 90.0% (83.1% a 94.8%), así que el mínimo de 80% fue PASS. Frente al candidato, más respuestas correctas (+3.3 puntos) siguió siendo INSUFFICIENT_EVIDENCE, y una tasa de aprobación del juez no peor por más de 5 puntos fue PASS. El juez se comprobó con las respuestas del candidato, no con las del seguimiento, y nadie etiquetó un par del seguimiento, así que la diferencia según las personas no decide nada allí.

Lo que esto no puede decirle

Un pequeño bot, un cambio, 120 casos y modelos locales. Muestra cómo el motor llega a cada decisión sobre un cambio real; no dice nada de otro sistema. Una muestra local es de buena fe: solo una muestra que extrae un workspace se comprueba allí. El registro completo, con cada id de ejecución, es docs/audits/DOGFOOD_LARKSPUR_2026-10-26.md. Vea Jueces, Reglas de comparación, Evaluación RAG y Límites.