การเรียกใช้เครื่องมือสำเร็จ แต่ผลลัพธ์ล้มเหลว

ทีมวิศวกรซอฟต์แวร์มักจะมองหาสัญญาณที่ผิดจุด

คุณมองหาการแครช (crashes) คุณมองหาข้อยกเว้น (exceptions) คุณมองหาแดชบอร์ดที่เป็นสีแดง

ความล้มเหลวที่เลวร้ายที่สุดบางอย่างไม่ได้ดูเหมือนความล้มเหลว แต่มันดูเหมือนความสำเร็จ

ผมเห็นรูปแบบนี้ตอนที่ทำงานกับ AI agents และ MCP servers Agent เรียกใช้เครื่องมือ เครื่องมือส่งการตอบกลับว่าสำเร็จ ไม่มีข้อผิดพลาด ไม่มี timeout ระบบดูเหมือนจะทำงานปกติ

แต่ภารกิจล้มเหลว การดำเนินการไม่ได้เกิดขึ้นจริง ผู้ใช้ได้รับผลลัพธ์ที่ผิดพลาด

ลูกค้าเป็นคนพบปัญหา ก่อนที่ทีมของคุณจะพบเสียอีก

ซอฟต์แวร์ส่วนใหญ่ทำงานบนแนวคิดเดียวคือ: ถ้าคำขอ (request) สำเร็จ ผลลัพธ์ (outcome) ก็จะสำเร็จด้วย

แนวคิดนี้จะใช้ไม่ได้ผลเมื่อคุณใช้ระบบภายนอก AI agents ต้องพึ่งพา APIs, ฐานข้อมูล และแพลตฟอร์ม SaaS ทุกๆ การพึ่งพา (dependency) จะสร้างช่องว่างระหว่างคำขอและความเป็นจริง

ระบบรายงานว่าสำเร็จ แต่ความเป็นจริงคือความล้มเหลว

ตัวอย่างสถานการณ์:

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

การแครชนั้นหาได้ง่าย แต่ความล้มเหลวที่เงียบเชียบ (silent failures) นั้นหายาก

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

การตรวจสอบมักจะเริ่มขึ้นเมื่อลูกค้าบ่น นั่นคือวิธีที่สิ้นเปลืองที่สุดในการตรวจพบปัญหาด้านความน่าเชื่อถือ (reliability)

เลิกเชื่อใจแค่คำขอที่สำเร็จ เริ่มตรวจสอบผลลัพธ์ที่สำเร็จแทน

Response code บอกคุณแค่ว่ามีการสื่อสารเกิดขึ้นหรือไม่ แต่มันไม่ได้บอกว่าเป้าหมายบรรลุผลหรือไม่

ลองตรวจสอบการเรียกใช้เครื่องมือในระบบ production 10 ครั้งล่าสุดของคุณ แล้วถามคำถามเหล่านี้:

  • คำขอสำเร็จหรือไม่?
  • ผลลัพธ์ที่ตั้งใจไว้เกิดขึ้นจริงหรือไม่?
  • เราจะรู้ได้อย่างไรหากมันล้มเหลว?

หากคำตอบแตกต่างกัน แสดงว่าคุณมีช่องว่างด้านความน่าเชื่อถือ (reliability gap) และผู้ใช้ของคุณจะพบมันในไม่ช้า หากคุณไม่พบเสียก่อน

Source: https://dev.to/sasi_sundar/the-tool-call-succeeded-the-outcome-failed-3l59

Optional learning community: https://t.me/GyaanSetuAi