Guías

Una segunda opinión sobre las puntuaciones de otra herramienta

Su puntuación de evaluación subió. ¿Es real? ¿Y puede fiarse del juez que la midió? Si ya evalúa con otra herramienta, exporte sus resultados por caso antes y después de un cambio, y Oloproof responde ambas preguntas sobre ellos sin volver a ejecutar nada.

Qué lee

Un archivo por versión del sistema, CSV o JSON Lines, con una fila por caso y criterio:

Columna	Qué contiene
case_id	El id del caso. Dos archivos solo se emparejan en un id que ambos contienen
criterion	El nombre de la métrica, que se convierte en la métrica que nombra una regla
score	Un número en la escala de la métrica, o vacío si la herramienta no puntuó ese caso
passed	true o false en lugar de una puntuación, o vacío
score_min, score_max	La escala en la que está una puntuación (0 y 1 en la mayoría de las herramientas), obligatoria para una puntuación
judge, judge_version	El modelo que juzgó, si lo hizo un modelo. Opcional

No se lee nada más, y un archivo con cualquier otra columna se rechaza: un archivo contiene ids de casos y puntuaciones, nunca una pregunta, una respuesta ni ningún otro contenido. Las recetas de más abajo convierten los resultados de cada herramienta en este archivo.

Ejecutarlo

oloproof init --example second-opinion second-opinion
cd second-opinion

El ejemplo contiene dos exportaciones de la fidelidad de un asistente de soporte en 150 preguntas, antes y después de un cambio de prompt, tal como las puntuó el juez de otra herramienta: una puntuación de 0 a 1, y su aprobado o suspenso en 0.7. make_exports.py es la simulación que las escribió. La puntuación media subió alrededor de 0.02.

oloproof scores import before.csv after.csv --policy release.yaml

faithfulness: +0.023 [-0.024, +0.068] · 150 paired · 0 missing · 0 excluded
faithfulness_passed: +5.3 points [-6.9, +18.0] · 150 paired · 0 missing · 0 excluded
Decisions
  score-went-up  faithfulness  superiority  INSUFFICIENT_EVIDENCE  evaluator_not_validated
  more-answers-pass  faithfulness_passed  superiority  INSUFFICIENT_EVIDENCE  evaluator_not_validated
Gate: BLOCK (exit 3)
score-went-up, more-answers-pass: the judge (or model or custom evaluator) behind these rules has not been measured against people yet, so it may not decide.

Cada archivo se convirtió en una ejecución, y las dos ejecuciones se compararon caso por caso. La respuesta tiene dos mitades.

¿Es real? Todavía no. La puntuación subió 0.023, pero el intervalo va de 0.024 menos a 0.068 más: con 150 preguntas, un cambio tan pequeño no se puede distinguir del ruido. La proporción de respuestas que el juez aprueba subió 5.3 puntos, con un intervalo de 6.9 puntos menos a 18.0 más.
¿Puede fiarse del juez? Nadie lo ha comprobado. release.yaml solo permite que un juez decida una publicación una vez que las etiquetas de personas lo han medido (require_validated_evaluators: true), así que ambas reglas se detienen en evaluator_not_validated antes de llegar al intervalo.

Para ver la primera mitad sola, como si el juez se hubiera comprobado:

oloproof scores import before.csv after.csv --policy statistics-only.yaml

  score-went-up  faithfulness  superiority  INSUFFICIENT_EVIDENCE  interval_overlaps_zero
  more-answers-pass  faithfulness_passed  superiority  INSUFFICIENT_EVIDENCE  interval_overlaps_zero

En CI, añada --summary markdown >> "$GITHUB_STEP_SUMMARY": el pull request se abre entonces con «Is it real?» y una línea por regla, que dice «not established» y por qué, y el código de salida es el mismo. Las líneas propias de la importación van a la salida de error estándar, de modo que el resumen recibe solo la respuesta (CI).

Sin --policy, el comando informa la comparación y no decide nada. Con un solo archivo informa esa ejecución, y --policy la somete a un gate con las reglas de ejecución de la política.

Comprobar el juez

