ดูให้ออกว่า Agent เรียก Tool ผิดจุดไหนก่อนผู้ใช้ร้องเรียน

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

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

บทความนี้อธิบายว่าควรเก็บ Telemetry อะไรบ้างสำหรับ Agent ที่สร้างด้วย Vercel AI SDK อ่านข้อมูลเหล่านั้นอย่างไรให้เจอสาเหตุจริง และข้อผิดพลาดที่ทีมมักเจอเมื่อเริ่มวาง Observability ให้ระบบ Agent

ทำไม Agent ต้องการ Observability ต่างจากแอปเว็บทั่วไป

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

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

ความไม่แน่นอนของ Response Time ก็เป็นอีกจุดที่ต่างจากแอปทั่วไป เพราะเวลาที่ใช้ขึ้นกับจำนวน Tool ที่ถูกเรียกและเวลาตอบสนองของโมเดลในแต่ละรอบ การมี Telemetry ที่แยกเวลาของแต่ละขั้นตอนช่วยให้ทีมรู้ว่าความช้าที่ผู้ใช้เจอมาจากขั้นตอนไหนกันแน่ ไม่ใช่แค่รู้ว่า Response ช้าโดยรวมเท่านั้น

ควรเก็บ Telemetry อะไรบ้างสำหรับ Agent

ไล่ Trace หนึ่ง Conversation ตั้งแต่ต้นจนจบทำอย่างไร

1. เริ่มจากดู Prompt เริ่มต้นที่ผู้ใช้ส่งเข้ามา และ Context ที่ระบบแนบไปให้โมเดลในรอบแรก เพื่อยืนยันว่าข้อมูลตั้งต้นถูกต้องครบถ้วน
2. ไล่ดูว่า Agent ตัดสินใจเรียก Tool ตัวไหนเป็นตัวแรก แล้วดูว่า Input ที่ส่งให้ Tool นั้นตรงกับที่ควรจะเป็นหรือไม่ บ่อยครั้งปัญหาเริ่มจากจุดนี้ที่ Agent ส่งพารามิเตอร์ผิดตั้งแต่ต้น
3. ตรวจผลลัพธ์ที่ Tool ส่งกลับมา เทียบกับสิ่งที่ควรได้จริง ถ้า Tool ทำงานถูกต้องแต่ผลลัพธ์ไม่ตรงกับที่คาดไว้ อาจแปลว่าปัญหาอยู่ที่ข้อมูลต้นทางไม่ใช่ที่ตัว Agent
4. ดูว่า Agent ใช้ผลลัพธ์จาก Tool นั้นไปตัดสินใจขั้นตอนถัดไปอย่างไร ถ้าเรียก Tool ตัวที่สองต่อ ต้องตรวจว่าการตัดสินใจนั้นสอดคล้องกับผลลัพธ์ที่ได้จริงหรือเป็นการตีความที่คลาดเคลื่อน
5. สุดท้ายดูคำตอบที่ Agent เรียบเรียงส่งให้ผู้ใช้ เทียบกับข้อมูลทั้งหมดที่รวบรวมมาระหว่างทาง เพื่อยืนยันว่าคำตอบสุดท้ายสะท้อนข้อมูลจริงที่เก็บมาได้ ไม่ใช่การสรุปที่หลุดจากข้อมูลต้นทาง

ตั้งการแจ้งเตือนอย่างไรให้รู้ปัญหาก่อนผู้ใช้บ่น

การมี Telemetry อย่างเดียวยังไม่พอถ้าไม่มีใครไปดูจนกว่าจะมีคนแจ้งปัญหา ทีมควรตั้งการแจ้งเตือนอัตโนมัติจากตัวชี้วัดที่สะท้อนปัญหาได้เร็ว เช่นอัตราความล้มเหลวของ Tool ตัวใดตัวหนึ่งสูงขึ้นผิดปกติในช่วงเวลาสั้น ๆ หรือเวลาตอบสนองเฉลี่ยของ Agent เพิ่มขึ้นเกินเกณฑ์ที่ตั้งไว้

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

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

ต้นทุนที่เสียไปเมื่อไม่มี Observability ที่ดีพอ

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

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

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

ตัวอย่างสมมติ ไล่หาสาเหตุที่ Agent ตอบผิดในทีมซัพพอร์ต

