บทเรียนจากการสร้าง NLP Early Warning System ตัวแรกที่ใช้ Deep Learning ในที่ทำงาน
ระบบเตือนภัยล่วงหน้าที่อ่านข่าวและข้อความเพื่อจับสัญญาณความเสี่ยงด้านเครดิตก่อนกลายเป็นหนี้เสีย — บทเรียนจากการนำ deep learning (WangchanBERTa) มาใช้จริงเป็นครั้งแรกในที่ทำงาน
NLP Early Warning System: จับสัญญาณเสี่ยงก่อนเป็นหนี้เสีย
ข้อมูล
ข่าว+ข้อความ unstructured
NLP
สกัดสัญญาณเชิงลบ
เตือน
ส่งทีมก่อนเกิด NPL
งานสาย model risk ที่ผมทำมาตลอด มีคำถามหนึ่งที่ตามหลอนอยู่เสมอ — กว่าตัวเลขจะบอกว่าลูกหนี้กำลังมีปัญหา มันมักจะ "สาย" ไปแล้ว ยอดค้างชำระ อัตราส่วนทางการเงิน หรือพฤติกรรมการจ่าย ล้วนเป็นสัญญาณที่ปรากฏ "หลัง" จากเรื่องเริ่มแย่ ผมเลยลองตั้งคำถามกลับด้านว่า ถ้าสัญญาณบางอย่างซ่อนอยู่ใน "ข้อความ" — ข่าว คำให้สัมภาษณ์ รายงาน — ก่อนที่มันจะกลายมาเป็นตัวเลข เราจะดึงมันออกมาใช้เตือนล่วงหน้าได้ไหม นั่นคือจุดเริ่มต้นของ NLP Early Warning System ที่ผมสร้างขึ้น และเป็นครั้งแรกที่ผมนำ deep learning เข้ามาใช้กับงานลักษณะนี้ในที่ทำงาน โดยเลือกใช้ WangchanBERTa ซึ่งเป็นโมเดลภาษาไทยแบบ pretrained มาเป็นแกนหลักในการอ่านและตีความข้อความ — ที่เลือกตัวนี้ด้วยสองเหตุผล: ข้อความที่ต้องอ่านเป็นภาษาไทยเป็นหลัก และ WangchanBERTa เป็นโมเดลไทย pretrained ที่ดีและพร้อมใช้ที่สุดในตอนนั้น ผมจึงนำมา fine-tune ต่อได้เลยโดยไม่ต้องเทรนใหม่จากศูนย์
ทำไมสัญญาณจากตัวเลขล้วน ๆ ถึงมาช้า
โมเดลความเสี่ยงด้านเครดิตแบบดั้งเดิมพึ่งพาข้อมูลเชิงตัวเลขเป็นหลัก ซึ่งดีตรงที่วัดได้ชัดและเข้าโมเดลง่าย แต่จุดอ่อนคือมันสะท้อนสิ่งที่ "เกิดขึ้นแล้ว" ไม่ใช่สิ่งที่ "กำลังจะเกิด"
กว่างบการเงินจะออก กว่ายอดค้างชำระจะโผล่ในระบบ เรื่องที่อยู่เบื้องหลังมักดำเนินมาหลายเดือนแล้ว ในมุมของคนทำ risk การรู้ช้าแม้แค่ไตรมาสเดียวก็หมายถึงทางเลือกที่หายไปหลายทาง
ปัญหาหลักที่ผมพยายามแก้สรุปได้สั้น ๆ ว่า:
- สัญญาณเชิงตัวเลขเป็น lagging indicator — มาหลังเหตุการณ์เสมอ
- ข้อมูลที่ "มาก่อน" มักอยู่ในรูปข้อความที่ไม่มีโครงสร้าง (unstructured)
- คนอ่านข่าวเองไม่ไหว เพราะปริมาณเยอะเกินกว่าทีมจะตามทัน
มุมคนทำ model validation: สัญญาณจากตัวเลขล้วน ๆ เป็น lagging indicator — มันบอกสิ่งที่ "เกิดขึ้นแล้ว" ไม่ใช่สิ่งที่ "กำลังจะเกิด" และในงาน risk การรู้ช้าแม้แค่ไตรมาสเดียวก็แพง
ไอเดีย: ดึงสัญญาณจากข้อความก่อนที่มันจะเป็นตัวเลข
หัวใจของระบบคือสมมติฐานง่าย ๆ ว่า เรื่องร้ายมัก "ถูกพูดถึง" ก่อนที่มันจะปรากฏในงบ ข่าวเชิงลบ การเปลี่ยนผู้บริหารกะทันหัน ข้อพิพาท หรือสัญญาณความเครียดในซัพพลายเชน — สิ่งเหล่านี้เป็นภาษา ไม่ใช่ตัวเลข
งานของ NLP คือเปลี่ยน "ภาษา" ให้กลายเป็นสัญญาณที่ทีม risk เอาไปใช้ต่อได้ ไม่ใช่แทนที่โมเดลเดิม แต่มาเสริมให้เห็นภาพเร็วขึ้นอีกชั้นหนึ่ง
ผมตั้งใจให้มันเป็น complement ไม่ใช่ replacement ตั้งแต่แรก เพราะการเสนอว่าจะมาแทนของเดิมทั้งหมด เป็นวิธีที่เร็วที่สุดในการทำให้ทีมที่ใช้งานจริง "ไม่เชื่อใจ" เครื่องมือใหม่ — เรื่องการวางโมเดล AI ให้เสริมของเดิมแทนที่จะแทนที่ ผมเล่าต่อในมุมการจัดการความเสี่ยงโมเดลในยุค AI
ขั้นตอนคร่าว ๆ: ข้อมูล → NLP → เตือน
ในเชิงโครงสร้าง ระบบแบ่งเป็นสามช่วงตรงตามที่ภาพด้านบนสื่อ และแต่ละช่วงมีโจทย์ของตัวเอง
ช่วงแรกคือ รวบรวมข้อมูล — ดึงข้อความจากแหล่งที่เกี่ยวข้องเข้ามาอย่างสม่ำเสมอ จัดให้อยู่ในรูปที่ประมวลผลต่อได้ ความท้าทายที่นี่ไม่ใช่เรื่องโมเดล แต่เป็นเรื่องความสะอาดและความต่อเนื่องของข้อมูลล้วน ๆ
ช่วงที่สองคือ ใช้ NLP สกัดสัญญาณ — ระบุว่าข้อความนั้นพูดถึงใคร พูดในเชิงบวกหรือลบ และมีน้ำหนักมากพอที่จะสนใจไหม จุดนี้คือหัวใจ แต่ก็เป็นจุดที่หลอกตัวเองได้ง่ายที่สุดเช่นกัน
ช่วงสุดท้ายคือ ส่งสัญญาณให้ทีมก่อนเกิดปัญหา — เปลี่ยนผลลัพธ์ให้อยู่ในรูปที่คนทำงานเปิดดูแล้ว "ทำอะไรต่อได้" ไม่ใช่กองคะแนนที่ไม่มีใครรู้ว่าจะเอาไปใช้ยังไง
- เก็บข้อมูลให้สม่ำเสมอ สำคัญกว่าเก็บให้เยอะแบบกระโดด ๆ
- สัญญาณต้อง "อธิบายได้" ว่าทำไมถึงเตือน ไม่ใช่กล่องดำ
- ปลายทางต้องเชื่อมเข้ากับวิธีทำงานเดิมของทีม ไม่ใช่บังคับให้เขาเปลี่ยนนิสัย
บทเรียนที่สำคัญกว่าตัวโมเดล
บทเรียนแรกคือ false positive คือศัตรูตัวจริง ไม่ใช่ความแม่นยำ ระบบที่เตือนผิดบ่อย ๆ จะถูกทีมเมินภายในไม่กี่สัปดาห์ ต่อให้ในกระดาษมันดูฉลาดแค่ไหน คนที่ต้องตามเช็คทุกครั้งจะเลิกเชื่อก่อนเสมอ โจทย์ false positive เดียวกันนี้กำลังกลับมาเป็นตัวตัดสินอีกครั้งเมื่อผู้ให้บริการเริ่มเอา AI agent มารับงานสืบสวนฟอกเงินในแบงก์โดยตรง — เร็วขึ้นไม่มีความหมาย ถ้ามันทำให้คนเชื่อสัญญาณที่ผิดเร็วขึ้น ผมเรียนรู้ว่าการ "เตือนน้อยแต่ตรง" มีค่ามากกว่า "เตือนเยอะแล้วถูกบ้างผิดบ้าง"
กฎจากงานวัดความเสี่ยง: false positive คือศัตรูตัวจริง ไม่ใช่ความแม่นยำ — ระบบที่เตือนผิดบ่อย ๆ จะถูกทีมเมินภายในไม่กี่สัปดาห์ "เตือนน้อยแต่ตรง" ชนะเสมอ
บทเรียนที่สองคือ ความเชื่อใจสร้างยากกว่าโมเดล เครื่องมือ risk ที่ดีต้องให้ทีมที่ใช้รู้สึกว่ามันช่วยเขา ไม่ใช่มาตรวจการบ้านเขา ผมใช้เวลากับการนั่งฟังว่าทีมอยากเห็นอะไร และปรับรูปแบบการแจ้งเตือนตามนั้น มากพอ ๆ กับเวลาที่ใช้กับตัวอัลกอริทึม
บทเรียนสุดท้ายคือต้องวัดว่ามัน "มีประโยชน์จริง" ไม่ใช่แค่ "แม่น" — สองคำนี้ไม่เหมือนกัน
- โมเดลแม่นในชุดทดสอบ ไม่ได้แปลว่าช่วยงานจริง
- ตัวชี้วัดที่ดีคือ ทีมเอาสัญญาณไปใช้ตัดสินใจไหม
- ถ้าไม่มีใครเปิดดู ต่อให้ตัวเลขสวยก็คือล้มเหลว
ด่านที่หินจริงคือ audit: target leakage กับการอธิบายให้ได้
เรื่องที่ผมไม่ได้คาดไว้ตอนเริ่ม แต่กลายเป็นด่านสำคัญที่สุดตอนเอาระบบไปใช้จริง คือการทำให้ฝั่ง audit เชื่อ — และมันไม่ได้วัดกันที่ตัวเลขความแม่น สองเรื่องที่ผมต้องให้เวลามากเป็นพิเศษคือ
- การจัดการ target leakage — โมเดลที่ดู "แม่นเกินจริง" มักไม่ได้เก่ง แต่แอบเห็นข้อมูลที่ในความจริงยังมาไม่ถึง ณ จุดที่ต้องตัดสินใจ ในงานที่ผลกระทบเป็นเรื่องเครดิตจริง การไล่ปิดช่องรั่วพวกนี้ให้หมดสำคัญกว่าการดันคะแนนให้สูงขึ้นอีกนิด เพราะโมเดลที่แม่นเพราะ "โกง" พอเจอของจริงจะพังทันที
- การอธิบายด้วยค่า SHAP — แค่บอกว่า "โมเดลเตือน" ไม่พอ ต้องบอกได้ว่า ทำไม ผมใช้ค่า SHAP มาแสดงว่าแต่ละปัจจัยผลักการทำนายไปทางไหน เพื่อให้ทั้งทีมและ audit เห็นว่าสัญญาณมาจากอะไร ไม่ใช่กล่องดำที่ต้องเชื่อเพราะมันบอกให้เชื่อ
บทเรียนที่ติดตัวผมจากตรงนี้คือ ในงานที่มีคนตรวจสอบ ความสามารถในการอธิบายและพิสูจน์ว่าโมเดลไม่ได้โกง มีค่าพอ ๆ กับหรือมากกว่าความแม่นเสียอีก โมเดลที่อธิบายไม่ได้ ต่อให้คะแนนสวยแค่ไหน ก็ไม่ผ่านเข้าไปใช้งานจริง วินัยตรงนี้เป็นแกนเดียวกับขั้นตอนงาน data science สาย credit riskที่ผมยึดมาตลอด
เส้นที่ห้ามข้าม: โมเดลที่ "แม่นเกินจริง" มักไม่ได้เก่ง แต่แอบเห็นข้อมูลที่ยังมาไม่ถึง ณ จุดตัดสินใจ — ปิด target leakage ให้หมดสำคัญกว่าดันคะแนนขึ้นอีกนิด เพราะโมเดลที่แม่นเพราะ "โกง" พอเจอของจริงจะพังทันที
ภาพรวม: วันนี้ของแบบนี้สร้างได้เร็วและถูกลงมาก
ตอนผมสร้างระบบนี้ ส่วนที่กินเวลามากที่สุดไม่ใช่ไอเดีย แต่เป็นงานต่อท่อ ทดลอง และเขียนโค้ดวนซ้ำ ๆ กว่าจะได้ของที่ใช้จริง วันนี้ภาพเปลี่ยนไปเยอะ เครื่องมือ AI agent อย่าง Claude Code ทำให้ขั้นตอนพวกนี้เร็วและถูกลงมาก สิ่งที่เคยใช้เวลาเป็นสัปดาห์ ลองได้ภายในไม่กี่วัน
ผมเลยคิดว่าโจทย์ที่น่าสนใจที่สุดตอนนี้ ไม่ใช่ "ทำได้ไหม" แต่เป็น "คุณจะออกแบบให้มันมีประโยชน์จริงได้แค่ไหน" — และทักษะการกำกับ AI agent ให้สร้างของแบบนี้ ก็เป็นสิ่งที่เรียนรู้กันได้
ลองของจริง: ผมเอาวิธีทำงานแบบ "ทุกตัวเลขต้องกดตรวจต้นฉบับได้" ไปประกอบเป็นเครื่องมือจริงแล้ว — Boom Leverage Terminal ค้น MD&A/56-1 ทั้งตลาดด้วยความหมาย คืนข้อความจริงพร้อมลิงก์ต้นฉบับ ก.ล.ต. เริ่มฟรี 10 เครดิต/วัน ไม่ต้องผูกบัตร · ระดับทีม/สถาบัน (seats · Excel export · API) คุยได้ที่ หน้า Enterprise หรือ contact@boomleverage.com
ขอย้ำให้ชัด: บทความนี้เล่าบทเรียนจากการสร้างเครื่องมือช่วยเตือนความเสี่ยงด้านเครดิตและวิธีตรวจสอบความน่าเชื่อถือของมัน เพื่อการศึกษาเท่านั้น ไม่ใช่คำแนะนำการลงทุน ไม่ชี้นำหลักทรัพย์ใด และไม่รับประกันผลลัพธ์ใด ๆ · การลงทุนมีความเสี่ยง ผลในอดีตไม่รับประกันอนาคต
อ่านต่อ
แรงงานแพงขึ้น เงินทุนแพงขึ้น: ต้นทุนสองปัจจัยการผลิตของบริษัทไทย 2022–2026 อ่านจาก MD&A จริง
อ่านต่อ การเงินทำไม Ctrl+F อ่านงบทั้งตลาดไม่ได้: semantic search กับคำชี้แจงผู้บริหาร (MD&A) — ค้นด้วยความหมาย ไม่ใช่คำ
อ่านต่อ Alternative Dataหา alpha จากคำพูดผู้บริหารทั้งตลาด: alternative data ที่ยังไม่มีใครขุด — และนี่คือเดโมบนข้อมูลแค่ 40%
อ่านต่อ