Day 7: Error Analysis, Data Leakage, Threshold Tuning

Mục tiêu

Sau bài này bạn cần làm được những việc sau:

• Phân tích model sai ở đâu thay vì chỉ nhìn một metric tổng.
• Đọc confusion matrix theo chi phí business của false positive và false negative.
• Slice lỗi theo segment như contract, tenure bucket, region, payment method.
• Tune threshold từ 0.30 đến 0.80 theo business objective, không mặc định 0.50.
• Biết khi nào cần calibration và cách kiểm tra probability có đáng tin không.
• Phát hiện data leakage, train-serving skew và distribution shift.
• Tạo baseline regression test để model hoặc threshold mới không làm production tệ hơn.

TL;DR

Classification model không kết thúc ở model.predict. Trong production, model thường trả probability, còn quyết định cuối cùng phụ thuộc vào threshold, capacity, cost và policy. Error analysis là bước debug model giống cách Senior SE debug production incident: chia theo segment, tìm nhóm lỗi nặng, xem top false positives/false negatives, xác định nguyên nhân rồi mới quyết định sửa data, feature, model hay threshold.

Với churn prediction, false positive nghĩa là gửi ưu đãi cho khách không định rời đi, tốn budget. False negative nghĩa là bỏ lỡ khách sắp churn, mất revenue. Nếu false negative đắt hơn nhiều so với false positive, threshold nên thấp hơn 0.50 để tăng recall, nhưng phải kiểm soát số lượng case gửi cho sales/CSKH.

Bối cảnh thực hành

Bài này dùng bài toán customer churn dạng tabular classification:

• Input: tenure, monthly charges, số ticket hỗ trợ, usage drop, payment failures, contract type, internet service, region.
• Output: churn = 1 nếu khách có nguy cơ rời đi.
• Model trả P(churn), ví dụ 0.72.
• Business action: gửi offer, gọi CSKH, hoặc đưa vào queue review.

Điểm quan trọng: 0.72 chưa phải quyết định. Quyết định phụ thuộc vào threshold:

if P(churn) >= threshold:
    action = "intervene"
else:
    action = "no_action"

Threshold là một policy runtime. Nó cần được version, audit và rollback được giống config quan trọng trong backend service.

Workflow chuẩn từ offline metric đến production decision

Step 1: Khóa baseline và metric contract

Trước khi phân tích lỗi, cần biết baseline hiện tại là gì.

Baseline tối thiểu nên có:

• Model version: ví dụ churn-logreg-calibrated-v1.
• Dataset snapshot hoặc training window.
• Feature contract: danh sách feature, type, missing policy, category policy.
• Metric tổng: ROC-AUC, PR-AUC, precision, recall, F1.
• Threshold hiện tại và lý do chọn.
• Segment metrics quan trọng.
• Expected cost/profit nếu có business cost.

Ví dụ metric contract:

Không nên dùng test set để chọn threshold. Dùng validation set để chọn threshold, giữ test set cho đánh giá cuối cùng.

Step 2: Đọc confusion matrix theo business cost

Confusion matrix cho binary classification:

Trong churn:

• True Positive: model bắt đúng khách sẽ churn, có thể can thiệp.
• False Positive: khách không churn nhưng vẫn bị offer, tốn chi phí.
• False Negative: khách sẽ churn nhưng bị bỏ lỡ, mất revenue.
• True Negative: khách ổn, không cần can thiệp.

Ví dụ business cost:

TP value: giữ được một phần revenue, +300 USD
FP cost: offer hoặc cuộc gọi không cần thiết, -40 USD
FN cost: mất khách, -1,200 USD

Khi FN đắt hơn FP, tối ưu accuracy hoặc F1 có thể không đủ. Bạn nên tune threshold theo expected profit hoặc theo constraint như recall >= 0.80.

Step 3: Error slicing theo segment

Metric tổng có thể che giấu lỗi nghiêm trọng ở segment nhỏ.

Ví dụ:

