Kılavuzlar

Eğitim: bir sınıflandırıcı ve bir regresör

Komut satırından değerlendirilen üç tahminsel model için çalıştırılabilir bir anlatım: ikili bir müşteri kaybı sınıflandırıcısı, her seferinde bir sınıf değerlendirilen üç sınıflı bir talep yönlendiricisi ve bildirilen bir aralık içinde mutlak hatayla puanlanan bir teslimat süresi regresörü. Her biri sağlayıcı, anahtar ve ağ olmadan yerelde çalışır ve her biri temele karşı ölçülen bir aday değişiklikle biter.

Bu sayfa, her alanı açıklayan Sınıflandırıcılar ve regresörler sayfasının uygulamalı eşlikçisidir; başvuru için o sayfayı, bir kez baştan sona yapmak için bunu okuyun. Aralık, karar durumu ve sürüm eylemi gibi terimler Kavramlar sayfasında tanımlanmıştır.

Oloproof bir tahminsel model için neyi ölçer, neyi ölçmez

Model	Ne elde edersiniz	Ne elde etmezsiniz
İkili sınıflandırıcı	doğruluk, duyarlılık, kesinlik, Brier puanı, log loss, ROC-AUC ve ortalama kesinlik; ayrıca karışıklık sayıları, bir kalibrasyon tablosu ve bir eşik taraması	önerilen bir eşik
Çok sınıflı sınıflandırıcı	sınıf başına bir duyarlılık ve bir kesinlik; her biri pozitif sınıfı o sınıf olan ikili bir metrik (biri diğerlerine karşı)	makro ya da mikro ortalama bir metrik
Regresör	bildirdiğiniz bir target_range ile sınırlanan ortalama mutlak hata	karesel hata, R kare ya da bildirilmiş bir aralığı olmayan herhangi bir hata

Modelin kendisi sizde kalır. Oloproof yönelttiğiniz bir Python fonksiyonunu çağırır, döndürdüğü tahmini okur ve özellikleri, ağırlıkları ya da iç yapıyı asla görmez.

Ön koşullar

Hızlı başlangıçta olduğu gibi bir sanal ortamda Python 3.11 veya üstü ve pip install oloproof.
Paketle birlikte gelen örnek dosyalar. Çalıştırmaların depoları oraya düşsün diye onları yeni bir dizine kopyalayın:

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

Aşağıdaki her komut üç alt dizinden birinden çalışır. Her çalıştırma kanıtını, okuduğu oloproof.yaml yanındaki bir .oloproof/ dizinine yazar.

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

Bölüm 1: ikili bir sınıflandırıcı

Bağdaştırıcı

binary/app.py modeli ve bağdaştırıcıyı tek bir dosyada tutar. Model, churn_model örneğindekiyle (oloproof init --example churn_model) aynı deterministik müşteri kaybı modelidir; bağdaştırıcı Oloproof'un çağırdığı süslenmiş fonksiyondur:

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)}

Kendi modelinizi değerlendirmek için biçimi koruyun ve churn_score yerine ona yapılan bir çağrı koyun; örneğin içe aktarmada bir kez yüklediğiniz bir scikit-learn modeli için model.predict_proba([features(account)])[0][1]. Model ya da kesim noktası her değiştiğinde version değerini değiştirin: sürüm önbellek anahtarının parçasıdır, bu yüzden aynı sürüm altında yeniden eğitilmiş bir model eski tahminleri yeniden kullanırdı.

Girdi ve çıktı biçimleri

data/accounts.jsonl dosyasının bir satırı bir vakadır:

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

Kısım	Biçim	Kim okur
input	fonksiyonunuzun aldığı nesne	bağdaştırıcınız
expected.label	true ya da false, gerçek	değerlendiriciler
metadata.plan	herhangi bir JSON	yalnızca dilimler
döndürülen label	true ya da false, tahmin	değerlendiriciler
döndürülen score	[0, 1] içinde bir sayı, pozitif sınıfın olasılığı	Brier, log loss, sıralama, kalibrasyon, tarama

Değerlendiriciler ve neden bunlar

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

Doğruluk, duyarlılık ve kesinlik, üç farklı satır kümesi üzerindeki üç orandır: her hesap, kaybedilen hesaplar ve modelin işaretlediği hesaplar. Bir müşteri kaybı modeli üçüne de ihtiyaç duyar, çünkü hesapların yaklaşık üçte biri kaybedilir; yani kimsenin gitmeyeceğini tahmin eden bir model %68 doğrudur ve hiç kimseyi bulmaz.
Brier ve log loss etiketin arkasındaki olasılığı puanlar. Log loss clip gerektirir, çünkü aksi halde tek bir emin hata sonsuz olur.
predictive_ranking artı iki metrics: girdisi ROC-AUC ve ortalama kesinlik verir. Kesim noktasının nerede durduğundan ayrı olarak, modelin hesapları ne kadar iyi sıraladığını yanıtlar.
predictive: bloğu etiketin, puanın ve gerçeğin nerede olduğunu söyler ve metriklerin yanında karışıklık sayılarını, kalibrasyon tablosunu ve eşik taramasını üretir.

