AIG เคลม Claude ดันความแม่นยำงาน underwriting จาก 75% เป็นกว่า 90% — คนทำ model risk อ่านตัวเลขนี้ยังไง

ตอนทำงานวัดความเสี่ยงโมเดลในแบงก์ สิ่งที่ผมระวังที่สุดเวลามี vendor เดินเข้ามาขายเครื่องมือ ไม่ใช่ว่ามันทำอะไรได้ แต่คือ "ตัวเลขที่มันเอามาอวด" — เพราะตัวเลขความแม่นยำที่ฟังดูสวยมักมาจากนิยามและชุดข้อมูลที่คนเล่าเป็นคนเลือกเอง รอบนี้ Anthropic เจ้าของ Claude เปิดหน้า Claude for Financial Services พร้อมยกกรณีของ AIG บริษัทประกันภัยยักษ์ใหญ่ของสหรัฐฯ มาเป็นหลักฐานว่า Claude ช่วยงาน underwriting ได้จริง โดยอ้างตัวเลขที่จับต้องได้สองตัว ในฐานะคนที่เคยนั่งตรวจ model output มากับมือ ผมอ่านข่าวนี้แล้วสนใจ แต่ก็ตั้งคำถามทันทีว่า ตัวเลขพวกนี้แปลว่าอะไร และที่สำคัญกว่าคือ มันไม่ได้แปลว่าอะไร

1. เกิดอะไรขึ้น: AIG เปิดตัวเลขสองตัวจากการใช้ Claude

ในหน้า Claude for Financial Services ของ Anthropic มีการอ้างถ้อยคำจากฝั่ง AIG ที่ระบุว่า Claude ช่วย "improving our data accuracy from 75% to over 90%" — เพิ่มความแม่นยำของข้อมูลจาก 75% เป็นกว่า 90% ในกระบวนการที่เกี่ยวกับการพิจารณารับประกันภัย (underwriting)

ตัวเลขที่สองเป็นเรื่องความเร็ว ทาง AIG ระบุว่า Claude ช่วย "compress the timeline to review business by more than 5x" — ย่นเวลาในการ review งานลงกว่า 5 เท่า ซึ่งในบริบทของ insurance underwriting หมายถึงงานที่เคยใช้เวลาหลายวันในการรวบรวมและตรวจสอบข้อมูลก่อนตัดสินรับประกัน

ทั้งสองตัวเลขนี้ปรากฏตรงกันทั้งในหน้าทางการของ Anthropic และในรายงานของสื่อสาย fintech ที่รายงานการเปิดตัวแพลตฟอร์มเดียวกัน จึงถือว่าเป็นถ้อยแถลงที่ตรวจสอบที่มาได้ ไม่ใช่ตัวเลขที่ลอยมาจากการสรุปข่าวต่อ ๆ กัน แต่ "ตรวจสอบที่มาได้" กับ "เชื่อได้ทั้งหมด" เป็นคนละเรื่อง — และนี่คือจุดที่งานคนทำ risk เริ่มต้น

ทำไมมันสำคัญกับเรา: AIG ไม่ใช่สตาร์ทอัพที่ทดลองของเล่น แต่เป็นบริษัทประกันภัยที่งาน underwriting คือหัวใจธุรกิจและอยู่ใต้การกำกับ การที่องค์กรระดับนี้ยอมออกชื่อรับรองผลเป็นสัญญาณว่าเครื่องมือผ่านการใช้งานจริงในระดับหนึ่ง — แต่สำหรับคนทำ model validation สัญญาณนั้นคือ "จุดเริ่มให้ไปตรวจ" ไม่ใช่ "ข้อสรุปให้ไปเชื่อ"

2. อ่านเลข 75% เป็นกว่า 90% แบบคนทำ model validation

ตัวเลข "ความแม่นยำเพิ่มจาก 75% เป็นกว่า 90%" ฟังดูหนักแน่น แต่คำถามแรกที่ผมถามไม่ใช่ "เพิ่มเท่าไร" — คือ "แม่นยำของอะไร เทียบกับอะไร"

ในงานวัดผลโมเดล คำว่า accuracy เป็นคำที่หลอกได้ง่ายที่สุดคำหนึ่ง เพราะมันขึ้นกับสามอย่างที่ตัวเลขเดี่ยว ๆ ไม่บอก: หนึ่ง นิยามว่าอะไรนับเป็น "ถูก" — ความแม่นยำของการดึงข้อมูลจากเอกสาร (data extraction) กับความแม่นยำของการตัดสินรับประกัน เป็นคนละเรื่องที่มีเดิมพันต่างกันมาก สอง ชุดข้อมูลที่ใช้วัด — วัดบนเคสง่ายหรือเคสยาก วัดบนตัวอย่างที่เป็นตัวแทนของงานจริงไหม สาม ใครเป็นคนตัดสินว่าคำตอบถูก และเกณฑ์นั้นคงที่ตลอดหรือเปล่า

