เลิกมัวแต่รัน benchmark โมเดลใหม่ๆ แล้วเริ่มมานั่งดู agent ของคุณพยายามยกเลิกการสมัครสมาชิกดูบ้าง ช่องว่างระหว่างกิจกรรมทั้งสองอย่างนี้แหละคือจุดที่ระบบใน production พังทลายลง การทดสอบแบบ single-turn อาจบอกคุณได้ว่าคำตอบที่ได้นั้นฟังดูรื่นหูหรือไม่ แต่มันไม่สามารถบอกได้ว่า agent เพิ่งจะคืนเงินให้ลูกค้าผิดคน, วนลูปใส่ calendar API ถึงสิบสี่ครั้ง หรือตัดสินใจข้ามขั้นตอนการตรวจสอบการทุจริตไปเลย ข้อความคือสิ่งที่อันตรายน้อยที่สุดที่ agent ผลิตออกมา ความเสี่ยงที่แท้จริงซ่อนอยู่ในเครื่องมือที่มันสัมผัส ข้อมูลที่มันเปลี่ยนแปลง และช่วงเวลาที่มันควรจะขอความช่วยเหลือแต่กลับฝืนทำต่อไป

ทำไม Text Benchmarks ถึงล้มเหลวใน Production

คะแนนที่สูงลิ่วจาก benchmark มาตรฐานได้กลายเป็นความสบายใจที่หลอกลวง agent ที่เขียนข้อความได้สละสลวยอาจยังคงเป็นอันตรายต่อการปฏิบัติงานได้ เมื่อระบบของคุณต้องจองนัดหมาย, แก้ไขบันทึกในฐานข้อมูล หรือส่งตั๋วสนับสนุน (support tickets) ข้อความที่ถูกสร้างขึ้นมาเป็นเพียงพื้นผิวที่มองเห็นได้ของเวิร์กโฟลว์เท่านั้น แต่ภายใต้พื้นผิวนั้น agent กำลังตัดสินใจอย่างเป็นรูปธรรมว่าจะเรียกใช้ endpoint ไหน, จะส่ง payload อะไร และควรจะหยุดเมื่อไหร่ มันอาจจะครองอันดับต้นๆ ใน leaderboard ด้านการอ่านจับใจความ แต่กลับทำให้คุณเสียเงินจากการจองทรัพยากรซ้ำซ้อน, แก้ไขข้อมูลผิดแถว หรือทำข้อมูลสถานะที่ละเอียดอ่อนหลุดเข้าไปใน log file คุณจำเป็นต้องตรวจสอบกลไกการทำงาน ไม่ใช่แค่ความสวยงามของผลลัพธ์ หาก agent สามารถทำคะแนนได้ดีในการทดสอบ QA แบบ offline แต่ยังทำให้เวิร์กโฟลว์ของคุณพังด้วยการวนลูปหรือใช้เครื่องมือผิดประเภท แสดงว่าการประเมินของคุณกำลังมองไปที่สัญญาณที่ผิดจุด

การกำหนดความเชื่อมโยงทั้ง 5 ประการ (Mapping the Five Dependencies)

ทีมงานที่ Van Data Team เริ่มต้นการประเมินทุกครั้งด้วยการกำหนดจุดควบคุมเฉพาะ 5 จุด ซึ่งจะเปลี่ยนคำถามไปโดยสิ้นเชิง คุณจะเลิกถามว่าโมเดลไหนฉลาดกว่ากัน แต่จะเริ่มถามว่า agent สามารถทำงานใน production ให้สำเร็จภายใต้ข้อจำกัดจริงของคุณได้หรือไม่

ผลลัพธ์ทางธุรกิจ (Business outcomes). นิยามคำว่า "เสร็จสิ้น" ในเชิงมูลค่าเงินและผลกระทบต่อลูกค้า งานหนึ่งงานไม่ได้เสร็จสมบูรณ์เพียงเพราะ agent สรุปเนื้อหาออกมา แต่มันจะเสร็จสมบูรณ์ก็ต่อเมื่อบันทึกสินค้าคงคลังถูกต้อง, การนัดหมายได้รับการยืนยัน และลูกค้าได้รับหมายเลขติดตามพัสดุที่ถูกต้อง

สถานะที่เปลี่ยนแปลงได้ (Mutable state). ต้องรู้ให้แน่ชัดว่า agent ได้รับอนุญาตให้เปลี่ยนแปลงอะไรได้บ้าง? ตารางไหน, สถานะใด, หรือ flag ของบัญชีไหนบ้าง? หาก agent สามารถคืนเงิน, เลื่อนกำหนดการทำงาน หรืออัปเดตที่อยู่ในการเรียกเก็บเงินได้ คุณจำเป็นต้องทำรายการทุกฟิลด์ที่มันเข้าไปแตะต้อง

