การรั่วไหลของข้อมูลและการทำซ้ำ: ภัยพิบัติเงียบและวินัย

กำไร:

• ความสามารถในการจดจำประเภทของการรั่วไหลของข้อมูล (เป้าหมาย เวลา การประมวลผลล่วงหน้า แถวที่จัดกลุ่ม) และสอบถามคะแนน 'ดีเกินจริง' เพื่อเป็นสัญญาณเตือน
• ความสามารถในการป้องกันการรั่วไหลโดยแยกชุดทดสอบ ไปป์ไลน์ และการแบ่งส่วนที่ถูกต้องตั้งแต่เนิ่นๆ (ตามลำดับเวลา/จัดกลุ่ม)
• ความสามารถในการทำให้การวิเคราะห์ทำซ้ำได้ด้วยการตั้งต้นแบบตายตัว การควบคุมเวอร์ชัน และการถอดขั้นตอนแบบแมนนวลออก

มีข้อผิดพลาดสองประการที่ทำให้เสียความพยายามมากที่สุดในวิทยาศาสตร์ข้อมูล และทั้งสองข้อผิดพลาดร้ายกาจเพราะนำไปสู่หายนะเมื่อทุกอย่าง "ดูเหมือนจะเรียบร้อยดี" ประการแรกคือข้อมูลรั่วไหล: โมเดลนี้ใช้งานได้ดีกับชุดทดสอบแต่เกิดข้อขัดข้องในการผลิต ประการที่สองคือไม่สามารถทำซ้ำได้: คุณทำการวิเคราะห์หกเดือนต่อมา และได้ผลลัพธ์ที่แตกต่างไปจากเดิมอย่างสิ้นเชิง หน่วยนี้จัดทำขึ้นเพื่อให้ทราบและหลีกเลี่ยงหลุมพรางทั้งสองนี้ในเชิงลึก AI สามารถเพิ่มความเสี่ยงทั้งสองได้ (สร้างขึ้นอย่างรวดเร็ว แนะนำการรั่วไหลที่ซ่อนอยู่ ช่วยให้คุณดำเนินการตามขั้นตอนด้วยตนเองได้ง่ายขึ้น) แต่ยังสามารถลดความเสี่ยงได้หากใช้อย่างถูกต้อง ความแตกต่างอยู่ที่วินัย

ข้อมูลรั่วไหล: โมเดลผู้มีญาณทิพย์

ข้อมูลรั่วไหลคือเมื่อโมเดลเห็นข้อมูลระหว่างการฝึกซึ่งจะไม่มีในขณะที่คาดการณ์จริง โมเดล "โกง" ด้วยข้อมูลนี้ ดูดีในชุดทดสอบ แต่ล้มเหลวในการผลิตโดยไม่มีข้อมูลนั้น อาการของการรั่วไหลแทบจะเหมือนเดิมทุกครั้ง: ดีเกินกว่าจะเป็นจริงได้ ก่อนที่คุณจะดีใจเมื่อเห็นความแม่นยำ 99% คุณควรมองหารอยรั่วก่อน

การรั่วไหลประเภทหลักคือ:

1. การรั่วไหลของประตู: คุณลักษณะเป็นผลมาจากเป้าหมาย ในการคาดการณ์ "ถูกยกเลิก" คอลัมน์ "วันที่ยกเลิก" หรือ "จำนวนเงินคืน" เป็นผลจากเป้าหมาย จะถูกเติมเมื่อผลลัพธ์ชัดเจนเท่านั้น

2. การรั่วไหลของเวลา: นำข้อมูลในอนาคตไปสู่อดีต เมื่อคำนวณ "ค่าเฉลี่ย 30 วันที่ผ่านมา" ให้รวมวันหลังจากวันที่คาดการณ์ หรือหารอนุกรมเวลาแบบสุ่ม

3. การรั่วไหลก่อนการประมวลผล: การเปลี่ยนแปลงการเรียนรู้ เช่น การปรับขนาด การเติม การเขียนโค้ดจากข้อมูลทั้งหมดก่อนพาร์ติชันการฝึกอบรม/การทดสอบ ค่าเฉลี่ยของข้อมูลการทดสอบรบกวนการฝึกอบรม

