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

เรื่องราวที่แท้จริงอยู่ที่เส้นทางที่ agent ใช้เพื่อไปถึงจุดนั้น เส้นทางนั้นเรียกว่า agent trajectory ซึ่งรวมถึงการเรียกใช้ tool ทุกครั้ง การตัดสินใจเลือกเส้นทาง (routing decision) ทุกอย่าง และทุกช่วงเวลาที่ agent หยุดเพื่อทบทวนใหม่ คุณสามารถมองว่ามันคือร่องรอยเศษขนมปัง (trail of breadcrumbs) ของ agent และหากคุณตรวจสอบเพียงแค่จุดหมายปลายทาง คุณก็จะพลาดสัญญาณเตือนทั้งหมดที่กระจายอยู่ตามรายทาง

ปัญหาของเส้นทางที่ยุ่งเหยิง

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

ในทางปฏิบัติ ความยุ่งเหยิงนี้มีลักษณะอย่างไร?

อย่างแรกคือ การเรียกใช้ tool ที่ซ้ำซ้อน (redundant tool call) Agent สอบถามข้อมูลจากฐานข้อมูลลูกค้าของคุณ ได้ผลลัพธ์มา แล้วก็ลืมมันไปในอีกห้าวินาทีต่อมา จากนั้นก็สอบถามข้อมูลเดิมด้วยพารามิเตอร์เดิมอีกครั้ง นี่ไม่ใช่ปัญหาด้านข้อมูล แต่มันคือปัญหาด้าน trajectory เพราะ agent ไม่สามารถรักษา state ไว้ได้ จึงต้องทำงานซ้ำซาก

ต่อมาคือ รูปแบบการเลือกใช้ tool ผิดตั้งแต่เริ่ม (wrong-tool-first pattern) เช่น coding agent อาจพยายามค้นหาคำนิยามของ function บนเว็บ ทั้งที่มันมีอยู่ใน local repository อยู่แล้ว หรือ support agent อาจพยายามเรียกใช้ billing API ทั้งที่คำถามของผู้ใช้ต้องการเครื่องมือจัดการการตั้งค่าบัญชี (account settings tool) อย่างชัดเจน ทุกการตัดสินใจที่ผิดพลาดจะเผาผลาญ tokens เพิ่ม latency และเพิ่มโอกาสที่ context limits จะเต็มก่อนที่งานจริงจะเริ่มขึ้นเสียอีก

Router loops คือสัญญาณเตือนอีกอย่างหนึ่ง เมื่อ decision node ไม่สามารถตัดสินใจได้แน่วแน่ มันส่งงานไปที่ branch A แล้วเปลี่ยนใจ ดึงงานกลับมา ส่งต่อไปยัง branch B จากนั้นก็ส่งผ่าน general-purpose fallback node โดยไม่มีเหตุผล ทุกการวนลูปจะเพิ่ม network hop และเพิ่มความสับสนให้กับ debug log ในท้ายที่สุด

สุดท้ายคือ การวิเคราะห์ซ้ำซาก (repeated analysis) Agent เอาแต่หาข้อสรุปเดิมซ้ำๆ ในทุกขั้นตอน แทนที่จะถือว่าข้อสรุปนั้นนิ่งแล้ว เปรียบเสมือนช่างไม้ที่วัดแผ่นไม้สิบครั้งก่อนจะตัดทุกครั้ง ครั้งแรกที่วัดนั้นก็ใช้ได้แล้ว แต่อีกเก้าครั้งที่เหลือคือการเสียแรงเปล่า

ขั้นตอนที่เกินมาเหล่านี้ส่งผลกระทบที่แท้จริง Latency จะสะสมมากขึ้น ในอินเทอร์เฟซแชทแบบ synchronous เวลาที่เพิ่มขึ้นเพียงสามวินาทีอาจให้ความรู้สึกเหมือนชั่วกัปชั่วกัลป์ และเมื่อขยายขนาดระบบ (at scale) วินาทีเหล่านั้นจะกลายเป็นค่าใช้จ่ายในการประมวลผล (compute) หลายพันดอลลาร์ ความเสี่ยงในการล้มเหลวก็เพิ่มขึ้นด้วย ทุกๆ hop ที่ไม่จำเป็นคืออีกหนึ่งโอกาสที่ external API จะ time out, context window จะ overflow หรือเกิด race condition ขึ้น และเมื่อมีบางอย่างพังขึ้นมา ขอให้โชคดีกับการ debug trace ที่ดูยุ่งเหยิงเหมือนเส้นสปาเกตตี คุณจะต้องเสียเวลาหลายชั่วโมงเพื่อย้อนรอยว่าทำไม agent ถึงทำขั้นตอนที่เจ็ด ทั้งที่ความจริงแล้วขั้นตอนที่เจ็ดไม่ควรจะมีอยู่ตั้งแต่แรก

ความหมายที่แท้จริงของ Convergence

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

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

คุณสามารถคำนวณคะแนน convergence คร่าวๆ ได้โดยการเปรียบเทียบขั้นตอนที่ agent ใช้จริง กับเส้นทางที่สั้นที่สุดที่คุณกำหนดไว้สำหรับงานประเภทนั้น หากการสอบถามเรื่องการคืนเงินมาตรฐานควรใช้การเรียก tool เพียงสามครั้ง แต่ agent กลับใช้ถึงเก้าครั้ง อัตราส่วน convergence ของคุณก็จะลดลง คุณสามารถปรับปรุงการคำนวณนี้ได้โดยการให้ค่าน้ำหนัก (weighting) กับความสูญเสียแต่ละประเภท การเรียก tool ผิดเพียงครั้งเดียวอาจมีต้นทุนสูงกว่าการเรียกซ้ำ ขึ้นอยู่กับ latency และราคาของ tool นั้นๆ ส่วน router loop ที่ไม่ได้สร้างมูลค่าเพิ่มเลยอาจต้องได้รับบทลงโทษ (penalty) หนักที่สุด เพราะมันเป็นสัญญาณบ่งบอกถึงปัญหาทางด้าน architectural