ก่อนเปิดให้ใช้งานโมเดล นักพัฒนาทดสอบอะไรบ้าง และเราควรดูอะไรบ้างก่อนเลือกโมเดล LLM มาใช้ใน Local AI

ประเภท: Explainer · วันที่: 2026-10-03

คะแนนทดสอบมาตรฐานช่วยเปรียบเทียบความสามารถของโมเดลภาษาขนาดใหญ่ หรือ LLM ได้บางด้าน แต่คะแนนรวมเพียงตัวเดียวตอบไม่ได้ว่าโมเดลเหมาะกับงานของคุณหรือไม่

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

1. ความสามารถพื้นฐาน: ทำงานประเภทนั้นได้จริงหรือไม่

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

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

2. การทำตามคำสั่ง: ตอบตรงเงื่อนไขหรือไม่

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

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

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

3. ความถูกต้อง: มีหลักฐานรองรับคำตอบหรือไม่

นักพัฒนาตรวจว่าคำตอบตรงกับเอกสาร ฐานข้อมูล หรือแหล่งอ้างอิงที่เชื่อถือได้หรือไม่ รวมถึงทดสอบว่าโมเดลยอมรับข้อมูลที่ไม่เพียงพอ แทนการแต่งคำตอบหรือไม่

ตัวอย่างเช่น หากเอกสารไม่ได้ระบุวันเริ่มโครงการ คำตอบที่เหมาะสมคือ “เอกสารนี้ไม่ได้ระบุวันเริ่มโครงการ” ไม่ใช่การคาดเดาวันขึ้นมา

สำหรับงานของคุณ ให้ตรวจอย่างน้อย 3 จุด:

• ข้อเท็จจริง: ตัวเลข ชื่อ และวันที่ตรงกับหลักฐานหรือไม่
• แหล่งอ้างอิง: แหล่งข้อมูลมีอยู่จริงและรองรับข้อความที่อ้างหรือไม่
• ความครบถ้วน: คำตอบตกหล่นเงื่อนไขหรือข้อยกเว้นสำคัญหรือไม่

4. การอ่านเอกสารยาว: รับข้อมูลได้กับใช้ข้อมูลได้เป็นคนละเรื่อง

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

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

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

5. รูปแบบคำตอบ: โปรแกรมนำไปใช้ต่อได้หรือไม่

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

ตัวอย่างเช่น คุณกำหนดให้ amount เป็นตัวเลข โมเดลต้องส่ง 1500 ไม่ใช่ข้อความ "ประมาณ 1,500 บาท"

การตรวจต้องแยกสองเรื่องออกจากกัน:

• โครงสร้างถูกต้อง: โปรแกรมอ่านคำตอบได้และคำตอบผ่านข้อกำหนดของ Schema
• เนื้อหาถูกต้อง: ค่าที่โมเดลใส่ตรงกับข้อมูลต้นทาง

JSON ที่อ่านได้ไม่ได้แปลว่าข้อมูลภายในถูกต้อง

6. การใช้เครื่องมือและการทำงานหลายขั้นตอน: ทำงานสำเร็จภายในขอบเขตหรือไม่

โมเดลที่เชื่อมต่อเครื่องมือค้นหา เครื่องคิดเลข หรือ API ต้องเลือกเครื่องมือ ส่งค่าพารามิเตอร์ และตีความผลลัพธ์ให้ถูกต้อง

สำหรับระบบ Agent นักพัฒนาต้องตรวจลำดับการทำงานที่สังเกตได้ เช่น การเลือกขั้นตอน การรับมือเมื่อเครื่องมือล้มเหลว และการขออนุมัติก่อนทำรายการที่ต้องได้รับความยินยอม

ตัวอย่างเช่น ระบบจัดตารางประชุมควรตรวจเวลาว่าง เสนอเวลา และขอคำยืนยันก่อนส่งคำเชิญ หากคุณกำหนดให้ขั้นตอนส่งคำเชิญต้องผ่านการอนุมัติ

เกณฑ์ประเมินจึงควรครอบคลุมทั้งความสำเร็จของงาน จำนวนขั้นตอนที่ใช้ และการทำงานเกินสิทธิ์ที่คุณอนุญาต

7. ความปลอดภัย: จัดการคำขอและข้อมูลที่เสี่ยงได้หรือไม่

นักพัฒนาใช้การทดสอบเชิงรุก หรือ Red Teaming เพื่อค้นหาพฤติกรรมที่ไม่ต้องการ เช่น การเปิดเผยข้อมูลที่ไม่มีสิทธิ์เข้าถึง หรือการทำตามคำสั่งแทรกในเอกสารแทนคำสั่งของผู้ใช้

คุณควรตรวจทั้งสองด้าน:

• ระบบปฏิเสธคำขอที่อยู่นอกสิทธิ์หรือขอบเขตการใช้งานได้หรือไม่
• ระบบยังช่วยทำงานที่อนุญาตได้ โดยไม่ปฏิเสธเกินความจำเป็นหรือไม่

8. คุณภาพคำตอบ: ใครเป็นผู้ตัดสิน

งานแต่ละประเภทต้องใช้ผู้ประเมินต่างกัน การตรวจด้วยวิธีเดียวอาจมองไม่เห็นข้อผิดพลาดบางชนิด

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

งานวิจัย MT-Bench และ Chatbot Arena พบว่าผู้ประเมินแบบ LLM อาจให้คะแนนต่างกันตามลำดับคำตอบ ความยาว หรือความชอบคำตอบของโมเดลเอง คุณจึงควรกำหนดเกณฑ์ให้ชัด สลับลำดับคำตอบ และสุ่มให้มนุษย์ตรวจซ้ำ arxiv

9. ประสิทธิภาพและระบบจริง: คุ้มกับเวลาและต้นทุนหรือไม่

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

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

ตัวอย่างเช่น เมื่อผู้ช่วยตอบคำถามจากคู่มือผิด:

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

คุณจะนำหลักเหล่านี้ไปใช้เลือกโมเดลอย่างไร

1. กำหนดงานเป้าหมาย: ระบุให้ชัดว่าคุณต้องการให้โมเดลทำอะไร และผลลัพธ์แบบใดถือว่าสำเร็จ
2. สร้างชุดทดสอบจากงานจริง: รวมกรณีทั่วไป กรณียาก และกรณีที่ข้อมูลไม่เพียงพอ
3. กำหนดเกณฑ์ก่อนเริ่มทดสอบ: แยกความถูกต้อง การทำตามคำสั่ง ความสำเร็จของงาน เวลา และต้นทุน
4. เปรียบเทียบภายใต้เงื่อนไขเดียวกัน: ใช้ข้อมูล คำสั่ง เครื่องมือ และวิธีให้คะแนนชุดเดียวกัน
5. อ่าน Model Card หรือ System Card: ตรวจข้อจำกัด วิธีทดสอบ และเงื่อนไขที่ผู้พัฒนาเปิดเผย
6. ทดสอบซ้ำเมื่อระบบเปลี่ยน: ตรวจผลหลังเปลี่ยนโมเดล คำสั่ง เอกสาร หรือเครื่องมือที่เชื่อมต่อ

เริ่มจากเลือกงานที่คุณใช้บ่อยหนึ่งงาน แล้วเขียนเกณฑ์ให้ชัดว่าคำตอบแบบใด “ผ่าน” ก่อนนำโมเดลมาเปรียบเทียบ

แหล่งอ้างอิง

• https://arxiv.org/abs/2306.05685
• https://arxiv.org/abs/2309.15217