วิทยาศาสตร์ข้อมูลการเงิน Part.0: 7 เรื่องที่ทำให้วิทยาศาสตร์ข้อมูลการเงินต่างจาก ML ทั่วไป

เริ่มต้นซีรีส์ 「พื้นฐานวิทยาศาสตร์ข้อมูลการเงิน」 บทความนี้เป็นตอนแรก (Part 0) ผมตั้งใจจะค่อยๆ อธิบายเป็นลำดับเหมือนอ่านหนังสือ ตั้งแต่ Part 0 ว่าทำไมวิทยาศาสตร์ข้อมูลในงานพิจารณาสินเชื่อจึงทำงานต่างจาก ML ทั่วไป โดยจะพูดถึงหัวข้ออย่าง reject inference, การอนุมานเชิงสาเหตุ, calibration, การตรวจสอบความถูกต้อง, fairness และกฎระเบียบ
ต้นฉบับลงในบล็อกของผมก่อน → https://han-co.com/ko/blog/part0-finance-ds-7-differences

ผมไม่ใช่ผู้คร่ำหวอดในสายงานนี้มานานมาก เดิมทำงานเป็นวิศวกรในภาคการผลิตก่อนย้ายมาสู่แวดวงการเงิน และตอนนี้ทำงานเป็น data scientist ฝั่งพิจารณาสินเชื่อ เพราะฉะนั้นบทความนี้ก็อยากให้มองว่าไม่ใช่การบอกว่า “นี่คือคำตอบที่ถูกต้อง” แต่เป็นการรวบรวมสิ่งที่ผมเคยสับสนหลังเข้ามาในสายนี้ และคำถามแบบ “เอ๊ะ ทำตามตำราแล้วทำไมยังพลาดอยู่เรื่อย?” มากกว่า

เรื่องที่น่าสนใจก็คือ ไม่ได้มีแค่ผมคนเดียวที่เจอแบบนี้ ต่อให้เป็นคนที่ทำตั้งแต่การสร้างโมเดล ML ทั่วไปไปจนถึงการประเมินผลได้ดี พอเข้ามาทำงานพิจารณาสินเชื่อก็มักพลาดคล้ายๆ กันสักครั้ง ตัวชี้วัดตอนตรวจสอบดูดี แต่พอใช้จริงกลับทำผลงานได้ไม่ถึงที่คิด ความแม่นยำ 99% แต่ไม่มีใครดีใจ หรือรีดประสิทธิภาพเพิ่มมาได้อีก 0.01 แต่ฝ่ายความเสี่ยงกลับสั่งห้าม deploy…

เรื่องนี้ไม่ใช่เพราะขาดฝีมือ แต่เพราะการเงิน (โดยเฉพาะงานพิจารณาสินเชื่อ) ไม่ใช่แค่ “การเอา ML มาใช้กับข้อมูลการเงิน” หากเป็นสาขาที่มีกติกาต่างออกไป และเกือบทุกอย่างที่จะพูดถึงในซีรีส์นี้ต่อจากนี้ ไม่ว่าจะ reject inference, การอนุมานเชิงสาเหตุ, calibration, การตรวจสอบความถูกต้อง, fairness ล้วนตั้งอยู่บนกติกาเหล่านี้

1. Selection bias คือค่าเริ่มต้น

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

ML ทั่วไปมักตั้งสมมติฐานว่า “ข้อมูลเป็นตัวแทนของประชากรทั้งหมด” แต่ในงานพิจารณาสินเชื่อ สมมติฐานนี้พังตั้งแต่แรก ข้อมูลฝึกคือกลุ่มลูกค้าที่เคยได้รับการอนุมัติในอดีต แต่สิ่งที่โมเดลต้องตัดสินจริงๆ คือผู้สมัครทั้งหมดที่ยังไม่ได้รับการอนุมัติ ทั้งสองกลุ่มนี้เป็นคนละประชากรกัน

ผู้สมัครทั้งหมด  
├─ อนุมัติ (สังเกตผลลัพธ์ได้)  
│   ├─ ชำระคืน  → ชำระปกติ  
│   └─ ผิดนัด  → ค้างชำระ·ผิดนัด  
└─ ปฏิเสธ (สังเกตผลลัพธ์ไม่ได้)  → ??? ไม่รู้ว่าจะชำระคืนหรือผิดนัด  

โมเดลเรียนรู้จาก “ลูกค้าที่ได้รับอนุมัติ” เท่านั้น ผลลัพธ์จริงของลูกค้าที่ถูกปฏิเสธจะไม่ถูกบันทึกไว้ในข้อมูล

