الأدلة الإرشادية

درس تعليمي: مُصنِّف ونموذج انحدار

جولة قابلة للتشغيل لثلاثة نماذج تنبؤية تُقيَّم من سطر الأوامر: مُصنِّف ثنائي لتوقع تسرّب العملاء، ومُوجِّه تذاكر بثلاث فئات يُقيَّم فئةً فئة، ونموذج انحدار لزمن التوصيل يُقاس بالخطأ المطلق ضمن مدى مُعلَن. يعمل كل منها محليًا دون مزوِّد ودون مفتاح ودون شبكة، وينتهي كل منها بتغيير مرشَّح يُقاس مقابل خط الأساس.

هذه الصفحة هي الرفيق العملي لصفحة المُصنِّفات ونماذج الانحدار، التي تشرح كل حقل؛ اقرأ تلك الصفحة للمرجع وهذه لتنفّذ العمل مرة واحدة من البداية إلى النهاية. والمصطلحات مثل الفترة وحالة القرار وإجراء الإصدار معرَّفة في المفاهيم.

ما يقيسه Oloproof لنموذج تنبؤي، وما لا يقيسه

النموذج	ما تحصل عليه	ما لا تحصل عليه
مُصنِّف ثنائي	الدقة الإجمالية، والاستدعاء، والدقة، ودرجة Brier، والخسارة اللوغاريتمية، وROC-AUC، ومتوسط الدقة، إضافة إلى أعداد مصفوفة الالتباس، وجدول معايرة، ومسح للعتبات	عتبة موصى بها
مُصنِّف متعدد الفئات	استدعاء واحد ودقة واحدة لكل فئة، كل منهما مقياس ثنائي فئته الموجبة هي تلك الفئة (واحدة مقابل البقية)	مقياس متوسط كلي أو جزئي
نموذج انحدار	متوسط الخطأ المطلق، محدودًا بـ target_range تعلنه أنت	الخطأ التربيعي، أو R تربيع، أو أي خطأ دون مدى مُعلَن

يبقى النموذج نفسه لك. يستدعي Oloproof دالة Python توجّهه إليها، ويقرأ التنبؤ الذي تعيده، ولا يرى أبدًا الخصائص أو الأوزان أو الداخليات.

المتطلبات المسبقة

Python 3.11 أو أحدث وpip install oloproof في بيئة افتراضية، كما في البدء السريع.
ملفات المثال، وهي تأتي مع الحزمة. انسخها إلى مجلد جديد كي تستقر مخازن التشغيلات هناك:

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

كل أمر أدناه يُشغَّل من أحد مجلداته الفرعية الثلاثة. ويكتب كل تشغيل أدلته في مجلد .oloproof/ بجانب oloproof.yaml الذي قرأه.

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

الجزء 1: مُصنِّف ثنائي

المحوِّل

يحمل binary/app.py النموذج والمحوِّل في ملف واحد. النموذج هو نموذج التسرّب الحتمي نفسه في مثال churn_model (oloproof init --example churn_model)؛ والمحوِّل هو الدالة المزخرَفة التي يستدعيها Oloproof:

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

لتقييم نموذجك أنت، احتفظ بالشكل واستبدل churn_score باستدعاء له، مثلًا model.predict_proba([features(account)])[0][1] لنموذج scikit-learn تحمّله مرة واحدة عند الاستيراد. وغيّر version كلما تغيّر النموذج أو عتبة القطع: النسخة جزء من مفتاح التخزين المؤقت، فالنموذج المعاد تدريبه تحت النسخة نفسها سيعيد استخدام التنبؤات القديمة.

أشكال المُدخَل والمُخرَج

سطر واحد من data/accounts.jsonl حالة واحدة:

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

الجزء	الشكل	من يقرؤه
input	الكائن الذي تتلقاه دالتك	محوِّلك
expected.label	true أو false، الحقيقة	المُقيِّمات
metadata.plan	أي JSON	الشرائح فقط
label المُعاد	true أو false، التنبؤ	المُقيِّمات
score المُعاد	رقم في [0, 1]، احتمال الفئة الموجبة	Brier، والخسارة اللوغاريتمية، والترتيب، والمعايرة، والمسح

