Trường hợp theo cụm

Phần lớn các phép tính khoảng đều giả định mọi trường hợp độc lập với mọi trường hợp khác. Ba lượt của cùng một cuộc hội thoại thì không: khi cuộc hội thoại đi sai hướng, cả ba lượt thường đều sai theo. Một bộ kiểm thử coi chúng là độc lập sẽ báo cáo một khoảng hẹp hơn mức bằng chứng cho phép, và một cổng có thể đạt dựa trên khoảng đó.

Khai báo một cụm

Một trường hợp nêu tên cụm của nó bằng group_id, ở cấp cao nhất của hàng, bên cạnh id:

{"id": "conv00_t0", "group_id": "conv00", "input": {"question": "Conversation 0 turn 0: refund please (garbled)"}, "expected": {"label": "refund"}}
{"id": "conv00_t1", "group_id": "conv00", "input": {"question": "Conversation 0 turn 1: where is my order (garbled)"}, "expected": {"label": "other"}}
{"id": "conv00_t2", "group_id": "conv00", "input": {"question": "Conversation 0 turn 2: refund please (garbled)"}, "expected": {"label": "refund"}}

Chỉ cần một trường hợp khai báo cụm, toàn bộ bộ kiểm thử sẽ được phân tích theo cụm. Không có công tắc theo từng chỉ số để quay lại: coi các trường hợp đã nhóm là độc lập là hướng không an toàn, nên tùy chọn đó không được cung cấp.

Điều gì thay đổi

Cùng 108 lượt từ 36 cuộc hội thoại, cứ sáu cuộc hội thoại thì có một cuộc bị lỗi nội dung từ lượt đầu tiên đến lượt cuối cùng. Không có group_id:

│ exact_label │ 83.3%    │ [74.9%, 89.9%] │ 90 / 108 observed · 0 missing · 0 excluded │

Có group_id:

│ exact_label │ 83.3%    │ [65.2%, 94.6%] │ 90 / 108 observed · 0 missing · 0 excluded · 36 clusters · approximate │

Ước lượng giống hệt nhau. Khoảng rộng gần gấp đôi, vì bộ kiểm thử chứa 36 quan sát độc lập chứ không phải 108. Với một ngưỡng sàn 0.70, và với tùy chọn chủ động được mô tả bên dưới, lần chạy đầu tiên đạt còn lần thứ hai thì không:

label-floor: PASS (lower_bound_meets_minimum)

label-floor: INSUFFICIENT_EVIDENCE (interval_overlaps_threshold)

Câu trả lời thứ hai là câu trả lời đúng cho dữ liệu này.

Tùy chọn chủ động

Khoảng theo cụm là một phép bootstrap cụm có chuẩn hóa student (studentized cluster bootstrap). Đây là một phương pháp xấp xỉ, và một chính sách phải nói rõ rằng nó chấp nhận phương pháp xấp xỉ trước khi một quy tắc được phép quyết định dựa trên đó. Nếu không, cùng lần chạy đã nhóm đó sẽ cho kết quả:

label-floor: MANUAL_REVIEW (approximate_method_not_permitted)

và thoát với mã 4. Để cho phép quy tắc quyết định, hãy thêm dòng này vào release.yaml:

allow_approximate_methods: true

Hai thiết lập nữa giới hạn phạm vi mà phương pháp này được tin cậy.

Một chính sách đặt min_clusters: 5 sẽ bị từ chối trước khi có bất cứ điều gì được quyết định:

Configuration error: p5.yaml: min_clusters: Input should be greater than or equal to 10

Cùng các cuộc hội thoại đó, với một cuộc gặp lỗi ở mọi lượt:

│ exact_label │ 82.9%    │ [64.3%, 94.5%] │ 87 / 105 observed · 3 missing · 0 excluded · 35 clusters · approximate │

label-floor: INSUFFICIENT_EVIDENCE (missingness_unbounded)

Một quy tắc nêu rõ mức thiếu mà nó chấp nhận:

rules:
  - id: label-floor
    metric: exact_label
    min: 0.60
    max_missing_fraction: 0.15

label-floor: PASS (lower_bound_meets_minimum)

Việc nêu một tỷ lệ là ghi lại một giả định: rằng các trường hợp thiếu bị thiếu một cách ngẫu nhiên. Quyết định chỉ tốt bằng giả định đó, và đó là lý do engine sẽ không đưa ra giả định đó thay bạn.

Những gì một bộ kiểm thử theo cụm chưa làm được

Chỉ các tỷ lệ đạt/không đạt mới có khoảng theo cụm. Trên một bộ kiểm thử khai báo group_id:

• một giá trị trung bình, một phân vị hoặc một chỉ số xếp hạng không có khoảng, và một quy tắc trên

các chỉ số đó cho kết quả MANUAL_REVIEW với unsupported_dependence_structure;

• với replicates: lớn hơn 1, không chỉ số nào có khoảng, kể cả các tỷ lệ đạt/không đạt, vì hai cấu

trúc phụ thuộc kết hợp với nhau và không có gì mô hình hóa được cả hai;

• một so sánh giữa hai lần chạy không có khoảng cho bất kỳ chỉ số nào.

Một phân vị độ trễ trên bộ kiểm thử đã nhóm:

│ latency_p50 │ 1.365 ms │ no interval: unsupported_dependence_structure │ p50 of 108 observed · 0 missing · 0 excluded │

Hạn chế cuối cùng là quan trọng nhất. So sánh hai lần chạy của bộ kiểm thử hội thoại, trong đó ứng viên sửa được mọi cuộc hội thoại bị lỗi nội dung:

oloproof compare CANDIDATE_RUN_ID BASELINE_RUN_ID --policy compare.yaml

Comparison sha256:ed7820e6471f70ce2b5e16ba618fdd48ea92a5ed39d23cce0b719ab31fcb16af of run_01M3C43MWTH8127R7S5M4N9DQ9 against run_01M3C43J2DVM93EWWWRBMRW22E · 108 paired cases
exact_label: +16.7 points · 108 paired · 0 missing · 0 excluded
  no interval: unsupported_dependence_structure
Decisions
  no-regression  exact_label  non-inferiority, margin 5.0 points  MANUAL_REVIEW  unsupported_dependence_structure
Gate: BLOCK (exit 4)

Chưa có thủ tục ghép cặp nào cho bộ kiểm thử theo cụm vượt qua lưới kiểm định của nó, nên so sánh chỉ báo cáo chênh lệch và hỏi một người thay vì quyết định một cách xấp xỉ. Là MANUAL_REVIEW chứ không phải INSUFFICIENT_EVIDENCE, vì thêm nhiều trường hợp cùng loại cũng không giải quyết được vấn đề.

Tiếp theo

• Quy tắc so sánh trình bày các quy tắc dùng để quyết định một so sánh.
• Khái niệm cốt lõi trình bày bốn trạng thái quyết định.