ถ้อยคำของ AIG เองใช้คำว่า "data accuracy" ซึ่งบอกใบ้ว่าน่าจะเป็นความแม่นยำของชั้นข้อมูล (เช่น การอ่านและจัดระเบียบข้อมูลจากเอกสารจำนวนมาก) มากกว่าความแม่นยำของการตัดสินใจปลายทาง นี่เป็นรายละเอียดที่สำคัญ เพราะการที่ AI อ่านข้อมูลเข้าระบบได้แม่นขึ้น เป็นคนละเรื่องกับการที่ "การตัดสินรับประกันดีขึ้น" — ขั้นตอนหลังยังขึ้นกับโมเดลประเมินความเสี่ยง การตั้งราคา และดุลยพินิจของ underwriter อยู่ดี

มุมคนทำ model validation: ตัวเลข accuracy ที่ไม่มีนิยาม baseline และ test set กำกับ มีค่าเท่ากับ "เคลม" ไม่ใช่ "ผลวัด" สิ่งที่ผมจะขอดูก่อนเชื่อคือ วัดบนงานอะไร เทียบกับเส้นฐานแบบไหน (คนล้วน หรือระบบเดิม) และตัวอย่างที่วัดเป็นตัวแทนของ portfolio จริงแค่ไหน — ถ้าตอบสามข้อนี้ไม่ได้ ตัวเลขกว่า 90% ก็เป็นแค่ป้ายโฆษณา

เรื่องความเร็ว "กว่า 5 เท่า" ก็ต้องอ่านด้วยแว่นเดียวกัน การย่นเวลา review เป็นประโยชน์ชัดเจนในงานที่คอขวดคือการรวบรวมข้อมูล แต่ในงานที่อยู่ใต้การกำกับ ความเร็วมีด้านมืดของมัน — ถ้าเร็วขึ้นเพราะคนข้ามขั้นตอนตรวจสอบ นั่นไม่ใช่ประสิทธิภาพ แต่คือความเสี่ยงที่ถูกซ่อนไว้ในตัวเลขที่ดูดี ผมเคยเขียนเรื่องนี้ไว้ในมุมของการวัดความเสี่ยงโมเดลในยุค AI ว่าทำไม "เร็วและถูก" ต้องมากับ "ตรวจสอบย้อนได้" เสมอ

3. เลข benchmark ที่พ่วงมา: อ่านอะไรได้ อ่านอะไรไม่ได้

นอกจากกรณี AIG หน้าเดียวกันยังอ้างผล benchmark ของตัวโมเดลเพื่อสนับสนุนว่า Claude เหมาะกับงานการเงิน สองตัวที่ระบุชัดคือ Claude "passed 5 out of 7 levels of the Financial Modeling World Cup" — ผ่าน 5 จาก 7 ระดับของการแข่งขัน Financial Modeling World Cup และ "scored 83% accuracy on complex excel tasks" — ทำคะแนนความแม่นยำ 83% บนงาน Excel ที่ซับซ้อน

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

แต่สิ่งที่ benchmark พวกนี้ไม่ได้บอกคือ ผลบนงานจริงในองค์กรของคุณ — ซึ่งมีข้อมูลเฉพาะ มีข้อกำหนดด้านกำกับเฉพาะ และมีต้นทุนความผิดพลาดที่ benchmark มาตรฐานไม่ได้จำลอง คะแนน 83% บนงาน Excel ที่ออกแบบมาทดสอบ ไม่ได้แปลว่าจะได้ 83% บนสเปรดชีตคำนวณเงินสำรองของแบงก์คุณ และการผ่าน 5 จาก 7 ระดับก็แปลว่ายังมี 2 ระดับที่ไม่ผ่าน — ตัวเลขที่ vendor เลือกเล่ามักเน้นด้านที่ผ่าน

ทำไมมันสำคัญกับเรา: benchmark คือ "ผลสอบในห้องสอบ" ส่วนงานจริงคือ "งานในสนาม" ทั้งสองมีค่า แต่คนละค่า คนทำ risk ที่ฉลาดจะใช้ benchmark เป็นตัวคัดกรองรอบแรก แล้ววัดซ้ำบนงานและข้อมูลของตัวเองก่อนตัดสิน — ไม่เอาคะแนนสอบของคนอื่นมาเป็นหลักประกันผลงานในบ้านตัวเอง

4. เช็คลิสต์ก่อนเชื่อ case study ของ vendor