المُقيِّمات، ولماذا هذه

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

الدقة الإجمالية والاستدعاء والدقة ثلاثة معدلات على ثلاث مجموعات مختلفة من الصفوف: كل حساب، والحسابات التي تسرّبت، والحسابات التي أشار إليها النموذج. يحتاج نموذج التسرّب إلى الثلاثة لأن نحو ثلث الحسابات يتسرّب، فالنموذج الذي يتنبأ بأن أحدًا لن يتسرّب دقيق بنسبة 68% ولا يعثر على أحد.
يقيس Brier والخسارة اللوغاريتمية الاحتمال الذي وراء الوسم. وتحتاج الخسارة اللوغاريتمية إلى clip، لأن خطأً واثقًا واحدًا يكون لا نهائيًا لولا ذلك.
يعطي predictive_ranking مع إدخالَي metrics: قيمتَي ROC-AUC ومتوسط الدقة. ويجيبان عن مدى جودة ترتيب النموذج للحسابات، بمعزل عن موضع عتبة القطع.
تقول كتلة predictive: أين يوجد الوسم والدرجة والحقيقة، وتنتج أعداد مصفوفة الالتباس وجدول المعايرة ومسح العتبات بجانب المقاييس.

السياسة

يضع binary/release.yaml حدًا أدنى لكل معدل:

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}

تنجح القاعدة حين يتجاوز الحد الأدنى للفترة الحد المطلوب، وتُخفق حين يكون الحد الأعلى دونه، وتقرأ خلاف ذلك INSUFFICIENT_EVIDENCE.

شغّله

cd binary
oloproof run

مختصرًا:

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 │

كيف تقرؤه:

يعني Gate: ALLOW (exit 0) أنه لم تبلغ أي قاعدة حالة تحجب عليها السياسة. وليس ادعاءً بأن النموذج جيد فيما يتجاوز الحدود الدنيا الثلاثة التي كتبتها.
أعداد excluded هي المقامات وهي تعمل: يُقاس الاستدعاء على الحسابات الأربعة والستين التي تسرّبت، فتُستبعد منه الحسابات المئة والستة والثلاثون التي لم تتسرّب، ولا تُحتسب إخفاقات.
ليس لـ pr_auc فترة. عند 200 صف يمتنع المحرك عن حد لا يستطيع دعمه؛ والقاعدة المبنية عليه ستقرأ INSUFFICIENT_EVIDENCE مع interval_unavailable.

تحت المقاييس، يطبع المُخرَج نفسه أعداد مصفوفة الالتباس وجدول المعايرة ومسح العتبات:

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

الأعداد ليست معدلات ولا يجوز لأي قاعدة تسميتها. وتقول صفوف المعايرة إن احتمالات النموذج منحرفة: في النطاق من 0.2 إلى 0.3 يزعم أن نحو واحد من كل أربعة سيتسرّب، ولم يتسرّب أي من الأربعة والثلاثين. وعنوان المسح Thresholds (exploratory; recommends nothing): يُظهر ما كانت كل عتبة قطع ستقيسه ويترك الاختيار لك، لأنك وحدك تعرف كم يكلّف عميل متسرّب فائت مقابل مكالمة احتفاظ ضائعة.

افحص الإخفاقات

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 هو المعرّف في السطر الأول من مُخرَج التشغيل. يعرض oloproof inspect RUN_ID --case account_037 مُدخَل حالة واحدة وقيمتها المتوقعة ومُخرَجها وكل حكم. ويقع عدد من المتسرّبين الفائتين تحت عتبة القطع 0.5 مباشرة (0.37، 0.43)، وهو ما أشار إليه أصلًا صف 0.4 في المسح.

الإجراء التالي ذو المعنى ينبع مما تراه، لا من البوابة: هنا تتجمع الأخطاء تحت عتبة القطع، فيجرّب المرشَّح عتبة أدنى. ولو كانت أخطاءً واثقة (0.07)، لكان الإجراء التالي في خصائص النموذج، ولما ساعدت أي عتبة قطع.

