Hãy lấy một golden panel gồm 58 trường hợp và một trợ lý tài liệu đang chạy thật, trả lời từ một chỉ mục tìm kiếm thật, rồi so sánh khi bật và khi tắt reranker của nó. Nếu chỉ đọc các ước lượng điểm, reranker nâng tỷ lệ câu trả lời có trang xếp hạng đầu là trang đúng từ 61,8% lên 74,5%. Điều đó trông như tiến bộ, và trong một bản cập nhật tình hình, nó thường được báo cáo là mức tăng 12,7 điểm.
Chạy cùng một nhánh hai lần mà không thay đổi gì, độ chính xác của câu trả lời ra 71,2%, rồi 76,0%. Đo lại với ba lần lặp cho mỗi trường hợp, khoảng một trong chín trường hợp quan sát được đã đổi phán quyết giữa các lần đo giống hệt nhau: 6 trên 54 về độ chính xác, 7 trên 57 về trang xếp hạng đầu.
Lý do không phải là phép đo bị hỏng. Mà là một chênh lệch trên 58 trường hợp, trong đó có một số hoàn toàn không đo được, vẫn nằm gọn trong mức nhiễu mà riêng mẫu có thể tạo ra. Chính khoảng, chứ không phải ước lượng điểm, cho bạn biết liệu bạn đã học được điều gì hay chưa.
Cần báo cáo gì
Ba con số, theo thứ tự này: chênh lệch, khoảng của nó, và số trường hợp đứng sau nó. Thiếu bất kỳ con số nào thì người đọc không thể đánh giá nhận định đó. Đây là lần chạy ấy, bật reranker so với tắt reranker, ghép cặp theo từng trường hợp, tính bằng điểm:
| Trường hợp ghép cặp | Chỉ số | Chênh lệch | Khoảng 95% | Đọc là |
|---|---|---|---|---|
| 48 | Trang đúng ở hạng 1 | +6.2 | −36.3 … +45.5 | Chưa kết luận |
| 46 | Câu trả lời đúng | +6.5 | −39.4 … +48.4 | Chưa kết luận |
| 27 | Trang đúng trong top 3 | +3.7 | −73.9 … +76.2 | Chưa kết luận |
Mọi khoảng đều cắt qua số không, và cắt rất rộng. Các ước lượng điểm đều nói reranker có ích; các khoảng nói panel này không thể cho biết nó giúp ích hay gây hại. Bản thân điều đó đã là một phát hiện: panel quá nhỏ, và mất quá nhiều dữ liệu, để giải quyết câu hỏi mà nó được dùng để giải quyết.
Thiếu không phải là số không
Bốn trong số 58 lệnh gọi trả về HTTP 500 từ hệ thống đang được kiểm thử, và hai lệnh gọi giám khảo không trả về phán quyết nào có thể phân tích được. Một harness lấy trung bình một trường hợp chưa chấm như số không sẽ ghi sáu trường hợp đó là trợ lý thất bại: sáu thất bại bị tạo ra trên 58. Oloproof ghi chúng là thiếu và nới rộng khoảng để bao trọn bất kể giá trị của chúng có thể là gì.
Đó chính là điều mà hàng thứ ba đang tính đến. Chỉ 27 trên 58 trường hợp đo được ở ngưỡng cắt ba trang xếp hạng, và khoảng tính đến 31 trường hợp còn lại thay vì che giấu chúng.
Panel nhỏ vẫn qua cổng
Quy tắc tương tự cũng đúng ở đầu nhỏ. Một lần chạy smoke gồm ba trường hợp đạt điểm 1,000, với khoảng 95% từ 0,292 đến 1,000. Một cổng so sánh ước lượng điểm với mục tiêu sẽ cho phát hành nó. Một cổng đọc khoảng thì nói lên sự thật: ba trường hợp không thể phân biệt một hệ thống hoàn hảo với một hệ thống chỉ đúng ba lần trên mười.
Thu hẹp khoảng
Nhiều trường hợp hơn sẽ thu hẹp một khoảng, và mất ít trường hợp hơn cũng vậy. Trên cùng panel đó, khai báo các lỗi HTTP 500 của hệ thống là tạm thời, để runner thử lại chúng, đã khôi phục 18 trên 22 trường hợp bị thiếu và thu hẹp khoảng 39%, chỉ vài phút sau, mà không thay đổi gì khác.
Một chênh lệch có khoảng vượt qua ngưỡng sẽ hỗ trợ một quyết định, bất kể độ lớn của nó, và đó là thứ mà một cổng nên dựa vào để hành động. Cho đến lúc đó, hãy báo cáo chênh lệch, khoảng của nó và các trường hợp đứng sau nó, và nói rằng câu trả lời vẫn chưa có.
Muốn điều này được tính sẵn cho bạn ở mỗi thay đổi?
Liên hệ với chúng tôi