บริบท ไม่ใช่การควบคุม
ทุกกฎใน prompt ของ agent ของคุณ ล้วนเริ่มต้นจากบั๊ก
มีคนเห็นพฤติกรรมที่ไม่ดี เขียนกฎขึ้นมา แล้วก็ไปต่อ อีกคนก็ทำแบบเดียวกัน คนที่สามเพิ่ม "ห้ามทำ X" เพราะโมเดลเคยทำอะไรแปลก ๆ ในวันอังคาร ไม่มีใครลบอะไรออกเลย
หกเดือนต่อมา agent ใช้ context window ส่วนใหญ่ไปกับการอ่าน rulebook ของตัวเอง มากกว่าคิดถึงงานจริง
นี่คือแนวคิดแบบควบคุม และผมคิดว่านี่คือหนึ่งในข้อผิดพลาดด้านการออกแบบที่ใหญ่ที่สุดที่ทีมต่าง ๆ มักทำเมื่อสร้าง AI agent
ตัวอย่างเล็ก ๆ ที่เผยให้เห็นรูปแบบที่ใหญ่กว่า
เราเคยเจอปัญหาที่ agent ซึ่งถูกเรียกโดย scheduled task กลับสร้าง scheduled task ใหม่ ขึ้นมาจากใน run นั้นเอง กลายเป็น recursion ไม่รู้จบ แถมมีผลกระทบในโลกจริงด้วย
มีสองวิธีในการตอบสนอง
แนวควบคุม: แบนมัน เขียนโค้ดบล็อกไม่ให้ schedule สร้าง schedule เพิ่ม ใส่กฎใน prompt: "ห้ามสร้าง schedule ซ้อนใน schedule" แล้วปล่อยใช้งาน
แนวบริบท: บอก agent ว่ากำลังเกิดอะไรขึ้นจริง ๆ
คุณถูกเรียกโดย scheduled task เวลา 3:00 AM Pacific time Schedule ID: sched_29x8f การ run แบบ scheduled เป็นการดำเนินการแยกเดี่ยวที่มีขอบเขตชัดเจนซึ่งผู้ใช้อนุมัติไว้แต่แรก การสร้าง scheduled task ใหม่จะขยายขอบเขตนั้นเกินกว่าที่ได้รับอนุญาตเดิม
วิธีแรกแก้ไขพฤติกรรมเดียว วิธีที่สองให้ agent เข้าใจสถานการณ์
ตอนนี้ agent สามารถคิดต่อยอดกับคำถามใกล้เคียงได้ เช่น ควรส่งการแจ้งเตือนเวลา 3 AM หรือไม่? ควรสร้างกระบวนการติดตามที่ผู้ใช้ไม่ได้ขอไว้หรือไม่? ควรแก้ไขอะไรที่เกินขอบเขต run เดิมหรือไม่?
ไม่ต้องมีกฎ Agent คิดเองได้
หลายทีมมักเลือกใช้การควบคุม ทั้งที่จริง ๆ แล้วควรใช้บริบท
ความแตกต่างนี้เกิดขึ้นใน prompt ด้วย
ไม่ใช่แค่การบังคับระดับระบบ ความแตกต่างระหว่างบริบทกับการควบคุมมีอยู่ใน prompt ด้วย
Prompt แบบบริบท: เน้นข้อเท็จจริง ความคิดเห็นน้อยที่สุด:
คุณกำลังทำงานเพราะ scheduled task ถูกเรียกเวลา 3:00 AM Beijing time Task ID: sched_29x8f ผู้ใช้อนุมัติ run นี้สำหรับขอบเขตเฉพาะ
Prompt แบบควบคุม: มีความเห็น ชี้นำ:
หลีกเลี่ยงการสร้าง schedule คุณควรแจ้งผู้ใช้ด้วยเครื่องมือ X ห้ามทำ Y เว้นแต่ Z
บางครั้งคำแนะนำแบบชี้นำก็มีประโยชน์ แต่บ่อยครั้งมันเป็นการชดเชยข้อเท็จจริงที่ขาดหายไป และเมื่อเริ่มชดเชยแบบนี้ มันจะกลายเป็นนิสัย
Prompt กลายเป็นระบบราชการได้อย่างไร
นี่คือโหมดล้มเหลวที่ลึกกว่า
ทีมเห็นปัญหาแล้วเพิ่มกฎ แล้วก็เพิ่มอีก และอีก ทุกกฎแก้ปัญหาเฉพาะจุด แต่รวมกันแล้วกลายเป็นระบบที่เต็มไปด้วย ตัวแทน
Bezos อธิบายรูปแบบนี้ในจดหมายผู้ถือหุ้นปี 2016: กระบวนการที่ดีคือเครื่องมือให้คุณบริการลูกค้าได้ดีขึ้น แต่ถ้าไม่ระวัง กระบวนการจะกลายเป็นเป้าหมายแทน
นั่นคือสิ่งที่เกิดขึ้นในระบบ agent
กฎไม่ใช่เป้าหมาย กฎเป็นตัวแทนของผลลัพธ์ที่คุณต้องการ และตัวแทนเหล่านี้จะทับถมกัน กฎหนึ่งสร้าง edge case ที่ต้องมีกฎเพิ่ม ไม่นาน agent ก็ต้องคิดผ่านชั้นของคำสั่งที่สะสมมาด้วยเหตุผลในอดีตที่ไม่มีใครจำได้
ในองค์กรมนุษย์ สิ่งนี้กลายเป็นระบบราชการ ในระบบ agent มันกลายเป็น prompt ที่เต็มไปด้วยรอยแผลเป็น
ข้อเท็จจริงคงอยู่ ความคิดเห็นเสื่อมสลาย
ข้อเท็จจริงอย่าง "run นี้ถูกเรียกโดย scheduled task เวลา 3 AM" มีความมั่นคง มันยังคงเป็นจริงไม่ว่าโมเดลไหนจะอ่าน: Claude, GPT, Gemini หรืออะไรก็ตามที่ออกใหม่
ข้อความอย่าง "คุณควรหลีกเลี่ยงการสร้าง sub-schedule" เปราะบาง ขึ้นกับการตีความ อาจช่วยในบางสถานการณ์แต่ผิดพลาดเงียบ ๆ ในอีกกรณี
เมื่อคุณเปลี่ยนโมเดล ทุกความคิดเห็นใน prompt คือกับระเบิดที่อาจระเบิดได้ โมเดลใหม่มีแนวโน้มการให้เหตุผลต่างกัน และ "หลีกเลี่ยง" ที่คุณปรับจูนไว้อาจมีความหมายต่างไปโดยสิ้นเชิง
แต่ข้อเท็จจริงที่ยึดโยงกับสภาพแวดล้อม สิทธิ์ ขอบเขต และข้อจำกัด มักจะใช้ได้กับทุกโมเดลและ edge case นั่นคือเหตุผลที่ข้อเท็จจริงเหมาะกับการสร้างระบบมากกว่า
กับดักนิสัยโมเดล
นี่อาจเป็นรูปแบบที่แย่ที่สุดของปัญหาการควบคุม: ทีมเปลี่ยนข้อบกพร่องชั่วคราวของโมเดลให้กลายเป็นโครงสร้างถาวรของระบบ
โมเดลมีพฤติกรรมไม่ดีในบางกรณี ทีมจึงเพิ่ม guardrail: patch ใน prompt, เช็คโค้ด, หรือ branch แปลก ๆ ที่มีไว้กันความล้มเหลวเฉพาะจุด
patch นั้นคือการเดิมพันว่าความผิดปกติจะยังอยู่ ซึ่งแทบไม่เคยเป็นจริง
สามเดือนต่อมา โมเดลเปลี่ยน พฤติกรรมเดิมหายไป แต่ patch ยังอยู่ ไม่มีใครอยากลบ เพราะอาจมีเหตุผลที่มันถูกเพิ่มไว้
นี่คือวิธีที่ system prompt กลายเป็น legacy code
เรามองเห็นอันตรายนี้ได้ง่ายเมื่อพูดในเชิงนามธรรม แต่ในทางปฏิบัติ การ patch แนวโน้มการให้เหตุผลของ Sonnet ใน prompt ซ้ำ ๆ ก็คือรูปแบบเดียวกันในอีกมุม
การบันทึกพฤติกรรมระบบที่มั่นคงมีคุณค่า การ patch แนวโน้มโมเดลคือการวิ่งบนลู่วิ่ง โมเดลจะเปลี่ยนเร็วกว่าที่คุณจะตาม patch ทัน
กรณีทดสอบที่ดี: Permission Denied
คุณจะเห็นความแตกต่างนี้ชัดเจนในเครื่องมือวิเคราะห์ เมื่อ agent เจอ permission error:
แนวควบคุม:
TOKEN หายไป รัน "zero permissions request gmail.send" เพื่อแก้ไข
ตรงไปตรงมา แต่ agent ไม่ได้เรียนรู้อะไรเลย ครั้งหน้าถ้าเจอ permission error แบบอื่นก็ยังติดอยู่
แนวบริบท:
process.env.GMAIL_TOKEN → มีอยู่ zero connectors inspect gmail → เชื่อมต่อแล้ว zero permissions inspect gmail.send → ถูกปฏิเสธ
ตัวเลือก:
- ขออนุมัติจากผู้ใช้สำหรับ gmail.send
- ใช้เส้นทางที่ได้รับอนุญาตอยู่แล้วถ้ามี
ตอนนี้ agent รู้แล้วว่า token มีอยู่ ตัวเชื่อมต่อใช้งานได้ และสิทธิ์เฉพาะถูกปฏิเสธ มันเข้าใจสถานะของระบบและสามารถคิดกับสถานการณ์ใหม่ ๆ ที่คนเขียนกฎไม่เคยคาดคิด
หลักคิด
นี่คือสิ่งที่ผมกลับมาทบทวนเสมอ:
ทุกครั้งที่คุณกำลังจะเขียน "ห้าม" "หลีกเลี่ยง" หรือ "อย่า" ใน prompt หยุดก่อน ถามตัวเองว่ากฎนี้กำลังชดเชยข้อเท็จจริงอะไรที่ขาดอยู่?
มักจะมีข้อเท็จจริงที่ขาดหาย Agent ไม่เข้าใจว่าสภาพแวดล้อมเป็นอย่างไร ผู้ใช้อะไรอนุมัติไว้ การกระทำใดที่ย้อนกลับไม่ได้ หรือ run นี้ต่างจากแชทปกติอย่างไร
เขียนข้อเท็จจริงนั้นลงไป แล้วลบกฎทิ้ง
บางครั้งคุณยังต้องการข้อจำกัด โดยเฉพาะกับการกระทำที่ทำลายล้าง การเคลื่อนย้ายเงิน หรือขอบเขตความปลอดภัย การควบคุมที่เข้มงวดยังสำคัญ
แต่กฎใน prompt หลายข้อไม่ใช่ขอบเขตที่แท้จริง พวกมันคือการชดเชยความเข้าใจที่ขาดหาย และสิ่งเหล่านี้เองที่สะสมและเสื่อมสลาย
เป้าหมาย
เป้าหมายไม่ใช่ agent ที่ท่องเช็กลิสต์
เป้าหมายคือ agent ที่เข้าใจสถานการณ์ของตัวเองดีพอจะตัดสินใจได้ดีภายใต้ขอบเขตที่ชัดเจน
แนวคิดหนึ่งควบคุมพฤติกรรมด้วยการซ้อนกฎ อีกแนวคิดปรับปรุงพฤติกรรมด้วยการทำให้โลกเข้าใจง่ายขึ้น
แนวแรกนำไปสู่ระบบราชการ แนวหลังนำไปสู่ความเข้าใจ
สร้างบริบท ลบรอยแผลเป็น ส่ง agent ที่คิดเองได้
