Data Science สาย Credit Risk: จากสมมติฐานสู่โมเดลที่ใช้งานได้จริง

ตอนเริ่มทำงาน data science ในสายความเสี่ยงเครดิต ผมเข้าใจผิดอยู่นานว่างานนี้คือการไล่ค่า accuracy ให้สูงที่สุด ยิ่งโมเดลแม่นยิ่งเก่ง แต่พอทำจริงในงานที่มีคนเอาผลไปตัดสินใจปล่อยสินเชื่อ และมี regulator คอยตรวจ ผมถึงเข้าใจว่าหัวใจของงานไม่ได้อยู่ที่ตัวเลขความแม่นเลย — มันอยู่ที่ว่าโมเดลตอบคำถามธุรกิจถูกข้อไหม อธิบายได้ไหม และเชื่อถือได้นานแค่ไหนหลังเอาไปใช้จริง บทความนี้คือ workflow ที่ผมใช้จริง เล่าเป็นหลักการล้วน ๆ ไม่อิงเคสของที่ไหน

ความเข้าใจผิดเรื่องแรก: accuracy ไม่ใช่เป้าหมาย

ในงาน credit risk โมเดลที่แม่นบนกระดาษแต่เอาไปใช้ไม่ได้ มีค่าน้อยกว่าโมเดลที่ธรรมดากว่าแต่ตัดสินใจได้จริง เพราะปลายทางไม่ใช่คะแนน แต่คือการตัดสินใจที่มีเงินและคนเกี่ยวข้อง การไล่ตัวเลขความแม่นอย่างเดียวมักพาเราไปผิดทาง

ปัญหาที่เจอบ่อยเมื่อมองแต่ความแม่น:

• โมเดลแม่นเพราะ leak ข้อมูลอนาคต ที่ตอนใช้งานจริงยังไม่มี
• แม่นกับกลุ่มลูกค้าเก่า แต่พังกับกลุ่มที่พฤติกรรมต่างออกไป
• เพิ่มความแม่นนิดเดียว แต่แลกกับความซับซ้อนที่อธิบายให้ใครฟังไม่ได้

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

เริ่มจากคำถามธุรกิจก่อนแตะข้อมูล

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

คำถามที่ผมถามตัวเองก่อนเสมอ:

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

พอตอบสามข้อนี้ได้ การออกแบบ target ช่วงเวลาที่ใช้ และเกณฑ์วัดผลก็ชัดขึ้นเอง สมมติฐานที่ดีต้องเขียนเป็นประโยคที่ falsifiable ได้ — ระบุชัดว่าถ้าผลออกมาแบบไหนถือว่าสมมติฐานนี้ผิด ไม่ใช่ปล่อยให้กว้างจนยังไงก็ตีความว่าถูกได้

สร้างฟีเจอร์และโมเดลที่อธิบายได้

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

หลักที่ผมยึดตอนสร้างฟีเจอร์และเลือกโมเดล:

• ฟีเจอร์ต้องมีตรรกะธุรกิจรองรับ ไม่ใช่ correlation ที่บังเอิญเจอ
• เลือกโมเดลที่เรียบที่สุดเท่าที่งานต้องการ ก่อนกระโดดไปหาของซับซ้อน
• ระวัง bias ที่ไม่เป็นธรรม ฟีเจอร์บางตัวสัมพันธ์กับคุณสมบัติที่ใช้ตัดสินใจไม่ได้ตามกฎ

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

พิสูจน์: validation จริงจัง และ monitor หลัง deploy

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

สิ่งที่ผมทำเพื่อพิสูจน์ว่าเชื่อถือได้:

• แบ่ง validation ตามเวลา เลียนแบบการใช้งานจริงที่ทำนายอนาคตจากอดีต
• ตรวจเสถียรภาพข้ามกลุ่ม ไม่ใช่ดูแค่ค่าเฉลี่ยรวมที่ซ่อนปัญหาในกลุ่มย่อย
• ตั้ง monitor หลัง deploy เฝ้าดู data drift และคุณภาพการทำนายต่อเนื่อง ไม่ใช่ส่งแล้วลืม

ในงานที่มี regulator หรือ IC กำกับ ทุกขั้นต้องมีร่องรอยให้ตรวจย้อนได้ — สมมติฐาน เหตุผลของฟีเจอร์ วิธี validation และผลที่ผ่าน ล้วนต้องบันทึกไว้เป็นเอกสาร นี่คือความต่างใหญ่จากงาน data science ทั่วไป ความถูกต้องอย่างเดียวไม่พอ คุณต้อง พิสูจน์ความถูกต้องนั้นให้คนนอกเห็นได้ด้วย

เมื่อมองทั้ง workflow จะเห็นว่ามันคือวงจร ตั้งคำถาม → สร้าง → พิสูจน์ ที่หมุนซ้ำ ไม่ใช่เส้นตรงที่จบในรอบเดียว เครื่องมือ AI อย่าง Claude Code ช่วยเร่งทุกขั้นได้จริง — ร่างสมมติฐาน เขียนโค้ดสร้างฟีเจอร์ ตั้ง validation และจัดเอกสารร่องรอย — แต่จะเร่งได้ก็ต่อเมื่อคุณวางระบบและกติกาเป็น ไม่ใช่ปล่อยให้มันเดาเอง ใครอยากเห็นว่าผมวางระบบการทำงานกับ Claude Code แบบไหนให้มันเป็นผู้ช่วยที่เชื่อถือได้จริง ผมถอดวิธีและตัวอย่างจาก workspace ที่ผมใช้เองไว้ในคอร์ส Claude Code เผื่อหยิบไปปรับกับงานของคุณได้