เดโมเอเจนต์ของคุณใช้งานได้ นั่นแหละคือกับดัก

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

ช่องว่างระหว่างเดโมกับโปรดักชันคือเรื่องของคณิตศาสตร์ เมื่อคุณเข้าใจคณิตศาสตร์นี้ คุณจะสร้างมันออกมาต่างออกไป

หากแต่ละขั้นตอนในเอเจนต์ของคุณมีความน่าเชื่อถือ 95% ฟังดูเหมือนจะดี แต่เอเจนต์ทำงานด้วยการเชื่อมต่อขั้นตอนต่างๆ เข้าด้วยกัน (chains of steps) หากคุณเชื่อมต่อ 10 ขั้นตอนเข้าด้วยกัน อัตราความสำเร็จของคุณจะลดลงเหลือเพียง 60% และหากคุณใช้ 20 ขั้นตอน อัตราความสำเร็จจะลดลงเหลือเพียง 36%

ในการทำงานจริง ขั้นตอนต่างๆ มักมีอัตราข้อผิดพลาดอยู่ที่ 10% ถึง 20% หากเอเจนต์มี 8 ขั้นตอน โดยมีความน่าเชื่อถือขั้นตอนละ 85% มันจะล้มเหลวถึง 75% ของจำนวนครั้งทั้งหมด

ตัวโมเดลไม่ใช่ปัญหา แต่ความน่าจะเป็นที่สะสมเพิ่มขึ้น (Compounding probability) ต่างหากที่เป็นปัญหา

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

ความล้มเหลวในเอเจนต์ไม่ได้ดูเหมือนการที่ระบบล่ม (crash) แต่มันดูเหมือนข้อผิดพลาดที่เงียบเชียบ

ขั้นตอนที่ 3 อ่านฟิลด์ผิด แต่ผลลัพธ์ที่ได้ยังดูเหมือน JSON ที่ถูกต้อง ขั้นตอนที่ 4 นำข้อมูลที่ผิดพลาดนั้นไปใช้ในการประมวลผล (reasoning) จากนั้นขั้นตอนที่ 5 ถึง 8 ก็ทำงานต่อบนความผิดพลาดนั้น ผลลัพธ์สุดท้ายจึงผิดพลาดแต่ดูสมเหตุสมผล และไม่มี error log ใดๆ บอกคุณเลยว่ามันผิดพลาดตรงไหน

เลิกพูดว่าโมเดล "หลอน" (hallucinated) ได้แล้ว โมเดลแค่ส่งต่อข้อมูลที่ผิดพลาดที่มันได้รับมาต่างหาก ระบบของคุณต่างหากที่ขาดจุดตรวจสอบ (checkpoint) เพื่อดักจับข้อผิดพลาดในขั้นตอนที่ 3

เลิกปฏิบัติกับเอเจนต์เหมือนเป็นแค่ prompt แต่จงเริ่มปฏิบัติกับมันในฐานะ "ระบบ"

ทำตามกฎเหล่านี้เพื่อสร้างเอเจนต์ที่เชื่อถือได้:

  • บันทึกสถานะ (state) ไว้นอกเอเจนต์ เก็บสถานะไว้ในฐานข้อมูล ไม่ใช่ในบทสนทนา หากกระบวนการล้มเหลวที่ขั้นตอนที่ 6 คุณสามารถกลับมาทำต่อที่ขั้นตอนที่ 6 ได้ โดยไม่ต้องเริ่มกระบวนการใหม่ทั้งหมด

  • ตรวจสอบความถูกต้องที่จุดเชื่อมต่อ (validate at the boundaries) ตรวจสอบทุก input และ output เทียบกับ schema เพื่อดักจับข้อผิดพลาดในขั้นตอนที่มันเกิดขึ้น สิ่งนี้จะเปลี่ยนความลึกลับให้กลายเป็นข้อผิดพลาดที่สามารถกู้คืนได้ (recoverable error)

  • ทำให้ side effects เป็น idempotent คุณต้องสามารถลองใหม่ (retry) ได้เมื่อขั้นตอนต่างๆ ล้มเหลว หากขั้นตอนนั้นมีการส่งอีเมลหรือตัดบัตรเครดิต ให้ใช้ idempotency key เพื่อป้องกันการทำงานซ้ำซ้อนระหว่างการ retry

  • ใช้ evals ใน CI ของคุณ พฤติกรรมของเอเจนต์จะเปลี่ยนไปทุกครั้งที่มีการปรับแต่ง การเปลี่ยน prompt อาจช่วยแก้ปัญหาหนึ่งได้ แต่อาจทำให้เกิดปัญหาอื่นตามมาอีกห้าอย่าง ใช้ชุดทดสอบ (test set) เพื่อดักจับการถดถอย (regressions) เหล่านี้โดยอัตโนมัติ

การเปลี่ยนจากเดโมไปสู่ผลิตภัณฑ์จริงคือเรื่องของวิศวกรรม มันคือเรื่องของการจัดการข้อผิดพลาด (error handling), การจัดการสถานะ (state management) และการสังเกตการณ์ระบบ (observability) ไม่ใช่เรื่องของการเขียน prompt ให้ดีขึ้น

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

Source: https://dev.to/sagar_jain4010/your-agent-demo-works-thats-the-trap-4joc

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