คะแนน Benchmark ขึ้นทุกรอบที่อัปเดตโมเดล แต่ผู้ใช้จริงกลับบ่นว่าคำตอบแย่ลง

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

ปัญหานี้ไม่ใช่เรื่องแปลก คะแนน Benchmark สาธารณะอย่าง MMLU, HumanEval หรือชุดทดสอบที่ผู้ผลิตโมเดลเผยแพร่เอง วัดความสามารถทั่วไปของโมเดลในสถานการณ์ที่หลากหลาย แต่ไม่ได้วัดว่าโมเดลนั้นเหมาะกับงานเฉพาะของทีมคุณแค่ไหน โมเดลที่เก่งเรื่องคณิตศาสตร์หรือเขียนโค้ดอาจไม่ได้เก่งเรื่องสรุปเอกสารภาษาไทยในโทนที่บริษัทต้องการ และการเปลี่ยนแปลงเล็ก ๆ ในวิธีตอบก็อาจกระทบผู้ใช้จริงมากกว่าที่ตัวเลข Benchmark สะท้อนออกมา

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

LLM Evaluation คืออะไร ต่างจากการทดสอบซอฟต์แวร์ทั่วไปตรงไหน

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

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

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

ทำไมคะแนน Benchmark สูงขึ้นแต่คุณภาพงานจริงกลับแย่ลงได้

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

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

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

ประเภทของการประเมิน เลือกใช้แบบไหนตอนไหน

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

สร้างชุดข้อมูลทดสอบของตัวเองอย่างไรให้สะท้อนงานจริง

1. รวบรวมคำถามหรือคำขอจริงที่ผู้ใช้เคยส่งเข้ามา จาก Log การใช้งาน แชทที่ทีม Support เคยได้รับ หรือคำถามที่ทีมภายในคาดว่าจะเจอบ่อย แทนที่จะแต่งคำถามขึ้นเองล้วน ๆ
2. คัดเลือกให้ครอบคลุมทั้งกรณีทั่วไปที่เจอบ่อยและกรณีขอบ (Edge Case) ที่มักทำให้โมเดลตอบผิด เช่น คำถามกำกวม คำถามที่ไม่มีข้อมูลรองรับ หรือคำถามที่พยายามหลอกให้โมเดลตอบนอกขอบเขต
3. กำหนดคำตอบอ้างอิงหรือเกณฑ์การให้คะแนนสำหรับแต่ละข้อไว้ล่วงหน้า อาจเป็นคำตอบที่ถูกต้องตายตัว รายการประเด็นที่ต้องมีในคำตอบ หรือกฎว่าอะไรถือว่าตอบผิด เพื่อให้การให้คะแนนภายหลังทำได้สม่ำเสมอ
4. แบ่งชุดข้อมูลเป็นหมวดตามลักษณะงาน เช่น คำถามข้อมูลทั่วไป คำถามที่ต้องดึงข้อมูลจาก ระบบ RAG หรือคำถามที่ต้องปฏิเสธอย่างสุภาพ เพื่อให้เห็นว่าโมเดลอ่อนในหมวดไหนเป็นพิเศษ ไม่ใช่ดูแค่คะแนนรวม
5. ทบทวนและเพิ่มเคสใหม่เข้าชุดข้อมูลอย่างสม่ำเสมอ โดยเฉพาะทุกครั้งที่พบว่าโมเดลตอบผิดในงานจริง ให้เพิ่มเคสนั้นเข้าชุดทดสอบเพื่อป้องกันไม่ให้ปัญหาเดิมย้อนกลับมาในเวอร์ชันถัดไป

ใช้ LLM ตัดสิน LLM ด้วยกันเอง เชื่อถือได้แค่ไหน

เมื่อชุดข้อมูลทดสอบมีจำนวนมากจนให้คนตรวจทุกข้อไม่ทัน หลายทีมเริ่มใช้เทคนิคที่เรียกว่า LLM-as-Judge คือให้โมเดลภาษาอีกตัวหนึ่งทำหน้าที่ตรวจและให้คะแนนคำตอบของโมเดลที่กำลังทดสอบ วิธีนี้รันได้เร็วและขยายขนาดได้ง่ายกว่าการให้คนตรวจทุกข้อ

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

แนวทางที่ใช้ได้จริงคือผสมสองแบบเข้าด้วยกัน ใช้ LLM-as-Judge เป็นตัวกรองด่านแรกเพื่อรันบ่อย ๆ ทุกครั้งที่มีการเปลี่ยนแปลง Prompt หรือโมเดล แล้วให้คนตรวจเฉพาะเคสที่คะแนนก้ำกึ่งหรือเคสสำคัญที่มีผลกระทบสูง แทนที่จะพึ่งพาวิธีใดวิธีหนึ่งเพียงอย่างเดียว

