구성 참조

oloproof.yaml과 release.yaml의 모든 필드를, 파일을 읽는 모델에서 가져온 타입, 기본값, 허용 값, 예시와 함께 정리합니다. 필드를 찾아볼 때 쓰세요. 작업 흐름을 배우려면 빠른 시작과 게이팅 페이지를 읽으세요.

두 파일 모두 무엇이든 실행되기 전에 검증됩니다. 알 수 없는 필드, 철자가 틀린 필드, 잘못된 타입의 값은 구성 오류이며, 명령은 케이스를 하나도 실행하지 않고 2로 종료합니다. 두 파일 모두 JSON Schema가 있어, JSON Schema를 읽는 편집기라면 자동 완성에 쓸 수 있습니다. 설치된 패키지가 결과 스키마와 함께 현재 디렉터리 아래의 schemas/v1/에 이를 씁니다: python -m oloproof_core.models.schema_export(두 파일은 project_config.schema.json과 release_policy.schema.json입니다).

아래 표에서 "필수"는 그 필드가 없으면 파일이 거부된다는 뜻이며, 다른 필드에는 생략했을 때 쓰이는 값이 표시됩니다.

oloproof.yaml 한눈에 보기

작지만 완전한 프로젝트입니다. Python 함수를 로컬에서 실행하고, 네트워크도 키도 필요 없으며, 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

최상위 필드

concurrency

pricing 항목

Oloproof는 가격표를 제공하지 않습니다. 각 항목은 평가기의 model:이 쓰는 것과 정확히 같은 이름으로 모델을 지정합니다.

# 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

시스템에는 callable, http, 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

요청과 응답의 계약, 그리고 타임아웃과 HTTP 오류 시 일어나는 일은 결과와 실행에 있습니다.

system.rag

여기서 준 설정은 클래스가 선언한 설정보다 우선합니다. 단계형 시스템은 자신의 retrieval/v1, context/v1, citations/v1 아티팩트를 스스로 기록하므로, 그 옆의 records는 거부됩니다. RAG를 보세요.

evaluators

모든 항목은 type과 다음 두 공통 필드를 받습니다.

fail은 통과/실패 평가기에만 적용되며, 점수 평가기에 쓰면 구성 오류입니다. on_execution_error는 YAML 필드입니다. SDK 평가기 클래스는 그런 인수를 받지 않으며, 오류가 난 케이스는 누락으로 셉니다.

평가기 유형

"읽는 것"은 평가기의 판정이 무엇에 달려 있는지를 나열하며, 이는 캐시된 판정의 키이기도 합니다. "SDK"는 oloproof.evaluators의 클래스 이름입니다.

호스팅 모델을 호출하는 심사 모델은 케이스 내용을 그 제공자에게 보내며, 요금은 그 제공자가 청구합니다. 키는 api_key_env에 지정한 환경 변수에서 읽으며, Oloproof는 이 파일들에 키를 저장하지 않습니다.

결정론적 평가기

모델 심사 모델

rubric_judge, groundedness_judge, citation_support_judge는 다음 필드를 공유합니다. rubric_judge에는 rubric_file과 rubric_text 중 정확히 하나가 필요하며, 두 RAG 심사 모델은 최대 하나를 받고 없으면 내장 루브릭을 씁니다. 이들의 criterion 기본값은 groundedness와 citation_support입니다.

probability_judge는 형식이 정해진 질문을 하고 모델의 확률을 읽습니다.

cascade는 저렴한 심사 모델을 먼저 실행하고 불확실한 케이스를 상위로 넘깁니다.

각 단계는 캐스케이드 자신의 criterion을 심사하며, 다른 기준을 지정한 단계는 거부됩니다.

model_classifier는 TEI 호환 서버의 학습된 모델로 텍스트에 점수를 매깁니다.

RAG 평가기

에이전트 평가기

각 에이전트 유형에는 기본 criterion이 있어 생략할 수 있습니다. 자신의 유형 이름이거나, 설정으로 만든 이름입니다(agent_steps_le_8, agent_tool_lookup_called, agent_handoffs_le_2). 에이전트를 보세요.