Overall F1: 0.73

F1 by contract:
- month_to_month: 0.76
- one_year: 0.55
- two_year: 0.31

Overall nhìn ổn, nhưng model gần như không dùng được cho two_year. Với production, lỗi này có thể dẫn đến unfair treatment, lãng phí budget hoặc bỏ lỡ nhóm khách có giá trị cao.

Các segment nên slice trong bài toán churn:

• contract: month-to-month, one-year, two-year.
• tenure_bucket: 0-6, 7-12, 13-24, 25+ tháng.
• internet_service: DSL, fiber, none.
• region: north, south, central.
• monthly_charge_bucket: low, medium, high.
• payment_method nếu có.

Mỗi slice nên xem:

• Count.
• Actual positive rate.
• Predicted positive rate.
• Precision.
• Recall.
• F1.
• Confusion counts: TN, FP, FN, TP.

Lưu ý trade-off: slice càng nhỏ càng dễ nhiễu. Không nên kết luận mạnh từ segment chỉ có vài chục sample. Cần minimum sample size, confidence interval hoặc so sánh qua nhiều snapshot.

Step 4: Xem top false positives và false negatives

Sau khi có threshold, luôn tạo bảng:

• Top false positives có probability cao nhất.
• Top false negatives có probability thấp nhất.
• Các sample gần threshold nhất.

Vì sao cần ba nhóm này:

• High-confidence false positives chỉ ra feature/model đang hiểu sai pattern nào đó.
• High-confidence false negatives chỉ ra khách nguy hiểm mà model rất tự tin bỏ lỡ.
• Near-threshold samples giúp quyết định vùng nào cần human review hoặc rule bổ sung.

Ví dụ câu hỏi khi review top FP/FN:

• Có category mới mà training chưa thấy không?
• Có missing value bị xử lý khác production không?
• Có segment bị under-represented trong training không?
• Label có bị delay hoặc sai không?
• Feature có được tạo sau thời điểm dự đoán không?

Step 5: Threshold tuning từ 0.30 đến 0.80

Default 0.50 chỉ hợp lý khi:

• Probability đã calibrated.
• Class tương đối cân bằng.
• FP và FN có cost gần nhau.
• Không có capacity constraint.

Trong thực tế, các điều kiện này hiếm khi cùng đúng.

Threshold thấp:

• Recall tăng.
• False negative giảm.
• Precision thường giảm.
• Nhiều case cần xử lý hơn.

Threshold cao:

• Precision tăng.
• False positive giảm.
• Recall giảm.
• Bỏ lỡ nhiều positive hơn.

Một sweep đơn giản:

threshold: 0.30, precision: 0.32, recall: 0.91, f1: 0.47
threshold: 0.40, precision: 0.39, recall: 0.84, f1: 0.53
threshold: 0.50, precision: 0.48, recall: 0.70, f1: 0.57
threshold: 0.60, precision: 0.58, recall: 0.51, f1: 0.54
threshold: 0.70, precision: 0.69, recall: 0.30, f1: 0.42
threshold: 0.80, precision: 0.78, recall: 0.12, f1: 0.21

Cách chọn threshold theo context:

Best solution cho churn trong bài này: chọn threshold trên validation set bằng rule recall >= target rồi tối đa expected profit hoặc precision. Sau đó đánh giá một lần trên test set và lưu threshold thành artifact riêng.

Step 6: Calibration

Calibration trả lời câu hỏi: nếu model nói P(churn) = 0.80, trong 100 khách tương tự có khoảng 80 khách churn thật không?

Ranking tốt không đồng nghĩa probability tốt. Model có thể phân biệt thứ tự khách rủi ro cao/thấp tốt, nhưng probability bị over-confident hoặc under-confident.

Khi nào cần calibration:

• Dùng probability để tính expected value.
• Dùng risk score trong policy hoặc pricing.
• So sánh probability giữa nhiều model.
• Gửi probability cho stakeholder hoặc downstream service.
• Tune threshold dựa trên cost cụ thể.

