Référence de configuration

Chaque champ de oloproof.yaml et de release.yaml, avec son type, sa valeur par défaut, les valeurs qu’il accepte et un exemple, tirés des modèles qui lisent les fichiers. Servez-vous-en pour retrouver un champ ; lisez les pages démarrage rapide et porte de CI pour apprendre la démarche.

Les deux fichiers sont validés avant toute exécution. Un champ inconnu, un champ mal orthographié ou une valeur du mauvais type est une erreur de configuration, et la commande sort avec le code 2 sans exécuter aucun cas. Les deux fichiers ont des schémas JSON, qu’un éditeur capable de lire JSON Schema peut utiliser pour la complétion. Le paquet installé les écrit, avec les schémas de résultats, dans schemas/v1/ sous le répertoire courant : python -m oloproof_core.models.schema_export (les deux sont project_config.schema.json et release_policy.schema.json).

Dans les tableaux ci-dessous, « obligatoire » signifie que le fichier est refusé sans le champ ; tout autre champ indique la valeur utilisée quand il est omis.

oloproof.yaml en un coup d’œil

Un petit projet complet. Il exécute une fonction Python en local, ne demande ni réseau ni clé, et a la forme que génère 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

Champs de premier niveau

concurrency

Entrées de pricing

Oloproof ne livre aucune table de prix. Chaque entrée nomme un modèle exactement comme le nomme le model: d’un évaluateur.

# 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 système demande exactement un de callable, http ou 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

Le contrat de requête et de réponse, et ce qui se passe en cas de délai dépassé et d’erreur HTTP, se trouvent dans Résultats et exécution.

system.rag

Les réglages donnés ici remplacent ceux que déclare la classe. Un système par étapes enregistre lui-même ses artefacts retrieval/v1, context/v1 et citations/v1, si bien que records est refusé à côté de lui. Voyez Évaluation RAG.

evaluators

Chaque entrée prend un type et ces deux champs communs :

fail ne s’applique qu’aux évaluateurs réussite/échec ; un évaluateur de score avec ce réglage est une erreur de configuration. on_execution_error est un champ YAML ; les classes d’évaluateurs du SDK ne prennent pas un tel argument, et un cas en erreur compte comme manquant.

Types d’évaluateurs

« Lit » liste ce dont dépend le verdict de l’évaluateur, qui est aussi ce sur quoi son jugement en cache est indexé. « SDK » nomme la classe dans oloproof.evaluators.

Un juge qui appelle un modèle hébergé envoie le contenu des cas à ce fournisseur et est facturé par lui. Les clés sont lues dans la variable d’environnement nommée dans api_key_env ; Oloproof ne les stocke jamais dans ces fichiers.

Évaluateurs déterministes

Juges modèles

rubric_judge, groundedness_judge et citation_support_judge partagent ces champs. rubric_judge exige exactement un de rubric_file ou rubric_text ; les deux juges RAG en prennent au plus un et utilisent sinon une grille intégrée. Leur criterion vaut par défaut groundedness et citation_support.

probability_judge pose une question typée et lit les probabilités du modèle :

cascade exécute d’abord un juge bon marché et fait remonter les cas incertains :

Les étapes jugent le criterion propre à la cascade ; une étape qui en nomme un autre est refusée.

model_classifier note du texte avec un modèle entraîné sur un serveur compatible TEI :

Évaluateurs RAG

Évaluateurs d’agents

Chaque type d’agent a un criterion par défaut, si bien qu’on peut l’omettre : son propre nom de type, ou un nom construit à partir de son réglage (agent_steps_le_8, agent_tool_lookup_called, agent_handoffs_le_2). Voyez Agents et outils.

Évaluateurs prédictifs

Un évaluateur prédictif qui n’écrit pas positive, field ou expected_field le prend dans le bloc predictive: ; une valeur qu’il écrit est conservée.

predictive

metrics

Chaque critère d’évaluateur est déjà une métrique. Une entrée metrics: en ajoute une de plus, distinguée par 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 politique de publication : quelles règles décident, et quelles décisions bloquent. Les réglages omis gardent leurs valeurs par défaut, si bien qu’une politique qui ne nomme que ses règles bloque quand même sur FAIL, INSUFFICIENT_EVIDENCE et MANUAL_REVIEW.

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

rules

Une seule liste contient les deux sortes. Une règle d’exécution prend exactement un de min, max ou max_failures. Une règle de comparaison nomme son kind et décide une différence entre deux exécutions ; voyez Règles de comparaison.

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

Sortes d’artefacts

Un artefact est un enregistrement typé qu’un système écrit à côté de sa sortie, comme ce qu’il a récupéré. Une sorte est un nom en minuscules avec une version facultative, qui correspond à ^[a-z][a-z0-9_]*(/v[1-9][0-9]*)?$. Les évaluateurs qui ont besoin d’un artefact le nomment, et une exécution dont le système ne déclare pas une sorte requise est refusée avant de commencer, plutôt que de compter chaque cas comme manquant.

Un système appelable déclare les sortes qu’il enregistre dans records: (ou @system(records=...)) ; un système HTTP dans http.artifacts ; un système RAG par étapes enregistre les siennes.

Versions, clés de cache et invalidation

Oloproof réutilise le travail dont les entrées n’ont pas changé, et décide de ce que signifie « inchangé » à partir d’empreintes de contenu. Chacune est calculée par le moteur et enregistrée avec l’exécution.

Ce qu’Oloproof ne peut pas voir, c’est à vous de le déclarer :

• Le comportement d’un système HTTP réside sur le serveur. Changez system.version chaque fois que ce qui se trouve derrière l’URL change, sinon une ancienne sortie en cache tiendra lieu du nouveau système.
• Les modules auxiliaires d’un appelable ne sont hachés que lorsque code_paths les reconnaît. Sans cela, modifier un module auxiliaire ne change pas la version.
• Une méthode ou un objet appelable doit déclarer une version, et la version doit changer quand l’état de l’objet change.
• Un index RAG est identifié par index_version ; changez-le quand l’index est reconstruit.
• L’identité d’un juge modèle est faite de ses réglages, pas des poids du fournisseur. Un fournisseur qui met à jour le modèle derrière le même nom n’est pas détecté par le cache.
• Un @evaluator personnalisé hache le fichier de module qui le définit, et ses jugements ne sont réutilisés d’une exécution à l’autre que lorsqu’il déclare cacheable=True. Les juges à grille intégrés peuvent être mis en cache ; les évaluateurs déterministes sont recalculés, ce qui coûte peu.

Le travail en cache réside dans le magasin local du projet, .oloproof/store.sqlite à côté de oloproof.yaml (ou sous OLOPROOF_HOME). Supprimer le magasin efface chaque cache et chaque exécution. Dans un espace de travail hébergé, le moteur ne réutilise pas les exécutions, jugements ou analyses en cache, parce qu’un push peut les écrire ; il recalcule.