Panduan

Progres dan konkurensi

Suite yang dijalankan terhadap model aktif memakan waktu beberapa menit, dan sebagian besar waktu itu dihabiskan untuk menunggu model. Halaman ini membahas berapa banyak panggilan yang dijalankan Oloproof secara bersamaan, apa yang ditampilkannya kepada Anda selama panggilan itu berjalan, dan cara mengetahui berapa banyak eksekusi tambahan yang diperlukan untuk menuntaskan aturan yang belum menghasilkan keputusan.

Konkurensi

concurrency: di oloproof.yaml membatasi berapa banyak panggilan yang berjalan sekaligus:

concurrency:
  system: 4
  judge: 4

system membatasi panggilan ke sistem yang diuji dan bawaannya 8. judge membatasi panggilan ke juri LLM dan bawaannya 4. Keduanya terpisah karena biasanya berada di balik batas laju (rate limit) yang berbeda.

Seratus dua puluh kasus terhadap sistem yang memerlukan sepersepuluh detik per panggilan:

system:	Waktu nyata
1	13,4 dtk
16	1,7 dtk
tidak berubah, dijalankan ulang	0,4 dtk

Baris terakhir adalah efek cache, bukan konkurensi: setiap hasil eksekusi dipakai kembali. Konkurensi bukan bagian dari identitas sistem, sehingga mengubahnya tidak pernah membatalkan apa yang sudah tersimpan.

Setiap kasus adalah panggilan tersendiri. Oloproof tidak mengelompokkan kasus ke dalam batch API milik penyedia, sehingga diskon batch penyedia tidak tersedia melaluinya; konkurensi dan cache-lah yang membuat eksekusi lebih cepat.

Percobaan ulang

Penyedia juri atau sistem HTTP yang menjawab 429 atau 5xx, mengalami timeout, atau memutus koneksi akan dicoba ulang dengan backoff, hingga empat percobaan, dan tidak pernah lebih cepat daripada yang diminta header Retry-After. Sistem callable ikut serta dengan memunculkan TransientError dari oloproof dengan retryable=True:

from oloproof import TransientError, system


@system(name="example-support-bot", version="1")
def answer(case):
    ...
    raise TransientError("provider timed out", retryable=True)

Nilai bawaan retryable adalah False. Tanpanya, error direkam pada kasus, yang kemudian menjadi hilang alih-alih dicoba ulang. Sistem yang memunculkan error dengan cara itu pada panggilan pertama untuk masing-masing dari tiga puluh kasus, lalu menjawab pada panggilan kedua:

│ exact_label │ 100.0%   │ [88.4%, 100.0%] │ 30 / 30 observed · 0 missing · 0 excluded │

Sistem yang sama dengan retryable=True dihapus:

│ exact_label │          │ [0.0%, 100.0%] │ 0 / 0 observed · 30 missing · 0 excluded │

Apa yang ditampilkan eksekusi selama berjalan

Di terminal, oloproof run menggambar ulang tampilan langsung di standard error: kasus yang selesai, cache hit, error, dan estimasi sementara untuk setiap metrik biner. Satu bingkai:

                    56/120 cases · 0 cached · 0 errors
┏━━━━━━━━━━━━━┳━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Metric      ┃ Estimate ┃ Provisional interval ┃ Cases                   ┃
┡━━━━━━━━━━━━━╇━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━┩
│ exact_label │ 89.8%    │ [78.2%, 95.6%]       │ 49 observed · 0 missing │
└─────────────┴──────────┴──────────────────────┴─────────────────────────┘
     Provisional Wilson estimates over finished cases; not a decision.

Keterangan itulah aturannya. Interval sementara adalah interval Wilson atas apa pun yang sudah selesai, yang berguna untuk dipantau tetapi bukan untuk dijadikan dasar keputusan: interval itu dihitung ulang setiap kali kasus masuk, dan interval yang diperiksa berulang kali sampai terlihat bagus bukan lagi interval 95%. Tidak ada yang menghentikan eksekusi lebih awal berdasarkan interval itu. Keputusan diambil satu kali, atas bukti yang sudah lengkap, dengan metode yang disebutkan kebijakan.

Di luar terminal, misalnya di CI, tampilan langsung tidak digambar dan tabel-tabelnya dicetak satu kali, di akhir.