예측 평가기

positive, field 또는 expected_field를 쓰지 않은 예측 평가기는 그 값을 predictive: 블록에서 가져오며, 직접 쓴 값은 유지됩니다.

predictive

metrics

각 평가기 기준은 이미 지표입니다. metrics: 항목은 지표를 하나 더 추가하며, 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

릴리스 정책입니다. 어떤 규칙이 결정하고, 어떤 결정이 차단하는지를 정합니다. 생략한 설정은 기본값을 유지하므로, 규칙만 지정한 정책도 여전히 FAIL, INSUFFICIENT_EVIDENCE, MANUAL_REVIEW에서 차단합니다.

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

rules

하나의 리스트가 두 종류를 모두 담습니다. 실행 규칙은 min, max, max_failures 중 정확히 하나를 받습니다. 비교 규칙은 kind를 지정하고 두 실행 사이의 차이를 결정합니다. 비교 규칙을 보세요.

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

아티팩트 종류

아티팩트는 시스템이 출력 옆에 쓰는 타입이 있는 레코드로, 예를 들어 무엇을 검색했는지입니다. 종류는 선택적 버전이 붙은 소문자 이름으로, ^[a-z][a-z0-9_]*(/v[1-9][0-9]*)?$에 맞아야 합니다. 아티팩트가 필요한 평가기는 그 이름을 지정하며, 시스템이 필요한 종류를 선언하지 않은 실행은 모든 케이스를 누락으로 세는 대신 시작하기 전에 거부됩니다.

호출 가능 시스템은 기록하는 종류를 records:(또는 @system(records=...))에 선언하고, HTTP 시스템은 http.artifacts에 선언하며, 단계형 RAG 시스템은 스스로 기록합니다.

버전, 캐시 키, 무효화

Oloproof는 입력이 바뀌지 않은 작업을 재사용하며, 무엇이 "바뀌지 않음"인지는 내용 다이제스트로 판단합니다. 각 다이제스트는 엔진이 계산하고 실행과 함께 기록합니다.

Oloproof가 볼 수 없는 것은 여러분이 선언해야 합니다.

• HTTP 시스템의 동작은 서버에 있습니다. URL 뒤에 있는 것이 바뀔 때마다 system.version을 바꾸세요. 그렇지 않으면 예전에 캐시된 출력이 새 시스템을 대신하게 됩니다.
• 호출 가능 객체의 보조 모듈은 code_paths가 그것에 맞을 때만 해시됩니다. 없으면 보조 모듈을 수정해도 버전이 바뀌지 않습니다.
• 메서드나 호출 가능 객체는 버전을 선언해야 하며, 객체의 상태가 바뀌면 버전도 바뀌어야 합니다.
• RAG 인덱스는 index_version으로 식별됩니다. 인덱스를 다시 만들면 바꾸세요.
• 모델 심사 모델의 식별자는 제공자의 가중치가 아니라 설정입니다. 제공자가 같은 이름 뒤의 모델을 갱신해도 캐시는 이를 감지하지 못합니다.
• 사용자 정의 @evaluator는 그것을 정의한 모듈 파일을 해시하며, cacheable=True를 선언할 때만 판정이 실행 사이에 재사용됩니다. 내장 루브릭 심사 모델은 캐시 가능하며, 결정론적 평가기는 다시 계산되는데 그 비용은 작습니다.

캐시된 작업은 프로젝트의 로컬 저장소, 즉 oloproof.yaml 옆의 .oloproof/store.sqlite(또는 OLOPROOF_HOME 아래)에 있습니다. 저장소를 지우면 모든 캐시와 모든 실행이 사라집니다. 호스팅 워크스페이스에서 엔진은 캐시된 실행, 판정, 분석을 재사용하지 않습니다. 푸시가 그것을 쓸 수 있기 때문이며, 엔진은 다시 계산합니다.