ข่าวแบบนี้จะมาถี่ขึ้นเรื่อย ๆ ทั้งฝั่งประกันและธนาคาร และคนทำ data/risk จะเป็นด่านที่ต้องตอบว่า "เราจะเชื่อแค่ไหน" สิ่งที่ผมใช้เป็นกรอบตั้งคำถามเวลาเจอ case study ที่มีตัวเลขสวย ๆ:

• ถามนิยามก่อนถามขนาด — "แม่นยำขึ้น" วัดจากอะไร เทียบกับเส้นฐานไหน ถ้า vendor ตอบไม่ได้ ตัวเลขนั้นใช้ตัดสินใจไม่ได้ ต่อให้ใหญ่แค่ไหน
• แยกชั้นข้อมูลออกจากชั้นตัดสินใจ — AI ที่อ่านข้อมูลแม่นขึ้น ไม่ได้แปลว่าการตัดสินรับประกันหรืออนุมัติสินเชื่อดีขึ้นโดยอัตโนมัติ ตรวจให้ชัดว่าตัวเลขที่อวดอยู่ชั้นไหน
• ระวังความเร็วที่มาจากการข้ามขั้น — "เร็วขึ้น 5 เท่า" ดีถ้าย่นงานรวบข้อมูล แต่ถ้าเร็วเพราะลดการตรวจสอบของคน นั่นคือความเสี่ยงปลอมตัวมาเป็นประสิทธิภาพ
• ขอผลวัดบนข้อมูลของตัวเอง — ก่อนตัดสินใจซื้อหรือขยายผล ต้องมี pilot ที่วัดบน portfolio และเคสจริงขององค์กร ไม่ใช่ benchmark กลางหรือ case study ของบริษัทอื่น
• ลงทะเบียนเป็นโมเดลในกรอบ governance เดิม — เครื่องมือ AI ที่เข้าไปอยู่ในกระบวนการตัดสินใจ คือโมเดลที่ต้องมีเจ้าของ มีรอบทบทวน และมีร่องรอยตรวจสอบ เหมือนโมเดลความเสี่ยงตัวอื่น

กรอบเดียวกันนี้ใช้ได้กับข่าว AI การเงินอื่น ๆ ที่กำลังมา — ผมเคยลงรายละเอียดมุมตรวจสอบไว้ตอนที่FIS จับมือ Anthropic เอา agent ลุยงานปราบฟอกเงิน และตอนที่AI agent เริ่มขยับเงินจริงในระบบธนาคาร ซึ่งทั้งสองกรณีคำถามหลักก็วนกลับมาที่เรื่องเดิม คือ "ตรวจสอบย้อนได้แค่ไหน" ไม่ใช่ "เก่งแค่ไหน"

เส้นที่ผมขีดไว้: ตัวเลขจาก vendor ใช้เป็นเหตุผล "ให้ลองทดสอบ" ได้ แต่ใช้เป็นเหตุผล "ให้ข้ามการทดสอบ" ไม่ได้ — ยิ่งตัวเลขสวย ยิ่งต้องวัดซ้ำด้วยมือตัวเองก่อนเอาไปตัดสินเรื่องที่มีคนได้เสีย

ภาพรวม

กรณี AIG เป็นหลักฐานที่ดีว่า Claude ขยับจากเครื่องมือทดลองเข้าไปอยู่ในกระบวนการจริงของสถาบันการเงินขนาดใหญ่แล้ว ตัวเลขเพิ่มความแม่นยำจาก 75% เป็นกว่า 90% และย่นเวลากว่า 5 เท่า เป็นสัญญาณว่ามูลค่าในงาน underwriting มีจริง แต่สำหรับคนทำ data/risk งานของเราไม่ใช่การเชื่อหรือไม่เชื่อตัวเลข — เป็นการถามว่ามันวัดจากอะไร อยู่ชั้นไหนของกระบวนการ และเราจะวัดซ้ำบนงานของตัวเองได้ยังไง คนที่ได้เปรียบในคลื่นลูกนี้ไม่ใช่คนที่ตื่นเต้นกับตัวเลข vendor เร็วที่สุด แต่คือคนที่รู้วิธีแยก "เคลม" ออกจาก "ผลวัด" และเอาเครื่องมือไปพิสูจน์ในสนามของตัวเองได้อย่างมีระบบ

ถ้าอยากเริ่มใช้ Claude Code มาช่วยงาน data/risk แบบที่ตรวจสอบย้อนได้จริง — ตั้งแต่ดึงข้อมูล ตรวจตัวเลข ไปจนถึงทำรายงานที่ผู้ตรวจอ่านรู้เรื่อง — ผมรวบวิธีที่ผมใช้จริงไว้ในคอร์ส Claude Code

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

ที่มา

• Claude for Financial Services — Anthropic
• Anthropic unveils Claude's new finance-focused platform — FinTech Global