เทคนิคทดสอบ Google ADK TypeScript Agents ไม่ให้พังง่าย

การทำให้การทดสอบ AI-agent กลายเป็นเรื่องเปราะบางและพังง่ายที่สุด คือการเขียนโค้ดเพื่อตรวจสอบประโยคสุดท้ายที่โมเดลตอบกลับมา ยกตัวอย่างเช่น เมื่อผู้ใช้ป้อนคำสั่งค้นหาโรงแรมในปารีส โมเดลอาจตอบกลับด้วยข้อความที่แตกต่างกันเล็กน้อยในแต่ละครั้ง แม้พฤติกรรมการทำงานของระบบจะถูกต้อง แต่การทดสอบกลับล้มเหลวทันที

เครื่องมือ Agent Development Kit (ADK) ของ Google เข้ามาช่วยยกระดับให้นักพัฒนาสามารถจัดการกับเอเจนต์ได้ใกล้เคียงกับการพัฒนาซอฟต์แวร์ทั่วไปมากขึ้น โดยรวบรวมทั้งองค์ประกอบของเอเจนต์ เครื่องมือ การประสานการทำงาน เซสชัน เหตุการณ์ การประเมิน และการปรับใช้ให้อยู่ในรูปของโค้ดและรันไทม์พริมทิฟ อย่างไรก็ตาม สิ่งนี้ไม่ได้ทำให้โมเดลกลายเป็นระบบแบบ Deterministic แต่เป็นการมอบพื้นที่ที่ดีกว่าเพื่อให้เราสร้างสัญญาการทำงานที่แน่นอนรอบตัวโมเดลได้

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง

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

• Small human-reviewed evals: การประเมินโดยมนุษย์ในสเกลเล็ก
• End-to-end trajectory scenarios: สถานการณ์จำลองการทำงานตั้งแต่ต้นจนจบ
• Runtime contracts: สัญญาการทำงานของรันไทม์ ได้แก่ นโยบาย, สถานะ และสรีมา
• Deterministic unit tests for tools and adapters: ยูนิตเทสแบบกำหนดผลลัพธ์ได้แน่นอนสำหรับเครื่องมือและอะแดปเตอร์

การทดสอบส่วนใหญ่ควรเกิดขึ้นที่เลเยอร์ล่างสุด เนื่องจากมีความรวดเร็ว ต้นทุนต่ำ และให้ผลลัพธ์ที่แน่นอน นักพัฒนาควรเลือกใช้การประเมินแบบ Live-model อย่างตั้งใจและหลีกเลี่ยงการใช้กับทุกๆ การยืนยันผลลัพธ์

สำหรับเครื่องมือใน ADK TypeScript สามารถแสดงผลได้ผ่าน FunctionTool ร่วมกับ Zod parameter schema ในขณะที่ฟังก์ชันธุรกิจที่อยู่เบื้องหลังยังคงเป็นโค้ด TypeScript ธรรมดาที่ควรได้รับการทดสอบด้วยวิธีการทั่วไป สำหรับการทดสอบแบบ Integration test นักพัฒนาควรเรียกใช้งาน ADK agent พร้อมทั้งรวบรวมเหตุการณ์ทั้งหมด จากนั้นแปลงเหตุการณ์ภายในของเฟรมเวิร์กให้เป็นข้อมูลสรุปที่เป็นของแอปพลิเคชัน เพื่อป้องกันไม่ให้ชุดทดสอบผูกติดกับรายละเอียดภายในของแต่ละอีเวนต์

การทดสอบเส้นทางที่มีความสุขหรือ Happy-path prompts นั้นไม่เพียงพอต่อการใช้งานจริง ความล้มเหลวในระบบโปรดักชันมักเกิดขึ้นที่ขอบเขตระหว่างคำขอที่ดูสมเหตุสมผลกับการกระทำที่ไม่ปลอดภัย การทดสอบความปลอดภัยที่ดีควรผ่านได้เพราะนโยบายของแอปพลิเคชันบล็อกการกระทำนั้นไว้ ไม่ใช่เพราะโมเดลปฏิเสธไปเองตามความบังเอิญ

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

แม้เครื่องมือที่กว้างขวางของ ADK จะช่วยสนับสนุนการประเมินและการให้คะแนน แต่แอปพลิเคชันยังคงต้องการกฎเกณฑ์การผ่านหรือตกที่ชัดเจนคะแนนคุณภาพรวมเพียงตัวเดียวไม่ควรถูกนำมาใช้เพื่อปกปิดการเรียกใช้เครื่องมือที่ถูกห้าม ทีมพัฒนาควรแยกการติดตามข้อจำกัดที่เข้มงวดออกจากคุณภาพแบบยืดหยุ่น:

• Hard: ห้ามเขียนข้อมูลโดยไม่ได้รับอนุญาต, สรีมาต้องถูกต้อง, การยืนยันต้องครบถ้วน
• Soft: ความเกี่ยวข้อง, ความสมบูรณ์, น้ำเสียง, ความกระชับ
• Operational: ค่าความหน่วง, จำนวนครั้งที่เรียกใช้โมเดลและเครื่องมือ, การลองใหม่, ต้นทุนที่ประเมินไว้

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

ที่มา: Dev.to