Commencer

Démarrage rapide

Installez le moteur, générez la structure d’un projet, et obtenez une première exécution et une décision de porte sur votre propre machine. Rien n’en sort à moins que vous ne le poussiez.

Ces étapes sont celles du README, reproduites ici plutôt que retapées : README.md est la copie qu’un développeur rencontre sur GitHub et celle que les tests d’intégration confrontent au code ; il reste donc la source, et cette page en est générée par scripts/generate_quickstart.py.

Installation pour le développement

Depuis la racine du dépôt :

python3 -m venv .venv
.venv/bin/python -m pip install -e '.[dev]'
pnpm install --frozen-lockfile
make check
pnpm --filter @oloproof/web check

La surface Python publique est :

from oloproof import evaluate, system, current_case
from oloproof.evaluators import ExactMatch, Contains, JsonSchema, Regex, RubricJudge, evaluator

Tout ce qui se trouve sous oloproof_core relève des composants internes du moteur.

Démarrage rapide

Générez un petit projet :

. .venv/bin/activate
oloproof init /tmp/oloproof-demo
cd /tmp/oloproof-demo
oloproof run

Évaluateurs

Les valeurs de type: qu’accepte oloproof.yaml :


déterministe	exact_match, contains, regex, json_schema
juge LLM	rubric_judge, groundedness_judge, citation_support_judge ; probability_judge : une question oui/non, à choix ou à score, à laquelle répondent les probabilités d’un seul token ; cascade : d’abord un juge probabiliste, puis un second juge seulement là où il n’est pas sûr
modèle	model_classifier : un classifieur entraîné ou un modèle NLI sur un serveur TEI, évalué par rapport à un seuil
récupération	hit_rate, recall, mrr, ndcg, citation_validity
agent	agent_max_steps, agent_tool_called, agent_no_tool_loop, agent_tool_sequence, agent_no_undeclared_tool, agent_constraints_satisfied
multi-agent	agent_route, agent_tool_permissions, agent_max_handoffs
prédictif	predictive_correct, predictive_precision, predictive_recall, predictive_ranking, predictive_brier, predictive_log_loss, predictive_absolute_error

Un juge indique son provider (anthropic, openai ou openai_compatible), son model, et sa grille d’évaluation sous forme de rubric_text ou de rubric_file. Un juge sur un fournisseur qui parle l’API OpenAI sans être OpenAI — Groq, Together, un serveur local — a aussi besoin de base_url et api_key_env :

evaluators:
  - type: rubric_judge
    criterion: answer_correct
    provider: openai_compatible
    model: openai/gpt-oss-20b
    base_url: https://api.groq.com/openai/v1
    api_key_env: GROQ_API_KEY
    rubric_text: "PASS if the answer conveys the same fact as the reference."

Nommer un champ qu’un évaluateur n’accepte pas vous vaut en réponse la liste de ceux qu’il accepte.

Redécidez une exécution existante sans réexécuter le système ni les évaluateurs :

oloproof gate RUN_ID --policy release.yaml

Examinez les échecs et un cas :

oloproof inspect RUN_ID --failures
oloproof inspect RUN_ID --case refund_00

Exportez un lot et ouvrez-le dans l’atelier web :

oloproof export RUN_ID
OLOPROOF_BUNDLE_DIR="$PWD/.oloproof/bundles" pnpm --dir /path/to/Oloproof --filter @oloproof/web dev

Le chemin du lot doit être absolu, car pnpm démarre l’application depuis apps/web. L’atelier s’ouvre sur l’index de ses espaces de travail ; un OLOPROOF_BUNDLE_DIR seul y apparaît comme le projet local/bundles. Pour héberger plusieurs projets sur une même machine, faites plutôt pointer OLOPROOF_WORKBENCH_DIR vers un répertoire contenant un workbench.json (docs/API_CONTRACTS.md).