เราลอง NVIDIA Kumo: ช่วยคัดกองเคสได้ แต่ยังตัดสินเองไม่ได้

ช่วงนี้ถ้าเลื่อนฟีดเจอโพสต์ "Nvidia Kumo คืออะไร" คงเห็นรายการ use case ยาวเหยียด ทั้งทาย churn จับ fraud วางแผน supply chain บางโพสต์ไปไกลถึงขั้นให้ AI ตัดสินใจแทนทีมได้เลย ถ้ามีฐานข้อมูลลูกค้า ใบแจ้งหนี้ การชำระเงินอยู่ในมือ คำถามแรกที่ผุดขึ้นมาก็น่าจะเป็น "ของจริงทำได้แค่ไหน แล้วเอามาใช้กับข้อมูลเราได้ไหม"

เราสงสัยแบบเดียวกัน เลยลองวัดเอง Productize ทดสอบ Kumo Relational บนฐานข้อมูลสาธารณะที่มีหลายตารางโยงกัน ตั้งเกณฑ์ไว้ก่อนรัน แล้วเอาตัวเลขทั้งหมดมาวางไว้ตรงนี้ ส่วน decision model (AI ที่เลือกคำตอบจากตัวเลือกที่กำหนดไว้) เราไม่ได้เอามาทดสอบแข่งกับ Kumo แต่จะอธิบายว่าทำงานต่างกันตรงไหน เพราะทั้งคู่มักถูกขายว่าเป็น "AI ที่ตัดสินใจได้"

ช่วงที่ 1Kumo Relational คืออะไร ทายอะไรได้บ้าง?

Kumo Relational คือ foundation model (โมเดลที่ฝึกไว้ก่อนกับข้อมูลจำนวนมาก แล้วใช้กับงานใหม่ได้เลย) สำหรับข้อมูลหลายตารางที่โยงกัน พอป้อนตารางลูกค้า ใบแจ้งหนี้ การชำระเงิน มันก็ทายผลของลูกค้าแต่ละรายจากเคสในอดีตที่รู้ผลแล้ว

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

ที่บอกว่า "ไม่ต้องเทรน" ก็คือ ตอนสั่งทาย เรายื่นเคสในอดีตที่รู้ผลแล้วให้มันดูเป็นตัวอย่าง (รอบของเราราว 1,000 เคส) แล้วมันก็ทายเคสใหม่ได้เลย ไม่มีอะไรต้องเทรนหรือปรับจูน

มันทายได้ 2 แบบเท่านั้น คือคำตอบใช่หรือไม่ (ลูกค้ารายนี้จะจ่ายช้าไหม) กับตัวเลขค่าเดียว (เดือนหน้าจะซื้อเท่าไร) งานแบบใช่หรือไม่จะได้ความน่าจะเป็นกลับมา เช่น 0.83 คือคิดว่ามีโอกาสเกิด 83% คำถาม churn อย่าง "ลูกค้ารายนี้จะเลิกใช้ใน 30 วันถัดไปไหม" เข้ากับรูปแบบใช่หรือไม่นี้ แต่เรายังไม่ได้ทดสอบ ส่วนงานจับ fraud ก็ยังไม่ได้ทดสอบ

โพสต์ hype มักไม่บอกว่ามันทำอะไรไม่ได้ ใน model card ไม่มีงานแนะนำสินค้า ถามหลายเป้าหมายพร้อมกันไม่ได้ อ่านข้อความอิสระอย่างหมายเหตุไม่ได้ ส่งข้อมูลได้ไม่เกิน 30MB ต่อคำขอ และไม่บอกเหตุผลว่าทำไมทายแบบนั้น

ช่วงที่ 2เราทดสอบยังไง

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

ทั้ง 3 งานถามทีละนักขับว่าในราว 30 วันถัดไป คนนั้นจะมีการแข่งที่ไม่จบไหม จะเข้า 3 อันดับแรกไหม และจะเข้าเส้นอันดับที่เท่าไร 2 งานแรกวัดด้วย AUROC คือโอกาสที่โมเดลจัดเคสที่เกิดเหตุจริงไว้สูงกว่าเคสที่ไม่เกิด 0.5 เท่ากับเดาสุ่ม 1.0 คือเรียงถูกหมด งานที่สามวัดด้วย MAE คือทายพลาดไปเฉลี่ยกี่อันดับ ยิ่งต่ำยิ่งดี

ตัวเทียบหลักคือ baseline หรือวิธีพื้นฐานที่ทำไว้เทียบ ของเราใช้ LightGBM วิธีทำนายแบบดั้งเดิม และไม่ดึงข้อมูลจากตารางอื่นมาประกอบ ตัวนี้จึงอ่อน

