Referencia de configuración

Cada campo de oloproof.yaml y de release.yaml, con su tipo, su valor por defecto, los valores que acepta y un ejemplo, tomados de los modelos que leen los archivos. Úsela para consultar un campo; lea las páginas de la guía rápida y de gates para aprender el flujo de trabajo.

Ambos archivos se validan antes de que se ejecute nada. Un campo desconocido, un campo mal escrito o un valor del tipo equivocado es un error de configuración, y el comando sale con 2 sin ejecutar ningún caso. Ambos archivos tienen JSON Schemas, que un editor capaz de leer JSON Schema puede usar para el autocompletado. El paquete instalado los escribe, junto con los esquemas de resultados, en schemas/v1/ bajo el directorio actual: python -m oloproof_core.models.schema_export (los dos son project_config.schema.json y release_policy.schema.json).

En las tablas de abajo, "obligatorio" significa que el archivo se rechaza sin el campo; cualquier otro campo muestra el valor que se usa cuando se omite.

oloproof.yaml de un vistazo

Un proyecto pequeño y completo. Ejecuta una función de Python en local, no necesita red ni claves, y es la forma que genera oloproof init.

# oloproof.yaml
version: 1
project: support-bot
dataset: datasets/support.jsonl
system:
  name: support-bot
  callable: app.bot:answer
evaluators:
  - type: exact_match
    criterion: correct_label
    field: label

Campos de nivel superior

concurrency

entradas de pricing

Oloproof no incluye ninguna tabla de precios. Cada entrada nombra un modelo exactamente como lo nombra el model: de un evaluador.

# oloproof.yaml
version: 1
project: support-bot
dataset: datasets/support.jsonl
system:
  name: support-bot
  callable: app.bot:answer
evaluators:
  - type: exact_match
    criterion: correct_label
    field: label
pricing:
  - model: my-judge-model
    input_per_mtok: 0.15
    output_per_mtok: 0.6
egress: [raw_outputs]

system

Un sistema necesita exactamente uno de callable, http o rag.

system.http

# oloproof.yaml
version: 1
project: support-api
dataset: datasets/support.jsonl
system:
  name: support-api
  version: "2026-10-08"
  http:
    url: http://localhost:8000/answer
    output_path: answer
    artifacts:
      retrieval/v1: debug.retrieval
evaluators:
  - type: hit_rate
    k: 5

El contrato de petición y respuesta, y lo que ocurre con los tiempos de espera agotados y los errores HTTP, están en Resultados y ejecución.

system.rag

Los ajustes indicados aquí sustituyen a los que declara la clase. Un sistema por etapas registra sus propios artefactos retrieval/v1, context/v1 y citations/v1, así que records se rechaza junto a él. Consulte RAG.

evaluators

Cada entrada toma un type y estos dos campos comunes:

fail solo se aplica a evaluadores de aprobado/fallo; un evaluador de puntuación con él es un error de configuración. on_execution_error es un campo de YAML; las clases de evaluador del SDK no toman ese argumento, y un caso con error cuenta como faltante.

Tipos de evaluador

"Lee" enumera aquello de lo que depende el veredicto del evaluador, que es también aquello por lo que se indexa su juicio en caché. "SDK" nombra la clase en oloproof.evaluators.

Un juez que llama a un modelo alojado envía el contenido de los casos a ese proveedor, que se lo factura. Las claves se leen de la variable de entorno nombrada en api_key_env; Oloproof nunca las guarda en estos archivos.

Evaluadores deterministas

Jueces modelo

rubric_judge, groundedness_judge y citation_support_judge comparten estos campos. rubric_judge exige exactamente uno de rubric_file o rubric_text; los dos jueces RAG toman como mucho uno y, si no, usan una rúbrica integrada. Su criterion vale por defecto groundedness y citation_support.

probability_judge plantea una pregunta tipada y lee las probabilidades del modelo:

cascade ejecuta primero un juez barato y escala los casos inciertos:

Las etapas juzgan el propio criterion de la cascada; una etapa que nombra otro se rechaza.

model_classifier puntúa texto con un modelo entrenado en un servidor compatible con TEI:

Evaluadores RAG

Evaluadores de agentes

