Multi-Tenancy คือปัญหาที่แท้จริงของแพลตฟอร์ม Agent

เดโมของ Agent ส่วนใหญ่ใช้งานได้ดีเพราะมีผู้ใช้เพียงคนเดียว

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

เมื่อคุณเปลี่ยนจากเดโมให้กลายเป็นแพลตฟอร์ม ส่วนที่ยากไม่ใช่เรื่องของ prompt แต่ส่วนที่ยากคือการแยกส่วน (isolation)

ทุกๆ การคิวรีฐานข้อมูล, cache key, stream, การเรียกใช้เครื่องมือ (tool call) และการค้นหาหน่วยความจำ (memory lookup) สามารถพิสูจน์ได้หรือไม่ว่าข้อมูลนั้นเป็นของ tenant ใด? หากมีแม้เพียงอย่างเดียวที่ทำไม่ได้ นั่นหมายความว่าคุณกำลังเผชิญกับความเสี่ยงที่ข้อมูลจะรั่วไหล

หลายทีมมุ่งเน้นไปที่การเลือกโมเดลหรือคุณภาพของหน่วยความจำ แต่พวกเขาลืมตั้งคำถามว่าข้อมูลและค่าใช้จ่ายของ tenant หนึ่งจะถูกแยกออกจากอีก tenant หนึ่งอย่างชัดเจนหรือไม่

การแยกส่วน (Isolation) ไม่ใช่สิ่งที่คุณจะมาเพิ่มในตอนท้าย แต่มันคือโครงสร้างหลักของแพลตฟอร์มคุณ

ในการสร้างแพลตฟอร์ม Agent ที่ใช้งานได้จริง ให้มองหากลไกเหล่านี้:

  • Request context ที่มีการระบุประเภท (typed) ซึ่งถูกส่งต่อไปยัง graph
  • การเข้าถึงแบบจำกัดขอบเขต (scoped access) ในทุกๆ จุดเชื่อมต่อ (boundary)
  • การทดสอบที่สามารถตรวจพบการรั่วไหลของข้อมูลระหว่าง tenant ก่อนที่จะกลายเป็นอุบัติการณ์จริง

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

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

ทุกการทำงานที่เกี่ยวข้องกับข้อมูล, เครื่องมือ หรือหน่วยความจำ จะต้องถูกกำหนดขอบเขตตาม tenant ก่อนที่โมเดลจะเริ่มทำงาน นี่คือมาตรฐานความปลอดภัยของ backend ที่นำมาประยุกต์ใช้กับ agent runtime

ขั้นตอนที่นำไปใช้ได้จริงสำหรับสถาปัตยกรรมของคุณ:

  • ใช้ RequestContext object เพียงอันเดียวแทนการใช้พารามิเตอร์แบบกระจัดกระจาย
  • กำหนดให้ทุกจุดเชื่อมต่อ (boundary) ต้องยอมรับ context มิฉะนั้นให้ถือว่าล้มเหลว
  • กรองรายการเครื่องมือ (tool catalogs) ก่อนที่โมเดลจะมองเห็น
  • ใช้ vector filtering เป็นส่วนหนึ่งที่จำเป็นของการทำ authorization
  • ตรวจสอบให้แน่ใจว่า traces และ logs ใช้ tenant tags ที่ไม่ระบุตัวตน (opaque) แทนการใช้ข้อมูลที่ละเอียดอ่อน

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

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

เริ่มต้นด้วยการไล่สายการทำงาน (trace) ของ agent flow หนึ่งรายการ ติดตาม tenant context ตั้งแต่ HTTP request ไปจนถึงการเรียกใช้เครื่องมือครั้งสุดท้าย ระบุทุกจุดที่ context นั้นถูกคัดลอกหรือถูกละเลย แผนผังนั้นแหละคือจุดที่ความเสี่ยงที่แท้จริงของคุณซ่อนอยู่

Source: https://dev.to/luffy_14/multi-tenancy-is-the-real-agent-platform-problem-1dh2

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