Hướng dẫn

Hướng dẫn: một bộ phân loại và một bộ hồi quy

Một bài hướng dẫn có thể chạy được cho ba mô hình dự đoán được đánh giá từ dòng lệnh: một bộ phân loại churn nhị phân, một bộ định tuyến ticket ba lớp được đánh giá từng lớp một, và một bộ hồi quy thời gian giao hàng được chấm bằng sai số tuyệt đối trong một khoảng giá trị đã khai báo. Mỗi mô hình chạy cục bộ không cần nhà cung cấp, không cần khóa và không cần mạng, và mỗi phần kết thúc bằng một thay đổi ứng viên được đo so với đường cơ sở.

Trang này là phần thực hành đi kèm Bộ phân loại và bộ hồi quy, trang giải thích mọi trường; hãy đọc trang đó để tham chiếu và trang này để làm một lần từ đầu đến cuối. Các thuật ngữ như khoảng, trạng thái quyết định và hành động phát hành được định nghĩa trong Khái niệm.

Oloproof đo gì cho một mô hình dự đoán, và không đo gì

Mô hình	Bạn nhận được gì	Bạn không nhận được gì
Bộ phân loại nhị phân	accuracy, recall, precision, điểm Brier, log loss, ROC-AUC và average precision, cùng với số đếm nhầm lẫn, một bảng hiệu chuẩn và một phép quét ngưỡng	một ngưỡng được khuyến nghị
Bộ phân loại đa lớp	một recall và một precision cho mỗi lớp, mỗi cái là một chỉ số nhị phân có lớp dương là lớp đó (một so với phần còn lại)	một chỉ số trung bình macro hoặc micro
Bộ hồi quy	sai số tuyệt đối trung bình, bị chặn bởi một target_range mà bạn khai báo	sai số bình phương, R bình phương, hoặc bất kỳ sai số nào không có khoảng giá trị được khai báo

Bản thân mô hình vẫn là của bạn. Oloproof gọi một hàm Python mà bạn trỏ nó tới, đọc dự đoán mà hàm trả về, và không bao giờ thấy đặc trưng, trọng số hay phần bên trong.

Điều kiện tiên quyết

Python 3.11 trở lên và pip install oloproof trong một môi trường ảo, như trong phần bắt đầu nhanh.
Các tệp ví dụ, đi kèm với gói. Sao chép chúng vào một thư mục mới để kho lưu trữ của các lần chạy nằm ở đó:

oloproof init --example predictive ~/oloproof-predictive
cd ~/oloproof-predictive

Mọi lệnh bên dưới chạy từ một trong ba thư mục con của nó. Mỗi lần chạy ghi bằng chứng của nó vào một thư mục .oloproof/ bên cạnh tệp oloproof.yaml mà nó đã đọc.

predictive/
  binary/        app.py  oloproof.yaml  candidate.yaml  release.yaml  comparison.yaml  data/accounts.jsonl
  multiclass/    app.py  oloproof.yaml  candidate.yaml  release.yaml  data/tickets.jsonl
  regression/    app.py  oloproof.yaml  candidate.yaml  release.yaml  data/orders.jsonl

Phần 1: một bộ phân loại nhị phân

Adapter

binary/app.py chứa mô hình và adapter trong một tệp. Mô hình là cùng mô hình churn tất định như ví dụ churn_model (oloproof init --example churn_model); adapter là hàm được trang trí mà Oloproof gọi:

from oloproof import system


@system(name="churn-model", version="baseline")
def run(account):
    score = churn_score(account)
    return {"label": score >= 0.5, "score": round(score, 4)}


@system(name="churn-model", version="candidate-cutoff-0.4")
def run_candidate(account):
    score = churn_score(account)
    return {"label": score >= 0.4, "score": round(score, 4)}