4. การรั่วไหลของแถวที่ซ้ำกัน/จัดกลุ่ม: แถวที่เป็นของบุคคลคนเดียวกันจะปรากฏทั้งในการฝึกอบรมและการทดสอบ (การนัดตรวจสองครั้งของผู้ป่วยรายเดียวกันในชุดที่ต่างกัน) โมเดลจะจดจำบุคคล

ประเภทการรั่วไหล

เกิดมาได้อย่างไร

วิธีป้องกัน

เป้าหมายรั่ว

คอลัมน์ที่เป็นผลลัพธ์ของเป้าหมาย

แบบทดสอบ "ฉันมีตอนทำนายไหม"

เวลารั่วไหล

นำอนาคตไปสู่อดีต

การแบ่งตามลำดับเวลา การควบคุมหน้าต่าง

การรั่วไหลของการประมวลผลล่วงหน้า

การแปลงก่อนแยก

ไปป์ไลน์พอดีตั้งแต่การฝึกอบรม

แถวที่จัดกลุ่มรั่ว

หน่วยเดียวกันในสองชุด

แยกตามกลุ่ม (GroupKFold)

วินัยเท่านั้นที่จะป้องกันการรั่วซึม

วิธีแก้ปัญหาทั่วไปสำหรับการรั่วไหลทุกประเภทมีอยู่เพียงประโยคเดียว: แยกชุดการทดสอบออกโดยเร็วที่สุดเพื่อเลียนแบบอนาคตที่แท้จริง และอย่า "สอน" สิ่งใดเลย ในทางปฏิบัติ หมายถึง: อันดับแรก แบ่ง จากนั้นเรียนรู้การเปลี่ยนแปลงทั้งหมดจากการฝึกอบรมเท่านั้น และนำไปใช้ในไปป์ไลน์ (โครงสร้างที่รวบรวมขั้นตอนทั้งหมดไว้ในห่วงโซ่เดียว) สำหรับแต่ละฟีเจอร์ ให้ถามคำถาม "ฉันมีข้อมูลนี้ในขณะที่คาดการณ์หรือไม่" หากมีเวลาก็ให้แบ่งตามลำดับเวลา หากหน่วยเดียวกันซ้ำกัน ให้แบ่งตามกลุ่ม

ข้อควรระวัง: แง่มุมที่อันตรายที่สุดของการรั่วไหลคือแสดงว่ามันประสบความสำเร็จ โมเดลที่ไม่ดีจะสร้างผลลัพธ์ที่ไม่ดีอย่างเห็นได้ชัดและจะถูกสังเกต โมเดลที่รั่วไหลออกมานั้นใช้งานได้ดี ทำให้ทุกคนพอใจ และถูกนำไปใช้จริง นั่นคือจุดเริ่มต้นของการล่มสลาย นั่นเป็นเหตุผลว่าทำไมผลลัพธ์ที่ "ดีมาก" จึงเป็นเรื่องที่น่าตกใจ ไม่ใช่การเฉลิมฉลอง

ความสามารถในการทำซ้ำ: ได้ผลลัพธ์เดียวกันสองครั้ง

ความสามารถในการทำซ้ำคือความสามารถในการได้รับผลลัพธ์เดียวกันเมื่อคุณทำการวิเคราะห์อีกครั้งในเวลาอื่นบนเครื่องอื่น หากปราศจากสิ่งนี้ การวิเคราะห์ของคุณก็จะเป็นเรื่องบังเอิญ ไม่ใช่ทางวิทยาศาสตร์ สาเหตุหลักและวิธีแก้ปัญหาที่ทำให้ความสามารถในการทำซ้ำลดลง:

ขั้นตอนแบบแมนนวล: การเปลี่ยนเซลล์ใน Excel ด้วยตนเอง การแก้ไขแผนภูมิด้วยตนเอง วิธีแก้ไข: มีโค้ดแต่ละขั้นตอน

