Tham chiếu cấu hình

Mọi trường của oloproof.yaml và release.yaml, kèm kiểu, giá trị mặc định, các giá trị nó chấp nhận và một ví dụ, được lấy từ các mô hình đọc các tệp này. Hãy dùng trang này để tra cứu một trường; đọc các trang bắt đầu nhanh và cổng để học quy trình.

Cả hai tệp đều được kiểm tra trước khi bất cứ thứ gì chạy. Một trường không xác định, một trường viết sai chính tả hoặc một giá trị sai kiểu là một lỗi cấu hình và lệnh thoát với 2 mà không thực thi trường hợp nào. Cả hai tệp đều có JSON Schema, mà một trình soạn thảo đọc được JSON Schema có thể dùng để gợi ý hoàn thành. Gói đã cài đặt ghi chúng, cùng với các schema kết quả, vào schemas/v1/ dưới thư mục hiện tại: python -m oloproof_core.models.schema_export (hai tệp là project_config.schema.json và release_policy.schema.json).

Trong các bảng bên dưới, "bắt buộc" nghĩa là tệp bị từ chối nếu thiếu trường đó; mọi trường khác cho thấy giá trị được dùng khi nó bị bỏ qua.

Tổng quan về oloproof.yaml

Một dự án nhỏ, đầy đủ. Nó chạy một hàm Python cục bộ, không cần mạng và không cần khóa, và là hình dạng mà oloproof init tạo khung.

# 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

Các trường cấp cao nhất

concurrency

Các mục pricing

Oloproof không đi kèm bảng giá nào. Mỗi mục nêu một mô hình đúng như model: của một bộ đánh giá nêu nó.

# 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

Một hệ thống cần đúng một trong callable, http hoặc 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

Hợp đồng yêu cầu và phản hồi, và điều gì xảy ra khi hết thời gian và khi có lỗi HTTP, nằm trong Kết quả và thực thi.

system.rag

Các thiết lập đưa ở đây ghi đè các thiết lập mà lớp khai báo. Một hệ thống phân tầng tự ghi lại các artifact retrieval/v1, context/v1 và citations/v1 của nó, nên records bị từ chối khi đi cùng nó. Xem RAG.

evaluators

Mọi mục nhận một type và hai trường chung sau:

fail chỉ áp dụng cho các bộ đánh giá đạt/không đạt; một bộ đánh giá điểm số có nó là một lỗi cấu hình. on_execution_error là một trường YAML; các lớp bộ đánh giá của SDK không nhận đối số như vậy, và một trường hợp bị lỗi được tính là bị thiếu.

Các loại bộ đánh giá

"Đọc" liệt kê những gì phán quyết của bộ đánh giá phụ thuộc vào, cũng là thứ mà phán quyết đã lưu đệm của nó được lập khóa theo. "SDK" nêu lớp trong oloproof.evaluators.

Một giám khảo gọi một mô hình được lưu trữ sẽ gửi nội dung trường hợp tới nhà cung cấp đó và bị nhà cung cấp đó tính phí. Khóa được đọc từ biến môi trường được nêu trong api_key_env; Oloproof không bao giờ lưu chúng trong các tệp này.

Bộ đánh giá tất định

Giám khảo mô hình

rubric_judge, groundedness_judge và citation_support_judge dùng chung các trường này. rubric_judge yêu cầu đúng một trong rubric_file hoặc rubric_text; hai giám khảo RAG nhận tối đa một và nếu không thì dùng một rubric có sẵn. criterion của chúng mặc định là groundedness và citation_support.

probability_judge hỏi một câu hỏi có kiểu và đọc các xác suất của mô hình:

cascade chạy một giám khảo rẻ trước và chuyển lên các trường hợp chưa chắc chắn:

Các tầng chấm theo chính criterion của cascade; một tầng nêu một tiêu chí khác sẽ bị từ chối.

model_classifier chấm điểm văn bản bằng một mô hình đã huấn luyện trên một máy chủ tương thích TEI:

Bộ đánh giá RAG

Bộ đánh giá agent

