Errores

La distinción por la que existe esta página: una ejecución que falló y una ejecución que tuvo un error son cosas distintas, y presentar una como la otra le dice a un desarrollador que su cambio es malo cuando la verdad es que el harness se cayó.

Un fallo es un resultado. Un error no.

FAIL significa que se evaluó un gate y que la evidencia quedó por debajo del umbral. Es un resultado de calidad sobre el cambio.

RUN_ERROR significa que la ejecución no terminó. No se evaluó ningún gate y no se ha medido nada sobre el cambio. No es un estado de decisión, y tampoco lo son PARTIAL ni CANCELLED: describen lo que le ocurrió a una ejecución, no lo que se decidió sobre un sistema.

Lo que informa una ejecución incompleta

Un gate sobre una ejecución incompleta termina con 5, no con 1. La evidencia falta, no es mala, y ambas situaciones requieren respuestas distintas: un gate que falla pide revisar el cambio; uno incompleto pide revisar la infraestructura.

Casos que no se pudieron medir

Un caso con error se acota, no se descarta. Cada métrica registra cuatro conteos (total, elegibles, observados y faltantes) y el intervalo tiene en cuenta los casos que no pudo ver.

Esto importa más de lo que parece. Una métrica que cuenta como cero un caso sin calificar atribuye las caídas del propio sistema al modelo como fallos de calidad, y un denominador que se reduce sin avisar cuando un sistema empieza a fallar es la manera en que un sistema que falla informa una puntuación en alza. Ambas cosas se observaron en un asistente en vivo, donde el 13,8% de las llamadas devolvió HTTP 500.

Fallos transitorios

Un sistema puede declarar que un fallo fue transitorio, y un fallo transitorio se reintenta en lugar de registrarse como resultado de calidad. Un timeout del proveedor no es evidencia sobre un prompt.

La declaración es explícita: un sistema invocable lanza TransientError con retryable=True. retryable vale False por defecto, y un TransientError sin él se registra en el caso como cualquier otra excepción, así que el caso queda faltante en lugar de reintentarse. Un sistema HTTP y un proveedor de juez no necesitan declaración: para ellos se reintenta un timeout, una conexión perdida, un 429 o un 5xx. En cualquier caso, una llamada se intenta como máximo cuatro veces, con backoff, y un caso que sigue fallando queda faltante. Progreso y concurrencia muestra ambos.

Errores de configuración

El código de salida 2 significa que la invocación o la configuración era incorrecta y que no se ejecutó nada. Un rechazo por cuota es uno de ellos: es un error de configuración con un motivo explícito, rechazado antes de que se ejecute el primer caso, y nunca es un estado de decisión. Un hecho comercial no debe llegar disfrazado de veredicto de calidad.

Diagnosticar lo que sí falló

oloproof diagnose RUN_ID --intervention gold-context --criterion answer_correct

La intervención es aquello bajo lo que se vuelven a ejecutar los casos fallidos (gold-context, top-k o reranker), y el criterio indica de qué evaluador se toman los fallos. Un diagnóstico informa factores de fallo con conteos, los ids de escenario que los respaldan y los supuestos que hizo. Nombra un factor, no una causa: el motor no afirma que una cosa produjo otra, y tampoco lo hace ninguna pantalla que lo muestre.

Siguientes pasos

• Conceptos básicos cubre los estados de decisión y los denominadores.
• Gates en CI enumera todos los códigos de salida.
• Evaluación RAG recorre un diagnóstico de principio a fin.