แค่เรื่องเดียวนี้ก็ทำให้เกิดปัญหามากกว่าที่คิด เมื่อไม่มีข้อมูลหลังการปฏิเสธของ “ลูกค้าที่เคยถูกปฏิเสธ” โมเดลก็ไม่สามารถเรียนรู้บริเวณที่ตัวเองปฏิเสธได้ และรับช่วงอคติของนโยบายอนุมัติในอดีตมาแบบเดิมๆ ดังนั้นในสาขานี้ reject inference (การอนุมานกรณีถูกปฏิเสธ) และการอนุมานเชิงสาเหตุจึงไม่ใช่เทคนิคพิเศษ แต่เป็นพื้นฐาน (สองเรื่องนี้จะค่อยๆ แยกอธิบายเชิงลึกในตอนถัดๆ ไป)

2. เวลาไหลไปทางเดียว และโมเดลก็เสื่อมตามเวลา

ถ้าคุณสุ่มสลับข้อมูลแล้วทำ K-fold จริงๆ แล้วก็เท่ากับแอบลอกอนาคตนิดหน่อย เพราะในชุด validation มีข้อมูลทั้งอดีตและอนาคตปะปนกันอยู่

ข้อมูลสินเชื่อไหลไปตามเวลา โมเดลที่ฝึกจากข้อมูลผู้สมัครปี 2024 จะถูกใช้ประเมินลูกค้าในปี 2026 ระหว่างนั้นเศรษฐกิจก็เปลี่ยน อัตราดอกเบี้ยก็ขึ้น พฤติกรรมลูกค้าและตัวผลิตภัณฑ์ก็เปลี่ยน การกระจายข้อมูลจึงเกิด drift การทำ K-fold แบบสุ่มจะเอาอดีตกับอนาคตมาปนกัน แล้วแอบใส่ข้อมูลที่ไม่มีวันได้ใช้จริงเข้าไปในขั้น validation

เพราะฉะนั้น วิธีตรวจสอบพื้นฐานของงานการเงินคือ OOT (out-of-time) หรือการประเมินด้วยช่วงเวลาที่อยู่หลังช่วงฝึก และหลัง deploy ก็ต้องติดตามต่อเนื่องว่าการกระจายข้อมูลเคลื่อนไปแค่ไหน ลูกค้าเปลี่ยนไปอย่างไรตามเวลา โมเดลเริ่มเสื่อมทันทีตั้งแต่วินาทีที่ถูก deploy

3. แค่ “ใครเสี่ยงกว่า” ยังไม่พอ ต้องรู้ด้วยว่า “กี่ % กันแน่”

โจทย์ classification ทั่วไปมักแค่จัดอันดับให้ถูกก็พอ รู้ว่าใครเสี่ยงกว่ากันและเรียงลำดับได้ดี AUC ก็จะเป็นตัววัดความสามารถนั้น

แต่ในงานสินเชื่อ แค่นั้นยังหยุดไม่ได้ เราต้องการ ความน่าจะเป็นสัมบูรณ์ หรือ PD ที่ผ่านการปรับเทียบแล้ว (calibrated PD) ต้องมีตัวเลขอย่าง “ลูกค้าคนนี้มีโอกาสผิดนัด 3.2% อย่างแม่นยำ” ถึงจะใช้ตั้งราคาได้ (risk-based pricing) ตั้งสำรองได้ (provisioning) และคำนวณ expected loss ได้ ถ้ามีแค่อันดับ จะทำสิ่งเหล่านี้ไม่ได้เลย

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

4. ต้นทุนไม่สมมาตร มาช้า และอยู่ในหน่วยของจำนวนเงิน

accuracy นับความผิดพลาดทุกแบบเท่ากัน แต่ในงานสินเชื่อ น้ำหนักของความผิดพลาดไม่เท่ากันเลย

กำไรจากการอนุมัติลูกค้าคุณภาพดีหนึ่งคนคือ margin (หลักพันเยน) แต่ต้นทุนของการผิดนัดหนึ่งเคสคือ LGD × EAD (หลักหลายแสนเยน) ฝั่งหนึ่งหนักกว่าอีกฝั่งหลายสิบเท่า เพราะฉะนั้นสิ่งที่เราควร optimize ไม่ใช่ accuracy แต่เป็น expected profit และ expected loss

กำไรคาดหวัง = (1 − PD) × margin − PD × LGD × EAD  

