AI agent ในโปรดักชันคืออะไร และทำไมเดโม่สวยไม่พอ
AI agent ในโปรดักชันคือระบบที่ใช้โมเดลภาษาเชื่อมกับเครื่องมือหรือบริการต่างๆ เพื่อทำงานอัตโนมัติแบบหลายขั้นตอน ตั้งแต่ตีความข้อความผู้ใช้ เลือกและเรียกใช้เครื่องมือ ตรวจผลลัพธ์กลางทาง ไปจนสรุปคำตอบหรือทำแอ็กชันกลับออกไป ระบบแบบนี้ไม่ใช่แค่บ็อตตอบแชต แต่เป็นโฟลว์ธุรกิจเต็มรูปที่ต้องควบคุมคุณภาพทั้งความถูกต้อง ปลอดภัย ประสิทธิภาพ และความสามารถในการฟื้นจากความผิดพลาด ปัญหาคือ คนส่วนใหญ่หยุดคิดเมื่อเดโม่รันผ่านครั้งแรก โมเดลตอบได้ เรียกเครื่องมือครั้งหนึ่งแล้วดูโอเคก็ถือว่าพอ แต่ความยากจริงเริ่มตรงที่พรอมป์ครั้งที่ห้า การเรียกเครื่องมือครั้งที่สิบ อินพุตแปลกๆ หรือโมเดลอัปเดตรอบหน้า ที่ทำให้เอเจนต์เปลี่ยนพฤติกรรมแบบเงียบๆ โดยไม่มีใครรู้ ยิ่งถ้าทีมเริ่มใช้เอเจนต์ช่วยเขียนโค้ดหรือรีวิวงาน ความเร็วเพิ่มขึ้นแต่ประสบการณ์จริงกลับลดลง ผู้ใช้ AI ทำคะแนนหลังทำงานต่ำลง 17 จุด แม้เวลาเสร็จงานเท่าเดิม นี่คือสัญญาณตรงๆ ว่าเรากำลังได้ความเร็วแต่เสียความรู้และการควบคุม
เอเจนต์ไม่เหมือนฟังก์ชันโค้ด ทำไม AI agent testing ต้องคิดเป็นระบบ
ซอฟต์แวร์แบบเดิมเป็นดีเทอร์มินิสติก อินพุตเดิมเอาต์พุตเดิม ทำให้เขียนเทสต์แบบคาดคำตอบเป๊ะๆ ได้ง่าย แต่เอเจนต์อาจเปลี่ยนถ้อยคำ เลือกเครื่องมือคนละตัว หรือฟื้นจากความผิดพลาดหลายวิธีที่ยังถือว่าถูกต้อง ถ้า AI agent testing ยังคิดแค่เช็กสตริงผลลัพธ์ เทสต์จะหลอกเราว่าทุกอย่างโอเค ทั้งที่ระบบกำลังไหลออกนอกกรอบ เอเจนต์ที่สุกต้องถูกมองเป็นระบบโปรดักต์เต็มตัว เหมือนโฟลว์เช็คเอาต์ ระบบแนะนำ หรือระบบตรวจทุจริต เราต้องตรวจพฤติกรรมตลอดสาย ไม่ใช่ดูแค่คำตอบปลายทาง งานประเมินควรแตกเป็นสามชั้น คือคุณภาพอินพุต การประมวลผล และผลลัพธ์สุดท้าย รวมทั้งคุณสมบัติระดับระบบ เช่น ความแม่นในการเลือกเครื่องมือ ความถูกต้องของอาร์กิวเมนต์ ขอบเขตความปลอดภัย พฤติกรรมการรีไทร ละตี้ และต้นทุน ถ้าเราเช็กแค่ชั้นเดียว เราจะพลาดโหมดล้มเหลวส่วนใหญ่โดยไม่รู้ตัว
Tracing และ replay เปลี่ยนการดีบักจากการเดาเป็นหลักฐาน
ภาพที่ควรใช้ในการออกแบบ agent evaluation framework คือโซ่การตัดสินใจ เริ่มจากคำขอผู้ใช้ การตีความของโมเดล การเลือกเครื่องมือ การรันเครื่องมือ ผลลัพธ์กลาง การตอบสุดท้าย และผลกระทบต่อผู้ใช้ ความล้มเหลวเกิดได้ทุกข้อของโซ่ โมเดลอาจเข้าใจโจทย์แต่เลือกเครื่องมือผิด เครื่องมือถูกแต่ส่งอาร์กิวเมนต์ผิด เครื่องมือรันสำเร็จแต่เอเจนต์สรุปผลผิด หรือคำตอบช้าเกินจนใช้จริงไม่ได้ นี่คือเหตุผลที่การ tracing และ replay สำคัญมาก แทนการอ่านคำตอบสุดท้ายแบบสปอตเช็ก เราต้องล็อกทุกขั้นให้รันย้อนดูได้เสมอ เช่น ไอดีรีเควสต์ พรอมป์ผู้ใช้ โมเดลที่ใช้ เวอร์ชันพรอมป์ระบบ ชื่อเครื่องมือที่ถูกเรียก อาร์กิวเมนต์ ผลเครื่องมือ เวลาแต่ละขั้น โทเคนที่ใช้ และสถานะสำเร็จหรือผิดพลาด เมื่อเอเจนต์ล้มในโปรดักชัน เราจึงไล่กลับได้ว่าอินพุตเสีย เครื่องมือพัง หรือการตีความผลลัพธ์มีปัญหา การ replay ทำให้การดีบักกลายเป็นงานวิศวกรรม ไม่ใช่การเถียงกันตามความรู้สึก
ดักความล้มเหลวก่อนโปรดักชันแตก: จาก monitoring สู่เกตปล่อยจริง
การตรวจความล้มเหลวในโปรดักชันไม่ใช่แค่ดูว่าเอเจนต์ตอบผิดหรือถูก แต่ต้องเฝ้าดูการเรียกเครื่องมือและโซ่การตัดสินใจทั้งเส้น production failure detection ที่ดีเริ่มจาก tool call monitoring ตรวจว่าเอเจนต์ใช้เครื่องมือถูกตัว ส่งอาร์กิวเมนต์ปลอดภัย เคารพสิทธิ์ และไม่มีไซด์เอฟเฟกต์อันตราย จากนั้นต้องมีระบบสกอร์และรีเกรสชันเทสต์ที่รันกับเคสจริงก่อนปล่อยเวอร์ชันใหม่ เพื่อรู้ว่าการเปลี่ยนพรอมป์ โมเดล หรือเครื่องมือ ทำให้ระบบดีขึ้นหรือแย่ลง ฝั่งทีมเดเวลอปเปอร์ ถ้าเอเจนต์ถูกใช้เขียนโค้ดหรือสร้างงานอัตโนมัติมากขึ้น ปริมาณงานจะพุ่งจนคนรีวิวตามไม่ทัน ข้อมูลชี้ว่าทีมที่ใช้ AI หนักทำงานเสร็จมากขึ้น 21 เปอร์เซ็นต์ และรวมพีอาร์มากขึ้น 98 เปอร์เซ็นต์ แต่เวลาตรวจพีอาร์เพิ่มขึ้นถึง 91 เปอร์เซ็นต์ และ 31 เปอร์เซ็นต์ของพีอาร์ถูกเมิร์จโดยไม่มีรีวิวเลย นั่นคือเรากำลังได้สปีดแต่กำลังหลุดการควบคุม การตั้งเกตปล่อยงานตามความจุรีวิวของคนจึงไม่ใช่เรื่องหรู แต่เป็นเกราะกันโปรดักชันแตก
ออกแบบทีมให้อยู่กับเอเจนต์ได้ โดยไม่หมดแรงรีวิว
เมื่อเอเจนต์เริ่มเข้ามาในการพัฒนาโค้ด หลายทีมเจอช่องว่างระหว่างรอเอเจนต์ทำงาน คนเริ่มหลุดโฟกัสจากการจับคู่เขียนโค้ด ไปคุยเรื่องอนาคตงานตัวเองแทน จนทั้งความรู้ร่วมและความสนุกในทีมลดลง ผู้ใช้ AI ทำคะแนนหลังทำงานต่ำลง 17 จุดแม้เวลาทำงานเท่าเดิม ซึ่งสะท้อนแบบตรงๆ ว่าเรากำลังได้ความเร็วแต่กำลังเสียประสบการณ์ งานวิเคราะห์ยังพบว่าโค้ดจาก AI ต้องรอรีวิวนานกว่าของคนถึง 4.6 เท่า ถ้าปล่อยให้จำนวนเอเจนต์โตตามใจ เราจะชนขีดจำกัดการรีวิวของมนุษย์ที่วิจัยชี้ชัดว่าประมาณ 400 บรรทัดต่อชั่วโมงและหมดแรงในราว 60 นาที ทางออกที่เป็นรูปธรรมคือกำหนดจำนวนงานจากเอเจนต์ตามกำลังรีวิวที่แท้จริง แบ่งงานเป็นชุดเล็กที่รีวิวได้หมด และใช้เวลาว่างระหว่างรอเอเจนต์หารือสถาปัตยกรรมหรือดีไซน์โค้ดมากกว่าคุยเรื่องกลัวตกงาน ทีมที่ตั้งวงจร feedback รอบเอเจนต์อย่างมีสติ จะได้ทั้งสปีดและความน่าเชื่อถือโดยไม่เผาตัวเองไปกับรีวิวไม่รู้จบ