สิทธิ์การใช้งานเครื่องมือ (Tool permissions). ระบุให้ชัดเจนว่า API endpoint และฟังก์ชันใดบ้างที่อยู่ในขอบเขต agent ที่เข้าถึงได้ทั้งเครื่องมือค้นหา, เครื่องมือเขียนข้อมูล และเครื่องมือแจ้งเตือน จะเกิดความสับสนหากขอบเขตเหล่านี้ไม่ชัดเจน จงจับคู่แต่ละสิทธิ์เข้ากับความต้องการในการปฏิบัติงานที่เฉพาะเจาะจง

การกู้คืนเมื่อเกิดความล้มเหลว (Failure recovery). ตัดสินใจว่าควรเกิดอะไรขึ้นเมื่อ calendar API หมดเวลา (timeout), ส่งค่า 500 กลับมา หรือส่ง JSON ที่รูปแบบผิดเพี้ยนมาให้ agent ไม่ควรตื่นตระหนก, สร้างข้อความหลอนว่าสำเร็จ (hallucinate a success message) หรือพยายามลองใหม่ไปเรื่อยๆ อย่างไม่มีที่สิ้นสุด แต่มันต้องมีเส้นทางการจัดการเมื่อเกิดข้อผิดพลาด (fallback path) ที่ชัดเจน

จุดตรวจสอบโดยมนุษย์ (Human review gates). ระบุช่วงเวลาที่มนุษย์ต้องลงนามอนุมัติก่อนที่ agent จะดำเนินการต่อ นี่ไม่ใช่สัญญาณของความอ่อนแอในระบบอัตโนมัติ แต่มันคือวาล์วนิรภัยสำหรับการเปลี่ยนแปลงที่มีผลกระทบสูง และเป็นแหล่งข้อมูลความจริง (ground-truth labels) สำหรับเกณฑ์การประเมินของคุณ

แผนการประเมินผลที่แท้จริงควรเป็นอย่างไร

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

สร้าง ชุดทดสอบจากความล้มเหลวที่เกิดขึ้นจริงใน production ไม่ใช่จากคลังคำถามที่สร้างขึ้นมาเอง (synthetic question banks) หาก agent ของคุณทำงานพลาดเมื่อวันอังคารที่ผ่านมาเนื่องจากสับสนระหว่าง SKU สองรายการที่คล้ายกัน ความสับสนนั้นควรถูกนำมาเป็นกรณีทดสอบถาวร ชุดการประเมินของคุณควรเติบโตขึ้นทุกครั้งที่มีเหตุการณ์ใหม่ๆ มาสอนบทเรียนให้คุณ

เขียน เกณฑ์การให้คะแนน (rubrics) ที่นิยามความสำเร็จในเชิงปฏิบัติการ เกณฑ์ที่คลุมเครืออย่าง "มีประโยชน์" หรือ "แม่นยำ" นั้นไร้ประโยชน์ เกณฑ์ที่มีประสิทธิภาพควรระบุว่า งานคืนเงินจะถือว่าสำเร็จก็ต่อเมื่อมีการอ้างอิง ID การชำระเงินเดิม, จำนวนเงินตรงกับคำขอ, มีการส่งอีเมลยืนยันเข้าคิว และมีการบันทึก transaction ID ลงในระบบแล้วเท่านั้น

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

กำหนด นโยบายว่าเมื่อใดควรแจ้งเตือนมนุษย์ agent ควรจะรู้ขอบเขตของตัวเอง หากคำขอมีมูลค่าเกินเกณฑ์ที่กำหนด, อ้างอิงถึงบัญชี VIP หรือพบกับสถานะที่ไม่เคยเห็นมาก่อน มันควรจะส่งเรื่องต่อให้มนุษย์ (escalate) แทนที่จะเดาสุ่มไปเอง

ติดตั้ง release gates เพื่อสกัดกั้นการอัปเกรดโมเดลที่แย่ โมเดลใหม่จะเป็นการอัปเกรดก็ต่อเมื่อมันช่วยปรับปรุงผลลัพธ์เฉพาะเจาะจงของคุณให้ดีขึ้นเท่านั้น หากมันเกิดอาการ hallucinate ในส่วนของ tool arguments บ่อยขึ้น เพิ่มความหน่วง (latency) หรือนำความเสี่ยงด้านความปลอดภัยใหม่ๆ เข้ามา โมเดลนั้นก็ไม่ควรถูกนำไปใช้งาน ด่านตรวจนี้จะช่วยรักษาความเสถียรของระบบ production แม้ว่าผู้ให้บริการโมเดลพื้นฐานจะปล่อยเวอร์ชันใหม่ออกมาก็ตาม