expected loss (EL) ในกรณีผิดนัดยังสามารถแยกเป็นผลคูณขององค์ประกอบ 3 อย่างได้อีก

EL = PD × LGD × EAD  

• PD: ความน่าจะเป็นที่จะผิดนัด
• LGD: อัตราความเสียหายเมื่อผิดนัด
• EAD: ยอดคงค้าง ณ เวลาผิดนัด

องค์ประกอบทั้งสามเป็นปัญหาการทำโมเดลคนละแบบกัน หัวใจของ scoring คือ PD

ยิ่งไปกว่านั้น คำตอบยังมาช้ามาก ลูกค้าที่เราอนุมัติวันนี้จะผิดนัดหรือไม่ มักต้องรออีก 12–24 เดือนจึงจะยืนยันได้ การที่ label มาช้าขนาดนี้ทำให้แนวคิดแบบ ML ที่คุ้นกับ feedback เร็วๆ ชนกับความจริงพอสมควร เพราะเราต้องตัดสินใจต่อเนื่องทั้งที่ยังไม่รู้ผลลัพธ์

5. เสถียรภาพสำคัญกว่าประสิทธิภาพสูงสุด

ถ้าเป็นการแข่งขัน ML การรีด AUC เพิ่มอีก 0.001 ก็ถือเป็นคุณความดี แบบเดียวกับการแข่งขันอย่าง Kaggle แต่สำหรับโมเดลสินเชื่อในงานจริง หลายครั้งสิ่งนั้นกลับทำให้เสียมากกว่าได้

โมเดลที่แลกความไม่เสถียรเพื่อเอาประสิทธิภาพเพิ่มมาอีกหยดหนึ่ง จะกลายเป็นต้นทุนในการปฏิบัติการในไม่ช้า เช่น โมเดลที่อินพุตสั่นนิดเดียวแล้วคะแนนแกว่งแรง ทำซ้ำไม่ได้ หรือมีช่วงประหลาดอย่าง “ยิ่งรายได้สูง คะแนนยิ่งต่ำ” เสถียรภาพในการปฏิบัติการ, ความสามารถในการทำซ้ำ, และ monotonicity มักสำคัญกว่าค่าประสิทธิภาพระดับทศนิยม นี่ก็เป็นเหตุผลหนึ่งที่ logistic regression ยังรอดมาได้ในฐานะมาตรฐานของ scoring แม้จะเข้าสู่ยุค GBM แล้วก็ตาม

6. ความสามารถในการอธิบายไม่ใช่ทางเลือก แต่เป็นข้อบังคับ

ในสาขาอื่น หากอธิบายได้ว่า “ทำไมถึงได้ prediction นี้” ก็ถือเป็นโบนัสที่ดี แต่ในงานสินเชื่อ ถ้าทำไม่ได้ก็อาจผิดกฎหมายหรือ deploy ไม่ได้เลย

การแจ้งเหตุผลในการปฏิเสธ (adverse action, 否決理由), การอธิบายต่อหน่วยงานกำกับ, และ internal governance ล้วนต้องการคำอธิบายว่า “ทำไมจึงได้คะแนนนี้” เพราะฉะนั้น black box ไม่ได้ดูเท่ แต่เป็นความเสี่ยงในตัวมันเอง นี่คือเหตุผลที่งานจริงนิยมโครงสร้างอย่าง WOE หรือ scorecard ที่ดึงเหตุผลออกมาได้อย่างเป็นธรรมชาติ และแม้จะใช้ boosting ก็มักเตรียมกลไกอย่าง SHAP เพื่อดึงเหตุผลออกมาควบคู่กันไป

7. มีภาระด้านกฎระเบียบและ governance ปกคลุมอยู่เสมอ

สุดท้าย โมเดลไม่ใช่สิ่งที่ deploy ได้อย่างอิสระ

ไม่ได้จบแค่สร้างโมเดลเสร็จ การบริหารความเสี่ยงโมเดล (MRM), การตรวจสอบอิสระ, การจัดทำเอกสาร, และ audit trail ล้วนเป็นส่วนหนึ่งของกระบวนการพัฒนา มีการแยกผู้พัฒนากับผู้ตรวจสอบออกจากกัน และโมเดลใหม่ก็มักต้องรันแบบ shadow mode ควบคู่สังเกตการณ์อยู่นานก่อนจะเข้าไปมีบทบาทในคำตัดสินจริง สัญชาตญาณแบบสตาร์ตอัปที่ว่า “รีบเอาโมเดลที่ผลงานดีไป deploy ให้เร็ว” มักใช้ไม่ค่อยได้ในที่นี้ ที่ช้าก็มีเหตุผล เพราะโมเดลหนึ่งตัวส่งผลต่อไปถึงการตั้งสำรองและการคำนวณเงินกองทุน