การสุ่มแบบไม่คงที่: การฝึกโมเดล การสุ่มตัวอย่าง การแยกเกี่ยวข้องกับการสุ่ม วิธีแก้ไข: แก้ไขเมล็ดสุ่ม (ค่าเริ่มต้นของตัวสร้างแบบสุ่ม) (random_state=42)

การเปลี่ยนแปลงเวอร์ชัน: ผลลัพธ์อาจเปลี่ยนแปลงเมื่อเวอร์ชันไลบรารีเปลี่ยนแปลง วิธีแก้ไข: แก้ไขการขึ้นต่อกัน (requirements.txt, ไฟล์สภาพแวดล้อม)

ไม่มีการเก็บบันทึก: ไม่ชัดเจนว่าข้อมูลใด รหัสใด พารามิเตอร์ใดที่ใช้ วิธีแก้ไข: การควบคุมเวอร์ชัน (Git — ระบบที่บันทึกโค้ดทุกเวอร์ชัน) และการกำหนดเวอร์ชันข้อมูล

"ใช้งานได้บนเครื่องของฉันเท่านั้น": วิธีแก้ไข: บันทึกสภาพแวดล้อม ใช้คอนเทนเนอร์ (นักเทียบท่า) หากเป็นไปได้

มินิเคสสามอัน

กรณีที่ 1 — เป้าหมายรั่ว การวิเคราะห์ด้านสุขภาพมีคอลัมน์ "ยาหลังจำหน่าย" เพื่อคาดการณ์ "ว่าผู้ป่วยจะเข้ารับการรักษาอีกครั้งหรือไม่" คอลัมน์นี้จะถูกเติมหลังจากผู้ป่วยออกจากโรงพยาบาลแล้วเท่านั้น โมเดลให้ 96% ในการผลิต 61% โครงการ 8 สัปดาห์เป็นขยะ บทเรียน: ถามแต่ละฟีเจอร์ว่า "มีอยู่ในขณะที่ทำนายหรือไม่"

กรณีที่ 2 — การรั่วไหลของการประมวลผลล่วงหน้า ทีมหนึ่งปรับขนาดข้อมูลทั้งหมดแล้วแยกออก ค่าเฉลี่ยของข้อมูลการทดสอบเกี่ยวข้องกับการปรับขนาด คะแนน CV 89% การผลิตจริง 76% ความสำเร็จจอมปลอมหายไปเมื่อฉันย้ายไปที่ Pipeline และเรียนรู้เกี่ยวกับการเปลี่ยนแปลงจากการฝึกฝนเท่านั้น บทเรียน: แบ่งก่อน แปลงทีหลัง

กรณีที่ 3 — ความล้มเหลวในการทำซ้ำ นักวิเคราะห์ต้องการอัปเดตแผนภูมิที่เขานำเสนอต่อฝ่ายบริหารในสามเดือนต่อมา แต่จำไม่ได้ว่าเขาสร้างมันขึ้นมาอย่างไร มีหลายขั้นตอนที่ดำเนินการด้วยตนเองใน Excel ผลลัพธ์ไม่ได้ผลและความเชื่อมั่นก็สั่นคลอน บทเรียน: ไม่มีขั้นตอนที่ต้องทำเอง ทุกอย่างอยู่ในโค้ดและ Git

เทมเพลตที่สามารถคัดลอกได้สี่แบบ

1) การตรวจสอบรอยรั่ว:

บทบาทของคุณ: ผู้ตรวจสอบการรั่วไหล เป้าหมาย: "ปั่น" (0/1) วันที่อ้างอิงการคาดการณ์: record_date ฉันจะให้รายการคุณสมบัตินี้แก่คุณ สำหรับคุณลักษณะแต่ละรายการ: (a) มันเป็นผลมาจากเป้าหมายหรือไม่ (b) ฉันสามารถใช้ได้ในขณะที่คาดการณ์หรือไม่ (c) กรอบเวลารวมอนาคตหรือไม่ ทำเครื่องหมายว่า "ไม่ปลอดภัย/น่าสงสัย/รั่วไหล" และเขียนเหตุผล คุณสมบัติ: [รายการ]