Runtime Grading: การเฝ้าดูการทำงานของ Agent

Anthropic กำลังผลักดันให้อุตสาหกรรมก้าวข้ามการทดสอบแบบออฟไลน์ไปสู่ runtime grading แทนที่จะตัดสินบันทึกการสนทนา (transcript) หลังจากเหตุการณ์ผ่านไปแล้ว runtime grading จะช่วยให้ระบบสามารถตัดสินการทำงานของ agent ได้ในขณะที่งานกำลังดำเนินการอยู่ สิ่งนี้ช่วยสร้างโอกาสในการตรวจพบข้อผิดพลาดก่อนที่มันจะกลายเป็นปัญหาที่แก้ไขได้ยาก

การเพิ่ม grader จะทำให้เสียทั้งโทเคนและความหน่วง (latency) คุณไม่สามารถให้คะแนนทุกขั้นตอนเล็กๆ น้อยๆ ได้ การวางตำแหน่งของแต่ละ grader จึงเป็นการตัดสินใจเชิงการออกแบบ ควรวางไว้ในจุดที่หากเกิดข้อผิดพลาดแล้วจะมีมูลค่าความเสียหายสูง จุดตรวจสอบที่มีค่าที่สุดคือจุดที่อยู่ก่อนการบันทึกการเปลี่ยนแปลงสถานะ (state change) ลงในฐานข้อมูล, ก่อนการเรียกเก็บเงิน และก่อนการส่งข้อความถึงลูกค้า ช่วงเวลาเหล่านี้คือตอนที่การตัดสินใจที่ผิดพลาดจะกลายเป็นการกระทำที่ไม่สามารถย้อนกลับได้

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

เป้าหมายในที่นี้คือการควบคุมการดำเนินงาน (operational control) เชื่อมโยงข้อมูลเหตุการณ์ผิดปกติ (incident data), เกณฑ์การให้คะแนนงาน (task rubrics) และร่องรอยการทำงานขณะรัน (runtime traces) ของคุณเข้าด้วยกันเป็นวงจรการตอบกลับเดียว ประเมินเส้นทางทั้งหมด: ทั้งแผนการ, การใช้เครื่องมือ, พฤติกรรมการกู้คืน และผลลัพธ์สุดท้าย ใช้การทดสอบแบบออฟไลน์เพื่อตรวจจับข้อผิดพลาดที่ทราบและทำซ้ำได้ก่อนการปล่อยเวอร์ชัน ใช้ runtime traces เพื่อค้นหาความล้มเหลวใหม่ๆ ที่คุณไม่ได้คาดการณ์ไว้ และใช้การตรวจสอบโดยมนุษย์เพื่อค้นหาว่าเกณฑ์การให้คะแนนของคุณยังไม่รัดกุมพอและจำเป็นต้องปรับปรุงตรงไหน

ดังนั้น ลองถามตัวเองว่า: คุณจะวาง runtime grader ไว้ตรงไหนในเวิร์กโฟลว์ของคุณ? ก่อนการเรียกใช้เครื่องมือ (tool call), หลังการเรียกใช้เครื่องมือ หรือเฉพาะก่อนการเปลี่ยนแปลงที่มีความเสี่ยง? ทีมส่วนใหญ่มักจะเริ่มกว้างเกินไปโดยการให้คะแนนทุกอย่าง แล้วสุดท้ายก็ต้องหยุดชะงักลงเพราะค่าใช้จ่ายที่สูงเกินไป ให้เริ่มจากจุดที่แคบก่อน เลือกการกระทำเพียงอย่างเดียวที่จะสร้างความเสียหายมากที่สุดหากผิดพลาด แล้ววาง grader ไว้ที่นั่นเป็นอันดับแรก

เริ่มต้นด้วยข้อผิดพลาดที่มีมูลค่าความเสียหายสูงเพียงอย่างเดียว

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

หากคุณต้องการเจาะลึกเรื่องการประเมิน agent และ runtime grading ร่วมกับชุมชนของผู้เชี่ยวชาญ คุณสามารถพบกับชุมชนการเรียนรู้ของ GyaanSetu ได้ที่ https://t.me/GyaanSetuAi