AI agent testing คืออะไร และทำไมแค่เดโมผ่านยังไม่พอ
AI agent testing คือกระบวนการประเมิน ตรวจสอบ และเฝ้าดูพฤติกรรมของเอเย่นต์ตั้งแต่รับอินพุต การเรียกใช้เครื่องมือ ไปจนถึงผลลัพธ์สุดท้าย เพื่อดูว่าเอเย่นต์ทำงานอย่างถูกต้อง ปลอดภัย ประหยัดทรัพยากร และคงเสถียรเมื่อมีการอัปเดตโมเดล เปลี่ยนพรอมต์ เพิ่มเครื่องมือ หรือเจออินพุตแปลกใหม่ในสภาพแวดล้อมโปรดักชันที่เปลี่ยนแปลงตลอดเวลา
โลกของ AI agent ไม่เหมือนซอฟต์แวร์เชิงฟังก์ชันแบบเดิม เอเย่นต์อาจตอบไม่เหมือนกันในแต่ละครั้ง เลือกเครื่องมือต่างกัน หรือฟื้นตัวจากข้อผิดพลาดด้วยเส้นทางหลายแบบได้ การทดสอบแบบเป๊ะทุกตัวอักษรจึงมักไม่ใช่มาตรวัดที่ถูกต้อง สิ่งที่เราต้องถามคือ เอเย่นต์ยังตัดสินใจถูก ใช้เครื่องมือเหมาะสม ส่งพารามิเตอร์ปลอดภัย และฟื้นตัวจากความล้มเหลวได้หรือไม่ การทำ AI agent testing ให้ดีจึงต้องมีระบบประเมินและสังเกตการณ์ที่บอกได้ว่าเอเย่นต์เริ่ม “ดริฟต์” ตรงไหน เริ่มล้มเหลวเมื่อใด และการรีลีสครั้งล่าสุดทำให้ระบบดีขึ้นหรือแย่ลง
เลเยอร์ที่หายไปก่อนส่งเอเย่นต์ลงโปรดักชัน: evaluation, tracing, failure detection
ปัญหาใหญ่ของหลายทีมคือหยุดแค่ตอนเดโมผ่าน โมเดลตอบได้ เรียกเครื่องมือได้หนึ่งครั้ง แล้วคิดว่าพร้อมโปรดักชัน ทั้งที่ความยากจริงอยู่ที่คำถามว่า เอเย่นต์จะยังทำงานถูกหลังพรอมต์ชุดที่ห้า การเรียกเครื่องมือครั้งที่สิบ หรือเมื่อผู้ใช้ใส่อินพุตพิสดารหรือไม่ เราต้องสร้างเลเยอร์ evaluation และ observability ให้ตอบคำถามลึกว่า เอเย่นต์เลือกเครื่องมือถูกหรือเปล่า พารามิเตอร์ปลอดภัยไหม ฟื้นตัวจากข้อผิดพลาดได้หรือไม่ รุ่นโมเดลหรือพรอมต์ใหม่ทำให้ระบบดีขึ้นหรือแย่ลง
การมองเอเย่นต์ให้เหมือนระบบสินค้า เช่น flow ชำระเงินหรือระบบแนะนำสินค้าช่วยให้เราเข้าใจว่าต้องตรวจพฤติกรรมทั้งเส้น ไม่ใช่แค่ออกพุตสุดท้าย เราควรมีการ trace ตั้งแต่สิ่งที่ผู้ใช้ถาม สิ่งที่โมเดลตีความ เครื่องมือที่เลือก อาร์กิวเมนต์ที่ส่ง ผลลัพธ์ของเครื่องมือ เวลาแต่ละขั้น และคำตอบสุดท้าย เป้าหมายไม่ใช่แดชบอร์ดสวย แต่คือ feedback loop ที่มี trace การ replay การให้คะแนน การทดสอบ regression และการวิเคราะห์ความล้มเหลว เพื่อไม่ต้องรอให้ผู้ใช้เป็นคนเจอปัญหาก่อน
ออกแบบ workflow ให้ทนทาน: idempotency keys และ effect ledger มาก่อน checkpoint
หลายคนหลงรักคำว่า checkpoint เพราะฟังดูปลอดภัย เหมือนว่าถ้าเอเย่นต์ล้มก็กลับมาทำงานต่อได้ทันที แต่ความจริงคือเอ็นจิ้น workflow ฟื้นสถานะของตัวเองได้เท่านั้น มันไม่สามารถยกเลิกหรือย้อนโลกภายนอกได้แบบอะตอมิก ช่องว่างระหว่างการเรียก API ภายนอกกับการเขียน checkpoint อาจทำให้เอเย่นต์เรียก API ซ้ำและสร้างความเสียหายซ้ำเมื่อกลับมารันต่อ การทำให้ workflow ทนทานจึงเริ่มที่ “การทำซ้ำที่ปลอดภัย” ไม่ใช่แค่การบันทึกสถานะ
หลักคิดคือยอมรับว่าฟังก์ชันหลัง boundary ล่าสุดอาจรันมากกว่าหนึ่งครั้งเสมอ เราจึงต้องทำให้ผลกระทบภายนอกเป็นแบบ idempotent โดยให้ทุก effect มีตัวตนผ่าน idempotency keys ที่ผูกกับ “การกระทำทางธุรกิจ” ไม่ใช่การลองยิงเครือข่ายแต่ละครั้ง เช่นการคำนวณ key จาก run ของ workflow ขั้นตอนเชิงตรรกะ ออบเจ็กต์ธุรกิจ และผลที่ตั้งใจ เมื่อ retry จะใช้ key เดิมและระบบภายนอกเก็บผลครั้งแรกแล้วส่งคืนผลเดิมหากมีคำขอซ้ำ การออกแบบแบบนี้ทำให้การประมวลผลแบบ exactly once ถูกสร้างจากการส่งอย่างน้อยหนึ่งครั้งบวกกับ effect ที่ทำซ้ำได้อย่างปลอดภัย ไม่ใช่ขนส่งวิเศษ
การ trace และ replay เพื่อจับ tool call พังและ latency ก่อนโปรดักชันแตก
ถ้าไม่มีการ trace คุณกำลังบินแบบปิดไฟ cockpit การสังเกตการณ์ที่ดีต้องเริ่มจากการล็อกทุก run ของเอเย่นต์อย่างมีโครงสร้าง ทั้งอินพุต คำอธิบายที่โมเดลตีความ เครื่องมือที่เลือก อาร์กิวเมนต์ที่ใช้ ผลลัพธ์ที่ได้ การตัดสินใจต่อเนื่อง และเวลาในแต่ละขั้น การ trace แบบนี้คือฐานของ agent ops เพราะทำให้เห็นว่าระบบแข็งแรงตรงไหน เปราะบางตรงไหน และความล้มเหลวครั้งต่อไปมีแนวโน้มเกิดที่จุดใด
หัวใจอีกข้อคือความสามารถในการ replay เมื่อเอเย่นต์พังในโปรดักชัน เราต้องเล่นซ้ำ run เดิมให้ได้ใกล้ที่สุดเพื่อดูเส้นทางที่นำไปสู่ความล้มเหลวและตรวจว่าพฤติกรรมที่เปลี่ยนเกิดจากโมเดล พรอมต์ หรือการเรียกเครื่องมือ การมี trace และ replay ทำให้เราจับปัญหา tool call ที่พัง อาร์กิวเมนต์ผิดรูปแบบ หรือ latency ที่ยืดโดยไม่รู้ตัว ก่อนที่ระบบโปรดักชันจะแตกต่อหน้าผู้ใช้ เป้าหมายคือสร้าง loop การประเมินแบบต่อเนื่องจากทราฟฟิกจริงเพื่อกลายเป็นการปรับปรุงไม่หยุด
checkpoint อย่างเดียวไม่พอ: compensation และ reconciliation เพื่อ production safety
การมี checkpoint เพียงอย่างเดียวอาจสร้างภาพลวงว่าปลอดภัย ทั้งที่ในหลายกรณี workflow กลับมารันใหม่แล้วทำความเสียหายซ้ำ เพราะไม่รู้ว่า effect ภายนอกเคยเกิดขึ้นแล้วหรือไม่ ช่องว่างนี้คือ effect gap เมื่อเอเย่นต์เรียกบริการคืนเงินแล้ว worker ตายก่อนเขียน checkpoint ระบบภายในจะมองว่าไม่มีใบเสร็จและลองคืนเงินอีกครั้ง การออกแบบ production safety ที่ดีจึงต้องแยกการบันทึกสถานะการสนทนาออกจากบันทึกเจตนาและผลของ effect ผ่าน effect ledger ที่บันทึกว่ามี action ใดเกิดขึ้นหรืออยู่ในสถานะไม่ทราบผล
เมื่อเจอผลลัพธ์ไม่ชัด เช่น timeout หลังส่งคำขอ ความหมายคือ UNKNOWN ซึ่งไม่เท่ากับล้มเหลว เราต้องใช้ pattern reconciliation คือสอบถามสถานะกับระบบภายนอกด้วย idempotency key หรือ reference ก่อนจะลองทำซ้ำ สำหรับ effect ที่ทำให้ idempotent ยาก เช่นหลายขั้นตอนผ่านไปแล้ว workflow ล้มกลางทาง เราต้องคิดเรื่อง compensation แทนการ rollback เช่นยกเลิกการจอง ออกเครดิตแก้ไข ปิด ticket ซ้ำ หรือเพิกถอนสิทธิ์ชั่วคราว แนวคิดนี้ทำให้การ resume กลับมาไม่ใช่แค่ “เริ่มจาก checkpoint เดิม” แต่เป็นการกลับมาในสภาพที่ถูกชดเชยและคงความปลอดภัยของโปรดักชัน
