อยากเป็น Data Scientist สายการเงิน/ธนาคาร เริ่มยังไง — เส้นทางจากคนที่เดินมาแล้ว

มีคนถามผมบ่อยว่า "อยากเข้าสาย data science การเงินต้องเริ่มจากอะไร" แล้วคำตอบที่เขาคาดหวังมักจะเป็นคอร์สไหน ภาษาอะไร เรียนอัลกอริทึมตัวไหนก่อน แต่พอผมเดินเส้นทางนี้มาเองในสาย risk modeling ของธนาคาร — ทำตั้งแต่สร้างโมเดล ทำ validation ไปจนถึงสร้าง early warning system ที่ใช้ deep learning — ผมกลับพบว่าสิ่งที่แยกคนทำงานสายนี้ได้จริงออกจากคนที่ติดอยู่แค่หน้า notebook ไม่ใช่จำนวนอัลกอริทึมที่รู้เลย บทความนี้ผมเล่าภาพรวมเส้นทางแบบหลักการล้วน ๆ ให้คนที่อยากเข้าสายนี้เห็นว่าปลายทางทำอะไร ต้องเตรียมอะไร และยุคนี้ควร leverage ตัวเองยังไง

งานสายนี้ทำอะไรจริง ไม่ใช่แค่เทรนโมเดล

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

งานที่ผมเห็นว่าเป็นแกนของสายนี้ในฝั่งธนาคาร:

• Credit risk modeling — สร้างโมเดลประเมินว่าลูกค้ารายไหนน่าจะผิดนัดชำระ เพื่อใช้ตัดสินใจอนุมัติ ตั้งวงเงิน หรือตั้งราคาตามความเสี่ยง
• Model risk / model validation — ตรวจสอบโมเดลที่คนอื่นสร้าง ว่าตั้งสมมติฐานถูกไหม ทดสอบครบไหม และยังเชื่อถือได้อยู่หรือเปล่าหลังเอาไปใช้จริง
• Early warning system — ระบบจับสัญญาณเตือนล่วงหน้าว่าลูกค้าหรือพอร์ตกำลังจะมีปัญหา ก่อนที่มันจะกลายเป็นหนี้เสีย
• งาน data ที่ต้องเข้าใจ domain — ทำความสะอาดและจัดการข้อมูลการเงิน สร้างฟีเจอร์ที่มีตรรกะธุรกิจรองรับ และตอบคำถามจาก business ด้วยข้อมูล

จุดร่วมของงานพวกนี้คือ ปลายทางไม่ใช่คะแนนความแม่นในกระดาษ แต่คือการตัดสินใจที่ตรวจสอบได้และอธิบายให้ผู้กำกับฟังรู้เรื่อง ผมเขียนรายละเอียด workflow ฝั่งนี้ไว้แล้วใน Data Science สาย Credit Risk จากสมมติฐานสู่โมเดลที่ใช้งานได้จริง ถ้าอยากเห็นว่าวันทำงานจริงเป็นยังไง

ทักษะที่ต้องมีจริง ไม่ใช่แค่เก่งโมเดล

ถ้าให้ผมจัดน้ำหนักทักษะของสายนี้ ผมไม่ได้ให้น้ำหนัก ML สูงสุดอย่างที่หลายคนคิด มันสำคัญ แต่เป็นแค่ขาหนึ่งของเก้าอี้สี่ขา ขาดขาไหนไปก็นั่งไม่ได้

สี่ขาที่ผมคิดว่าจำเป็นจริง:

• พื้นฐานสถิติและ ML — ไม่ต้องรู้ทุกอัลกอริทึม แต่ต้องเข้าใจลึกพอจะรู้ว่าเมื่อไรควรใช้อะไร และโมเดลกำลังโกหกเราตรงไหน เช่น overfitting หรือข้อมูลรั่ว
• การเขียนโค้ดและจัดการข้อมูล — Python กับ SQL คือเครื่องมือพื้น งานจริงเวลาส่วนใหญ่หมดไปกับการดึง ทำความสะอาด และต่อข้อมูลให้พร้อมใช้ ไม่ใช่กับบรรทัดที่เรียก .fit()
• เข้าใจ domain การเงิน — อันนี้คือขาที่คนเข้าสายใหม่ประเมินค่าต่ำที่สุด ถ้าไม่เข้าใจว่าสินเชื่อทำงานยังไง ความเสี่ยงเกิดจากอะไร หรือกฎเกณฑ์บังคับอะไร เราจะสร้างฟีเจอร์ที่ไม่มีความหมาย และตอบคำถามผิดข้อ
• สื่อสารผลให้คนไม่ใช่สาย tech เข้าใจ — ต้องอธิบายโมเดลให้ business และผู้กำกับฟังรู้เรื่อง ว่ามันตัดสินใจจากอะไรและเชื่อถือได้แค่ไหน โมเดลที่อธิบายไม่ได้ ในงานที่มี regulator ถือว่าใช้ไม่ได้ ต่อให้แม่นแค่ไหน

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