Unas personas etiquetan una muestra aleatoria de los casos de una ejecución importada, sin ver el veredicto del juez, y Oloproof mide el juez frente a ellas:

oloproof labels export RUN_ID --criterion faithfulness_passed --sample 60 --out sample.csv
oloproof labels import sample.csv
oloproof evaluators validate EVALUATOR_ID --by NAME

En la muestra aparece el id de cada caso y nada del veredicto del juez. Quien etiqueta lee el caso en la herramienta que lo contiene, por su id, y escribe pass o fail en passed. oloproof evaluators list da el id del evaluador. Una vez validado, las reglas que leen ese juez deciden solo con la evidencia.

Las etiquetas son aprobado o suspenso, así que comprueban el veredicto de aprobado o suspenso de un juez, no su puntuación. Importe el veredicto junto a la puntuación, como hace el ejemplo con faithfulness_passed: ese es el criterio que las personas pueden validar.

Desde su herramienta

La carpeta recipes/ del ejemplo contiene un script breve por herramienta. Cada uno lee los resultados de esa herramienta y escribe el archivo, conservando solo ids y puntuaciones. Ejecute uno por versión y luego importe los dos archivos.

Herramienta	Receta	Qué identifica un caso entre dos ejecuciones	Notas
DeepEval	deepeval_results.py RESULTS_JSON OUT	El name del caso de prueba	Guarde los resultados con DisplayConfig(results_folder=...) y ponga nombre a cada LLMTestCase. Cada métrica da su puntuación y su aprobado o suspenso como <metric>_passed, con el modelo juez
Braintrust	braintrust_experiment.py PROJECT EXPERIMENT OUT	El registro del conjunto de datos sobre el que se ejecutó el experimento (origin.id)	Puntuaciones de 0 a 1; --judge nombra el modelo si uno las juzgó todas
LangSmith	langsmith_experiment.py EXPERIMENT OUT --scale LOW HIGH	El ejemplo del conjunto de datos (reference_example_id)	Una puntuación verdadera o falsa se convierte en aprobado o suspenso; un número necesita su escala
Langfuse	langfuse_experiment.py EXPERIMENT SINCE OUT	El elemento del conjunto de datos (experiment_item_id)	Los experimentos de Langfuse 5; puntuaciones numéricas en el rango de su configuración de puntuación, o --scale

Las recetas siguen el SDK de cada herramienta tal como estaba publicado el 16 de octubre de 2026 (DeepEval 4.3.1, braintrust 0.46.1, langsmith 0.14.11, langfuse 5.0.2) y están probadas con resultados de esa forma, no contra una cuenta real. Una herramienta que cambia el nombre de un campo rompe su receta, no la importación: el archivo que escribe es el contrato.

Qué debe hacer bien un archivo

Un caso presente solo en un archivo falta en el otro lado, se cuenta y se acota en su peor valor; nunca se empareja con otro caso.
Una segunda fila para un mismo caso y criterio, una puntuación fuera de score_min y score_max, una fila con una puntuación y además un aprobado o suspenso, y un criterio que es una puntuación en un archivo y un aprobado o suspenso en el otro se rechazan, indicando la fila.
Los archivos comparados deben coincidir en la escala y el juez de cada criterio: las puntuaciones de dos jueces son dos instrumentos, y su diferencia se debería en parte a los instrumentos.
Cada archivo es una versión del sistema identificada por su contenido. Importar de nuevo el mismo archivo reutiliza lo que se almacenó; nunca se ejecuta nada, así que ninguna nueva ejecución puede reproducir ni cambiar una puntuación importada.
--tool registra de dónde vienen las puntuaciones, y --name nombra el sistema de cada archivo; ambos se guardan con la ejecución.

Qué no está construido

Leer directamente el formato de exportación propio de una herramienta: una receta lo convierte en el archivo descrito arriba.
Subir los archivos al sitio alojado sin instalar nada.
Validar las puntuaciones de un juez, a diferencia de sus veredictos de aprobado o suspenso.

Siguientes pasos

Comparar un candidato con una línea base: qué lee una comparación pareada.
Reglas de comparación: superioridad, no inferioridad y equivalencia.
Jueces: cómo se mide un juez frente a personas antes de que pueda actuar como gate.