2) ท่อไร้รอยรั่ว:

ตั้งค่า sklearn Pipeline: ขั้นแรกแยกรถไฟ/ทดสอบ (stratified, seed=42) จากนั้นจึงปรับการประมวลผลล่วงหน้าทั้งหมด (ใส่, สเกล, เข้ารหัส) ลงในไปป์ไลน์จากการฝึกอบรมเท่านั้น อธิบายว่าเหตุใดโค้ดจึงไม่มีการรั่วไหล ขั้นตอนใดเรียนรู้จากที่ไหน

3) รหัสรายการตรวจสอบการทำซ้ำ:

ฉันต้องการให้การวิเคราะห์ของฉันทำซ้ำได้ แนะนำโค้ด/โครงสร้างที่เพิ่ม: (1) ฮาร์ดซีดสำหรับการสุ่มทั้งหมด (2) เวอร์ชันไลบรารีการพิมพ์ที่ใช้ (3) แท็กวันที่/เวอร์ชันสำหรับข้อมูลและเอาต์พุต และให้รายการตรวจสอบเพื่อให้แน่ใจว่าไม่มีขั้นตอนที่ต้องดำเนินการด้วยตนเอง

4) พาร์ติชันที่จัดกลุ่ม (หน่วยเดียวกันรั่ว):

ในข้อมูลมี customer_id เดียวกันอยู่ในหลายแถว ทำการแยก (GroupKFold หรือ GroupShuffleSplit, group = customer_id) ที่ป้องกันไม่ให้ลูกค้ารายเดียวกันอยู่ในทั้งการฝึกอบรมและการทดสอบ รวมรหัสเพื่อตรวจสอบว่าไม่มีลูกค้าอยู่ในทั้งสองชุดหลังจากแยก

พรอมต์อ่อน / พรอมต์แข็งแกร่ง

พรอมต์ที่อ่อนแอ:

โมเดลของฉันส่งคืนความแม่นยำ 98% เยี่ยมมากใช่ไหม ปรับโค้ดให้เหมาะสม

ฉลอง 98% ซ่อนรอยรั่ว ก่อนที่จะเพิ่มประสิทธิภาพ ควรตั้งคำถามว่าคะแนนนี้มีจริงหรือไม่

พรอมต์อันทรงพลัง:

บทบาทของคุณ: ผู้ตรวจสอบการรั่วไหล แบบจำลองของฉันส่งคืนความแม่นยำ 98% ในชุดทดสอบ ซึ่งฟังดู "ดีเกินจริง" สำหรับฉัน ตรวจสอบ: (1) เป็นคุณสมบัติใด ๆ ที่เป็นผลลัพธ์ของเป้าหมาย (2) เป็นการแปลงที่ทำก่อนที่จะแยก (3) เป็นหน่วยเดียวกันในสองชุด (4) มีการรั่วไหลทุกครั้งหรือไม่ ระบุประเด็นที่น่าสงสัย เน้นหาจุดรั่วไม่แก้คะแนน

ในที่นี้ คะแนนที่สูงจะถือเป็นสัญญาณที่ต้องถูกตั้งคำถาม ไม่ใช่เพื่อเฉลิมฉลอง

ข้อผิดพลาดทั่วไป

• ฉลองผลงาน "ดีมาก" คะแนนที่ดีเกินจริงคือการแจ้งเตือนการรั่วไหล ไม่ใช่ความสำเร็จ
• เรียนรู้การเปลี่ยนแปลงจากข้อมูลทั้งหมดก่อนการแบ่งส่วน การรั่วไหลที่พบบ่อยที่สุด แยกก่อนด้วยไปป์ไลน์
• การแบ่งอนุกรมเวลาแบบสุ่ม โมเดลมองเห็นอนาคต การแบ่งตามลำดับเวลาเป็นสิ่งจำเป็น
• ออกจากหน่วยเดียวกันเป็นสองชุด แบบจำลองจะจดจำบุคคลนั้น แบ่งตามกลุ่ม.
• ไม่ก้าวเข้ามาด้วยตนเองและเขียนลงในโค้ด การวิเคราะห์ไม่สามารถทำซ้ำได้ ทุกอย่างควรอยู่ในโค้ดและ Git