Cada tipo de agente tiene un criterion por defecto, así que puede omitirse: el nombre de su propio tipo, o uno construido a partir de su ajuste (agent_steps_le_8, agent_tool_lookup_called, agent_handoffs_le_2). Consulte Agentes.

Evaluadores predictivos

Un evaluador predictivo que no escribe positive, field o expected_field lo toma del bloque predictive:; un valor que sí escribe se conserva.

predictive

metrics

Cada criterio de evaluador ya es una métrica. Una entrada de metrics: añade una más, distinguida por type.

# oloproof.yaml
version: 1
project: support-bot
dataset: datasets/support.jsonl
system:
  name: support-bot
  callable: app.bot:answer
evaluators:
  - type: exact_match
    criterion: correct_label
    field: label
metrics:
  - id: latency_p95
    type: quantile
    source: latency_ms
    quantile: 0.95

release.yaml

La política de publicación: qué reglas deciden, y qué decisiones bloquean. Los ajustes omitidos conservan sus valores por defecto, así que una política que solo nombra sus reglas sigue bloqueando con FAIL, INSUFFICIENT_EVIDENCE y MANUAL_REVIEW.

# release.yaml
version: 1
rules:
  - id: label_accuracy
    metric: correct_label
    min: 0.8

rules

Una sola lista contiene ambos tipos. Una regla de ejecución toma exactamente uno de min, max o max_failures. Una regla de comparación nombra su kind y decide una diferencia entre dos ejecuciones; consulte Reglas de comparación.

families

# release.yaml
version: 1
warn_on: [INSUFFICIENT_EVIDENCE]
block_on: [FAIL, MANUAL_REVIEW]
rules:
  - id: label_accuracy
    metric: correct_label
    min: 0.8
    max_missing_fraction: 0.05
  - id: no_regression
    metric: correct_label
    kind: non_inferiority
    margin: 0.02

Tipos de artefacto

Un artefacto es un registro tipado que un sistema escribe junto a su salida, como lo que recuperó. Un tipo es un nombre en minúsculas con una versión opcional, que coincide con ^[a-z][a-z0-9_]*(/v[1-9][0-9]*)?$. Los evaluadores que necesitan un artefacto lo nombran, y una ejecución cuyo sistema no declara un tipo requerido se rechaza antes de empezar, en lugar de contar todos los casos como faltantes.

Un sistema callable declara los tipos que registra en records: (o @system(records=...)); un sistema HTTP, en http.artifacts; un sistema RAG por etapas registra los suyos propios.

Versiones, claves de caché e invalidación

Oloproof reutiliza el trabajo cuyas entradas no han cambiado, y decide qué significa "sin cambios" a partir de digests de contenido. Cada uno lo calcula el motor y se registra con la ejecución.

Lo que Oloproof no puede ver le corresponde a usted declararlo:

• El comportamiento de un sistema HTTP está en el servidor. Cambie system.version cada vez que cambie lo que hay detrás de la URL, o una salida antigua en caché representará al sistema nuevo.
• Los módulos auxiliares de un callable solo entran en el hash cuando code_paths coincide con ellos. Sin él, editar un auxiliar no cambia la versión.
• Un método o un objeto callable debe declarar una versión, y la versión debe cambiar cuando cambia el estado del objeto.
• Un índice RAG se identifica por index_version; cámbiela cuando se reconstruya el índice.
• La identidad de un juez modelo son sus ajustes, no los pesos del proveedor. La caché no detecta que un proveedor actualice el modelo detrás del mismo nombre.
• Un @evaluator personalizado calcula el hash del archivo de módulo que lo define, y sus juicios solo se reutilizan entre ejecuciones cuando declara cacheable=True. Los jueces de rúbrica integrados se pueden almacenar en caché; los evaluadores deterministas se recalculan, lo cual es barato.

El trabajo en caché vive en el almacén local del proyecto, .oloproof/store.sqlite junto a oloproof.yaml (o bajo OLOPROOF_HOME). Borrar el almacén descarta todas las cachés y todas las ejecuciones. En un espacio de trabajo alojado, el motor no reutiliza ejecuciones, juicios ni análisis en caché, porque un push puede escribirlos; los vuelve a calcular.