ยกตัวอย่างจริงตอนผมทำ early warning system — สองเรื่องที่กลายเป็นหัวใจไม่ใช่ตัวอัลกอริทึม แต่คือ การจัดการ target leakage (กันไม่ให้โมเดลแอบเห็นข้อมูลที่ในความจริงยังมาไม่ถึง จนดูแม่นเกินจริง) กับการใช้ ค่า SHAP มาอธิบายว่าแต่ละฟีเจอร์ผลักการทำนายไปทางไหน สองอย่างนี้สำคัญที่สุดตอนต้องนำเสนอและตอบคำถามฝั่ง audit เพราะเขาไม่ได้สนแค่ว่าโมเดลแม่นแค่ไหน แต่สนว่าเราเข้าใจมันจริงไหม และพิสูจน์ได้ไหมว่ามันไม่ได้แม่นเพราะ "โกง" ข้อมูล จุดนี้แหละที่แยกคนสร้างโมเดลให้เล่นในเดโม ออกจากคนสร้างโมเดลที่ผ่านเข้าไปใช้งานจริงได้

เริ่มจากตรงไหน ถ้ายังไม่ได้อยู่ในสาย

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

• ปูพื้นให้แน่นก่อน — สถิติพื้นฐาน Python และ SQL ให้ใช้งานคล่อง ไม่ต้องรอจนเพอร์เฟกต์ แค่พอทำโปรเจกต์จริงได้
• เติม domain การเงินคู่ขนานไปเลย — อ่านเรื่องสินเชื่อ ความเสี่ยงเครดิต และพื้นฐานการกำกับ ควบคู่กับการเรียนเทคนิค อย่าแยกสองอย่างนี้ออกจากกัน
• ทำ portfolio ที่เลียนแบบงานจริง — แทนที่จะทำโปรเจกต์ทำนายราคาหุ้นที่ใคร ๆ ก็ทำ ลองหยิบชุดข้อมูลสินเชื่อสาธารณะมาสร้างโมเดลทำนายการผิดนัดชำระ แล้วโฟกัสที่การอธิบาย ว่าทำไมเลือกฟีเจอร์นี้ ทำไมเชื่อผลนี้ และจะตรวจสอบความน่าเชื่อถือยังไง โปรเจกต์ที่อธิบายเหตุผลได้ชัดมีค่ากว่าโปรเจกต์ที่ accuracy สูงแต่เล่าที่มาไม่ได้
• มองงานให้ถูกประตู — ตำแหน่งเริ่มต้นในสายนี้มักมาในชื่อ data analyst ฝั่งความเสี่ยง credit risk analyst หรือ model developer/validator junior อย่ารอตำแหน่งที่ชื่อสวยที่สุด ให้มองที่ว่างานนั้นได้แตะข้อมูลและการตัดสินใจจริงไหม

จุดที่อยากย้ำคือ portfolio ของสายนี้ไม่ได้วัดที่ความหวือหวาของโมเดล แต่วัดที่ว่าคุณคิดเหมือนคนทำงาน risk หรือยัง — ระแวงข้อมูลรั่ว ใส่ใจกลุ่มที่สำคัญต่อธุรกิจ และอธิบายทุกการตัดสินใจได้

domain การเงินคือกำแพงกั้น และคือข้อได้เปรียบ

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

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

ข่าวดีคือ กำแพงนี้แหละที่เป็นข้อได้เปรียบของคุณเมื่อข้ามมันได้ ในยุคที่ใคร ๆ ก็เรียน ML ได้จาก YouTube การเข้าใจว่าโมเดลนี้จะถูกใช้ตัดสินใจอะไร และจะผ่าน validation ได้ยังไง คือทักษะที่หายากกว่ามาก ผมเขียนเรื่องนี้ไว้ลึกขึ้นใน Model Risk Management ในยุค AI ว่าทำไมความเข้าใจกรอบการกำกับถึงยิ่งสำคัญขึ้นเมื่อโมเดลซับซ้อนขึ้น