Để đánh giá mô hình của chính bạn, hãy giữ hình dạng này và thay churn_score bằng một lời gọi tới nó, ví dụ model.predict_proba([features(account)])[0][1] cho một mô hình scikit-learn mà bạn tải một lần khi import. Đổi version mỗi khi mô hình hoặc ngưỡng cắt của nó thay đổi: phiên bản là một phần của khóa bộ nhớ đệm, nên một mô hình được huấn luyện lại dưới cùng phiên bản sẽ tái sử dụng các dự đoán cũ.

Hình dạng đầu vào và đầu ra

Một dòng của data/accounts.jsonl là một trường hợp:

{"expected": {"label": false}, "id": "account_000", "input": {"recent_upgrade": true, "support_contacts": 0, "tenure_months": 0}, "metadata": {"plan": "enterprise"}}

Phần	Hình dạng	Ai đọc nó
input	đối tượng mà hàm của bạn nhận	adapter của bạn
expected.label	true hoặc false, sự thật	các bộ đánh giá
metadata.plan	bất kỳ JSON nào	chỉ các lát cắt
label được trả về	true hoặc false, dự đoán	các bộ đánh giá
score được trả về	một số trong [0, 1], xác suất của lớp dương	Brier, log loss, xếp hạng, hiệu chuẩn, quét ngưỡng

Các bộ đánh giá, và vì sao chọn chúng

binary/oloproof.yaml:

version: 1
project: churn-tutorial
dataset: data/accounts.jsonl
system:
  name: churn-model
  version: baseline
  callable: app:run
evaluators:
  - {type: predictive_correct, criterion: accuracy}
  - {type: predictive_recall, criterion: recall}
  - {type: predictive_precision, criterion: precision}
  - {type: predictive_brier, criterion: brier}
  - {type: predictive_log_loss, criterion: log_loss, clip: 0.02}
  - {type: predictive_ranking, criterion: rank}
metrics:
  - {id: roc_auc, type: ranking, criterion: rank, statistic: roc_auc}
  - {id: pr_auc, type: ranking, criterion: rank, statistic: average_precision}
predictive:
  label_field: label
  score_field: score
  expected_field: label
  positive: true
  calibration_bins: 10
  thresholds: [0.3, 0.4, 0.5, 0.6, 0.7]
slices: [metadata.plan, "confidence:0.5"]
min_slice_support: 20

Accuracy, recall và precision là ba tỷ lệ trên ba tập dòng khác nhau: mọi tài khoản, các tài khoản đã churn, và các tài khoản mà mô hình đánh dấu. Một mô hình churn cần cả ba vì khoảng một phần ba số tài khoản churn, nên một mô hình dự đoán không ai churn có accuracy 68% và không tìm ra ai cả.
Brier và log loss chấm điểm xác suất đằng sau nhãn. Log loss cần clip, vì nếu không thì một lỗi tự tin sẽ là vô hạn.
predictive_ranking cùng hai mục metrics: cho ra ROC-AUC và average precision. Chúng trả lời mô hình sắp thứ tự các tài khoản tốt đến đâu, tách biệt với vị trí của ngưỡng cắt.
Khối predictive: cho biết nhãn, điểm số và sự thật nằm ở đâu, và tạo ra số đếm nhầm lẫn, bảng hiệu chuẩn và phép quét ngưỡng bên cạnh các chỉ số.

Chính sách

binary/release.yaml đặt một mức sàn cho mỗi tỷ lệ:

version: 1
confidence_level: 0.95
block_on: [FAIL, INSUFFICIENT_EVIDENCE, MANUAL_REVIEW]
rules:
  - {id: accuracy-floor, metric: accuracy, min: 0.75}
  - {id: recall-floor, metric: recall, min: 0.60}
  - {id: precision-floor, metric: precision, min: 0.60}

Một quy tắc đạt khi cận dưới của khoảng vượt qua mức sàn, thất bại khi cận trên nằm dưới nó, và trong trường hợp còn lại ghi INSUFFICIENT_EVIDENCE.

Chạy

cd binary
oloproof run

Đã rút gọn:

Run run_... [DECIDED/COMPLETE]
Gate: ALLOW (exit 0)
│ accuracy-floor  │ accuracy  │ PASS  │ lower_bound_meets_minimum │
│ recall-floor    │ recall    │ PASS  │ lower_bound_meets_minimum │
│ precision-floor │ precision │ PASS  │ lower_bound_meets_minimum │

│ accuracy  │ 88.5%    │ [83.2%, 92.6%]  │ 177 / 200 observed · 0 missing · 0 excluded                                │
│ recall    │ 81.2%    │ [69.5%, 90.0%]  │ 52 / 64 observed · 0 missing · 136 excluded                                │
│ precision │ 82.5%    │ [70.9%, 91.0%]  │ 52 / 63 observed · 0 missing · 137 excluded                                │
│ brier     │ 0.120    │ [0.094, 0.154]  │ mean of 200 observed · 0 missing · 0 excluded                              │
│ log_loss  │ 0.389    │ [0.323, 0.499]  │ mean of 200 observed · 0 missing · 0 excluded                              │
│ roc_auc   │ 92.3%    │ [69.3%, 100.0%] │ roc_auc over 64 positive · 136 negative · 0 missing · 0 excluded           │
│ pr_auc    │ 86.5%    │                 │ average_precision over 64 positive · 136 negative · 0 missing · 0 excluded │

Cách đọc:

Gate: ALLOW (exit 0) nghĩa là không quy tắc nào rơi vào một trạng thái mà chính sách chặn. Nó không khẳng định rằng mô hình tốt ngoài ba mức sàn mà bạn đã viết.
Các số đếm excluded là mẫu số đang hoạt động: recall được đo trên 64 tài khoản đã churn, nên 136 tài khoản không churn bị loại khỏi nó, không bị tính là thất bại.
pr_auc không có khoảng. Ở 200 dòng, engine giữ lại một cận mà nó không thể bảo đảm; một quy tắc trên nó sẽ ghi INSUFFICIENT_EVIDENCE với interval_unavailable.

Bên dưới các chỉ số, cùng đầu ra đó in số đếm nhầm lẫn, bảng hiệu chuẩn và phép quét ngưỡng:

│ actually positive │ 52                 │ 12                 │
│ actually negative │ 11                 │ 125                │

│ 0.2-0.3 │ 26.7%   │ 0.0%     │ 34 rows │
│ 0.5-0.6 │ 53.4%   │ 81.0%    │ 21 rows │

│ 0.3     │ 57.4%     │ 96.9%  │ 62/108 predicted positive · 62/64 actual positive │
│ 0.4     │ 62.6%     │ 89.1%  │ 57/91 predicted positive · 57/64 actual positive  │
│ 0.5     │ 82.5%     │ 81.2%  │ 52/63 predicted positive · 52/64 actual positive  │
│ 0.6     │ 83.3%     │ 54.7%  │ 35/42 predicted positive · 35/64 actual positive  │
│ 0.7     │ 100.0%    │ 37.5%  │ 24/24 predicted positive · 24/64 actual positive  │

Các số đếm không phải tỷ lệ và không quy tắc nào được nêu chúng. Các dòng hiệu chuẩn cho thấy xác suất của mô hình bị lệch: trong dải 0.2 tới 0.3 nó khẳng định khoảng một trên bốn người sẽ churn nhưng không ai trong 34 người đã churn. Phép quét có tiêu đề Thresholds (exploratory; recommends nothing): nó cho thấy mỗi ngưỡng cắt lẽ ra đã đo được gì và để lựa chọn cho bạn, vì chỉ bạn mới biết một người churn bị bỏ sót tốn kém thế nào so với một cuộc gọi giữ chân lãng phí.

Xem xét các thất bại

oloproof inspect RUN_ID --failures --limit 5

23 of 200 cases failed, errored or did not finish

account_032
  output: {"label": false, "score": 0.07}
  accuracy: failed
  recall: failed