(พอมาทำงานที่ญี่ปุ่นจะยิ่งรู้สึกเรื่องนี้ชัดขึ้น การออกบัตรและการกำหนดวงเงินมีหน้าที่ทางกฎหมายตามกฎหมายการขายผ่อนชำระ (割賦販売法) ในการคำนวณวงเงินที่คาดว่าชำระได้ (支払可能見込額) ทำให้โมเดลกลายเป็นฐานทางกฎหมายโดยตรง เรื่องนี้จะไปเล่าแยกในตอนว่าด้วยกฎระเบียบ)

แบบนี้ไม่ใช่ว่า AI จะทำให้หมดเลยหรือ

ช่วงนี้ผมโดนถามแบบนี้บ่อยมาก เมื่อ generative AI และ agent พัฒนาเร็วขนาดนี้ เรายังจำเป็นต้องเรียนความรู้ด้านการทำโมเดลพวกนี้อยู่หรือเปล่า คำตอบแบบตรงไปตรงมาคือ ยิ่งจำเป็นมากขึ้นต่างหาก (อย่างน้อยก็ในตอนนี้)

7 ข้อที่พูดมาทั้งหมดไม่ใช่เรื่องของอัลกอริทึมตัวใดตัวหนึ่ง แต่เป็นโครงสร้างของปัญหาในสาขานี้ ทั้ง counterfactual ที่สังเกตไม่ได้ ข้อมูลที่ไหลตามลำดับเวลา ต้นทุนไม่สมมาตร ความน่าจะเป็นสัมบูรณ์ เสถียรภาพ ภาระในการอธิบาย และกฎระเบียบ ต่อให้เอา LLM มาต่อเข้าไป ปัญหาเหล่านี้ก็ไม่ได้หายไป ตรงกันข้าม ต้องมีคนที่รู้ว่าปัญหาเหล่านี้มีอยู่ จึงจะกันไม่ให้โมเดลที่ถูกสร้างแบบอัตโนมัติ “มั่นใจเต็มที่แต่ผิดเต็มๆ” ได้

โดยเฉพาะข้อ 6 และ 7 คือหัวใจสำคัญ เราต้องอธิบายเหตุผลการปฏิเสธ ต้องตรวจสอบโมเดลอย่างอิสระ และผลลัพธ์นั้นยังเป็นฐานของการตั้งสำรองและการคำนวณเงินกองทุน โมเดลแบบ black box จึงติดข้อกำหนดเหล่านี้ในเชิงโครงสร้าง ทำให้ generative AI ยังไม่สามารถเข้ามาแทนงานพิจารณาสินเชื่อทั้งหมดได้ แต่คนที่เข้าใจว่า “ทำไมต้องอธิบายได้ และตรวจสอบอย่างไร” จะยังอยู่ในตำแหน่งที่คอยตัดสินผลลัพธ์ที่ AI สร้างออกมา

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

แล้วความเก่งในสายนี้คืออะไร

ถ้าจะสรุปทั้ง 7 ข้อให้เหลือหนึ่งบรรทัด ก็อาจพูดได้แบบนี้

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

ตัวชี้วัดประเมินผลและ scorecard เป็นเหมือนบัตรผ่านเข้าเท่านั้น ความต่างของฝีมือจริงอยู่ที่ selection bias, ความเป็นเหตุเป็นผล, การตรวจสอบความถูกต้อง, และ governance

ในซีรีส์นี้ผมตั้งใจจะค่อยๆ ขุดทั้ง 7 เรื่องทีละข้อ reject inference แก้อย่างไร ทำไมคนจำนวนมากพลาดเรื่อง calibration ทำไมการอนุมานเชิงสาเหตุจึงเป็นหัวใจของการพิจารณาสินเชื่อ และต้องตรวจสอบอย่างไรจึงจะรอดใน production ไปติดตามกันต่อได้ตั้งแต่ตอนหน้า

---

บทความนี้เผยแพร่ครั้งแรกที่ han-co.com และตีพิมพ์เป็นซีรีส์ทั้งภาษาเกาหลีและภาษาญี่ปุ่น ต้นฉบับที่มีไดอะแกรมวาดมือและการสมัครรับอีเมลอยู่ที่นี่ → https://han-co.com/ko/blog/part0-finance-ds-7-differences