ก่อนรันจริง เราเขียนเกณฑ์ไว้ 2 ข้อแล้วล็อกไฟล์ไม่ให้แก้ทีหลัง ข้อแรก Kumo ต้องชนะ baseline ของเราอย่างน้อย 2 ใน 3 งาน ข้อสองคือเกณฑ์ "ตัดสินเองได้ไหม" ซึ่งใช้กับ 2 งานแบบใช่หรือไม่เท่านั้น เรานับว่ามันมั่นใจเมื่อความน่าจะเป็นออกมาตั้งแต่ 0.7 ขึ้นไป หรือ 0.3 ลงมา เคสที่มั่นใจต้องมีอย่างน้อยครึ่งหนึ่ง และต้องทายถูกอย่างน้อย 90%

รอบนี้เราส่งข้อมูลไปรันบนบริการออนไลน์ของ NVIDIA

ช่วงที่ 3แม่นกว่า baseline แล้ว ทำไมยังให้ตัดสินเองไม่ได้?

เพราะเรียงเคสได้ดี กับพูดว่า "มั่นใจ" แล้วเชื่อได้ เป็นคนละเรื่อง Kumo ผ่านเกณฑ์ข้อแรก แต่ตกข้อสองทั้ง 2 งานแบบใช่หรือไม่

Kumo ชนะ baseline ของเราทั้ง 3 งาน งาน "แข่งไม่จบ" ได้ AUROC 0.688 เทียบกับ 0.617 งาน "เข้า 3 อันดับแรก" ได้ 0.832 เทียบกับ 0.590 งานอันดับเข้าเส้นได้ MAE 3.889 เทียบกับ 4.381

baseline ของเราตั้งใจทำให้ง่าย ดูแค่ตารางเดียว

ปัญหาอยู่ตอนที่มันบอกว่ามั่นใจ เกณฑ์ข้อสองที่เราตั้งไว้ก่อนรัน กำหนดให้เคสที่มั่นใจมีอย่างน้อยครึ่งหนึ่งของเคสทั้งหมด และทายถูกอย่างน้อย 90%

งาน "แข่งไม่จบ" Kumo มั่นใจใน 75% ของเคสทั้งหมด ในเคสนั้นทายถูก 76% ไม่ถึง 90% เคสที่มั่นใจทั้ง 529 เคสตอบว่า "มี" คือนักขับจะมีการแข่งที่ไม่จบในราว 30 วันถัดไป เพื่อให้เห็นภาพ นักขับในชุดทดสอบ 70.5% แข่งไม่จบจริงในช่วงนั้น แค่ทายเหมาว่าทุกคนแข่งไม่จบก็ถูกบ่อยขนาดนี้แล้ว 76% ของ Kumo จึงดีกว่ากันแค่นิดเดียว

งาน "เข้า 3 อันดับแรก" Kumo มั่นใจใน 85% ของเคสทั้งหมด ในเคสนั้นทายถูก 88% ยังไม่ถึง 90% เหมือนกัน เคสที่มั่นใจทั้ง 618 เคสตอบว่า "ไม่เข้า" ทั้งหมด ส่วนนักขับที่เข้า 3 อันดับแรกจริงมีแค่ 17.6%

สมมติว่ามีโมเดลทวงเงินที่แม่นได้แค่ระดับงาน "แข่งไม่จบ" แล้วปล่อยให้ตัดสินเองทุกครั้งที่มั่นใจ ทุก 100 ครั้งที่มันตัดสินเองก็จะผิดราว 24 ครั้ง และเพราะเคสที่มั่นใจตอบว่า "มี" ทุกเคส ครั้งที่ผิดจึงผิดไปทางเดียวกันหมด คือทวงคนที่ไม่ควรทวง

แล้วใช้เรียงคิวได้ไหม? หลังรันเสร็จ เรานับเพิ่มว่าใน 30, 70 และ 140 รายแรกที่ Kumo ให้คะแนนสูงสุด เกิดขึ้นจริงกี่ราย จุดตัดพวกนี้เราเลือกเองหลังรัน ไม่ได้ตั้งเป็นเกณฑ์ไว้ก่อน

• งาน "แข่งไม่จบ" (ทั้งหมด 702 เคส): 30 รายแรกถูก 29 ราย (97%) 70 รายแรกถูก 89% และ 140 รายแรกถูก 86% ส่วน baseline ของเรา 30 รายแรกถูกแค่ 19 ราย (63%)
• งาน "เข้า 3 อันดับแรก" (ทั้งหมด 726 เคส เข้าจริง 17.6%): 30 รายแรกเข้าจริงแค่ 4 ราย (13%) แต่ 70 รายแรกเข้าจริง 46% และ 140 รายแรก 48% หรือราว 2.7 เท่าของการสุ่ม

