การสร้าง AI Agent Playground ก่อนนำไปใช้งานจริง (Production)

ครั้งหนึ่ง coding agent เคยรันสคริปต์ทำความสะอาดข้อมูลกับสิ่งที่มันคิดว่าเป็นฐานข้อมูล staging แต่จริงๆ แล้วมันคือ production เอเจนต์ตัวนั้นได้ลบคำสั่งซื้อของลูกค้าไปถึง 4 เดือน เพราะมันทำตามคำสั่งทุกประการแต่ใช้ข้อมูลประจำตัว (credentials) ที่ผิดพลาด

ความล้มเหลวนี้ไม่ใช่เหตุผลที่จะหลีกเลี่ยงการใช้เอเจนต์ แต่มันคือเหตุผลที่เราต้องสร้าง playground ขึ้นมา

คุณคงไม่ให้สิทธิ์เข้าถึงฐานข้อมูล production แก่วิศวกรใหม่ตั้งแต่วันแรก คุณจะให้สภาพแวดล้อม staging, สิทธิ์การเข้าถึงแบบอ่านอย่างเดียว (read-only) และงานที่มีการควบคุม เอเจนต์ก็ต้องการการเตรียมความพร้อม (onboarding) แบบเดียวกัน พวกมันสามารถดำเนินการได้เป็นพันครั้งต่อนาที ดังนั้นต้นทุนของการข้ามขั้นตอนการใช้ playground จึงสูงกว่าเป็นพันเท่า

Playground ที่แท้จริงต้องทำสามสิ่งนี้:

  • ให้เอเจนต์รันวงจรการตัดสินใจ (decision loop) ได้อย่างเต็มรูปแบบ
  • ป้องกันไม่ให้ผลกระทบข้างเคียง (side effects) ทั้งหมดส่งผลถึงระบบจริง
  • บันทึกทุกอย่างเพื่อการตรวจสอบ

อย่าทดสอบแค่ prompt การทดสอบ prompt คือการถามคำถามและอ่านคำตอบ แต่พฤติกรรมของเอเจนต์คือลำดับของการเรียกใช้เครื่องมือ (tool calls) ความล้มเหลวที่แท้จริงมักเกิดขึ้นระหว่างวงจรเมื่อเครื่องมือส่งข้อมูลที่ไม่คาดคิดกลับมา

คุณไม่จำเป็นต้องทำ sandbox ให้กับโมเดล แต่คุณต้องทำ sandbox ให้กับตัวดำเนินการ (executor)

สร้างจุดเชื่อมต่อ (seam) ในจุดที่การเรียกใช้เครื่องมือเปลี่ยนเป็นการกระทำ ใช้ playground executor ที่ใช้ mock แทนที่จะเป็น executor จริง วงจรของเอเจนต์ไม่ควรจะรู้ถึงความแตกต่างนี้ หากเอเจนต์ของคุณเรียกใช้ database client โดยตรง คุณจะไม่มีจุดเชื่อมต่อและไม่มีความปลอดภัยเลย

ทดสอบสามด้านที่เฉพาะเจาะจง:

  • พฤติกรรม (Behavior): เอเจนต์เลือกเครื่องมือที่ถูกต้องตามลำดับที่ควรจะเป็นหรือไม่?
  • การเรียกใช้เครื่องมือ (Tool calls): อาร์กิวเมนต์ถูกต้องและอยู่ในขอบเขตที่ปลอดภัยหรือไม่?
  • รูปแบบความล้มเหลว (Failure modes): จะเกิดอะไรขึ้นเมื่อ API หมดเวลา (timeout) หรือส่งข้อมูลขยะกลับมา?

Mock ที่ประสบความสำเร็จเสมอไม่ได้ช่วยสอนอะไรเอเจนต์เลย Playground ของคุณต้องยอมให้คุณฉีดความล้มเหลว (inject failures) เช่น network timeout หรือข้อมูลที่ผิดรูปแบบ (malformed data) เข้าไปได้ นี่คือวิธีที่คุณจะดูว่าเอเจนต์จะพยายามใหม่ (retry) อย่างสมเหตุสมผล หรือเริ่มเกิดอาการหลอน (hallucinating)

หากเอเจนต์ของคุณมีการรันโค้ด คุณต้องมีการแยกส่วน (isolation) ที่แข็งแกร่ง ใช้ microVMs สำหรับโค้ดที่ไม่น่าเชื่อถือ อย่าเริ่มด้วยคอนเทนเนอร์ธรรมดาเพียงเพราะมันง่าย การตั้งค่าที่ง่ายเกินไปอาจนำไปสู่เหตุการณ์ด้านความปลอดภัยที่ร้ายแรงได้

จำไว้ว่าเอเจนต์มีความไม่แน่นอน (non-deterministic) การทดสอบที่ผ่านเพียงครั้งเดียวไม่ได้หมายความว่าเอเจนต์นั้นเชื่อถือได้ คุณต้องรันงานเดิมซ้ำหลายๆ ครั้ง หากเอเจนต์ผ่าน 7 จาก 10 ครั้ง มันจะล้มเหลวกับผู้ใช้จริงประมาณ 30% ความสม่ำเสมอ (consistency) คือตัวชี้วัดที่สำคัญที่สุดของคุณ

สุดท้าย จงป้องกันการโจมตีผ่านผลลัพธ์ของเครื่องมือ (adversarial tool outputs) เอเจนต์จะปฏิบัติกับข้อมูลจากเครื่องมือเหมือนเป็นคำสั่ง ผู้ใช้ที่ประสงค์ร้ายอาจใส่ prompt injection ลงในฐานข้อมูลเพื่อชี้นำเอเจนต์ จงทดสอบเอเจนต์ของคุณโดยการป้อนข้อมูลที่เป็นอันตราย (hostile payloads) ใน playground

สร้างเส้นทางการเลื่อนระดับ (graduation path) ไม่ใช่แค่ปุ่มกดเริ่มงาน (launch button):

  • เริ่มต้นด้วย mock และการทำ sandboxing อย่างเต็มรูปแบบ
  • ทดสอบความสม่ำเสมอจากการรันหลายๆ ครั้ง
  • ทดสอบกับข้อมูลนำเข้าที่เป็นอันตราย (adversarial inputs)
  • เปลี่ยนไปใช้โหมด dry-run กับข้อมูลที่มีโครงสร้างเหมือน production
  • จากนั้นจึงค่อยให้สิทธิ์การเข้าถึงแบบจำกัดขอบเขต (scoped), มีการควบคุม (gated) และมีการตรวจสอบ (monitored)

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

Source: https://dev.to/nazar_boyko/building-an-ai-agent-playground-before-giving-it-production-access-4glh

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