การประเมินตัวแทน AI คืออะไร และทำไมต้องวัดจากสิ่งที่ “ส่งมอบจริง”
การประเมินตัวแทน AI คือกระบวนการตรวจสอบว่าระบบ AI ที่ทำหน้าที่แทนมนุษย์ในงานซับซ้อน เช่น การเขียนโค้ดหรือสร้างแอป สามารถส่งมอบผลลัพธ์ที่เปิดใช้ได้จริง ทำงานครบตามโจทย์ และปลอดภัยพอจะนำไปใช้งานในระบบจริง โดยไม่หยุดอยู่แค่การผ่านเทสต์สั้นหรือเดโมตัวอย่างในห้องแลบ แนวโน้มใหม่ของการตรวจสอบคุณภาพ AI ไม่ได้เริ่มจากกราฟคะแนนบนสไลด์พรีเซนต์ แต่เริ่มจากหลักฐานเชิงประจักษ์ของงานที่เสร็จแล้ว เช่น แอปที่เปิดได้ บันทึกข้อมูลได้ และให้ผู้ใช้ส่งฟอร์มแล้วข้อมูลลงเขตที่ถูกต้องในเวิร์กสเปซของตนเอง การประเมินตัวแทน AI แบบนี้จึงกลายเป็นคำถามเชิงธุรกิจมากกว่างานวิจัย เพราะทุกครั้งที่องค์กรสั่งว่า “บรรยายแอปแล้วให้ AI สร้างให้” ความเสี่ยงจะโยกจากห้องทดลองไปสู่ผู้ใช้ปลายทางทันที มุมมองสำคัญคือ การทดสอบ AI agents ต้องเลิกมองแค่ฟังก์ชันเล็กๆ แล้วหันมาวัดทั้งผลิตภัณฑ์ว่าเปิด ตอบสนอง และเก็บข้อมูลถูกหรือไม่ ซึ่งต่างจากการเทสต์แพตช์แก้บั๊กที่มองเพียงว่าชุดเทสต์ผ่านหรือไม่
TSK-1: เกณฑ์ทดสอบที่ให้แอปเต็มๆ เป็นคำตอบ ไม่ใช่บรรทัดคะแนน
หัวใจของ TSK-1 คือการประกาศชัดว่า การทดสอบ AI agents ต้องวัดจากแอปทั้งตัว ไม่ใช่แค่แพตช์โค้ดเดี่ยวๆ TSK-1 ให้โมเดลสร้างแอปจริงสองตัวจากพรอมต์ตายตัว แล้วตรวจทีละขั้นว่ารันได้ เปิดได้ และรับส่งฟอร์มพร้อมบันทึกข้อมูลลงฟิลด์ถูกต้องในเวิร์กสเปซ เกณฑ์นี้เปิดเผยจุดอ่อนที่กราฟทั่วไปซ่อนเอาไว้ เมื่อมีการทดสอบบันทึกแล้ว 19 ครั้งในช่วงปลายกรกฎาคมถึงปลายสิงหาคม โดยถูกรวมเป็น 12 รายการบนฮับการประเมินตัวแทน AI สิ่งที่น่าสนใจคือทุกบิลด์ถูกเขียนบันทึกว่าอะไรเปิด อะไรรัน อะไรบันทึกได้ แล้วสรุปเป็นดัชนี 0–100 แทนคะแนนลอยๆ คำพูดที่ควรถูกหยิบไปอ้างบ่อยคือ “TSK-1 ประเมินทั้งผลิตภัณฑ์ ไม่ใช่เดโม” เพราะโมเดลที่เก่งแก้บั๊กเปลี่ยนเพียงหนึ่งฟังก์ชัน ในขณะที่โมเดลที่สร้างแอปได้คือโมเดลที่ส่งมอบผลิตภัณฑ์จริง ซึ่งมีโอกาสพังตั้งแต่เปิดไม่ติด เซฟข้อมูลผิดฟิลด์ ไปจนถึงการสร้างแอปผิดโจทย์โดยไม่บอกใคร
วันที่น่าสนใจที่สุดคือ 1 สิงหาคม ที่มีการสั่งให้โมเดล 9 ตัวสร้างแอปเดียวกันจากพรอมต์เดียวกันแบบวันเดียวจบ ผลคือ 3 จาก 9 บิลด์เปิดไม่ได้เลย และโมเดลที่ราคาถูกที่สุดกลับสร้างแอปที่ดูดีที่สุด มีธีมสว่างมืดครบ หน้าไม่พัง และเลย์เอาต์ใช้งานได้แม้กว้างเพียง 390 พิกเซลบนมือถือ นี่คือการตรวจสอบคุณภาพ AI ที่ตอบคำถามผู้ใช้มากกว่าตารางคะแนนในงานเปิดตัว ผู้ใช้อยากรู้ว่า “ถ้าฉันสั่งให้สร้างแอปวันนี้ ฉันจะได้ของใช้งานได้จริงหรือไม่” ไม่ได้อยากรู้เพียงว่าโมเดลทำข้อสอบเฉลี่ยได้กี่เปอร์เซ็นต์ ความต่างนี้เองที่ทำให้การปรับใช้ AI agents ในเวิร์กโฟลว์ธุรกิจไม่สามารถพึ่งเบนช์มาร์กแบบกราฟได้อีกต่อไป แต่ต้องหันมาดูหลักฐานระดับแอปทำงานจริงเป็นรายโมเดล
โครงประตูโค้ด: ด่านโครงสร้างที่ดักบั๊กของตัวประเมินเอง
ด้านโลกของโค้ด มีอีกตัวอย่างของการประเมินตัวแทน AI ที่เกิดขึ้นหน้างานจริง คือโครงประตูโค้ดที่ทำหน้าที่เป็นเบรกโครงสร้าง ปฏิเสธการเขียนไฟล์ของเอเจนต์ก่อนที่มันจะลงดิสก์ ด้วยเพดานความยาวไฟล์และจำนวนอิมพอร์ตต่อโมดูลแบบบังคับ ไม่มีทางลัดจากมนุษย์ ก่อนหน้านี้ผู้สร้างระบบเคยเขียนถึงแนวคิด “รัฐธรรมนูญสำหรับเอเจนต์โค้ด” ว่าให้ไฟล์ไม่เกิน 500 บรรทัด จำกัดอิมพอร์ตไม่เกิน 7 โมดูล ต่อด้วยรีวิวไขว้ข้ามผู้ให้บริการโมเดล และนิยามว่าเสร็จแล้วต้องพิสูจน์ได้ แต่ของที่ถูกส่งไปทดสอบภายนอกคือส่วนเล็กที่สุด นั่นคือโครงประตูที่ยกเครื่องง่ายและไม่ต้องพึ่งเครือข่ายใดๆ สัปดาห์ก่อน โครงประตูนี้ถูกแพ็กเป็นทาร์บอล วางบนเครื่องที่สองซึ่งรัน Windows 10 แบบเนทีฟ ใช้กับโปรเจ็กต์ TypeScript จริงที่คอยเฝ้าดูข้อมูลตลาดอสังหาริมทรัพย์และคุยกับ Telegram พร้อมเอเจนต์ที่ทำงานจริงให้ผู้ใช้คนหนึ่งไม่ใช่เดโมในห้องทดลอง นี่คือการประเมินตัวแทน AI จากเครื่องภายนอกที่มีโจทย์จริงและแรงกดดันจริง
การทดสอบกินเวลา 4 วัน มีการเขียนหรือแก้ไฟล์ที่ถูกโครงประตูกั้นไว้ราว 40 ครั้ง รายงานที่ได้ตอบคำถามการประเมิน 6 ข้อที่เตรียมไว้ แล้วเพิ่มรายการแก้ไขตามลำดับความคุ้มค่า พร้อมแนบข้อความปฏิเสธทุกครั้งอย่างละเอียด สี่ครั้งที่โครงประตูสั่งปฏิเสธ มีหนึ่งครั้งเป็นการทดสอบโดยตั้งใจด้วยไฟล์ 601 บรรทัดที่ถูกออกแบบมาเพื่อเช็กว่าเบรกยังทำงาน และมันถูกปฏิเสธก่อนเขียนลงดิสก์ อีกสองครั้งเกิดในรีแฟกเตอร์จริงบนกฎเดียวกัน คือโมดูลนำเข้า 8 ไฟล์ในขณะที่เพดานคือ 7 อันนี้คือการตรวจสอบคุณภาพ AI แบบที่ผู้ใช้จำนวนมากไม่เคยเห็น เพราะล็อกไว้หน้าดิสก์ก่อนจะเกิดความซับซ้อนสะสม คำพูดที่ช่วยเตือนใจคือ “ถ้าคุณซื้อเบรกโครงสร้างแต่หวังให้มันจับบั๊กฟังก์ชัน คุณจะผิดหวังกับเครื่องมือที่กำลังทำงานได้ดี” เพราะมันมีหน้าที่หยุดโมเมนตัมในจังหวะที่มนุษย์กำลังจะยอมง่ายที่สุด นั่นคือไฟล์รันได้แล้ว คนกำลังรอ และการเพิ่มอิมพอร์ตอีกหนึ่งบรรทัดดูเหมือนทางลัดที่ไม่มีต้นทุน
จากการประเมินภายนอกสู่ลูปแก้ไขภายใน 48 ชั่วโมง
สิ่งที่ทำให้โครงประตูโค้ดโดดเด่นในโลกการประเมินตัวแทน AI ไม่ใช่แค่กฎที่ใช้ แต่เป็นลูประหว่างการประเมินภายนอกกับการแก้ไขภายใน รายงาน 4 วันนั้นสรุปว่ามี 4 การปฏิเสธและข้อเสนอหนึ่งรายการ ก่อนที่เจ้าของเครื่องมือจะจัดการแก้ทุกจุดในเย็นวันเดียวกัน พร้อมสร้างฟังก์ชันเสริมที่เรียกว่า doctor แล้วแพ็กทาร์บอลเวอร์ชันใหม่ส่งกลับไป วันถัดมา เครื่องที่ใช้ประเมินเดิมรันการทดสอบซ้ำเพื่อยืนยันว่าทุกการแก้ไขทำงานได้จริง โดยอ้างอิงกับโค้ดเบสและสมุดจดระหว่างการรันรอบแรก ไม่ใช่ดูแค่บันทึกการเปลี่ยนแปลง หรือในคำอธิบายแบบเต็มว่า “Day 1–4 การประเมินรัน รายงานมาพร้อมสี่ผลและข้อเสนอเดียว เย็นวันเดียวกันนั้นการแก้ไขทั้งหมดและ doctor ถูกปล่อย เวอร์ชันใหม่ถูกส่ง และวันถัดมาเครื่องเดิมยืนยันทุกการแก้ไขกับโค้ดและสมุดจดชุดเดิม” ตัวสร้างโครงประตูยังยืนยันว่าระบบนี้ยังเป็นของส่วนตัว การประเมินครั้งนี้คือบันไดให้มัน “สร้างความชอบธรรมก่อนออกสู่สาธารณะ” พร้อมเชิญผู้ใช้กลุ่มเล็กมารันแพ็กเกจเดียวกับที่เครื่อง Windows ใช้ ใช้โค้ดเบสของตัวเอง และตอบชุดคำถามดุดันชุดเดิม นี่คือทิศทางของการทดสอบ AI agents ที่ให้เครื่องภายนอกเป็นกรรมการ และให้ลูปการแก้ไขวัดด้วยหลักฐานซ้ำ ไม่ใช่คำอธิบายบนกระดาษ
บทสรุป: การตรวจสอบคุณภาพ AI ต้องเริ่มจากหลักฐาน ไม่ใช่กราฟ
ทั้ง TSK-1 และโครงประตูโค้ดกำลังสอนบทเรียนเดียวกันให้คนที่กำลังคิดเรื่องการปรับใช้ AI agents ในงานจริง นั่นคือ เราควรวัดจากผลลัพธ์ที่เครื่องส่งออกสู่โลก ไม่ใช่คะแนนสังเคราะห์ในห้องทดสอบ ในโลกของแอป TSK-1 แสดงให้เห็นว่าการทดสอบ AI agents ด้วยการให้สร้างแอปจริงจากพรอมต์ตายตัวบนเคอร์เนลที่รวมโมเดล เมมโมรี เอเจนต์ และเวิร์กโฟลว์ แล้วตรวจว่าแอปเปิด รัน และบันทึกได้ครบทุกฟิลด์นั้น ช่วยแยกโมเดลที่ “ส่งของได้” ออกจากโมเดลที่เปิดแอปยังไม่ได้เลย ฮับของมันยังเก็บดาต้าทั้งหมดและลิงก์คิทแอปที่เปิดและโคลนได้ ทำให้ผู้อื่นกลับมาทดสอบซ้ำตามหลักฐานเดิมได้ตลอด ในโลกของโค้ด การประเมินตัวแทน AI จากภายนอกด้วยชุดคำถามชัดเจนบนเครื่องที่ต่างสภาพแวดล้อม แสดงให้เห็นว่าการป้องกันโครงสร้างที่จุดเขียนไฟล์สามารถดักปัญหาที่ไม่มีใครคิดถึง แม้แต่บั๊กในตัวตัวประเมินเอง ประโยคที่ควรถูกย้ำคือ “การประเมินภายนอกด้วยคำถามหกข้อที่ตรงไปตรงมามีค่านำหน้าการรันภายในร้อยครั้ง” เพราะมันทำให้เครื่องมือ AI ต้องเผชิญความจริงแบบหน้างาน สำหรับผู้อ่านที่กำลังคิดจะใช้หรือสร้าง AI agents บทเรียนคือ เริ่มจากการประเมินตัวแทน AI ด้วยงานจริง บันทึกหลักฐานทุกครั้งที่รัน และยอมรับว่าตัวประเมินเองก็ต้องถูกประเมิน วงจรนี้เท่านั้นที่จะทำให้การตรวจสอบคุณภาพ AI มีความหมายต่อผู้ใช้ปลายทาง ไม่ใช่เพียงสไลด์ในวันเปิดตัว
