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

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

แชตบอตตรวจง่าย แต่ agent ตรวจยากกว่ากันมาก

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

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

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

ห้าคำที่ต้องรู้ก่อน ถึงจะคุยเรื่องวัดผลกันรู้เรื่อง

• task คือโจทย์ทดสอบหนึ่งข้อ บางคนเรียก problem หรือ test case แต่ละข้อมีสองส่วน คือสิ่งที่สั่งให้ agent ทำกับเกณฑ์ที่เขียนไว้ล่วงหน้าว่าแบบไหนถึงนับว่าสำเร็จ ถ้าเกณฑ์ยังกำกวม ผลที่ได้ก็นำไปตีความต่อไม่ได้
• trial คือการลองทำโจทย์ข้อนั้นหนึ่งครั้ง แม้เป็นโจทย์เดิมก็ต้องลองซ้ำหลายครั้ง เพราะโมเดลให้ผลไม่เหมือนกันทุกครั้งที่รัน ผ่านหนึ่งครั้งจึงยังไม่ได้แปลว่าทำได้ ต้องลองหลายครั้งถึงจะเห็นว่าผลนิ่งแค่ไหน
• grader คือตัวให้คะแนน เป็นชุดตรรกะที่ตัดสินพฤติกรรมของ agent ทีละด้าน โจทย์ข้อเดียวมีตัวให้คะแนนได้หลายตัว เพราะความสำเร็จต้องดูหลายด้านพร้อมกัน เช่น ผลปลายทางถูกไหม เลือกเครื่องมือถูกไหม หรือจบงานภายในกี่รอบ
• transcript คือบันทึกการทำงานทั้งหมดของการลองหนึ่งครั้ง จะเรียก trace หรือ trajectory ก็ได้ ในนั้นเก็บทั้งคำตอบ การเรียกเครื่องมือทุกครั้ง กระบวนการคิดของโมเดลระหว่างทาง ผลที่ได้กลับมาในแต่ละรอบ และการโต้ตอบทั้งหมดจนจบงาน
• outcome คือผลลัพธ์ปลายทาง สภาพจริงของระบบ ณ วินาทีที่การลองครั้งนั้นจบลง

สี่คำแรกอ่านแล้วเข้าใจได้ไม่ยาก คำที่ห้าคือคำที่เปลี่ยนความหมายของการวัดผลทั้งหมด

"จองให้แล้ว" กับ "มีรายการจองอยู่จริง" คือคนละเรื่อง

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

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

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

เจ้าของธุรกิจที่จ้างทีมทำ agent จึงมีคำถามที่ใช้ตรวจรับงานได้จริงอยู่ข้อเดียว คือระบบวัดผลของทีมตรวจดูอะไรในฐานข้อมูลบ้าง การนำบทสนทนาที่ agent ตอบได้ดีมาให้ดูยังไม่ใช่คำตอบของคำถามนี้

เวลาบอกว่ากำลังวัด agent จริงๆ แล้ววัดอะไรอยู่

โมเดลอย่างเดียวยังทำงานเป็น agent ไม่ได้ ต้องมีระบบอีกชั้นคอยรับสิ่งที่ป้อนเข้ามา จัดลำดับว่าจะเรียกเครื่องมือไหนเมื่อไร แล้วส่งผลกลับออกไป ระบบนี้เรียกว่า agent harness บางคนเรียกว่า scaffold

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

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

ตัวให้คะแนนสามแบบ กับสาเหตุที่คะแนนต่ำอาจไม่ใช่ความผิดของ agent

ชุดวัดผลของ agent มักผสมตัวให้คะแนนสามแบบเข้าด้วยกัน แต่ละแบบดูคนละส่วนของบันทึกการทำงานและผลลัพธ์ปลายทาง

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

เรื่องที่คนมักมองข้ามคือคะแนนต่ำไม่ได้แปลว่า agent ทำไม่ได้เสมอไป บางครั้งโจทย์มีปัญหา หรือตัวให้คะแนนเข้มงวดเกินไปจนตัดสินว่าคำตอบที่ถูกเป็นคำตอบที่ผิด โมเดลตัวหนึ่งเคยได้ 42% บนชุดทดสอบงานวิจัยชื่อ CORE-Bench เพราะตัวให้คะแนนไม่ยอมรับคำตอบ 96.12 ทั้งที่เลขที่ควรได้คือ 96.124991 นอกจากนี้ โจทย์บางข้อยังกำกวม และบางข้อมีการสุ่มจนรันซ้ำแล้วได้ผลไม่เหมือนเดิม เมื่อแก้บั๊กและเปลี่ยนไปใช้ระบบที่กำหนดข้อจำกัดในการทำงานไว้น้อยลง คะแนนจึงเพิ่มเป็น 95%

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

ผ่านครั้งเดียวก็พอ หรือต้องผ่านให้ครบทุกครั้ง

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

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

แบบที่สองคือ pass^k ถามกลับด้านว่าถ้าให้ลอง k ครั้ง มีโอกาสแค่ไหนที่จะสำเร็จครบทุกครั้ง ยิ่งลองหลายครั้ง ตัวเลขนี้ยิ่งต่ำลง สมมติ agent ตัวหนึ่งทำสำเร็จ 75% ต่อหนึ่งรอบ ถ้าให้มันทำสามรอบติดกันโดยต้องถูกทั้งสามรอบ โอกาสจะเหลือราว 42% จากการนำ 0.75 มาคูณกันสามครั้ง ทั้งที่เป็น agent ตัวเดิม ไม่ได้เก่งขึ้นหรือแย่ลงเลย เปลี่ยนแค่คำถามที่ใช้วัด

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

เริ่มวัดผลตอนไหนถึงจะพอดี

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

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

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

จะเริ่มช้ากว่านั้นก็ได้ แต่ยิ่งช้าก็ยิ่งมีต้นทุน Bolt ใช้เวลาสามเดือนสร้างระบบวัดผลของตัวเอง หลังจากมีการใช้ agent ของพวกเขาอย่างแพร่หลายแล้ว

สิ่งที่ทำให้ชุดวัดผลเชื่อถือได้จริง

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

ที่เหลือคือรายละเอียดที่ทำให้ตัวเลขน่าเชื่อถือ

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

เรื่องสุดท้ายคือชุดวัดผลมีวันหมดอายุ SWE-bench Verified ให้ agent แก้ปัญหาจริงจากโปรเจกต์โอเพนซอร์ส แล้วรันชุดทดสอบเพื่อตัดสินว่าแก้ส่วนที่พังได้โดยไม่ทำให้ส่วนอื่นพังเพิ่มหรือไม่ คะแนนของโมเดลระดับแนวหน้าเพิ่มจากราว 30-40% เป็นมากกว่า 80% ในเวลาราวปีเดียว เมื่อคะแนนเข้าใกล้เพดาน ชุดทดสอบนั้นยังใช้เฝ้าระวังไม่ให้ความสามารถถอยหลังได้ แต่ไม่ได้บอกแล้วว่าควรพัฒนาอะไรต่อ และบางครั้งโมเดลที่เก่งขึ้นจริงก็อาจมีคะแนนเพิ่มเพียงเล็กน้อย บริษัท Qodo ไม่ประทับใจโมเดลรุ่นใหม่ตัวหนึ่งในตอนแรก เพราะชุดวัดผลของพวกเขาวัดงานเขียนโค้ดที่ต้องทำให้จบในครั้งเดียว จึงมองไม่เห็นความสามารถที่เพิ่มขึ้นในงานยาวและซับซ้อน

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

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

---

ที่มา: เอกสารทางการของ Demystifying evals for AI agents