account_037
  output: {"label": false, "score": 0.37}
  accuracy: failed
  recall: failed
...

RUN_ID là mã ở dòng đầu tiên trong đầu ra của lần chạy. oloproof inspect RUN_ID --case account_037 cho thấy đầu vào, giá trị kỳ vọng, đầu ra và mọi phán quyết của một trường hợp. Nhiều người churn bị bỏ sót nằm ngay dưới ngưỡng cắt 0.5 (0.37, 0.43), điều mà dòng 0.4 của phép quét đã gợi ý.

Một hành động tiếp theo có ý nghĩa đến từ những gì bạn thấy, không phải từ cổng: ở đây các lần bỏ sót tụ lại dưới ngưỡng cắt, nên ứng viên thử một ngưỡng thấp hơn. Nếu chúng là những lần bỏ sót tự tin (0.07), hành động tiếp theo sẽ là các đặc trưng của mô hình, và không ngưỡng cắt nào giúp được.

Một thay đổi ứng viên, và phép so sánh

binary/candidate.yaml là oloproof.yaml với hai dòng được thay đổi:

system:
  name: churn-model
  version: candidate-cutoff-0.4
  callable: app:run_candidate

oloproof run --config candidate.yaml

Gate: BLOCK (exit 3)
│ accuracy-floor  │ accuracy  │ INSUFFICIENT_EVIDENCE │ interval_overlaps_threshold │
│ recall-floor    │ recall    │ PASS                  │ lower_bound_meets_minimum   │
│ precision-floor │ precision │ INSUFFICIENT_EVIDENCE │ interval_overlaps_threshold │

│ accuracy  │ 79.5%    │ [73.2%, 84.9%]  │ 159 / 200 observed · 0 missing · 0 excluded                                │
│ recall    │ 89.1%    │ [78.7%, 95.5%]  │ 57 / 64 observed · 0 missing · 136 excluded                                │
│ precision │ 62.6%    │ [51.8%, 72.6%]  │ 57 / 91 observed · 0 missing · 109 excluded                                │

Đúng như dòng 0.4 của phép quét: recall tăng, precision giảm. Mã thoát 3 là INSUFFICIENT_EVIDENCE, không phải FAIL: các mức sàn nằm bên trong các khoảng, nên 200 tài khoản không thể nói ứng viên nằm ở phía nào. Điểm số không thay đổi, nên Brier, log loss và ROC-AUC giống hệt.

Giờ hãy so sánh hai lần chạy từng trường hợp một. binary/comparison.yaml chứa các quy tắc so sánh:

version: 1
confidence_level: 0.95
block_on: [FAIL, INSUFFICIENT_EVIDENCE, MANUAL_REVIEW]
rules:
  - {id: recall-no-worse, kind: non_inferiority, metric: recall, margin: 0.05}
  - {id: accuracy-no-worse, kind: non_inferiority, metric: accuracy, margin: 0.05}

oloproof compare CANDIDATE_RUN_ID BASELINE_RUN_ID --policy comparison.yaml

Comparison sha256:... of run_... against run_... · 200 paired cases
accuracy: -9.0 points [-17.9, -1.4] · 200 paired · 0 missing · 0 excluded
recall: +7.8 points [-2.8, +21.9] · 64 paired · 0 missing · 136 excluded
  excluded 136: not_a_positive_case
precision: +0.0 points [-8.3, +8.3] · 63 paired · 0 missing · 137 excluded
  excluded 137: not_predicted_positive
...
Decisions
  recall-no-worse  recall  non-inferiority, margin 5.0 points  PASS  lower_bound_above_margin
  accuracy-no-worse  accuracy  non-inferiority, margin 5.0 points  INSUFFICIENT_EVIDENCE  interval_overlaps_margin
    no sample size would make this PASS: the difference itself (-9.0 points) is outside the margin, so more cases would move it toward FAIL
Gate: BLOCK (exit 3)

