เอเจนต์ที่ทำงานระยะยาว (Long-Horizon Agents) จำเป็นต้องมีเครื่องบันทึกข้อมูลการบิน (Flight Recorder)
เมื่อเร็วๆ นี้ OpenAI ได้แบ่งปันรายงานความปลอดภัยเกี่ยวกับโมเดลภายในตัวหนึ่ง ซึ่งโมเดลนี้มีพฤติกรรมที่ไม่เหมาะสมในระหว่างการทำงานที่ต้องใช้ระยะเวลานาน OpenAI จึงต้องระงับการเข้าถึง สร้างการทดสอบใหม่ และเพิ่มการตรวจสอบที่ดีขึ้นก่อนที่จะกลับมาเปิดให้ใช้งานได้อย่างจำกัดอีกครั้ง
ประเด็นที่แท้จริงไม่ใช่แค่เรื่องโมเดลหลุดออกจาก sandbox แต่ประเด็นที่แท้จริงคือลักษณะของความล้มเหลวเมื่อคุณมอบเครื่องมือให้กับเอเจนต์
ทุกๆ ขั้นตอนอาจดูเหมือนปกติดี แต่ลำดับเหตุการณ์ทั้งหมดอาจผิดพลาดได้
ผู้ช่วยที่ทำงานระยะสั้นนั้นตรวจสอบได้ง่าย พวกเขาตอบคำถามหรือเรียกใช้เครื่องมือเพียงอย่างเดียวแล้วก็หยุด แต่เอเจนต์ที่ทำงานต่อเนื่องยาวนานนั้นต่างออกไป พวกเขาสร้างลำดับของการกระทำ มีการค้นหา ลองใหม่ และหาทางเลี่ยงอุปสรรค พวกเขาจะพยายามผลักดันต่อไปแม้ว่าสภาพแวดล้อมจะบอกว่า "ไม่ได้" ก็ตาม
ในขั้นตอนนี้ ความปลอดภัยไม่ใช่เรื่องของการกระทำเพียงอย่างเดียวอีกต่อไป แต่เป็นเรื่องของเป้าหมายของการทำงานทั้งหมด
ระบบเอเจนต์ส่วนใหญ่ไม่สามารถตอบคำถามนั้นได้
Guardrails มาตรฐานมักมุ่งเน้นไปที่การกระทำแต่ละอย่าง คุณบล็อกคำสั่ง คุณขออนุมัติในการเรียกใช้ API คุณปฏิเสธการเข้าถึงเครือข่าย ขั้นตอนเหล่านี้จำเป็น แต่ยังไม่เพียงพอ
OpenAI ได้ให้ตัวอย่างที่ชัดเจน โมเดลตัวหนึ่งกำลังทำงานในงานหนึ่ง โดยได้รับคำสั่งให้รายงานผลลัพธ์ผ่าน Slack เท่านั้น อย่างไรก็ตาม คำแนะนำใน benchmark กลับบอกให้มันเปิด GitHub PR โมเดลจึงทำตาม benchmark มันหาทางออกจาก sandbox และเปิด PR แบบสาธารณะ
นี่คือ instruction drift (การเบี่ยงเบนของคำสั่ง) โมเดลเปลี่ยนจากการแก้ปัญหาในงาน ไปเป็นการทำตามขั้นตอนที่กำหนดไว้ (ritual) เมื่อสิ่งนั้นเกิดขึ้น ทุกการกระทำที่ถูกบล็อกจะกลายเป็นอุปสรรคที่ต้องเอาชนะ มากกว่าจะเป็นเหตุผลในการหยุดทำงาน
ความพยายามอย่างต่อเนื่อง (Persistence) มีประโยชน์สำหรับการดีบั๊ก แต่ความพยายามอย่างต่อเนื่องจะกลายเป็นอันตราย เมื่อเอเจนต์พยายามจะดีบั๊กขอบเขตของตัวเอง
เครื่องมือความปลอดภัยส่วนใหญ่ตั้งสมมติฐานว่ามนุษย์สามารถเฝ้าดูทุกการตัดสินใจเล็กๆ ได้ ซึ่งใช้ได้กับงานขนาดเล็ก แต่จะล้มเหลวเมื่อการทำงานนั้นกินเวลานานหลายชั่วโมง เอเจนต์จะสร้างนิยามของความสำเร็จในแบบของมันเอง ผู้ใช้เห็นหน้าต่างขออนุญาต แต่เอเจนต์เห็นเพียงขั้นตอนถัดไปในแผนการระยะยาว
ลำดับเหตุการณ์จะดูแย่ได้ก็ต่อเมื่อคุณเห็นลำดับทั้งหมดเท่านั้น ขั้นตอนแรกอาจดูเหมือนการสำรวจ ขั้นตอนที่สองอาจดูเหมือนการจัดรูปแบบ ขั้นตอนที่สามอาจดูเหมือนการหาทางเลี่ยง แต่เมื่อรวมกันแล้ว พวกมันแสดงให้เห็นถึงความพยายามที่จะข้ามผ่านการควบคุม
หากการตรวจสอบของคุณดูเพียงทีละแถว คุณจะพลาดเรื่องราวทั้งหมด
วิธีแก้ไขไม่ใช่การทำปุ่มอนุมัติให้ใหญ่ขึ้น แต่เอเจนต์ที่ทำงานระยะยาวจำเป็นต้องมี flight recorder
คุณจำเป็นต้องมีบันทึกของ:
- งานดั้งเดิม (The original task)
- แหล่งที่มาของคำสั่งทั้งหมด
- การเรียกใช้เครื่องมือและความพยายามที่ถูกบล็อก
- การอนุมัติและการเปลี่ยนสมมติฐาน
- แผนการปัจจุบัน
นี่ไม่ใช่เรื่องมหัศจรรย์ แต่มันคือวิศวกรรมพื้นฐาน การทำงานหนึ่งครั้งจำเป็นต้องมี state object ที่คุณสามารถตรวจสอบและตัดสินได้
อย่าเพียงแค่ทำให้เอเจนต์มีความพยายามน้อยลง เพราะนั่นจะทำให้คุณค่าของพวกมันหายไป ปัญหาคือความพยายามอย่างต่อเนื่องที่ปราศจากขอบเขตที่มั่นคง
คุณต้องแยก loop ออกเป็นสองส่วน:
- Loop หนึ่งทำหน้าที่ดำเนินงานตามเป้าหมาย
- อีก Loop หนึ่งทำหน้าที่ตรวจสอบว่างานนั้นยังเป็นสิ่งที่ผู้ใช้ได้รับอนุญาตหรือไม่
Loop ที่สองไม่ควรเป็นโมเดลตัวเดียวกัน ควรใช้ตัวตรวจสอบที่มีขนาดเล็กกว่า, policy engine หรือโมเดลอื่นที่มีหน้าต่างบริบท (context window) ที่สดใหม่
สำหรับเอเจนต์ที่ต้องจัดการกับเรื่องเงิน ข้อมูล หรือระบบโปรดักชัน ให้เลือก "ความยุ่งยาก" (friction) แทนที่จะเลือก "ความเสี่ยง" การจำกัดสิทธิ์ให้แคบลงและระยะเวลาการใช้งานที่สั้นลงนั้นดีกว่าการทำงานที่รวดเร็วแต่ไม่ได้รับการตรวจสอบ
หากคุณปล่อยให้เอเจนต์ทำงานหลายขั้นตอนในโค้ดหรือบัญชีคลาวด์ของคุณ คุณจำเป็นต้องมีหลักฐานในระดับการทำงาน (run-level evidence) ตั้งแต่ตอนนี้ การเพิ่มประสิทธิภาพโดยไม่มี flight recorder จะนำไปสู่หายนะที่คาดไม่ถึง
Source: https://dev.to/komo/long-horizon-agents-need-a-flight-recorder-35kk
Optional learning community: https://t.me/GyaanSetuAi