ประเมินโมเดลภาษาก่อนขึ้นระบบจริง: ทำไมคะแนนเบนช์มาร์กดีถึงไม่ได้แปลว่าใช้งานได้

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

ทำไมคะแนนเบนช์มาร์กถึงไม่พอ

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

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

กรอบการประเมินแปดขั้น

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

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

สร้างชุดข้อมูลประเมินอย่างไรให้ใช้ได้จริง

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

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

จัดลำดับตัวชี้วัดเป็นสามชั้น

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

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

ใช้โมเดลเป็นผู้ช่วยตรวจ ไม่ใช่ผู้ตัดสินแทนคน

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

กับดักที่พบบ่อย

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

เช็กลิสต์ก่อนขึ้นระบบจริง

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

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