Dokumentacja konfiguracji

Każde pole oloproof.yaml i release.yaml, z typem, wartością domyślną, akceptowanymi wartościami i przykładem, wzięte z modeli, które czytają te pliki. Używaj jej, aby sprawdzić pole; aby poznać przebieg pracy, przeczytaj strony szybki start i bramkowanie.

Oba pliki są walidowane, zanim cokolwiek się uruchomi. Nieznane pole, błędnie zapisane pole lub wartość złego typu to błąd konfiguracji, a polecenie kończy się kodem 2 bez wykonania żadnego przypadku. Oba pliki mają schematy JSON Schema, z których edytor czytający JSON Schema może korzystać do podpowiedzi. Zainstalowany pakiet zapisuje je, razem ze schematami wyników, do schemas/v1/ w bieżącym katalogu: python -m oloproof_core.models.schema_export (te dwa to project_config.schema.json i release_policy.schema.json).

W tabelach poniżej "wymagane" oznacza, że plik bez tego pola jest odrzucany; każde inne pole pokazuje wartość używaną, gdy zostanie pominięte.

oloproof.yaml w skrócie

Mały, kompletny projekt. Uruchamia lokalnie funkcję w Pythonie, nie potrzebuje sieci ani kluczy i ma kształt, który tworzy 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

Pola najwyższego poziomu

concurrency

Wpisy pricing

Oloproof nie dostarcza tabeli cen. Każdy wpis nazywa model dokładnie tak, jak nazywa go model: ewaluatora.

# 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

System potrzebuje dokładnie jednego z callable, http lub 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

Kontrakt żądania i odpowiedzi oraz to, co dzieje się przy przekroczeniach limitu czasu i błędach HTTP, opisują Wyniki i wykonanie.

system.rag

Ustawienia podane tutaj nadpisują te, które deklaruje klasa. System etapowy sam zapisuje swoje artefakty retrieval/v1, context/v1 i citations/v1, więc records obok niego jest odrzucane. Zob. RAG.

evaluators

Każdy wpis przyjmuje type i te dwa wspólne pola:

fail dotyczy tylko ewaluatorów pass/fail; ewaluator wyniku liczbowego z nim to błąd konfiguracji. on_execution_error to pole YAML; klasy ewaluatorów w SDK nie przyjmują takiego argumentu, a przypadek z błędem liczy się jako brakujący.

Typy ewaluatorów

"Czyta" wymienia to, od czego zależy werdykt ewaluatora, a zarazem to, czym kluczowana jest jego ocena w cache. "SDK" podaje klasę w oloproof.evaluators.

Sędzia, który wywołuje hostowany model, wysyła treść przypadków do tego dostawcy i jest przez niego rozliczany. Klucze są czytane ze zmiennej środowiskowej wskazanej w api_key_env; Oloproof nigdy nie przechowuje ich w tych plikach.

Ewaluatory deterministyczne

Sędziowie-modele

rubric_judge, groundedness_judge i citation_support_judge mają wspólne te pola. rubric_judge wymaga dokładnie jednego z rubric_file lub rubric_text; dwaj sędziowie RAG przyjmują co najwyżej jedno, a w przeciwnym razie używają wbudowanej rubryki. Ich criterion domyślnie to groundedness i citation_support.

probability_judge zadaje typowane pytanie i czyta prawdopodobieństwa modelu:

cascade uruchamia najpierw taniego sędziego i eskaluje niepewne przypadki:

Etapy oceniają własne criterion kaskady; etap, który nazywa inne, jest odrzucany.

model_classifier ocenia tekst wytrenowanym modelem na serwerze zgodnym z TEI:

Ewaluatory RAG

Ewaluatory agentów

Każdy typ agenta ma domyślne criterion, więc można je pominąć: własna nazwa typu albo nazwa zbudowana z jego ustawienia (agent_steps_le_8, agent_tool_lookup_called, agent_handoffs_le_2). Zob. Agenci.

Ewaluatory predykcyjne

Ewaluator predykcyjny, który nie zapisuje positive, field ani expected_field, bierze je z bloku predictive:; wartość, którą zapisuje, zostaje zachowana.

predictive

metrics

Każde kryterium ewaluatora już jest metryką. Wpis metrics: dodaje jeszcze jedną, rozróżnianą przez 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

Polityka wydań: które reguły rozstrzygają i które decyzje blokują. Pominięte ustawienia zachowują wartości domyślne, więc polityka, która nazywa tylko swoje reguły, nadal blokuje na FAIL, INSUFFICIENT_EVIDENCE i MANUAL_REVIEW.

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

rules

Jedna lista zawiera oba rodzaje. Reguła przebiegu przyjmuje dokładnie jedno z min, max lub max_failures. Reguła porównania nazywa swój kind i rozstrzyga różnicę między dwoma przebiegami; zob. Reguły porównań.

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

Rodzaje artefaktów

Artefakt to typowany rekord, który system zapisuje obok swojego wyniku, na przykład to, co wyszukał. Rodzaj to nazwa małymi literami z opcjonalną wersją, pasująca do ^[a-z][a-z0-9_]*(/v[1-9][0-9]*)?$. Ewaluatory, które potrzebują artefaktu, go nazywają, a przebieg, którego system nie deklaruje wymaganego rodzaju, jest odrzucany przed startem, zamiast liczyć każdy przypadek jako brakujący.

System z funkcją wywoływalną deklaruje zapisywane rodzaje w records: (lub @system(records=...)); system HTTP w http.artifacts; etapowy system RAG zapisuje własne.

Wersje, klucze cache i unieważnianie

Oloproof ponownie używa pracy, której wejścia się nie zmieniły, a o tym, co znaczy "bez zmian", decyduje na podstawie skrótów treści. Każdy jest liczony przez silnik i zapisywany z przebiegiem.

To, czego Oloproof nie widzi, musisz zadeklarować sam:

• Zachowanie systemu HTTP żyje na serwerze. Zmieniaj system.version za każdym razem, gdy zmienia się to, co jest pod URL, w przeciwnym razie stary wynik z cache będzie reprezentował nowy system.
• Moduły pomocnicze funkcji wywoływalnej są hashowane tylko wtedy, gdy dopasowuje je code_paths. Bez tego edycja modułu pomocniczego nie zmienia wersji.
• Metoda lub obiekt wywoływalny muszą zadeklarować wersję, a wersja musi się zmienić, gdy zmienia się stan obiektu.
• Indeks RAG jest identyfikowany przez index_version; zmieniaj go przy przebudowie indeksu.
• Tożsamością sędziego-modelu są jego ustawienia, a nie wagi dostawcy. Aktualizacji modelu przez dostawcę pod tą samą nazwą cache nie wykrywa.
• Własny @evaluator hashuje plik modułu, który go definiuje, a jego oceny są ponownie używane między przebiegami tylko wtedy, gdy deklaruje cacheable=True. Wbudowani sędziowie z rubryką są cache'owalni; ewaluatory deterministyczne są liczone od nowa, co jest tanie.

Praca z cache żyje w lokalnym magazynie projektu, .oloproof/store.sqlite obok oloproof.yaml (lub pod OLOPROOF_HOME). Usunięcie magazynu odrzuca każdy cache i każdy przebieg. W hostowanym obszarze roboczym silnik nie używa ponownie wykonań, ocen ani analiz z cache, ponieważ push może je zapisywać; liczy od nowa.