Hãy đọc kỹ dòng precision. Precision của chính ứng viên giảm từ 82,5% xuống 62,6%, vậy mà khác biệt ghép cặp là +0.0 trên 63 cặp. Một phép so sánh ghép các dòng: một khác biệt precision chỉ được đo trên các tài khoản mà cả hai mô hình đều đánh dấu, và trên 63 tài khoản đó cả hai đều đúng. 28 tài khoản mà ứng viên đánh dấu thêm, 23 trong số đó là báo động giả, nằm ngoài tập đó. Đó là lý do comparison.yaml bảo vệ accuracy thay vì precision cho một thay đổi ngưỡng cắt; Quy tắc so sánh có các loại quy tắc.

Quyết định là phần hữu ích: recall được chứng minh là không tệ hơn, và accuracy không thể được chứng minh nằm trong năm điểm; dòng tư vấn nói thêm dữ liệu sẽ đẩy nó về phía FAIL. Việc đổi chín điểm accuracy lấy tám điểm recall có đáng hay không là một quyết định kinh doanh mà cổng đã làm cho hiện rõ.

Phần 2: một bộ phân loại đa lớp, từng lớp một

multiclass/app.py định tuyến một ticket hỗ trợ tới một trong ba hàng đợi, và có một lỗi cố ý: mọi ticket gửi từ ứng dụng di động đều đi tới technical.

@system(name="ticket-router", version="baseline")
def route(ticket):
    if ticket["channel"] == "app":
        return {"queue": "technical"}
    return {"queue": classify(str(ticket["subject"]))}

Một trường hợp:

{"expected": {"queue": "billing"}, "id": "ticket_000", "input": {"channel": "email", "subject": "update the card on file"}, "metadata": {"channel": "email"}}

Không có chỉ số đa lớp nào để bật. Mỗi lớp có khối nhị phân của riêng nó: recall cho billing là recall nhị phân có lớp dương là billing. multiclass/oloproof.yaml:

evaluators:
  - {type: predictive_correct, criterion: accuracy, field: queue, expected_field: queue}
  - {type: predictive_recall, criterion: recall_billing, field: queue, expected_field: queue, positive: billing}
  - {type: predictive_precision, criterion: precision_billing, field: queue, expected_field: queue, positive: billing}
  - {type: predictive_recall, criterion: recall_technical, field: queue, expected_field: queue, positive: technical}
  - {type: predictive_precision, criterion: precision_technical, field: queue, expected_field: queue, positive: technical}
  - {type: predictive_recall, criterion: recall_account, field: queue, expected_field: queue, positive: account}
  - {type: predictive_precision, criterion: precision_account, field: queue, expected_field: queue, positive: account}
slices: [metadata.channel]

Oloproof không tính trung bình macro hay micro trên các chỉ số này. Nếu bạn cần một cái, đó là một con số bạn tự suy ra từ các số đếm theo lớp, và không quy tắc nào có thể làm cổng dựa trên nó. Chính sách đặt một mức sàn cho các lớp quan trọng, vì một bộ định tuyến có thể chính xác về tổng thể mà vẫn đánh mất một hàng đợi:

rules:
  - {id: billing-recall-floor, metric: recall_billing, min: 0.80}
  - {id: account-recall-floor, metric: recall_account, min: 0.80}
  - {id: technical-precision-floor, metric: precision_technical, min: 0.80}

cd ../multiclass
oloproof run

Gate: BLOCK (exit 1)
│ billing-recall-floor      │ recall_billing      │ FAIL                  │ upper_bound_below_minimum   │
│ account-recall-floor      │ recall_account      │ INSUFFICIENT_EVIDENCE │ interval_overlaps_threshold │
│ technical-precision-floor │ precision_technical │ FAIL                  │ upper_bound_below_minimum   │