Khi nào calibration ít quan trọng hơn:

• Chỉ cần ranking top-K.
• Probability không được expose.
• Threshold được chọn trực tiếp từ validation set và không diễn giải như xác suất tuyệt đối.

Kỹ thuật phổ biến:

• Platt scaling/sigmoid: ổn khi data calibration không lớn, ít overfit hơn.
• Isotonic regression: linh hoạt hơn nhưng cần nhiều data calibration.
• Reliability table/diagram: chia probability thành bin, so sánh predicted probability trung bình với actual positive rate.
• Brier score: đo lỗi probability, càng thấp càng tốt.

Trade-off: calibration thêm một bước training và có thể overfit nếu calibration set nhỏ. Với scikit-learn, dùng CalibratedClassifierCV trong pipeline đánh giá để tránh tự viết logic sai.

Step 7: Data leakage

Data leakage xảy ra khi training nhìn thấy thông tin mà production inference không có tại thời điểm dự đoán.

Đây là một trong những lỗi nguy hiểm nhất trong ML vì offline metric rất đẹp nhưng deploy thì hỏng.

Các dạng leakage thường gặp:

Checklist nhanh:

• Feature này có tồn tại trước prediction time không?
• Feature này có được cập nhật sau khi customer churn không?
• Feature này có được tính bằng dữ liệu của toàn bộ dataset không?
• Một customer hoặc cùng household có nằm ở cả train và test không?
• Split có tôn trọng thời gian production không?

Step 8: Train-serving skew

Train-serving skew là khác biệt giữa cách tạo feature lúc training và lúc inference.

Ví dụ:

• Training fill missing bằng median, production fill bằng 0.
• Training category là Fiber optic, production gửi fiber_optic.
• Training timezone UTC, production timezone local.
• Training dùng full preprocessing pipeline, production reimplement logic bằng code khác.
• Training one-hot có category cố định, production gặp category mới và crash.

Cách giảm skew:

• Serialize nguyên Pipeline gồm preprocessing và model.
• Dùng OneHotEncoder(handle_unknown="ignore") cho categorical feature có category mới.
• Viết schema validation cho inference input.
• Dùng shared feature code hoặc feature store.
• Log feature distribution và prediction distribution theo version.
• Contract test giữa training pipeline và serving service.

Step 9: Distribution shift

Distribution shift là production data thay đổi so với training data.

Nguyên nhân:

• Marketing campaign mới làm khách rủi ro vào nhiều hơn.
• Giá thay đổi.
• Competitor launch.
• Seasonality.
• Kênh acquisition mới.
• Thay đổi product hoặc policy billing.
• Bug trong upstream data pipeline.

Monitor tối thiểu:

• Feature distribution: mean/std, missing rate, category share.
• Prediction distribution: histogram probability, predicted positive rate.
• Input volume theo segment.
• Delayed label performance khi label thật xuất hiện.
• Segment metrics theo cohort thời gian.

Nếu production positive rate tăng từ 10% lên 40%, không kết luận ngay là churn tăng thật. Cần kiểm tra:

1. Schema/input có đổi không.
2. Feature distribution nào drift mạnh.
3. Model version hoặc threshold version có đổi không.
4. Upstream data pipeline có bug không.
5. Business event nào xảy ra.
6. Delayed labels có xác nhận pattern này không.

Step 10: Baseline regression test

Baseline regression test trong ML giống test suite trong backend, nhưng kiểm tra hành vi thống kê.

Các gate nên có:

• Metric tổng không giảm quá ngưỡng.
• Threshold mới không phá capacity.
• Segment quan trọng không tụt quá mạnh.
• Confusion matrix không tăng FN/FP vượt mức cho phép.
• Probability calibration không tệ hơn nhiều.
• Data quality check không có schema/missing/category bất thường.

Ví dụ rule:

Model mới chỉ được promote nếu:
- ROC-AUC >= baseline ROC-AUC - 0.01
- PR-AUC >= baseline PR-AUC - 0.02
- Recall at selected threshold >= 0.75
- Predicted positive rate <= 0.45
- Không segment nào có recall < 0.50 với count >= 200

Không nên để một metric duy nhất quyết định deployment.

Best solution theo context Day 7

Với churn-like tabular classification, giải pháp hợp lý nhất cho giai đoạn foundation:

1. Train baseline bằng scikit-learn Pipeline + ColumnTransformer.
2. Encode categorical feature bằng OneHotEncoder(handle_unknown="ignore").
3. Fit toàn bộ preprocessing chỉ trên train để tránh preprocessing leakage.
4. Dùng validation set để sweep threshold từ 0.30 đến 0.80.
5. Chọn threshold theo business rule, ví dụ recall >= 0.75 rồi tối đa expected profit.
6. Đánh giá cuối cùng trên test set.
7. Tạo slice metrics cho ít nhất contract, tenure_bucket, internet_service.
8. Xuất top 20 FP/FN và near-threshold samples cho human review.
9. Nếu probability được dùng để tính cost/risk, thêm CalibratedClassifierCV và kiểm tra Brier score/reliability table.
10. Lưu artifact gồm model pipeline, feature contract, threshold, threshold version, model version, training snapshot và metric summary.
11. Chạy baseline regression gates trong CI hoặc trước khi promote model.

Performance considerations

• Threshold sweep rất rẻ: với n sample và k thresholds, chi phí khoảng O(n*k). Với vài trăm nghìn dòng và 11 threshold từ 0.30 đến 0.80, Pandas vẫn ổn.
• Error slicing trên dataset lớn nên đẩy về SQL/Spark hoặc batch job, không nhất thiết chạy trong request path.
• Calibration thường không làm inference chậm đáng kể, nhưng tăng complexity training và cần validation/calibration data đủ tốt.
• Serialize full pipeline giúp giảm train-serving skew, nhưng artifact có thể lớn. Cần version và kiểm soát tương thích dependency.
• Logging full feature vector có rủi ro PII và tốn storage. Production nên log sample, hash ID, aggregate metrics và chỉ lưu raw feature khi có policy rõ ràng.
• Với model tabular đơn giản như Logistic Regression, inference latency thường thấp. Bottleneck production thường là feature retrieval, validation, network và logging.

Dùng được trong production không?

Có, cách làm trong bài này dùng được trong production nếu đáp ứng các điều kiện sau:

• Dataset split đúng theo thời gian hoặc entity, không leakage.
• Pipeline preprocessing được serialize cùng model, không reimplement khác ở serving.
• Threshold được chọn trên validation set, test set chỉ dùng đánh giá cuối.
• Threshold có version riêng, audit log và rollback path.
• Có baseline regression gates trước khi promote model/threshold mới.
• Có monitoring cho input distribution, prediction distribution, positive rate, latency và delayed label quality.
• Có schema validation cho inference input.
• Có quy trình xử lý drift, skew và incident.
• Có kiểm soát PII trong logging và artifact.

Chưa nên dùng production nếu:

• Threshold được tune trên test set.
• Feature có thể chứa thông tin sau prediction time.
• Training và serving dùng hai code path preprocessing khác nhau.
• Không biết FP/FN cost hoặc capacity.
• Không có monitoring sau deploy.
• Không có rollback threshold/model.

Liên kết thực hành

• Bài tập chi tiết: exercise.md
• Script Python minh họa gần production: exercise.py
• Checklist vận hành và template review: document.md

Tài liệu

1. Confusion matrix cheat sheet

Luôn gắn FP/FN với cost thật. Nếu chưa có cost thật, ghi assumption rõ ràng và review lại sau khi có dữ liệu.

2. Error analysis checklist