Mỗi loại agent có một criterion mặc định, nên có thể bỏ qua nó: chính tên loại của nó, hoặc một tên được dựng từ thiết lập của nó (agent_steps_le_8, agent_tool_lookup_called, agent_handoffs_le_2). Xem Agent.

Bộ đánh giá dự đoán

Một bộ đánh giá dự đoán không viết positive, field hoặc expected_field sẽ lấy chúng từ khối predictive:; một giá trị mà nó viết thì được giữ nguyên.

predictive

metrics

Mỗi tiêu chí của bộ đánh giá vốn đã là một chỉ số. Một mục metrics: thêm một chỉ số nữa, được phân biệt bằng 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

Chính sách phát hành: quy tắc nào quyết định, và quyết định nào chặn. Các thiết lập bị bỏ qua giữ giá trị mặc định, nên một chính sách chỉ nêu các quy tắc của nó vẫn chặn trên FAIL, INSUFFICIENT_EVIDENCE và MANUAL_REVIEW.

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

rules

Một danh sách chứa cả hai loại. Một quy tắc lần chạy nhận đúng một trong min, max hoặc max_failures. Một quy tắc so sánh nêu kind của nó và quyết định một khác biệt giữa hai lần chạy; xem Quy tắc so sánh.

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

Các loại artifact

Một artifact là một bản ghi có kiểu mà một hệ thống viết bên cạnh đầu ra của nó, chẳng hạn những gì nó đã truy xuất. Một loại là một tên chữ thường với một phiên bản tùy chọn, khớp ^[a-z][a-z0-9_]*(/v[1-9][0-9]*)?$. Các bộ đánh giá cần một artifact sẽ nêu nó, và một lần chạy mà hệ thống không khai báo một loại bắt buộc sẽ bị từ chối trước khi bắt đầu, thay vì tính mọi trường hợp là bị thiếu.

Một hệ thống callable khai báo các loại mà nó ghi lại trong records: (hoặc @system(records=...)); một hệ thống HTTP trong http.artifacts; một hệ thống RAG phân tầng tự ghi lại các loại của nó.

Phiên bản, khóa bộ nhớ đệm và việc mất hiệu lực

Oloproof tái sử dụng công việc có đầu vào không thay đổi, và quyết định "không thay đổi" nghĩa là gì từ các digest nội dung. Mỗi digest được engine tính và ghi lại cùng lần chạy.

Những gì Oloproof không thể thấy là do bạn khai báo:

• Hành vi của một hệ thống HTTP nằm trên máy chủ. Hãy đổi system.version mỗi khi thứ đằng sau URL thay đổi, nếu không một đầu ra cũ đã lưu đệm sẽ đứng thay cho hệ thống mới.
• Các module phụ trợ của một callable chỉ được băm khi code_paths khớp với chúng. Không có nó, việc sửa một module phụ trợ không thay đổi phiên bản.
• Một phương thức hoặc một đối tượng callable phải khai báo một phiên bản, và phiên bản phải thay đổi khi trạng thái của đối tượng thay đổi.
• Một chỉ mục RAG được nhận diện bằng index_version; hãy đổi nó khi chỉ mục được xây dựng lại.
• Danh tính của một giám khảo mô hình là các thiết lập của nó, không phải trọng số của nhà cung cấp. Bộ nhớ đệm không phát hiện được việc một nhà cung cấp cập nhật mô hình đằng sau cùng một tên.
• Một @evaluator tùy chỉnh băm tệp module định nghĩa nó, và các phán quyết của nó chỉ được tái sử dụng giữa các lần chạy khi nó khai báo cacheable=True. Các giám khảo rubric có sẵn có thể lưu đệm; các bộ đánh giá tất định được tính lại, việc này rẻ.

Công việc đã lưu đệm nằm trong kho lưu trữ cục bộ của dự án, .oloproof/store.sqlite bên cạnh oloproof.yaml (hoặc dưới OLOPROOF_HOME). Xóa kho lưu trữ sẽ loại bỏ mọi bộ nhớ đệm và mọi lần chạy. Trong một không gian làm việc được lưu trữ, engine không tái sử dụng các lần thực thi, phán quyết hay phân tích đã lưu đệm, vì một lần push có thể ghi vào chúng; nó tính lại.