Aliran peristiwa

--json menulis progres yang sama sebagai satu objek JSON per baris di standard output, dan tabel-tabelnya di standard error:

oloproof run --json

Sebuah eksekusi 120 kasus, disimpan ke run.ndjson dan dihitung dengan jq -r '.type' run.ndjson | sort | uniq -c, menghasilkan:

 120 case_executed
 120 case_judged
  11 provisional_metrics
   1 run_finished
   2 run_phase_changed
   1 run_started

Masing-masing membawa id eksekusi dan stempel waktu:

{"run_id":"run_01M3C3ZNXPVQJCDF31DJSBXBHC","timestamp":"2026-09-25T11:07:37.782628Z","type":"run_started","suite_digest":"sha256:c6ae32f25d38ddac175f688c15c40991c1e0ec5348f32bfabd9c493a3f688c28","cases":120}
{"run_id":"run_01M3C3ZNXPVQJCDF31DJSBXBHC","timestamp":"2026-09-25T11:07:37.885640Z","type":"case_executed","scenario_id":"q000","status":"OK","from_cache":false,"latency_ms":102.11420899941004}
{"run_id":"run_01M3C3ZNXPVQJCDF31DJSBXBHC","timestamp":"2026-09-25T11:07:37.885667Z","type":"case_judged","scenario_id":"q000","criterion":"exact_label","status":"OK","passed":true,"score":null,"from_cache":false}
{"run_id":"run_01M3C3ZNXPVQJCDF31DJSBXBHC","timestamp":"2026-09-25T11:07:41.362779Z","type":"run_finished","status":"DECIDED","completeness":"COMPLETE","exit_code":0}

provisional_metrics membawa interval Wilson berjalan untuk setiap metrik biner:

jq -c 'select(.type == "provisional_metrics") | [.cases_done, .metrics[0].estimate, .metrics[0].wilson_lower, .metrics[0].wilson_upper]' run.ndjson

[1,1.0,0.20654931411298355,1.0]
[13,0.8461538461538461,0.5776536895684791,0.9567418216820717]
[25,0.88,0.7004420606159933,0.9583318285288502]
[37,0.8918918918918919,0.7529146844205937,0.9571481006263428]

Jangan menutup pipe terlalu awal. Pembaca yang berhenti setelah beberapa baris pertama, seperti head, mengakhiri eksekusi sebelum eksekusi itu menyimpan kasus-kasus terakhirnya, dan eksekusi tersebut direkam sebagai RUN_ERROR/PARTIAL.

Berapa banyak lagi yang diperlukan untuk memutuskan

Aturan yang terbaca INSUFFICIENT_EVIDENCE belum gagal; suite-nya terlalu kecil untuk memisahkan hasil dari ambang batas. oloproof plan menyatakan seberapa besar suite itu perlu diperbesar, dengan biaya yang dihitung dari apa yang sudah dihabiskan eksekusi tersebut. Untuk examples/support_bot/ yang berisi delapan belas kasus:

oloproof plan RUN_ID --run

Run run_01M3C3WS0SBTFAG55M7ECM1EZ4
  observed  18 cases

exact-label-floor: about 1614 more cases would decide it, if the observed rate holds (1632 in total)
  time      <1s – 27s
  tokens    none reported by this run's providers
  assuming  the cases to come resemble the 18 already run
            cases run one after another; concurrency divides the time and not the cost

Penentuan ukuran untuk aturan eksekusi hanya diterima untuk rasio lolos/gagal. Pada rata-rata, rencana menyatakan hal itu alih-alih menebak:

Run run_01M3C3W5YWJY65X9YM6N02F3W4: no sample size can be computed for a rule that did not decide.
  error-budget: sizing a run rule is admitted for binary rates only, and days_error is a MEAN metric: a run stores its summary, not the per-case values sizing one would need

Jika diberi id perbandingan, perintah ini merencanakan aturan-aturan perbandingan tersebut, dan tidak memerlukan flag.

Langkah selanjutnya

Merekam apa yang dilakukan sistem membahas angka latensi dan token yang menjadi

dasar perhitungan biaya estimasi ini.

Menjalankan di CI membahas cara membaca aliran peristiwa dari sebuah skrip.