• Có metric tổng: ROC-AUC, PR-AUC, precision, recall, F1.
• Có confusion matrix tại threshold đang dùng.
• Có threshold sweep từ 0.30 đến 0.80.
• Có lý do chọn threshold bằng business objective.
• Có top 20 false positives.
• Có top 20 false negatives.
• Có sample gần threshold.
• Có slice metrics theo ít nhất 2 segment quan trọng.
• Có minimum sample size cho slice metrics.
• Có nhận xét cụ thể: lỗi đến từ data, feature, label, model hay threshold.

3. Threshold Decision Record

Template nên lưu cùng artifact hoặc trong model registry:

model_version: churn-logreg-calibrated-v1
threshold_version: threshold-recall75-profit-v1
threshold: 0.42
selected_on: validation
selected_at: 2026-05-09T00:00:00Z
business_objective: maximize expected profit with recall >= 0.75
constraints:
  min_recall: 0.75
  max_predicted_positive_rate: 0.45
cost_assumptions:
  tp_retained_value: 300
  fp_offer_cost: 40
  fn_lost_value: 1200
validation_metrics:
  precision: 0.41
  recall: 0.78
  f1: 0.54
  predicted_positive_rate: 0.39
approval:
  owner: growth-ml
  reviewer: retention-business-owner
rollback:
  previous_model_version: churn-logreg-calibrated-v0
  previous_threshold_version: threshold-v0

4. Data leakage review checklist

Hỏi những câu này cho từng feature:

• Feature có tồn tại trước prediction time không?
• Feature có phụ thuộc trực tiếp hoặc gián tiếp vào label không?
• Feature có được tạo sau khi customer churn không?
• Aggregation window có dùng dữ liệu tương lai không?
• Query tạo training data có filter nào dựa trên outcome không?
• Có duplicate customer/entity giữa train và test không?
• Preprocessing có fit trên toàn bộ dataset trước split không?
• Label delay có làm train/test bị sai thời điểm không?
• Feature này có thể được tính giống hệt ở serving không?

Red flags:

• Tên cột chứa cancel, closed, resolved_after, refund_after, final_status.
• Feature có correlation gần tuyệt đối với label.
• Offline metric tăng đột biến sau khi thêm một feature.
• Feature chỉ có trong warehouse, không có trong online serving path.

5. Train-serving skew checklist

• Training và serving dùng cùng serialized preprocessing pipeline.
• Input schema có validation type/range/category.
• Missing value policy giống nhau.
• Categorical normalization giống nhau.
• Timezone và cutoff time giống nhau.
• Feature code có test với fixture production-like.
• model_version, feature_version, threshold_version được log ở mỗi prediction.
• Có alert khi missing rate/category unknown/predicted positive rate đổi mạnh.

6. Distribution shift dashboard

Dashboard tối thiểu nên có:

Alert không nên chỉ dựa vào một signal. Ví dụ positive rate tăng có thể do churn thật tăng, upstream bug, threshold đổi hoặc model artifact sai.

7. Baseline regression gates

Ví dụ gate trước khi promote:

Nếu gate fail, không tự động deploy. Cần error analysis và ghi decision nếu business vẫn muốn override.

8. Incident runbook: positive rate tăng bất thường

Khi predicted positive rate tăng từ 10% lên 40%:

1. Kiểm tra deploy log: model version, threshold version, feature version có đổi không.
2. Kiểm tra traffic volume và request schema.
3. So sánh feature distribution trước/sau thời điểm tăng.
4. Kiểm tra category unknown và missing rate.
5. Chạy lại inference trên một sample cũ bằng artifact mới và artifact cũ.
6. Kiểm tra upstream pipeline, timezone, cutoff window.
7. Nếu nghiêm trọng, rollback threshold hoặc model trước, phân tích sau.
8. Khi delayed labels về, so sánh actual positive rate để phân biệt real shift và pipeline bug.

9. Review findings thường gặp trong bài Day 7

• Bài học chỉ nói metric tổng nhưng thiếu segment analysis.
• Có threshold tuning nhưng chọn theo test set.
• Có calibration nhưng không giải thích khi nào cần.
• Code fit preprocessing trước split, gây leakage.
• Chỉ save model, không save threshold và feature contract.
• Không có baseline regression test.
• Không có câu trả lời rõ ràng về production readiness.

