ทำให้ AI เก่งขึ้นอย่างวัดผลได้: รู้จัก Eval และ Hillclimbing

เวลาเราปรับ prompt แล้ว AI ตอบดีขึ้น เราจะรู้ได้อย่างไรว่ามันเก่งขึ้นจริง ไม่ใช่แค่ตอบถูกกับตัวอย่างไม่กี่ข้อที่เราเพิ่งลอง?

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

Eval คือข้อสอบที่แทนงานจริง

Eval คือชุดโจทย์และวิธีให้คะแนน เพื่อวัดว่าแอปหรือ AI ทำงานเฉพาะอย่างได้ดีแค่ไหน เช่น ระบบจัดหมวดอีเมลอาจถูกทดสอบด้วยอีเมลที่ต้องส่งไปยังคิว billing, refund หรือ technical support

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

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

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

ให้คะแนนด้วยวิธีที่เหมาะกับคำตอบ

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

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

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

ปรับทีละอย่างด้วย Hillclimbing

เมื่อมี eval ที่เชื่อถือได้แล้ว เราจึงค่อยปรับระบบแบบเป็นรอบ ๆ วิธีนี้เรียกว่า hillclimbing: เปลี่ยนสิ่งหนึ่ง วัดผล แล้วเก็บการเปลี่ยนแปลงที่ช่วยให้เข้าใกล้เป้าหมาย

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

หลักสำคัญคือแบ่งโจทย์เป็นสองชุด:

• ชุดฝึก (train): ใช้วิเคราะห์ข้อผิดพลาดและคิดการแก้ไขได้
• ชุดทดสอบ (test): กันไว้ ไม่เปิดให้กระบวนการปรับแต่งดู ใช้วัดว่าการแก้ไขใช้ได้กับโจทย์ใหม่หรือไม่

ถ้าคะแนน train ดีขึ้น แต่ test ไม่ดีขึ้นหรือแย่ลง แปลว่าระบบอาจกำลังจำโจทย์ฝึก มากกว่าจะเข้าใจงานโดยรวม ก็ควรย้อนการเปลี่ยนแปลงนั้น

ระวังการ “จำข้อสอบ”

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

การกันชุด test ไว้ช่วยตรวจปัญหานี้ได้ แต่ยังต้องรักษาความลับของคำตอบด้วย อย่าใส่เฉลยไว้ใน prompt หรือเปิดให้ระบบค้นเจอคำตอบโดยตรง และไม่ควรนำข้อความความล้มเหลวจากชุด test ไปใช้ปรับ prompt

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

ตัวอย่าง: ลดต้นทุนโดยยังรักษาคุณภาพ

ในตัวอย่างที่ Anthropic ยกมา ทีมเริ่มจาก benchmark งานบริการลูกค้า 44 รายการ แบ่งเป็นชุดค้นหา 30 รายการและชุดทดสอบที่กันไว้ 14 รายการ ระบบตั้งต้นทำความถูกต้องได้ 74.4% และมีต้นทุนประมาณ 4.6 เซนต์ต่อเคส

หลังตรวจ prompt และลองปรับรุ่นโมเดลกับระดับ effort ระบบทำได้ 88.9% บนชุดค้นหาในต้นทุนประมาณ 1 เซนต์ต่อเคส จากนั้นปรับกฎการจัดเส้นทางงานเพิ่มเติม ผลบนชุดค้นหาเพิ่มเป็น 98.9% ส่วนชุดทดสอบที่กันไว้ได้ 90.5% เทียบกับระบบตั้งต้นที่ 78.6% โดยต้นทุนลดลงเหลือประมาณหนึ่งในห้า

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

เริ่มจากการวัด ก่อนรีบแก้

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

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

อ่านต้นฉบับ: Automating eval design and hillclimbing with Claude โดย Lance Martin, Anthropic