ลองสมมติทีมหนึ่งมี Agent ตอบคำถามลูกค้าเกี่ยวกับสถานะการจัดส่งสินค้า วันหนึ่งมีผู้ใช้แจ้งว่า Agent บอกสถานะสินค้าผิดจากความจริง ทั้งที่ระบบหลังบ้านมีข้อมูลถูกต้องอยู่แล้ว ถ้าทีมไม่มี Telemetry จะเห็นแค่ว่าผู้ใช้ถามอะไรและ Agent ตอบอะไร โดยไม่รู้ว่าระหว่างทางเกิดอะไรขึ้น

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

การรู้จุดนี้ทำให้ทีมแก้ปัญหาได้ตรงจุด คือปรับคำอธิบายของแต่ละสถานะย่อยให้ชัดเจนขึ้นในข้อมูลที่ส่งกลับจาก Tool แทนที่จะไปแก้ที่ตัว Agent เอง ถ้าไม่มี Trace แยกแต่ละขั้นตอนไว้ ทีมอาจเข้าใจผิดว่าปัญหาอยู่ที่ Tool และเสียเวลาไปกับการแก้จุดที่ไม่ใช่สาเหตุจริง

ทำแบบนี้แล้วพัง เพราะทีมมักพลาดจุดเหล่านี้

• เก็บ Log เฉพาะตอนเกิดข้อผิดพลาด — ทำให้ไม่มีข้อมูลของ Conversation ที่ทำงานปกติไว้เปรียบเทียบ เมื่อต้องดูว่าพฤติกรรมผิดปกติจริงหรือไม่ ไม่มีเส้นฐานให้เทียบ
• บันทึกข้อมูลอ่อนไหวของผู้ใช้ปนไปกับ Log ตรง ๆ — สร้างความเสี่ยงด้านความเป็นส่วนตัว ควรปิดบังหรือเข้ารหัสข้อมูลส่วนที่อ่อนไหวก่อนบันทึกเสมอ
• ไม่ได้ผูก Trace ของแต่ละ Conversation เข้าด้วยกัน — เห็นแต่ Log แยกเป็นชิ้น ๆ ของแต่ละ Tool Call โดยไม่รู้ว่าชิ้นไหนอยู่ใน Conversation เดียวกัน ทำให้ไล่ลำดับเหตุการณ์ไม่ได้
• ตั้งการแจ้งเตือนมากเกินจนทีมเริ่มเพิกเฉย — เมื่อมีการแจ้งเตือนถี่เกินไปโดยส่วนใหญ่ไม่ใช่ปัญหาจริง ทีมมักเริ่มมองข้ามการแจ้งเตือนไปเรื่อย ๆ จนพลาดครั้งที่สำคัญจริง ๆ
• ไม่มีใครดูข้อมูล Telemetry จนกว่าจะมีปัญหาใหญ่ — Observability มีประโยชน์เต็มที่เมื่อถูกดูสม่ำเสมอเพื่อหาสัญญาณผิดปกติล่วงหน้า ไม่ใช่แค่เปิดดูตอนไฟไหม้แล้ว

สรุป

Observability สำหรับ AI Agent คือการเก็บ Telemetry ทุกขั้นตอนตั้งแต่ Prompt ที่ส่งเข้าโมเดล การเรียก Tool แต่ละครั้ง ไปจนถึงคำตอบสุดท้าย เพื่อให้ทีมสืบสาเหตุของปัญหาได้จริงแทนการเดา ต่างจากแอปเว็บทั่วไปตรงที่ Agent มีการตัดสินใจไม่ตายตัวและเรียก Tool หลายตัวต่อเนื่องกัน จึงต้องการข้อมูลละเอียดกว่า Log แบบดั้งเดิม

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

• Observability คือการเก็บ Telemetry ทุกขั้นตอนของ Agent ไม่ใช่แค่อินพุตกับเอาต์พุตสุดท้าย
• ควรบันทึก Tool ที่ถูกเรียก ลำดับการเรียก Input/Output และเวลาที่ใช้ในแต่ละขั้นตอน
• ตั้งการแจ้งเตือนจากตัวชี้วัดที่สะท้อนปัญหาได้เร็ว เช่นอัตราความล้มเหลวของ Tool ที่สูงผิดปกติ
• ไม่มี Observability ที่ดีพอทำให้เสียเวลาสืบปัญหาและกระทบความเชื่อมั่นของผู้ใช้ในระยะยาว

คำถามที่พบบ่อย