Bài tập

Mục tiêu thực hành

Bạn sẽ chạy một workflow gần production cho churn classification:

• Sinh synthetic churn-like dataset có numerical và categorical features.
• Train scikit-learn Pipeline với ColumnTransformer.
• Dùng OneHotEncoder(handle_unknown="ignore") để tránh crash khi gặp category mới.
• Fit calibration bằng CalibratedClassifierCV.
• Sweep threshold từ 0.30 đến 0.80.
• Tạo confusion matrix, precision, recall, F1, ROC-AUC, PR-AUC.
• Chọn threshold theo business constraint.
• Slice metrics theo segment.
• Xuất top false positives, false negatives và near-threshold samples.
• Demo data leakage bằng một leaky feature.
• Tạo metadata cho model artifact và threshold version.

Cách chạy

Từ root repo:

python3 lessions/day-07-error-analysis-data-leakage-threshold-tuning/exercise.py

Nếu muốn ghi artifact mẫu vào folder bài học:

python3 lessions/day-07-error-analysis-data-leakage-threshold-tuning/exercise.py --write-artifacts

Nếu muốn biến baseline gates thành lỗi CI:

python3 lessions/day-07-error-analysis-data-leakage-threshold-tuning/exercise.py --enforce-gates

Dependencies:

pip install numpy pandas scikit-learn joblib

Bài tập bắt buộc

1. Chạy script mặc định và đọc threshold sweep.
2. Trả lời: threshold nào có recall cao nhất? threshold nào có precision cao nhất?
3. Giữ rule recall >= 0.75, chọn threshold có expected profit tốt nhất.
4. Đổi rule thành precision >= 0.50, xem threshold thay đổi thế nào.
5. Slice thêm theo region và tenure_bucket, ghi segment nào yếu nhất.
6. Đọc top 20 false positives, ghi 3 pattern có thể giải thích lỗi.
7. Đọc top 20 false negatives, ghi 3 pattern có thể gây mất revenue.
8. So sánh Brier score trước và sau calibration.
9. Chạy leakage demo và giải thích vì sao metric tăng là nguy hiểm.
10. Chạy với --write-artifacts, mở metadata JSON và kiểm tra threshold version.

Bài tập mở rộng

1. Thay Logistic Regression bằng Random Forest hoặc Gradient Boosting.
2. Thêm payment_method vào synthetic dataset và slice theo feature này.
3. Chọn threshold theo capacity: mỗi ngày chỉ xử lý tối đa 500 khách.
4. Thêm cost matrix riêng cho từng segment, ví dụ enterprise customer có FN cost cao hơn.
5. Tạo predict_customer_churn(input_json) dùng artifact đã ghi.
6. Thêm schema validation bằng Pydantic hoặc Pandera.
7. Thêm time-based split giả lập thay vì random stratified split.
8. Ghi baseline metrics vào JSON và so sánh với run mới.

Câu hỏi tự kiểm tra

1. Vì sao threshold 0.50 thường không phải default tốt trong production?
2. Data leakage khác train-serving skew như thế nào?
3. Khi nào calibration quan trọng hơn ROC-AUC?
4. Vì sao không nên chọn threshold trên test set?
5. Nếu model có overall F1 tốt nhưng segment two_year rất tệ, bạn xử lý thế nào?
6. Nếu predicted positive rate production tăng mạnh, bạn debug theo thứ tự nào?

Tiêu chí hoàn thành

• Có bảng threshold từ 0.30 đến 0.80.
• Có confusion matrix tại threshold đã chọn.
• Có top FP/FN.
• Có slice metrics ít nhất 3 segment.
• Có leakage demo và giải thích được vì sao không được dùng feature đó.
• Có threshold metadata gồm model version, threshold version và business objective.
• Có baseline regression gates.