เพราะฉะนั้นถ้าคุณมาจากสายการเงินอยู่แล้ว อย่ามองว่าตัวเองเริ่มช้า คุณมีของที่คนสาย tech ต้องใช้เวลาหลายปีกว่าจะได้ ที่ต้องเติมคือฝั่งเครื่องมือ และวันนี้ฝั่งเครื่องมือถูกเร่งให้เรียนเร็วขึ้นมากด้วย AI

AI กำลังเปลี่ยนงานสายนี้ และทำไมต้องจับตอนนี้

ไม่กี่ปีมานี้สิ่งที่เปลี่ยนมากที่สุดในงานสายนี้ไม่ใช่อัลกอริทึมใหม่ แต่คือเครื่องมือ agentic อย่าง Claude Code ที่ทำให้คนคนเดียวทำงาน data ได้กว้างและเร็วขึ้นมาก งานที่เคยกินเวลาหลายวัน — เขียนสคริปต์ดึงและต่อข้อมูล ทำ feature engineering ซ้ำ ๆ ร่างเอกสาร validation หรือไล่หา bug ในไปป์ไลน์ — ตอนนี้ทำผ่านการสั่งงานเป็นภาษาคนได้ในเสี้ยวของเวลาเดิม

ที่ผมรู้สึกถึงความต่างชัดที่สุดคือเรื่องการ explore และทำ PoC: ทุกวันนี้พอมีหัวข้อที่อยากลอง ผมให้ Claude Code ช่วยไป explore หรือขึ้น proof-of-concept ให้ แล้วเอาผลมานั่งคุยสรุปแนวทางกันต่อ — ใช้เวลาแค่ราว 20 นาทีต่อวัน แต่ผลคือผมได้ทดลองของใหม่แทบทุกวัน แทนที่จะเสียครึ่งวันไปกับการ setup จนหมดแรงก่อนได้เริ่มคิด ของเล็ก ๆ ที่ทบกันทุกวันแบบนี้แหละที่กลายเป็นข้อได้เปรียบระยะยาว

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

นี่คือเหตุผลที่ผมเชียร์ให้คนสายนี้ — โดยเฉพาะคนที่กำลังจะเข้าสาย — จับเครื่องมือ agentic ตั้งแต่วันนี้ ไม่ใช่รอให้เก่ง data ก่อนแล้วค่อยมาเรียน เพราะมันคือ leverage ที่ทำให้คนเริ่มต้นทำงานได้ใกล้เคียงคนมีประสบการณ์เร็วขึ้นมาก ผมขยายความว่าทำไมคนสายการเงินถึงควรเรียนเครื่องมือนี้ก่อนใครไว้ใน ทำไมคนสายการเงินควรเรียน Claude Code

สรุปเส้นทาง และก้าวต่อไป

ถ้าให้ย่อทั้งบทเป็นไม่กี่ประโยค เส้นทางเข้าสาย data science การเงินคือ ปูพื้นสถิติและการเขียนโค้ดให้พอใช้งาน เติม domain การเงินอย่างจริงจัง ฝึกอธิบายงานให้คนไม่ใช่สาย tech เข้าใจ และทำ portfolio ที่คิดเหมือนคนทำงาน risk จริง อย่าหลงไปไล่ความแม่นของโมเดลจนลืมว่าปลายทางคือการตัดสินใจที่ตรวจสอบได้

และในยุคนี้ ก้าวที่ให้ leverage สูงที่สุดก้าวหนึ่งคือการเรียนเครื่องมือ agentic ให้เป็นตั้งแต่ต้น เพราะมันคูณความเร็วของทุกอย่างข้างบน ผมตั้งใจทำคอร์ส Claude Code สำหรับคนสายการเงินและ data ขึ้นมาเพื่อให้คุณข้ามขั้นลองผิดลองถูกที่ผมเสียเวลาไปเอง และจับเครื่องมือนี้ได้เร็วกว่าด้วยตัวอย่างจากงานจริงสายธนาคาร

ถ้าคุณกำลังจะเข้าสายนี้ หรืออยู่ในสายแล้วและอยากเร่งตัวเองด้วย AI — ลองดูรายละเอียดได้ที่ คอร์ส Claude Code แล้วเริ่มสร้าง leverage ให้ตัวเองตั้งแต่วันนี้