เคล็ดลับ: เขียน "pledge of Honor" สองประโยคในตอนต้นของโปรเจ็กต์ของคุณ: "ฉันไม่ได้สัมผัสชุดทดสอบแต่อย่างใดก่อนที่จะเห็นมันในการผลิต ทุกขั้นตอนอยู่ในโค้ดและเมล็ดพืชได้รับการแก้ไขแล้ว" หากคุณไม่สามารถลงนามสองประโยคนี้ได้อย่างตรงไปตรงมา ผลลัพธ์ของคุณยังไม่น่าเชื่อถือ

โดยสรุป

ข้อมูลรั่วไหลและไม่สามารถทำซ้ำได้ถือเป็นข้อผิดพลาดเงียบที่มีราคาแพงที่สุดสองประการในสาขาวิทยาศาสตร์ข้อมูล การรั่วไหลเป็นวิสัยทัศน์ของโมเดลในอนาคตและนำเสนอตัวเองว่าเป็นความสำเร็จที่ผิดพลาด วิธีแก้ไขคือแยกชุดการทดสอบตั้งแต่เนิ่นๆ เรียนรู้การเปลี่ยนแปลงจากการฝึกอบรมเท่านั้น (ไปป์ไลน์) ถามแต่ละฟีเจอร์ด้วยคำถาม "ฉันมีการทดสอบนี้หรือไม่ในขณะที่คาดการณ์" และทำการแยกที่ถูกต้อง (ตามลำดับเวลา/จัดกลุ่ม) ความสามารถในการทำซ้ำคือการได้รับผลลัพธ์เดียวกันสองครั้ง วิธีแก้ปัญหาของเขาคือการลบขั้นตอนด้วยตนเอง ปักหมุด seed หยุดเวอร์ชัน และเก็บทุกอย่างไว้ใน Git AI สามารถเพิ่มหรือลดความเสี่ยงเหล่านี้ได้ มันเป็นวินัยของคุณที่กำหนด

งานสมัคร

นำรายการคุณลักษณะของแบบจำลองที่คุณสร้างขึ้น (หรือแบบจำลองสมมุติ) และถามคำถามแต่ละคุณลักษณะว่า "ฉันมีข้อมูลนี้ในขณะที่คาดการณ์หรือไม่" เป็นลายลักษณ์อักษร; ค้นหาผู้สมัครที่รั่วไหลอย่างน้อยหนึ่งราย จากนั้นกรอกรายการตรวจสอบเพื่อทำให้การวิเคราะห์ของคุณสามารถทำซ้ำได้: มีการแก้ไขเริ่มต้นหรือไม่ มีขั้นตอนแบบแมนนวล มีการลงทะเบียนเวอร์ชันต่างๆ หรือไม่ มีอยู่ใน Git หรือไม่ แก้ไขข้อบกพร่อง.

รายการตรวจสอบ

• [ ] ฉันค้นหาคะแนน "ดีเกินจริง" เพื่อเป็นการแจ้งเตือนการรั่วไหลหรือไม่
• [ ] ฉันได้เรียนรู้การเปลี่ยนแปลงทั้งหมดหลังการแยกจากกันแค่จากการฝึกฝนหรือเปล่า?
• [ ] ฉันได้แบ่งตามโครงสร้างเวลา/กลุ่ม (ตามลำดับเวลา/GroupKFold) หรือไม่?
• [ ] ฉันได้ทำการสุ่มซ้ำทั้งหมดด้วยเมล็ดคงที่หรือไม่?
• [ ] ฉันได้ลบขั้นตอนที่ต้องดำเนินการด้วยตนเองและเก็บทุกอย่างไว้ในโค้ดและการควบคุมเวอร์ชันหรือไม่