│ accuracy            │ 81.3%    │ [74.1%, 87.3%]  │ 122 / 150 observed · 0 missing · 0 excluded │
│ recall_billing      │ 66.0%    │ [51.2%, 78.8%]  │ 33 / 50 observed · 0 missing · 100 excluded │
│ precision_billing   │ 100.0%   │ [89.4%, 100.0%] │ 33 / 33 observed · 0 missing · 117 excluded │
│ recall_technical    │ 100.0%   │ [92.8%, 100.0%] │ 50 / 50 observed · 0 missing · 100 excluded │
│ precision_technical │ 64.1%    │ [52.4%, 74.7%]  │ 50 / 78 observed · 0 missing · 72 excluded  │
│ recall_account      │ 78.0%    │ [64.0%, 88.5%]  │ 39 / 50 observed · 0 missing · 100 excluded │
│ precision_account   │ 100.0%   │ [90.9%, 100.0%] │ 39 / 39 observed · 0 missing · 111 excluded │

Mã thoát 1 nghĩa là ít nhất một quy tắc là FAIL. Mỗi lớp có mẫu số của riêng nó: 78 ticket được gán technical, nên đó là mẫu số của precision cho technical. Bảng lát cắt chỉ ra nguyên nhân; các lát cắt mang tính khám phá và không bao giờ làm cổng, nhưng một lát cắt được đánh dấu là một manh mối đáng đọc:

│ metadata.channel=app   │ accuracy            │ 42.9%    │ [28.8%, 57.8%]  │ 21 / 49 observed · ... │ marked (p 0.0001)    │

oloproof inspect RUN_ID --failures --limit 2

28 of 150 cases failed, errored or did not finish

ticket_011
  output: {"queue": "technical"}
  accuracy: failed
  precision_technical: failed
  recall_account: failed
...

Ứng viên (route_candidate, chạy bằng oloproof run --config candidate.yaml) bỏ lối tắt theo kênh. Trên dữ liệu tổng hợp này, nó định tuyến đúng mọi ticket và cổng cho phép:

Gate: ALLOW (exit 0)
│ billing-recall-floor      │ recall_billing      │ PASS  │ lower_bound_meets_minimum │
│ account-recall-floor      │ recall_account      │ PASS  │ lower_bound_meets_minimum │
│ technical-precision-floor │ precision_technical │ PASS  │ lower_bound_meets_minimum │

oloproof compare hoạt động ở đây đúng như trong Phần 1, mỗi chỉ số lớp một khác biệt.

Phần 3: một bộ hồi quy, được chấm bằng sai số tuyệt đối

regression/app.py ước lượng số ngày giao hàng và bỏ qua việc mặt hàng có sẵn trong kho hay không:

@system(name="delivery-estimator", version="baseline")
def estimate(order):
    return {"days": round(base_days(order), 1)}

Một trường hợp, với sự thật là một con số:

{"expected": {"days": 11}, "id": "order_000", "input": {"distance_km": 468, "express": false, "in_stock": false}, "metadata": {"in_stock": false}}

Bộ đánh giá hồi quy duy nhất là sai số tuyệt đối, và nó cần khoảng giá trị mà mọi mục tiêu nằm trong. Một sai số tuyệt đối là một trung bình bị chặn mà khoảng của nó chỉ đứng vững trong khoảng giá trị đó, nên nó được khai báo, không bao giờ lấy mặc định. Việc giao hàng ở đây mất 0 tới 20 ngày:

evaluators:
  - type: predictive_absolute_error
    criterion: days_error
    field: days
    expected_field: days
    target_range: [0, 20]
slices: [metadata.in_stock]

Chính sách là một ngân sách, một quy tắc max:: nó đạt khi cận trên của khoảng bằng hoặc thấp hơn mức đó.

rules:
  - {id: error-budget, metric: days_error, max: 2.0}

cd ../regression
oloproof run

Gate: BLOCK (exit 1)
│ error-budget │ days_error │ FAIL  │ lower_bound_above_maximum │

│ days_error │ 2.66     │ [2.01, 3.57] │ mean of 120 observed · 0 missing · 0 excluded │