Politika

binary/release.yaml her orana bir taban koyar:

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}

Bir kural, aralığın alt sınırı tabanı aştığında geçer, üst sınır tabanın altında olduğunda başarısız olur, aksi halde INSUFFICIENT_EVIDENCE gösterir.

Çalıştırın

cd binary
oloproof run

Kısaltılmış:

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 │

Nasıl okunur:

Gate: ALLOW (exit 0), hiçbir kuralın politikanın engellediği bir duruma ulaşmadığı anlamına gelir. Modelin yazdığınız üç tabanın ötesinde iyi olduğu iddiası değildir.
excluded sayıları iş başındaki paydalardır: duyarlılık kaybedilen 64 hesap üzerinden ölçülür, bu yüzden kaybedilmeyen 136 hesap ondan dışlanır, başarısızlık sayılmaz.
pr_auc için aralık yoktur. 200 satırda motor destekleyemeyeceği bir sınırı vermez; onun üzerindeki bir kural interval_unavailable ile INSUFFICIENT_EVIDENCE gösterirdi.

Metriklerin altında aynı çıktı karışıklık sayılarını, kalibrasyon tablosunu ve eşik taramasını yazdırır:

│ 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  │

Sayılar oran değildir ve hiçbir kural onları adlandıramaz. Kalibrasyon satırları modelin olasılıklarının sapık olduğunu söyler: 0,2 ile 0,3 bandında dört müşteriden yaklaşık birinin gideceğini iddia eder ve 34 kişiden hiçbiri gitmedi. Taramanın başlığı Thresholds (exploratory; recommends nothing) şeklindedir: her kesim noktasının ne ölçeceğini gösterir ve seçimi size bırakır, çünkü kaçırılan bir müşterinin boşa giden bir elde tutma aramasına karşı neye mal olduğunu yalnızca siz bilirsiniz.

Başarısızlıkları inceleyin

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, çalıştırma çıktısının ilk satırındaki kimliktir. oloproof inspect RUN_ID --case account_037 bir vakanın girdisini, beklenen değerini, çıktısını ve her yargıyı gösterir. Kaçırılan birkaç müşteri 0.5 kesim noktasının hemen altında durur (0.37, 0.43); taramanın 0.4 satırı da bunu zaten düşündürüyordu.

Anlamlı bir sonraki eylem kapıdan değil, gördüğünüzden çıkar: burada kaçırılanlar kesim noktasının altında kümelenir, bu yüzden aday daha düşük bir kesim noktası dener. Emin kaçırmalar (0.07) olsalardı, sonraki eylem modelin özellikleri olurdu ve hiçbir kesim noktası yardım etmezdi.

Bir aday değişiklik ve karşılaştırma

binary/candidate.yaml, iki satırı değiştirilmiş oloproof.yaml dosyasıdır:

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                                │

Tam olarak taramanın 0.4 satırı: duyarlılık yukarı, kesinlik aşağı. 3 çıkışı FAIL değil INSUFFICIENT_EVIDENCE demektir: tabanlar aralıkların içindedir, bu yüzden 200 hesap adayın hangi tarafta olduğunu söyleyemez. Puanlar değişmedi, bu yüzden Brier, log loss ve ROC-AUC aynıdır.

Şimdi iki çalıştırmayı vaka vaka karşılaştırın. binary/comparison.yaml karşılaştırma kurallarını tutar:

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)

Kesinlik satırını dikkatle okuyun. Adayın kendi kesinliği %82,5'ten %62,6'ya düştü, yine de eşleştirilmiş fark 63 çift üzerinde +0.0'dır. Bir karşılaştırma satırları eşleştirir: bir kesinlik farkı yalnızca iki modelin de işaretlediği hesaplar üzerinden ölçülür ve bu 63 hesapta ikisi de haklıydı. Adayın işaretlediği, 23'ü yanlış alarm olan 28 ek hesap bu kümenin dışındadır. comparison.yaml dosyasının bir kesim noktası değişikliği için kesinliği değil doğruluğu korumasının nedeni budur; kural türleri Karşılaştırma kuralları sayfasındadır.

Yararlı kısım karardır: duyarlılığın daha kötü olmadığı gösterilmiştir, doğruluk ise beş puan içinde gösterilemez; tavsiye satırı daha fazla verinin onu FAIL'e doğru iteceğini söyler. Dokuz puanlık doğruluğu sekiz puanlık duyarlılıkla takas etmeye değip değmediği, kapının görünür kıldığı bir iş kararıdır.

Bölüm 2: her seferinde bir sınıf, çok sınıflı bir sınıflandırıcı

multiclass/app.py bir destek talebini üç kuyruktan birine yönlendirir ve kasıtlı bir kusuru vardır: mobil uygulamadan gönderilen her talep technical kuyruğuna gider.

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

Bir vaka:

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