ผนวก Evaluation เข้ากระบวนการปล่อยฟีเจอร์ให้จับปัญหาก่อนผู้ใช้

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

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

ควรกำหนดเกณฑ์ผ่าน-ไม่ผ่านที่ชัดเจนไว้ล่วงหน้า เช่น คะแนนเฉลี่ยต้องไม่ต่ำกว่าเวอร์ชันก่อนหน้าเกินกี่เปอร์เซ็นต์ หรือต้องไม่มีเคสที่เคยผ่านแล้วกลับมาล้มเหลว (Regression) เกินจำนวนที่กำหนด เพื่อให้ทีมมีเกณฑ์ตัดสินใจที่เป็นรูปธรรม ไม่ใช่ดูตัวเลขแล้วรู้สึกเอาเองว่า 'น่าจะโอเค'

ข้อผิดพลาดที่ทีมมักเจอเมื่อเริ่มทำ LLM Evaluation

• ทำแบบนี้แล้วพัง เพราะใช้ชุดข้อมูลทดสอบที่แต่งขึ้นเองล้วน ๆ ไม่ได้อิงจากคำถามจริงของผู้ใช้ ทำให้คะแนนดูดีในห้องทดลองแต่ไม่สะท้อนปัญหาที่เกิดขึ้นจริงเมื่อปล่อยใช้งาน
• ทำแบบนี้แล้วพัง เพราะเชื่อคะแนน Benchmark สาธารณะเพียงอย่างเดียวโดยไม่ทดสอบกับงานเฉพาะของตัวเอง แล้วสลับโมเดลตามคะแนนที่ผู้ผลิตประกาศโดยไม่มีการเปรียบเทียบคู่ขนาน
• ทำแบบนี้แล้วพัง เพราะรัน Evaluation แค่ครั้งเดียวตอนเริ่มโปรเจกต์ แล้วไม่เคยรันซ้ำอีกเลยแม้จะแก้ Prompt หรือเปลี่ยนโมเดลไปหลายรอบแล้ว ทำให้ไม่รู้ว่าการเปลี่ยนแปลงล่าสุดทำให้คุณภาพดีขึ้นหรือแย่ลง
• ทำแบบนี้แล้วพัง เพราะให้ LLM-as-Judge ตัดสินทุกอย่างโดยไม่เคยสุ่มตรวจสอบว่าตัวตัดสินให้คะแนนแม่นแค่ไหน ทำให้ปัญหาที่ตัวตัดสินมองข้ามหลุดรอดไปถึงผู้ใช้จริงโดยไม่มีใครรู้

ควรรัน Evaluation บ่อยแค่ไหน และทีมเล็กเริ่มจากตรงไหนได้บ้าง

ทีมขนาดใหญ่ที่มีทรัพยากรพอมักรัน Evaluation อัตโนมัติทุกครั้งที่มีการเปลี่ยนแปลงโค้ดหรือ Prompt คล้ายกับ Continuous Integration ของซอฟต์แวร์ทั่วไป แต่ทีมเล็กที่ยังไม่มีทรัพยากรระดับนั้นก็ยังทำได้ในระดับที่เบากว่า เริ่มจากชุดทดสอบเพียง 20-30 เคสที่ครอบคลุมงานสำคัญที่สุดก่อน แล้วรันด้วยมือทุกครั้งก่อนปล่อยเวอร์ชันใหม่

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

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

สรุป

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

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

• คะแนน Benchmark สาธารณะวัดความสามารถทั่วไป ไม่ได้สะท้อนว่าโมเดลเหมาะกับงานเฉพาะของทีมเสมอไป
• ชุดข้อมูลทดสอบที่ดีต้องมาจากคำถามจริงของผู้ใช้ ครอบคลุมทั้งกรณีทั่วไปและกรณีขอบ
• LLM-as-Judge ช่วยขยายขนาดการตรวจได้เร็ว แต่ต้องสุ่มตรวจสอบความแม่นยำเป็นระยะ ไม่ใช้แทนคนตรวจทั้งหมด
• ควรผนวก Evaluation เข้าเป็นขั้นตอนบังคับก่อนปล่อยทุกเวอร์ชัน เพื่อจับ Regression ก่อนผู้ใช้จริงเจอปัญหา

คำถามที่พบบ่อย