leak-check

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 สื่อสารเรื่องนี้กับทีม/อาจารย์ให้เป็น