สรุปคือรายการช่วยคัดกองได้ แต่ไม่ใช่ทุกงาน ในงาน "เข้า 3 อันดับแรก" 30 รายบนสุดไม่ดีกว่าสุ่มหยิบ ต้องดูลงไปถึง 70 รายถึงเริ่มช่วยได้ ทีมเก็บเงินจึงควรเปิดดูเคสชุดหนึ่งจากหัวรายการเองก่อนโทรตามใคร แล้วนับว่ามีกี่รายที่เกิดขึ้นจริง แบบที่เรานับ 30, 70 และ 140 รายแรก

ตัวเลขพวกนี้มีข้อจำกัด เรารันรอบเดียว ไม่ได้รันซ้ำ

ช่วงที่ 4ต่างจาก AI ที่เลือกคำตอบ จากตัวเลือกยังไง?

decision model คือ AI ที่เลือกคำตอบจากตัวเลือกที่กำหนดไว้ คำว่า decision ในชื่อหมายถึงการเลือก ไม่ได้แปลว่าตัดสินแทนคนได้ เรายื่นของชิ้นเดียวกับรายการตัวเลือกนั้นให้ แล้วมันจะเลือกมา 1 ข้อ พร้อมบอกว่ามั่นใจในแต่ละตัวเลือกแค่ไหน เช่น ยื่นใบเสร็จ 1 ใบกับรายชื่อหมวดค่าใช้จ่าย ก็จะได้หมวดกลับมา 1 หมวด

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

decision model ที่เราลองคือ Clef-flash ใครมีบัญชี Cloudflare ก็เรียกใช้ได้บน Workers AI เราเคยให้มันจัดหมวดบทความบนบล็อกของเราเอง อ่านรายละเอียดได้ในบทความนั้น

ใช้ตัวไหนตอนไหน ดูหน้าตาของข้อมูลก่อน คำถามที่ตอบได้จากประวัติในหลายตาราง เป็นงานของ Kumo ส่วนคำถามที่ตอบได้จากเอกสารชิ้นเดียวตรงหน้า เช่นใบเสร็จใบนี้เป็นค่าใช้จ่ายหมวดไหน เป็นงานของ decision model

ช่วงที่ 5ต้องมีข้อมูลแบบไหน ถึงจะลอง Kumo ได้?

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

ข้อสุดท้ายสำคัญที่สุด เราใช้บริการออนไลน์ของ NVIDIA ได้ก็เพราะข้อมูล F1 เป็นสาธารณะ ข้อมูลลูกค้าจริงไม่ควรส่งไปที่นั่นตรงๆ ถ้าจะลองกับข้อมูลจริง ทำได้ 2 ทาง คือโหลด Kumo มารันบน GPU ของตัวเอง หรือปรึกษาผู้รู้ด้าน PDPA (กฎหมายคุ้มครองข้อมูลส่วนบุคคล) แล้วตัดข้อมูลที่ระบุตัวคนได้ออกก่อน

NVIDIA เปิดไฟล์โมเดลไว้บน Hugging Face ให้โหลดฟรีและใช้เชิงพาณิชย์ได้ แต่ต้องรันบน GPU ของ NVIDIA สเปกที่ต้องใช้ก็ไม่ได้บอกไว้ และทางนี้เรายังไม่ได้ลอง ตอนรันบนเครื่องของเราที่ไม่มี GPU หน่วยความจำ 6 GB ไม่พอ เราจึงไปใช้บริการออนไลน์ของ NVIDIA แทน บริการนี้ยังไม่ได้ประกาศราคา

ถ้าจะลอง เริ่มจากคำถามเดียวที่ทีมต้องเรียงคิวอยู่แล้ว เช่นจะโทรตามหนี้ใครก่อน ทำ baseline ง่ายๆ ไว้เทียบ อย่างเรียงลูกหนี้ตามจำนวนวันที่ค้างจ่าย แล้วเขียนเกณฑ์ไว้ก่อนรัน ถ้า Kumo ชนะไม่ได้ก็หยุดแค่นั้น ถ้าชนะ ก็ใช้ผลเป็นรายการให้คนดู ยังไม่ต้องให้มันกดปุ่มเอง ตัวเลขของ Kumo ในบทความนี้มาจาก F1 ทั้งหมด ข้อมูลของคุณจะออกมาแบบไหน ต้องลองเองถึงจะรู้

ที่มาและอ้างอิง

อ่านต่อ: บทความทั้งหมดบน Productize / Decision model แบบ Jev ช่วยลดงานบัญชีได้ไหม / decision model ทำ auto-tagging ได้ตรงไหน พลาดตรงไหน / Human in the Loop ไม่ใช่เรื่องมีคนหรือไม่มีคน: โมเดล 3 ระดับ