│ metadata.in_stock=false │ days_error │ 5.18     │ [4.60, 6.65] │ mean of 53 observed · ... │
│ metadata.in_stock=true  │ days_error │ 0.67     │ [0.51, 2.19] │ mean of 67 observed · ... │

FAIL vì ngay cả cận dưới của khoảng cũng cao hơn ngân sách hai ngày. Một bộ đánh giá điểm số không có đạt hay thất bại theo từng trường hợp, nên oloproof inspect RUN_ID --failures không liệt kê gì; thay vào đó hãy đọc một trường hợp:

oloproof inspect RUN_ID --case order_000

output: {
  "days": 6.1
}
judgments:
  days_error: score 4.9

Lát cắt cho biết nên nhìn vào đâu: các đơn hàng hết hàng lệch năm ngày. Ứng viên (estimate_candidate) cộng thêm năm ngày cho một mặt hàng hết hàng:

oloproof run --config candidate.yaml

Gate: ALLOW (exit 0)
│ error-budget │ days_error │ PASS  │ upper_bound_meets_maximum │
│ days_error │ 0.70     │ [0.56, 1.57] │ mean of 120 observed · 0 missing · 0 excluded │

Khắc phục sự cố

Triệu chứng	Nguyên nhân và cách sửa
Configuration error: evaluator 'recall' counts 'churned' as the positive class, and no case's 'label' is 'churned'	positive: nêu một giá trị mà không trường hợp nào có. Hãy dùng giá trị đúng như nó xuất hiện dưới expected, phân biệt cả true với "true".
release rule ... refers to unknown metric 'false_positives'	Số đếm nhầm lẫn không phải chỉ số. Hãy làm cổng dựa trên recall hoặc precision.
Một bộ đánh giá hồi quy bị từ chối trước lần chạy	target_range bị thiếu hoặc rỗng. Hãy khai báo khoảng giá trị mà các mục tiêu thực sự có thể nhận; một khoảng rộng hơn cho một khoảng tin cậy rộng hơn.
Một quy tắc xếp hạng ghi INSUFFICIENT_EVIDENCE (interval_unavailable)	Bộ kiểm thử quá nhỏ cho khoảng của thống kê đó, thường là pr_auc. Hãy làm cổng dựa trên roc_auc, hoặc thêm trường hợp.
Ứng viên báo các con số của đường cơ sở	Cả hai lần chạy dùng chung một version, nên các dự đoán đã lưu đệm được tái sử dụng. Hãy cho mỗi thay đổi một phiên bản riêng.
Một trường hợp bị missing thay vì sai	Hàm của bạn đã ném lỗi, hoặc trường mà bộ đánh giá đọc bị thiếu hoặc không phải một số. oloproof inspect RUN_ID --case ID cho thấy lỗi.

Giới hạn

Không có ngưỡng được khuyến nghị. Phép quét báo mỗi ngưỡng cắt đã khai báo lẽ ra đã đo được gì.
Không có chỉ số trung bình macro hay micro cho đa lớp, và không hỗ trợ đa nhãn ngoài một khối cho mỗi nhãn.
Hồi quy chỉ là sai số tuyệt đối trong một target_range đã khai báo: không có sai số bình phương, R bình phương hay sai số không bị chặn.
Hiệu chuẩn được hiển thị dưới dạng bảng, không làm cổng và không được hiệu chỉnh.
Một khác biệt precision ghép cặp chỉ bao gồm các dòng mà cả hai mô hình đều đánh dấu, như Phần 1 cho thấy.
Các ví dụ là tất định và tổng hợp. Các quyết định của chúng cho thấy cơ chế, không phải cách một mô hình thật hành xử trên dữ liệu thật.

Bộ phân loại và bộ hồi quy là tài liệu tham chiếu theo từng trường.
So sánh một ứng viên với một đường cơ sở và Quy tắc so sánh trình bày quy trình so sánh.
Lát cắt trình bày các dải confidence: và độ hỗ trợ của lát cắt.
Cổng trong CI liệt kê các mã thoát.