Hướng dẫn

Tiến trình và mức đồng thời

Một bộ kiểm thử chạy với một mô hình thực tế mất vài phút, và phần lớn thời gian đó là chờ mô hình. Trang này trình bày Oloproof giữ bao nhiêu lời gọi đang diễn ra cùng lúc, những gì nó hiển thị cho bạn trong khi chúng chạy, và cách tìm ra cần chạy thêm bao nhiêu nữa để phân định một quy tắc chưa được quyết định.

Mức đồng thời

concurrency: trong oloproof.yaml giới hạn số lời gọi đang diễn ra cùng một lúc:

concurrency:
  system: 4
  judge: 4

system giới hạn các lời gọi tới hệ thống đang được kiểm thử và mặc định là 8. judge giới hạn các lời gọi tới giám khảo LLM và mặc định là 4. Chúng được tách riêng vì hai loại lời gọi này thường chịu các giới hạn tốc độ (rate limit) khác nhau.

Một trăm hai mươi trường hợp với một hệ thống mất một phần mười giây cho mỗi lời gọi:

system:	Thời gian thực
1	13,4 giây
16	1,7 giây
không đổi, chạy lại	0,4 giây

Hàng cuối cùng là nhờ bộ nhớ đệm, không phải mức đồng thời: mọi lần thực thi đều được tái sử dụng. Mức đồng thời không phải là một phần danh tính của hệ thống, nên thay đổi nó không bao giờ làm mất hiệu lực những gì đã được lưu.

Mỗi trường hợp là một lời gọi riêng. Oloproof không gom các trường hợp vào batch API của một nhà cung cấp, nên mức giảm giá cho batch của nhà cung cấp không khả dụng thông qua nó; mức đồng thời và bộ nhớ đệm mới là những thứ giúp một lần chạy nhanh hơn.

Thử lại

Một nhà cung cấp giám khảo hoặc một hệ thống HTTP trả về 429 hoặc một mã 5xx, hết thời gian chờ, hoặc ngắt kết nối sẽ được thử lại có backoff, tối đa bốn lần, và không bao giờ sớm hơn mức mà header Retry-After yêu cầu. Một hệ thống dạng callable chủ động tham gia bằng cách ném ra TransientError từ oloproof với retryable=True:

from oloproof import TransientError, system


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

retryable mặc định là False. Không có nó, lỗi được ghi trên trường hợp, và trường hợp đó bị tính là thiếu thay vì được thử lại. Một hệ thống ném lỗi theo cách đó ở lần gọi đầu tiên cho mỗi trường hợp trong ba mươi trường hợp, và trả lời ở lần gọi thứ hai:

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

Cùng hệ thống đó khi bỏ retryable=True:

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

Những gì một lần chạy hiển thị trong khi chạy

Trong terminal, oloproof run vẽ lại một khung nhìn trực tiếp trên standard error: số trường hợp đã xong, số lần trúng bộ nhớ đệm, số lỗi, và một ước lượng tạm thời cho mỗi chỉ số nhị phân. Một khung hình:

                    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.

Chú thích chính là quy tắc. Một khoảng tạm thời là một khoảng Wilson trên những gì đã hoàn tất, là thứ hữu ích để theo dõi nhưng không phải để dựa vào mà quyết định: nó được tính lại khi các trường hợp đến, và một khoảng được kiểm tra lặp đi lặp lại cho đến khi trông có vẻ ổn thì không còn là khoảng 95% nữa. Không có gì dừng một lần chạy sớm dựa trên nó. Quyết định được đưa ra một lần, trên bằng chứng đã hoàn tất, bằng phương pháp mà chính sách nêu tên.

Bên ngoài terminal, chẳng hạn trong CI, khung nhìn trực tiếp không được vẽ và các bảng được in ra một lần, ở cuối.

Luồng sự kiện

--json ghi cùng thông tin tiến trình đó dưới dạng mỗi dòng một đối tượng JSON trên standard output, và các bảng trên standard error:

oloproof run --json

Một lần chạy 120 trường hợp, được lưu vào run.ndjson và được đếm bằng jq -r '.type' run.ndjson | sort | uniq -c, phát ra:

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

Mỗi sự kiện mang id của lần chạy và một dấu thời gian:

{"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 mang khoảng Wilson đang chạy cho mỗi chỉ số nhị phân:

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]

Đừng đóng pipe sớm. Một trình đọc dừng lại sau vài dòng đầu, chẳng hạn head, sẽ kết thúc lần chạy trước khi nó lưu các trường hợp cuối cùng, và lần chạy được ghi nhận là RUN_ERROR/PARTIAL.

Cần thêm bao nhiêu để quyết định

Một quy tắc cho kết quả INSUFFICIENT_EVIDENCE không phải là đã thất bại; bộ kiểm thử quá nhỏ để tách kết quả khỏi ngưỡng. oloproof plan cho biết bộ kiểm thử cần lớn hơn bao nhiêu, với chi phí ước tính dựa trên những gì lần chạy đã tiêu tốn. Với examples/support_bot/ gồm mười tám trường hợp:

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

Việc ước tính cỡ mẫu cho một quy tắc của lần chạy chỉ được chấp nhận cho các tỷ lệ đạt/không đạt. Với một giá trị trung bình, kế hoạch nói rõ điều đó thay vì phỏng đoán:

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

Nếu thay vào đó bạn đưa vào một id so sánh, nó lập kế hoạch cho các quy tắc của so sánh, và không cần cờ nào.

Ghi lại những gì một hệ thống đã làm trình bày các số liệu độ trễ và token mà các

ước tính này dựa vào để tính chi phí.