| name | leak-check |
| description | ไล่ตรวจโค้ด ML หา data leakage และบาปคลาสสิกทั้ง 7 — preprocessing fit ก่อน split, feature จากอนาคต, group รั่วคร่อม train/test, target leakage, test-set contamination, ไม่ seed, train/serve skew — ชี้บรรทัด อธิบายกลไกรั่ว และตัดสินว่า metric ที่รายงานไว้เชื่อได้หรือต้องวัดใหม่ Trigger on "เช็ค leakage", "ตรวจ data leakage", "รีวิวโค้ดเทรน", "ทำไม accuracy สูงผิดปกติ", or when a model's metric looks too good to be true. |
leak-check — metric สวยผิดปกติ ให้สงสัยว่ารั่ว ก่อนสงสัยว่าเก่ง
Phase 0 — อ่านทั้ง pipeline ไม่ใช่แค่ไฟล์เทรน
ไล่ตามเส้นทางข้อมูลจริง: โหลด → clean/feature engineering → split → fit → evaluate → (serve ถ้ามี) — leakage ส่วนใหญ่เกิดก่อนบรรทัด model.fit() และมองไม่เห็นถ้าเปิดดูแค่ตอนเทรน
Phase 1 — บาป 7 ข้อ
| # | บาป | หน้าตาในโค้ด | กลไกการรั่ว |
|---|
| 1 | Fit ก่อน split | scaler.fit(X) แล้วค่อย train_test_split | สถิติของ test (mean/std/min-max) ซึมเข้า train — ต้อง fit เฉพาะ train แล้ว transform test |
| 2 | Temporal leakage | feature เป็น aggregate ทั้งช่วงเวลา, random split บนข้อมูลมีเวลา, ใช้ค่า "อนาคตของแถวนั้น" | โมเดลเห็นอนาคตตอนเทรน — ใน production ไม่มีอนาคตให้เห็น |
| 3 | Group leakage | user/คนไข้/ร้านเดิมอยู่ทั้ง train และ test | โมเดลจำ entity ไม่ใช่เรียน pattern — เจอ entity ใหม่แล้วร่วง |
| 4 | Target leakage | feature ที่เป็น proxy ของคำตอบ (ค่าที่รู้ได้ก็ต่อเมื่อเหตุการณ์เกิดแล้ว เช่น "จำนวนวันที่ค้างชำระ" ตอนทำนาย default) | metric เทพตอน dev, พังตอน serve เพราะ feature นั้นยังไม่มีค่า |
| 5 | Test contamination | ใช้ test set เลือก feature / tune hyperparameter / early stopping / เลือกโมเดล | test กลายเป็น validation — ตัวเลขสุดท้าย optimistic เสมอ |
| 6 | Randomness ไม่คุม | ไม่ seed numpy/torch/sklearn, split ใหม่ทุกรัน | ผล reproduce ไม่ได้ — เทียบ run ต่อ run ไม่มีความหมาย |
| 7 | Train/serve skew | preprocessing ตอนเทรนกับตอน serve เขียนคนละที่คนละ logic | โมเดลถูกแต่ input ตอนจริงคนละภาษากับตอนเทรน |
Phase 2 — รายงาน
ต่อ finding: file:line + เล่ากลไกรั่วเป็นเหตุการณ์ (ไม่ใช่แปะชื่อบาป) + วิธีแก้เจาะจง (pipeline object, split ใหม่, ตัด feature) + ผลต่อ metric
ปิดท้ายด้วย คำตัดสินรวม เสมอ:
- ✅ ไม่พบรั่ว — metric ปัจจุบันเชื่อได้ (ในขอบเขตที่โค้ดแสดง)
- ⚠️ พบรั่วเบา — ตัวเลข optimistic, แก้ข้อ X แล้ววัดใหม่เพื่อยืนยัน
- 🔴 พบรั่วหนัก — ตัวเลขที่รายงานไว้ใช้ไม่ได้ ต้องแก้แล้ว rerun ทั้งชุด ระบุลำดับ: แก้อะไรก่อน วัดใหม่ยังไง เทียบกับ baseline ไหน
กติกา
- ทุกข้อกล่าวหาต้องมีบรรทัดอ้างอิง — ไม่มีหลักฐาน = ไม่รายงาน
- อย่าเหมา: บาง pattern ดูเหมือนรั่วแต่ถูก (เช่น fit บน train ทั้งก้อนใน CV loop ที่ทำถูกแล้ว) — อ่าน context ก่อนฟันธง
- ถ้าแก้แล้ว metric ตก — นั่นคือข่าวดี (ตัวเลขจริงโผล่มาแล้ว) ช่วย user สื่อสารเรื่องนี้กับทีม/อาจารย์ให้เป็น