Açılacak bir çok sınıflı metrik yoktur. Her sınıf kendi ikili bloğunu alır: billing için duyarlılık, pozitif sınıfı billing olan ikili duyarlılıktır. 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 bunlar üzerinden makro ya da mikro bir ortalama hesaplamaz. Birine ihtiyacınız varsa, sınıf başına sayılardan kendiniz türettiğiniz bir sayıdır ve hiçbir kural onunla kapı denetimi yapamaz. Politika önemli olan sınıflara bir taban koyar, çünkü bir yönlendirici genel olarak doğru olup bir kuyruğu kaybedebilir:

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 │

1 çıkışı en az bir kuralın FAIL olduğu anlamına gelir. Her sınıfın kendi paydası vardır: 78 talep technical olarak adlandırıldı, yani technical için kesinliğin paydası budur. Dilim tablosu nedeni gösterir; dilimler keşif amaçlıdır ve asla kapı denetimine girmez, ama işaretlenmiş bir dilim okumaya değer bir ipucudur:

│ 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
...

Aday (oloproof run --config candidate.yaml ile çalıştırılan route_candidate) kanal kısayolunu kaldırır. Bu sentetik veride her talebi doğru yönlendirir ve kapı izin verir:

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 burada tam olarak Bölüm 1'deki gibi çalışır, sınıf metriği başına bir fark.

Bölüm 3: mutlak hatayla puanlanan bir regresör

regression/app.py teslimat günlerini tahmin eder ve ürünün stokta olup olmadığını yok sayar:

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

Gerçeği bir sayı olan bir vaka:

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

Tek regresyon değerlendiricisi mutlak hatadır ve her hedefin içinde bulunduğu aralığı gerektirir. Mutlak hata, aralığı yalnızca o aralık içinde geçerli olan sınırlı bir ortalamadır, bu yüzden bildirilir, asla varsayılan verilmez. Buradaki teslimatlar 0 ile 20 gün sürer:

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

Politika bir bütçedir, bir max: kuralı: aralığın üst sınırı onun seviyesinde ya da altında olduğunda geçer.

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, çünkü aralığın alt sınırı bile iki günlük bütçenin üzerindedir. Bir puan değerlendiricisinin vaka başına geçti ya da kaldı sonucu yoktur, bu yüzden oloproof inspect RUN_ID --failures hiçbirini listelemez; bunun yerine bir vakayı okuyun:

oloproof inspect RUN_ID --case order_000

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

Dilim nereye bakılacağını söyler: stokta olmayan siparişler beş gün sapar. Aday (estimate_candidate) stokta olmayan bir ürün için beş gün ekler:

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 │

Sorun giderme

Belirti	Neden ve çözüm
Configuration error: evaluator 'recall' counts 'churned' as the positive class, and no case's 'label' is 'churned'	positive: hiçbir vakada olmayan bir değeri adlandırıyor. Değeri expected altında göründüğü şekliyle kullanın; true ile "true" farkı dahil.
release rule ... refers to unknown metric 'false_positives'	Karışıklık sayıları metrik değildir. Duyarlılık ya da kesinlik üzerinde kapı denetimi yapın.
Bir regresyon değerlendiricisi çalıştırmadan önce reddediliyor	target_range eksik ya da boş. Hedeflerin gerçekten alabileceği aralığı bildirin; daha geniş bir aralık daha geniş bir aralık tahmini verir.
Bir sıralama kuralı INSUFFICIENT_EVIDENCE (interval_unavailable) gösteriyor	Paket o istatistiğin aralığı için çok küçük, genellikle pr_auc. roc_auc üzerinde kapı denetimi yapın ya da vaka ekleyin.
Aday temelin sayılarını bildiriyor	İki çalıştırma aynı version değerini paylaşıyor, bu yüzden önbellekteki tahminler yeniden kullanıldı. Her değişikliğe kendi sürümünü verin.
Bir vaka yanlış değil missing	Fonksiyonunuz hata fırlattı ya da değerlendiricinin okuduğu alan yok veya sayı değil. oloproof inspect RUN_ID --case ID hatayı gösterir.

Sınırlamalar

Önerilen eşik yoktur. Tarama, bildirilen her kesim noktasının ne ölçeceğini bildirir.
Çok sınıflı için makro ya da mikro ortalama metrik ve etiket başına bir blok dışında çok etiketli destek yoktur.
Regresyon yalnızca bildirilmiş bir target_range içinde mutlak hatadır: karesel hata, R kare ya da sınırsız hata yoktur.
Kalibrasyon bir tablo olarak gösterilir; kapı denetimine girmez ve düzeltilmez.
Eşleştirilmiş bir kesinlik farkı, Bölüm 1'in gösterdiği gibi yalnızca iki modelin de işaretlediği satırları kapsar.
Örnekler deterministik ve sentetiktir. Kararları mekaniği gösterir, gerçek bir modelin gerçek veride nasıl davrandığını değil.

Sonra nereye

Sınıflandırıcılar ve regresörler alan alan başvurudur.
Bir adayı bir temelle karşılaştırma ve Karşılaştırma kuralları karşılaştırma iş akışını anlatır.
Dilimler confidence: bantlarını ve dilim desteğini anlatır.
CI'da kapı denetimi çıkış kodlarını listeler.