تغيير مرشَّح، والمقارنة

binary/candidate.yaml هو oloproof.yaml مع تغيير سطرين:

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                                │

هذا صف 0.4 في المسح بالضبط: ارتفع الاستدعاء وانخفضت الدقة. والخروج 3 هو INSUFFICIENT_EVIDENCE، لا FAIL: الحدود الدنيا داخل الفترات، فلا تستطيع 200 حساب أن تقول في أي جانب يقع المرشَّح. ولم تتغير الدرجات، فتبقى Brier والخسارة اللوغاريتمية وROC-AUC متطابقة.

قارن الآن التشغيلين حالةً حالة. يحمل binary/comparison.yaml قواعد مقارنة:

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)

اقرأ سطر الدقة بعناية. انخفضت دقة المرشَّح نفسه من 82.5% إلى 62.6%، ومع ذلك فالفرق المزدوج +0.0 على 63 زوجًا. المقارنة تزاوج الصفوف: يُقاس فرق الدقة على الحسابات التي أشار إليها النموذجان كلاهما فقط، وعلى تلك الحسابات الثلاثة والستين كان كلاهما مصيبًا. والحسابات الثمانية والعشرون الإضافية التي أشار إليها المرشَّح، 23 منها إنذارات كاذبة، تقع خارج تلك المجموعة. ولهذا يحرس comparison.yaml الدقة الإجمالية لا الدقة عند تغيير عتبة القطع؛ وفي قواعد المقارنة أنواع القواعد.

القرار هو الجزء المفيد: ثبت أن الاستدعاء ليس أسوأ، ولا يمكن إثبات أن الدقة الإجمالية ضمن خمس نقاط؛ ويقول سطر النصيحة إن مزيدًا من البيانات سيدفعها نحو FAIL. وهل تستحق مقايضة تسع نقاط من الدقة الإجمالية بثماني نقاط من الاستدعاء؟ ذلك قرار تجاري جعلته البوابة مرئيًا.

الجزء 2: مُصنِّف متعدد الفئات، فئةً فئة

يوجّه multiclass/app.py تذكرة دعم إلى إحدى ثلاث قوائم انتظار، وفيه عيب متعمَّد واحد: أي تذكرة تُرسَل من تطبيق الهاتف تذهب إلى technical.

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

حالة:

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

لا يوجد مقياس متعدد الفئات يمكن تفعيله. تحصل كل فئة على كتلتها الثنائية الخاصة: الاستدعاء لـ billing هو الاستدعاء الثنائي الذي فئته الموجبة 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 متوسطًا كليًا أو جزئيًا على هذه. وإن احتجت إلى واحد، فهو رقم تشتقه بنفسك من أعداد كل فئة، ولا تستطيع أي قاعدة أن تحجب عليه بالبوابة. وتضع السياسة حدًا أدنى على الفئات المهمة، لأن المُوجِّه قد يكون دقيقًا إجمالًا ويفقد قائمة انتظار واحدة:

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 أن قاعدة واحدة على الأقل FAIL. ولكل فئة مقامها الخاص: صُنّفت 78 تذكرة بوصفها technical، فذلك مقام الدقة لـ technical. ويشير جدول الشرائح إلى السبب؛ فالشرائح استكشافية ولا يُحجب عليها بالبوابة أبدًا، لكن الشريحة المُعلَّمة خيط يستحق القراءة:

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

يُسقط المرشَّح (route_candidate، ويُشغَّل بـ oloproof run --config candidate.yaml) الاختصار المتعلق بالقناة. وعلى هذه البيانات الاصطناعية يوجّه كل تذكرة توجيهًا صحيحًا وتسمح البوابة:

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 هنا تمامًا كما في الجزء 1، بفرق واحد لكل مقياس فئة.

الجزء 3: نموذج انحدار، يُقاس بالخطأ المطلق

يقدّر regression/app.py أيام التوصيل ويتجاهل هل السلعة متوفرة في المخزون:

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

