Panduan
Referensi hasil dan eksekusi
Apa yang dikirim sebuah eksekusi ke sistem HTTP dan apa yang diharapkannya kembali, bagaimana setiap kasus masuk ke penyebut sebuah metrik, status keputusan dan kode alasan yang menjelaskannya, kode keluar, serta data apa yang tetap lokal atau berpindah ke ruang kerja yang di-hosting. Untuk gagasan di baliknya baca Konsep; untuk field kebijakan baca Referensi konfigurasi.
Kontrak sistem HTTP
Sistem HTTP (system.http di oloproof.yaml) dipanggil sekali per kasus, dan sekali per replikasi.
| Aspek | Perilaku |
|---|---|
| Permintaan | POST secara bawaan (GET dan PUT diterima). Body-nya adalah nilai input kasus sebagai JSON. |
| Header dan autentikasi | Tidak ada yang dapat dikonfigurasi. Permintaan hanya membawa bawaan klien HTTP. Endpoint yang memerlukan kunci sebaiknya ditempatkan di balik sistem callable Python yang menambahkannya. |
| Respons | Harus JSON. output_path memilih keluaran dengan path bertitik, seperti result.answer; tanpanya seluruh body adalah keluarannya. Field output_path yang tidak ada direkam sebagai error eksekusi untuk kasus itu. |
| Artefak | Setiap entri http.artifacts membaca path bertitik dari respons. Field yang dideklarasikan tetapi tidak ada dalam respons adalah error kontrak, dan eksekusi berhenti dengan keluar 2. |
| Batas waktu | http.timeout_s per permintaan, 30 detik secara bawaan. |
| Percobaan ulang | Batas waktu habis, kegagalan koneksi, serta HTTP 408, 429, dan 5xx dicoba ulang, hingga empat percobaan secara keseluruhan, dengan backoff eksponensial ber-jitter yang menghormati Retry-After. Respons 4xx lainnya tidak dicoba ulang. |
| Setelah percobaan terakhir | Eksekusi kasus direkam sebagai error dan kasus dihitung sebagai hilang (atau sebagai gagal, di bawah on_execution_error: fail). Eksekusi berlanjut. |
| Konkurensi | Paling banyak concurrency.system permintaan yang berjalan bersamaan, 8 secara bawaan. |
URL, metode, path keluaran, dan pemetaan artefak masuk ke versi sistem, tetapi apa yang dilakukan server tidak. Ubah system.version setiap kali perilaku server berubah; lihat Referensi konfigurasi untuk alasannya.
Tiga kosakata yang berbeda
Sebuah hasil memiliki tiga jenis status, dan ketiganya tidak pernah saling menggantikan.
| Jenis | Nilai | Menjawab |
|---|---|---|
| Status keputusan | PASS, FAIL, INSUFFICIENT_EVIDENCE, MANUAL_REVIEW | Apa yang dikatakan bukti tentang satu aturan. |
| Status eksekusi | Status eksekusi RUN_ERROR atau CANCELLED; kelengkapan eksekusi PARTIAL; eksekusi kasus ERROR atau TIMEOUT | Apa yang terjadi pada eksekusi atau pada panggilan satu kasus. Bukan hasil kualitas. |
| Tindakan rilis | ALLOW, WARN, BLOCK | Apa yang dilakukan kebijakan Anda terhadap setiap keputusan: status block_on memblokir, status warn_on memperingatkan, lainnya mengizinkan. |
Eksekusi yang berakhir normal berstatus DECIDED, atau DECIDED_EARLY ketika penghentian dini mengakhirinya. Eksekusi yang diinterupsi oleh Ctrl-C atau pembatalan tugas berstatus CANCELLED; eksekusi yang harness-nya memunculkan exception berstatus RUN_ERROR. Keduanya membuat eksekusi PARTIAL, menyimpan kasus yang sudah selesai, dan memungkinkan eksekusi berikutnya memakai ulang rekaman yang di-cache. Lihat Error.
Untuk ambang batas minimum T dan interval [L, U], sebuah aturan berstatus PASS ketika L >= T, FAIL ketika U < T, dan INSUFFICIENT_EVIDENCE selain itu. Ambang batas maksimum bersifat simetris. Sebelum membaca interval, sebuah aturan memeriksa apakah ia perlu memutuskan sama sekali: pertama alasan untuk MANUAL_REVIEW, lalu alasan untuk INSUFFICIENT_EVIDENCE. Tingkat pertama yang memiliki alasan yang memutuskan, dan mencantumkan setiap alasan yang ditemukannya.
Kode alasan
Setiap keputusan membawa satu atau lebih kode alasan.
MANUAL_REVIEW
| Kode | Arti |
|---|---|
| policy_requires_review | Aturan menetapkan requires_manual_review: true. |
| unsupported_method | Tidak ada interval yang disetujui untuk metrik ini dalam situasi ini. Lihat di bawah. |
| unsupported_dependence_structure | Suite mendeklarasikan klaster (group_id) dan tidak ada metode yang disetujui yang menanganinya untuk metrik ini. |
| approximate_method_not_permitted | Satu-satunya interval bersifat aproksimasi, dan kebijakan tidak menetapkan allow_approximate_methods: true. |
| evaluator_retired | Sebuah evaluator di balik metrik telah dipensiunkan. |
INSUFFICIENT_EVIDENCE
| Kode | Arti |
|---|---|
| no_observations | Tidak ada kasus yang diamati untuk metrik ini. |
| missingness_exceeds_policy | Kasus eligible yang hilang lebih banyak daripada yang diizinkan max_missing_fraction aturan. |
| missingness_unbounded | Metode membuang kasus yang hilang alih-alih membatasinya, dan aturan tidak mendeklarasikan max_missing_fraction. |
| evaluator_not_validated | Juri model di balik metrik belum divalidasi terhadap label manusia, dan require_validated_evaluators aktif (bawaan). |
| evaluator_recalibration_required | Juri divalidasi pada model yang dilayani yang bukan asal putusan eksekusi ini. |
| interval_unavailable | Metrik tidak memiliki interval untuk dibaca. |
| insufficient_clusters | Klaster lebih sedikit daripada min_clusters kebijakan. |
| interval_monte_carlo_uncertain | Ambang batas jatuh di dalam ketidakpastian simulasi dari sebuah batas berklaster. |
| interval_overlaps_threshold | Interval memuat ambang batas. Lebih banyak kasus akan mempersempitnya. |
| interval_unbounded | Interval tidak memiliki batas di sisi yang dibaca aturan. |
| missing_could_change_outcome | Aturan observed_count: kasus yang hilang dapat membawa kegagalan melewati max_failures. |
| interval_overlaps_zero, interval_overlaps_margin, interval_overlaps_margins | Perbandingan yang interval selisihnya melintasi nol atau sebuah margin. |
| insufficient_support | Aturan perbandingan irisan yang irisannya memiliki kasus lebih sedikit daripada min_support-nya. |
| family_correction_withheld | Aturan dalam entri families: yang dihentikan koreksi Holm sebelum mencapainya. |
PASS dan FAIL
| Kode | Status |
|---|---|
| lower_bound_meets_minimum, upper_bound_meets_maximum | PASS |
| upper_bound_below_minimum, lower_bound_above_maximum | FAIL |
| observed_failures_within_limit | PASS |
| observed_failures_exceed_limit | FAIL |
| difference_above_zero, lower_bound_above_margin, interval_within_margins | PASS (perbandingan) |
| difference_below_zero, upper_bound_below_margin, interval_outside_margins | FAIL (perbandingan) |
| cost_ceiling_exceeded | Disebutkan di samping status aturan biaya yang batas atas deklarasinya dilampaui oleh eksekusi yang direkam |
Hanya ruang kerja yang di-hosting
Ruang kerja yang memutuskan sendiri eksekusi yang di-push dapat menahan keputusan dengan ppi_not_verified (ruang kerja tidak memverifikasi interval yang menjadi dasar keputusan), execution_not_verified (keluaran tidak berasal dari runner terdaftar) atau workspace_cannot_decide (ruang kerja tidak menyimpan salinan kebijakan, atau tidak dapat membaca bukti). Lihat Gerbang.
Bagaimana setiap kasus masuk ke penyebut
Setiap metrik melaporkan empat hitungan: n_total (kasus dalam suite), n_eligible, n_observed, dan n_missing, dengan n_eligible = n_observed + n_missing. Kasus di luar n_eligible dicantumkan di bawah exclusions beserta alasannya.
| Apa yang terjadi pada kasus | Dihitung sebagai | Dalam penyebut |
|---|---|---|
| Evaluator mengembalikan lolos atau gagal | diamati, berhasil atau gagal | ya |
| Evaluator menyatakan dirinya tidak berlaku (misalnya, tidak ada nilai yang diharapkan untuk dibandingkan) | dikecualikan, dengan alasannya | tidak |
| Panggilan sistem mengalami error atau habis waktu | hilang, atau gagal di bawah on_execution_error: fail | ya |
| Evaluator memunculkan exception, atau balasan juri tidak dapat dibaca | hilang | ya |
| Kasus tidak pernah berjalan karena eksekusi diinterupsi | hilang, dan eksekusi berstatus PARTIAL | ya |
Kasus yang hilang dibatasi, bukan dibuang. Untuk tingkat kelulusan, batas bawah interval memperlakukan setiap kasus yang hilang sebagai kegagalan dan batas atasnya sebagai keberhasilan, sehingga eksekusi dengan banyak kasus hilang memiliki interval lebar yang tidak dapat meloloskan aturan yang menuntut; rata-rata terbatas mengganti dengan ujung-ujung rentang yang dideklarasikannya dengan cara yang sama. Metode yang tidak dapat membatasi kasus yang hilang (misalnya statistik peringkat) membuangnya dan merekam asumsinya, dan aturan atasnya berstatus missingness_unbounded sampai aturan itu mendeklarasikan max_missing_fraction.
Aturan observed_count menghitung kegagalan atas suite yang dieksekusi dan tidak membaca interval. Aturan itu hanya lolos ketika kegagalan yang diamati ditambah setiap kasus yang hilang masih muat dalam max_failures.
Metrik tanpa interval yang disetujui
Sebuah aturan hanya memutuskan berdasarkan interval yang metodenya telah disetujui melalui audit. Jika tidak ada, metrik tetap dihitung dan ditampilkan, dan aturan atasnya tidak meminjam metode yang belum divalidasi:
| Situasi | Apa yang dibaca aturan atasnya |
|---|---|
| Metrik skor (rata-rata) tanpa rentang yang dideklarasikan, seperti evaluator skor kustom tanpa score_range | MANUAL_REVIEW, unsupported_method |
| Metrik rata-rata, kuantil, peringkat, atau biaya pada suite yang mendeklarasikan group_id | MANUAL_REVIEW, unsupported_dependence_structure |
| Tingkat kelulusan pada suite berklaster | interval aproksimasi: MANUAL_REVIEW kecuali allow_approximate_methods: true, lalu pemeriksaan klaster di atas |
| Metrik kuantil atau peringkat dengan replicates di atas 1 | MANUAL_REVIEW, unsupported_method |
| Metrik apa pun pada suite dengan group_id sekaligus replikasi | MANUAL_REVIEW, unsupported_dependence_structure |
| Perbandingan pada suite berklaster | MANUAL_REVIEW |
| Irisan di bawah min_slice_support | tidak ada interval, tetapi irisan tidak pernah mencapai gerbang |
| Metrik human_score, human_preference, atau cost_per_accepted | ditolak saat file dibaca, keluar 2 |
Kode keluar
oloproof gate, oloproof run dengan kebijakan, dan perintah lain yang memutuskan semuanya menggunakan kode yang sama.
| Kode | Arti |
|---|---|
| 0 | Tidak ada yang diblokir kebijakan: setiap aturan lolos, atau aturan yang tidak lolos berada di luar block_on. |
| 1 | Sebuah aturan dalam block_on gagal. |
| 2 | Konfigurasi atau pemanggilan salah, atau sebuah sistem melanggar kontraknya; tidak ada yang diputuskan. |
| 3 | Sebuah aturan dalam block_on berstatus INSUFFICIENT_EVIDENCE. |
| 4 | Sebuah aturan dalam block_on berstatus MANUAL_REVIEW. |
| 5 | Eksekusi tidak selesai dan block_on_partial_run aktif (bawaan). |
Jika beberapa berlaku, kode yang dilaporkan adalah yang pertama dari 1, 5, 4, 3. Status yang tidak dicantumkan dalam block_on tidak dapat mengubah kode keluar: dengan block_on: [FAIL] dan warn_on: [INSUFFICIENT_EVIDENCE], aturan yang belum terputuskan memperingatkan dan gerbang keluar dengan 0. Karena itu keluar 0 hanya berarti tidak terjadi apa pun yang diblokir kebijakan Anda, bukan bahwa setiap aturan lolos. Lihat Gerbang.
Di mana pekerjaan berjalan dan ke mana data pergi
Lokal, bawaan
oloproof run, oloproof gate, dan SDK berjalan di mesin Anda. Setiap rekaman (kasus, keluaran, artefak, penilaian, metrik, dan keputusan) ditulis ke .oloproof/store.sqlite di samping oloproof.yaml, atau di bawah OLOPROOF_HOME jika ditetapkan. Tidak ada yang dikirim ke Oloproof. Satu-satunya lalu lintas jaringan adalah yang ditimbulkan konfigurasi Anda: panggilan ke URL sistem HTTP Anda, dan panggilan yang dilakukan juri model atau classifier model ke penyedianya, yang menerima konten kasus yang mereka nilai dan menagih Anda untuk itu.
Push ke ruang kerja yang di-hosting
oloproof push mengirim bukti sebuah eksekusi ke ruang kerja yang Anda hubungkan dengan oloproof login. Secara bawaan perintah ini mengirim metrik, interval, keputusan, dan irisan agregat, serta identitas, status, waktu, dan penggunaan setiap rekaman, tetapi bukan kontennya. Konten mentah disensor field demi field sebelum apa pun meninggalkan mesin, dan rekaman yang disensor menyebutkan kategori mana yang ditahan. Sebuah kategori hanya dikirim ketika egress: di oloproof.yaml mencantumkannya:
| Kategori | Apa yang dicakupnya |
|---|---|
| raw_inputs | Input skenario, nilai yang diharapkan, dan metadata kasus: baris-baris dataset |
| raw_outputs | Apa yang dikembalikan sistem yang diuji untuk setiap kasus |
| judge_rationales | Teks yang ditulis juri untuk menjelaskan putusan, yang mengutip keluaran |
| artifacts | Konteks retrieval, sitasi, dan trajektori yang direkam selama eksekusi |
| error_detail | Pesan dan detail exception, yang sering membawa input apa adanya |
| system_config | Konfigurasi yang dideklarasikan dari sistem yang diuji dan evaluatornya |
| label_notes | Catatan yang ditulis seseorang di samping label, yang sering mengutip keluaran |
| span_names | Nama trace, span, alat, dan agen yang direkam oleh instrumentasi |
Digest rekaman tidak dihitung ulang setelah sensor, sehingga rekaman yang di-hosting tetap menyebut bukti aslinya, yang tetap berada di mesin Anda. Sensor bukanlah enkripsi, dan metrik atas irisan yang sangat kecil masih dapat mengidentifikasi kasus di baliknya.
Ketika peninjau memberi label pada kasus di antrean tinjauan yang di-hosting, browser mereka mengambil konten kasus dari oloproof collect yang berjalan di sisi Anda; konten itu tidak melewati ruang kerja. Kunci penyedia yang digunakan ruang kerja disimpan dengan oloproof credentials set, dan oloproof credentials list menampilkan namanya, tidak pernah nilainya. Pekerjaan terkelola berjalan pada worker yang dioperasikan Oloproof, yang tidak menjalankan kode Python Anda; oloproof job melaporkan hasilnya dan keluar sesuai gerbangnya.
Di ruang kerja yang di-hosting, mesin tidak pernah memakai ulang eksekusi, penilaian, atau analisis yang di-cache, karena push dapat menulis cache tersebut; mesin menghitungnya ulang.