Guías

Referencia de resultados y ejecución

Lo que una ejecución envía a un sistema HTTP y espera de vuelta, cómo entra cada caso en el denominador de una métrica, los estados de decisión y los códigos de motivo que los explican, los códigos de salida, y qué datos se quedan en local o pasan a un espacio de trabajo alojado. Para las ideas que hay detrás, lea Conceptos; para los campos de la política, lea la Referencia de configuración.

El contrato del sistema HTTP

Un sistema HTTP (system.http en oloproof.yaml) se llama una vez por caso, y una vez por réplica.

Aspecto	Comportamiento
Petición	POST por defecto (se aceptan GET y PUT). El cuerpo es el valor input del caso como JSON.
Cabeceras y autenticación	No se puede configurar ninguna. La petición lleva solo los valores por defecto del cliente HTTP. Un endpoint que necesita una clave debe estar detrás de un sistema callable de Python que la añada.
Respuesta	Debe ser JSON. output_path selecciona la salida mediante una ruta con puntos, como result.answer; sin él, la salida es el cuerpo entero. Un campo output_path ausente se registra como un error de ejecución de ese caso.
Artefactos	Cada entrada de http.artifacts lee una ruta con puntos de la respuesta. Un campo declarado que falta en una respuesta es un error de contrato, y la ejecución se detiene con salida 2.
Tiempo de espera	http.timeout_s por petición, 30 segundos por defecto.
Reintentos	Los tiempos de espera agotados, los fallos de conexión y las respuestas HTTP 408, 429 y 5xx se reintentan, hasta cuatro intentos en total, con un retroceso exponencial con jitter que respeta Retry-After. Las demás respuestas 4xx no se reintentan.
Tras el último intento	La ejecución del caso se registra como un error y el caso cuenta como faltante (o como fallido, con on_execution_error: fail). La ejecución continúa.
Concurrencia	Como máximo concurrency.system peticiones en curso, 8 por defecto.

La URL, el método, la ruta de salida y el mapeo de artefactos entran en la versión del sistema, pero lo que hace el servidor no. Cambie system.version siempre que cambie el comportamiento del servidor; consulte la Referencia de configuración para saber por qué.

Tres vocabularios distintos

Un resultado tiene tres tipos de estado, y ninguno sustituye nunca a otro.

Tipo	Valores	Responde a
Estado de decisión	PASS, FAIL, INSUFFICIENT_EVIDENCE, MANUAL_REVIEW	Lo que dice la evidencia sobre una regla.
Estado de ejecución	Estado de la ejecución RUN_ERROR o CANCELLED; completitud de la ejecución PARTIAL; ejecución del caso ERROR o TIMEOUT	Lo que le ocurrió a la ejecución o a la llamada de un caso. No es un resultado de calidad.
Acción de publicación	ALLOW, WARN, BLOCK	Lo que su política hace con cada decisión: los estados de block_on bloquean, los de warn_on avisan, los demás permiten.

Una ejecución que termina con normalidad es DECIDED, o DECIDED_EARLY cuando la terminó la parada temprana. Una ejecución interrumpida con Ctrl-C o por la cancelación de la tarea es CANCELLED; una cuyo arnés lanzó una excepción es RUN_ERROR. Cualquiera de las dos deja la ejecución en PARTIAL, conserva los casos que terminaron y permite que la siguiente ejecución reutilice sus registros en caché. Consulte Errores.

Para un umbral mínimo T y un intervalo [L, U], una regla es PASS cuando L >= T, FAIL cuando U < T, e INSUFFICIENT_EVIDENCE en otro caso. Un umbral máximo es simétrico. Antes de leer el intervalo, una regla comprueba si debe decidir siquiera: primero los motivos de MANUAL_REVIEW, después los de INSUFFICIENT_EVIDENCE. El primer nivel con un motivo decide, y enumera todos los motivos que encontró.

Códigos de motivo

Cada decisión lleva uno o más códigos de motivo.

MANUAL_REVIEW

Código	Significado
policy_requires_review	La regla fija requires_manual_review: true.
unsupported_method	No existe ningún intervalo admitido para esta métrica en esta situación. Véase más abajo.
unsupported_dependence_structure	La suite declara clústeres (group_id) y ningún método admitido los trata para esta métrica.
approximate_method_not_permitted	El único intervalo es aproximado, y la política no fija allow_approximate_methods: true.
evaluator_retired	Un evaluador detrás de la métrica se retiró.

INSUFFICIENT_EVIDENCE