حالة، والحقيقة فيها رقم:

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

مُقيِّم الانحدار الوحيد هو الخطأ المطلق، وهو يحتاج إلى المدى الذي تقع فيه كل قيمة مستهدفة. فالخطأ المطلق متوسط محدود لا تصح فترته إلا ضمن ذلك المدى، لذا يُعلَن ولا يُفترض أبدًا. والتوصيل هنا يستغرق من 0 إلى 20 يومًا:

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

السياسة ميزانية، قاعدة max:: تنجح حين يكون الحد الأعلى للفترة عندها أو دونها.

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 لأن الحد الأدنى للفترة نفسه أعلى من ميزانية اليومين. ومُقيِّم الدرجة ليس له نجاح أو إخفاق لكل حالة، لذا لا يسرد oloproof inspect RUN_ID --failures شيئًا؛ اقرأ حالة بدلًا من ذلك:

oloproof inspect RUN_ID --case order_000

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

تقول الشريحة أين تنظر: الطلبات غير المتوفرة في المخزون منحرفة بخمسة أيام. ويضيف المرشَّح (estimate_candidate) خمسة أيام للسلعة غير المتوفرة:

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 │

استكشاف الأخطاء وإصلاحها

العَرَض	السبب والإصلاح
Configuration error: evaluator 'recall' counts 'churned' as the positive class, and no case's 'label' is 'churned'	يسمّي positive: قيمة ليست لأي حالة. استخدم القيمة تمامًا كما تظهر تحت expected، بما في ذلك true مقابل "true".
release rule ... refers to unknown metric 'false_positives'	أعداد مصفوفة الالتباس ليست مقاييس. احجب بالبوابة على الاستدعاء أو الدقة.
يُرفض مُقيِّم انحدار قبل التشغيل	target_range غائب أو فارغ. أعلن المدى الذي يمكن أن تأخذه القيم المستهدفة فعلًا؛ والمدى الأوسع يعطي فترة أوسع.
تقرأ قاعدة ترتيب INSUFFICIENT_EVIDENCE (interval_unavailable)	مجموعة الاختبار أصغر من أن تعطي فترة ذلك الإحصاء، وعادةً pr_auc. احجب على roc_auc، أو أضف حالات.
يُبلغ المرشَّح عن أرقام خط الأساس	يتشارك التشغيلان version واحدة، فأُعيد استخدام التنبؤات المخزّنة مؤقتًا. أعطِ كل تغيير نسخته الخاصة.
حالة missing بدلًا من أن تكون خاطئة	رفعت دالتك استثناءً، أو الحقل الذي يقرؤه المُقيِّم غائب أو ليس رقمًا. ويُظهر oloproof inspect RUN_ID --case ID الخطأ.

القيود

لا عتبة موصى بها. يُبلغ المسح عمّا كانت كل عتبة قطع مُعلَنة ستقيسه.
لا مقياس متوسط كلي أو جزئي للتصنيف متعدد الفئات، ولا دعم لتعدد الوسوم إلا بكتلة لكل وسم.
الانحدار هو الخطأ المطلق ضمن target_range مُعلَن فقط: لا خطأ تربيعي ولا R تربيع ولا خطأ غير محدود.
تُعرض المعايرة جدولًا، ولا يُحجب عليها بالبوابة ولا تُصحَّح.
فرق الدقة المزدوج لا يغطي إلا الصفوف التي أشار إليها النموذجان كلاهما، كما يُظهر الجزء 1.
الأمثلة حتمية واصطناعية. وقراراتها تُظهر الآلية، لا كيف يتصرف نموذج حقيقي على بيانات حقيقية.

إلى أين بعد ذلك

المُصنِّفات ونماذج الانحدار هو المرجع حقلًا حقلًا.
يغطي مقارنة مرشَّح بخط أساس وقواعد المقارنة سير عمل المقارنة.
يغطي الشرائح نطاقات confidence: ودعم الشرائح.
يسرد الحجب بالبوابة في CI رموز الخروج.