Código	Significado
no_observations	No se observó ningún caso para esta métrica.
missingness_exceeds_policy	Faltan más casos elegibles de los que permite el max_missing_fraction de la regla.
missingness_unbounded	El método descarta los casos faltantes en lugar de acotarlos, y la regla no declara ningún max_missing_fraction.
evaluator_not_validated	Un juez modelo detrás de la métrica no se ha validado frente a etiquetas humanas, y require_validated_evaluators está activado (por defecto).
evaluator_recalibration_required	El juez se validó sobre un modelo servido del que no proceden los veredictos de esta ejecución.
interval_unavailable	La métrica no tiene ningún intervalo que leer.
insufficient_clusters	Menos clústeres que el min_clusters de la política.
interval_monte_carlo_uncertain	El umbral cae dentro de la incertidumbre de simulación de un límite por clústeres.
interval_overlaps_threshold	El intervalo contiene el umbral. Más casos lo estrecharían.
interval_unbounded	El intervalo no tiene límite en el lado que lee la regla.
missing_could_change_outcome	Una regla observed_count: los casos faltantes podrían llevar los fallos por encima de max_failures.
interval_overlaps_zero, interval_overlaps_margin, interval_overlaps_margins	Una comparación cuyo intervalo de la diferencia abarca el cero o un margen.
insufficient_support	Una regla de comparación por segmento cuyo segmento tiene menos casos que su min_support.
family_correction_withheld	Una regla de una entrada families: en la que la corrección de Holm se detuvo antes de llegar a ella.

PASS y FAIL

Código	Estado
lower_bound_meets_minimum, upper_bound_meets_maximum	PASS
upper_bound_below_minimum, lower_bound_above_maximum	FAIL
observed_failures_within_limit	PASS
observed_failures_exceed_limit	FAIL
difference_above_zero, lower_bound_above_margin, interval_within_margins	PASS (comparación)
difference_below_zero, upper_bound_below_margin, interval_outside_margins	FAIL (comparación)
cost_ceiling_exceeded	Se indica junto al estado de una regla de coste cuyo techo declarado superó una ejecución registrada

Solo en el espacio de trabajo alojado

Un espacio de trabajo que decide él mismo una ejecución enviada puede retener una decisión con ppi_not_verified (no verificó el intervalo en el que se apoya la decisión), execution_not_verified (las salidas no proceden de un runner registrado) o workspace_cannot_decide (no tiene copia de la política, o no pudo leer la evidencia). Consulte Gates.

Cómo entra cada caso en el denominador

Cada métrica informa de cuatro conteos: n_total (casos de la suite), n_eligible, n_observed y n_missing, con n_eligible = n_observed + n_missing. Los casos fuera de n_eligible se enumeran en exclusions con un motivo.

Lo que le ocurrió al caso	Cuenta como	En el denominador
El evaluador devolvió aprobado o fallo	observado, éxito o fallo	sí
El evaluador se declaró no aplicable (por ejemplo, sin valor esperado con el que comparar)	excluido, con el motivo	no
La llamada al sistema dio error o agotó el tiempo	faltante, o fallo con on_execution_error: fail	sí
El evaluador lanzó una excepción, o no se pudo leer la respuesta de un juez	faltante	sí
El caso nunca se ejecutó porque la ejecución se interrumpió	faltante, y la ejecución es PARTIAL	sí

Un caso faltante se acota, no se descarta. Para una tasa de aprobados, el límite inferior del intervalo trata cada caso faltante como un fallo y su límite superior como un éxito, así que una ejecución con muchos casos faltantes tiene un intervalo ancho que no puede superar una regla exigente; una media acotada sustituye de la misma manera los extremos de su rango declarado. Un método que no puede acotar los casos faltantes (un estadístico de ranking, por ejemplo) los descarta y registra el supuesto, y una regla sobre él indica missingness_unbounded hasta que declare max_missing_fraction.

Una regla observed_count cuenta los fallos sobre la suite ejecutada y no lee ningún intervalo. Solo aprueba cuando los fallos observados más todos los casos faltantes siguen cabiendo dentro de max_failures.

Métricas sin intervalo admitido

Una regla solo decide sobre un intervalo cuyo método ha sido admitido por auditoría. Donde no existe ninguno, la métrica se sigue calculando y mostrando, y una regla sobre ella no toma prestado un método no validado:

Situación	Lo que indica una regla sobre ella
Una métrica de puntuación (media) sin rango declarado, como un evaluador de puntuación personalizado sin score_range	MANUAL_REVIEW, unsupported_method
Una métrica de media, cuantil, ranking o coste en una suite que declara group_id	MANUAL_REVIEW, unsupported_dependence_structure
Una tasa de aprobados en una suite agrupada	un intervalo aproximado: MANUAL_REVIEW salvo con allow_approximate_methods: true, y entonces las comprobaciones de clústeres de arriba
Una métrica de cuantil o ranking con replicates por encima de 1	MANUAL_REVIEW, unsupported_method
Cualquier métrica en una suite con group_id y réplicas a la vez	MANUAL_REVIEW, unsupported_dependence_structure
Una comparación en una suite agrupada	MANUAL_REVIEW
Un segmento por debajo de min_slice_support	sin intervalo, pero los segmentos nunca llegan al gate
Métricas human_score, human_preference o cost_per_accepted	rechazadas al leer el archivo, salida 2

Códigos de salida

oloproof gate, oloproof run con una política, y los demás comandos que deciden usan todos los mismos códigos.

Código	Significado
0	Nada sobre lo que la política bloquea: todas las reglas aprobaron, o las que no lo hicieron están fuera de block_on.
1	Una regla de block_on falló.
2	La configuración o la invocación eran incorrectas, o un sistema incumplió su contrato; no se decidió nada.
3	Una regla de block_on indicó INSUFFICIENT_EVIDENCE.
4	Una regla de block_on indicó MANUAL_REVIEW.
5	La ejecución no se completó y block_on_partial_run está activado (por defecto).

Cuando se aplican varios, el código que se informa es el primero de 1, 5, 4, 3. Un estado que se deja fuera de block_on no puede cambiar el código de salida: con block_on: [FAIL] y warn_on: [INSUFFICIENT_EVIDENCE], una regla sin decidir avisa y el gate sale con 0. Por tanto, la salida 0 solo significa que no ocurrió nada sobre lo que su política bloquea, no que todas las reglas aprobaran. Consulte Gates.

Dónde se ejecuta el trabajo y adónde van los datos

En local, por defecto

oloproof run, oloproof gate y el SDK se ejecutan en su máquina. Cada registro (casos, salidas, artefactos, juicios, métricas y decisiones) se escribe en .oloproof/store.sqlite junto a oloproof.yaml, o bajo OLOPROOF_HOME cuando está definido. No se envía nada a Oloproof. El único tráfico de red es el que provoca su configuración: llamadas a la URL de su sistema HTTP, y llamadas que un juez modelo o un clasificador modelo hacen a su proveedor, que recibe el contenido de los casos que juzga y se lo factura a usted.

Enviar a un espacio de trabajo alojado

oloproof push envía la evidencia de una ejecución al espacio de trabajo que conectó con oloproof login. Por defecto envía métricas, intervalos, decisiones y segmentos agregados, y la identidad, el estado, los tiempos y el uso de cada registro, pero no su contenido. El contenido en bruto se redacta campo por campo antes de que nada salga de la máquina, y un registro redactado indica qué categorías se retuvieron. Una categoría solo se envía cuando egress: en oloproof.yaml la incluye:

Categoría	Lo que abarca
raw_inputs	Entradas de los escenarios, valores esperados y metadatos de los casos: las filas del conjunto de datos
raw_outputs	Lo que el sistema evaluado devolvió para cada caso
judge_rationales	El texto que escribió un juez para explicar un veredicto, que cita la salida
artifacts	El contexto de recuperación, las citas y las trayectorias registradas durante una ejecución
error_detail	Mensajes y detalles de excepciones, que a menudo llevan la entrada literal
system_config	La configuración declarada del sistema evaluado y de sus evaluadores
label_notes	La nota que una persona escribió junto a una etiqueta, que a menudo cita la salida
span_names	Nombres de trazas, spans, herramientas y agentes que registró una instrumentación

Los digests de los registros no se recalculan tras la redacción, así que un registro alojado sigue nombrando la evidencia original, que se queda en su máquina. La redacción no es cifrado, y una métrica sobre un segmento muy pequeño todavía puede identificar los casos que hay detrás.

Cuando los revisores etiquetan casos en la cola de revisión alojada, su navegador obtiene el contenido de los casos de oloproof collect, que se ejecuta de su lado; no pasa por el espacio de trabajo. Las claves de proveedor que usa un espacio de trabajo se guardan con oloproof credentials set, y oloproof credentials list muestra sus nombres, nunca sus valores. Un trabajo gestionado se ejecuta en un worker que opera Oloproof, que no ejecuta su código Python; oloproof job informa de su resultado y sale según su gate.

En un espacio de trabajo alojado, el motor nunca reutiliza ejecuciones, juicios ni análisis en caché, porque un push puede escribir en esas cachés; los vuelve a calcular.