งานวิจัยชี้: พอ agent ย่อ context คำสั่งที่คุณสั่งไว้หายไป 83% — "ถามก่อนทำ" รอดแค่ 17%

นี่คือปัญหาที่คนใช้ AI agent ทำงานยาว ๆ น่าจะเคยเจอโดยไม่รู้ตัว: คุณสั่งไว้ตอนต้นเซสชันว่า “ยืนยันกับฉันก่อนทุกครั้งที่จะลบอะไร” agent ก็ทำตามดี จนกระทั่งบทสนทนายาวจน context เต็ม ระบบย่อบทสนทนาเก่าเป็นสรุปสั้น ๆ แล้วทำงานต่อ — และหลังจากนั้น agent ก็ลบไฟล์ให้เลยโดยไม่ถาม

งานวิจัย Lost in Compaction: Evaluating Side-Constraint Loss under Context Compaction จากทีม Pennsylvania State University (Zhiqi Wang, Yichi Zhang, Dongwon Lee, Yuchen Yang) วัดปรากฏการณ์นี้อย่างเป็นระบบเป็นครั้งแรก คำตอบสั้น ๆ คือ คำสั่งกำกับพฤติกรรมเหลือรอดจากการย่อ context เฉลี่ยเพียง 17%

หมายเหตุเรื่องวันที่อย่างตรงไปตรงมา: พรีปรินต์นี้ขึ้น arXiv ตั้งแต่ 31 กรกฎาคม 2026 เราไม่ได้รายงานตอนนั้น และเพิ่งมาถูกพูดถึงในวงกว้างสัปดาห์นี้ — เขียนถึงในฐานะของที่เราตกหล่น ไม่ใช่ข่าวใหม่วันนี้

Session Constraint คืออะไร และทำไมมันเปราะ

ทีมวิจัยตั้งชื่อคำสั่งประเภทนี้ว่า Session Constraint (SC) — คำสั่งที่ (1) ไม่ใช่ตัวงาน (2) มีไว้กำกับ วิธี ที่โมเดลทำงานตลอดเซสชันที่เหลือ และ (3) ไม่มีความหมายนอกเซสชันนั้น

ตัวอย่างที่เปเปอร์ใช้: “อีเมลบอกซาร่าว่าฉันจะไปสาย แต่จากนี้ไปให้ฉันดูร่างก่อนส่งอะไรทุกครั้ง” ประโยคแรกคืองาน ประโยคหลังคือ SC

ความเปราะเกิดจากธรรมชาติของ compactor เอง มันถูกออกแบบมาให้รักษา ความต่อเนื่องของงาน — เป้าหมาย สถานะ และขั้นถัดไป เพื่อให้ทำงานต่อได้ ดังนั้นสิ่งที่ compactor มองว่า “เกี่ยวกับงาน” จะรอด ส่วน SC ซึ่งมักถูกพูดแค่ครั้งเดียว ฝังอยู่ในประโยคที่เน้นงาน และผู้ใช้ทั่วไปมักพูดเป็นความชอบเบา ๆ ไม่ใช่คำสั่งเข้ม จึงถูกอ่านว่า “ไม่จำเป็น” และถูกตัดทิ้ง ผลคือความล้มเหลวแบบเงียบ ๆ: งานเดินต่อ แต่เดินผิดวิธีที่ผู้ใช้สั่งไว้

ทีมแบ่ง SC เป็นห้าประเภทตามสิ่งที่มันผูก — Action (ทำอะไรได้), Information (เปิดเผยอะไรได้), Process (ไปถึงคำตอบอย่างไร), Preference (เลือกคำตอบแบบไหนเมื่อดีเท่ากัน) และ Output (รูปแบบข้อความ)

COMPINT: วัดยังไง และได้ตัวเลขอะไร

ชุดประเมิน COMPINT สร้างบทสนทนายาว 100K โทเค็น (ราว 80% ของหน้าต่าง 128K เพื่อจำลองจังหวะที่ compaction ถูกทริกเกอร์จริง) จากสามสภาพแวดล้อม: WildChat (แชตหลายเทิร์นของผู้ใช้จริง), Hermes Agent (เส้นทางการทำงานของ agent ที่เรียกเครื่องมือและเขียนโค้ด) และ OpenResearcher (งานวิจัยยาวแบบเทิร์นเดียวที่ agent วนหาข้อมูลเอง) จากนั้นฉีด SC เข้าไป 15 แบบ × 50 บริบท = 750 เคสต่อหนึ่งเงื่อนไข แล้ววัดสองอย่าง: SC ยังอยู่ในสรุปไหม (Retention) และโมเดลยังทำตามไหมเมื่อถูกทดสอบด้วยคำถามปลายทาง (Compliance)

ผลลัพธ์บนตัวย่อ 6 แบบ:

• Recent-5 (เก็บ 5 เทิร์นล่าสุด) และ LLMLingua-2 ได้ 0% ทั้งสามชุดข้อมูล — วิธีย่อที่ไม่ใช้ LLM ทำ SC หายเกลี้ยง
• ตัวย่อที่ใช้โมเดลเปิดแกว่งตามพรอมป์ต์และชุดข้อมูลอย่างรุนแรง: บน Hermes Agent, gpt-oss-120b ได้ 36.3% เมื่อใช้พรอมป์ต์แบบ pi-mono (พรอมป์ต์ที่ OpenClaw ใช้) แต่เหลือ 18.5% เมื่อใช้พรอมป์ต์แบบ Anthropic ส่วน Gemma 4 E4B ได้ 12.5% และ Qwen3-30B-A3B ได้เพียง 2.1%
• บน WildChat ซึ่งเป็นชุดที่ยากที่สุด (หลายเทิร์น หัวข้อเปลี่ยนบ่อย) ตัวย่อโมเดลเปิดแทบทุกตัวอยู่ในช่วง 0–3.3%
• GPT-5.4-mini ทำได้ดีที่สุดแต่ก็ไม่น่าไว้ใจ — สูงถึง 98.0% บน OpenResearcher แต่ร่วงเหลือ 6.7% บน WildChat ด้วยพรอมป์ต์เดียวกัน

ที่สำคัญไม่แพ้กันคือฝั่งพฤติกรรม: compactor เกือบทุกตัว ทำให้การทำตามคำสั่งแย่ลงกว่าการไม่ย่อเลย และตัวเลขอื่นที่น่าสนใจ — การย่อทำให้บริบทสั้นลงเฉลี่ย 182 เท่า โดยความยาวเอาต์พุตของ compactor แทบไม่ขึ้นกับความยาวอินพุต (อินพุตโต 10 เท่า เอาต์พุตโตแค่ 0.84–1.28 เท่า) นั่นอธิบายว่าทำไมยิ่งบริบทยาว SC ยิ่งหาย — ที่ 10K โทเค็น retention บน Hermes Agent อยู่ราว 90% แล้วลดลงเรื่อย ๆ ตามความยาว

ปัจจัยฝั่งผู้ใช้ก็มีผล: SC ที่อยู่ ท้ายบริบท รอดดีกว่าอยู่ต้น และการ พูดซ้ำหลายจุด ช่วยได้ — แต่ไม่มีการตั้งค่าใดที่ทำให้ปลอดภัยจริง แม้แต่ผลดีที่สุดรายประเภท (Preference ภายใต้ gpt-oss pi-mono ที่ 36%) ก็ยังทำคำสั่งหายไปเกือบสองในสาม

ทางแก้ที่ทีมเสนอ: แยกโมดูลออกมาต่างหาก

ข้อสรุปเชิงสถาปัตยกรรมของเปเปอร์คือ การแก้พรอมป์ต์ของ compactor ให้เก่งขึ้นไม่พอ ต้องแยกหน้าที่ออกมา ทีมจึงเสนอ SC-aware extractor ที่ทำงานคู่ไปกับ compactor: ใช้โมเดลเล็ก Qwen3.5-9B อ่านเฉพาะ เทิร์นของผู้ใช้ ทีละเทิร์น ถ้าเจอ SC ก็ต่อเข้ารายการที่สะสมไว้ แล้วเอารายการนั้นแปะท้ายบริบทที่ย่อแล้ว

ผลคือ retention 95.6% บน Hermes Agent, 95.1% บน OpenResearcher และ 90.3% บน WildChat — ชนะทุก compactor โอเพนซอร์สและชนะ GPT-5.4-mini ถึง 62 จุดบน WildChat โดย ไม่ต้องเทรนอะไรเลย และเร็วพอใช้งานจริง: 0.03 วินาทีต่อบริบท 100K บน OpenResearcher (มีเทิร์นผู้ใช้เดียว) และสูงสุด 12.93 วินาทีบน WildChat (เฉลี่ย 257 เทิร์นผู้ใช้) โค้ดทั้งชุดประเมินและตัว extractor อยู่บน GitHub ภายใต้ใบอนุญาต MIT

มุมมอง AI Curator

เปเปอร์นี้จับจุดที่ผมคิดว่าเป็น ช่องโหว่เชิงระบบที่ถูกมองข้ามที่สุดของยุค agent เพราะทุกวันนี้แทบทุกฮาร์เนสมี compaction เป็นค่าเริ่มต้น — Claude Code, OpenClaw, Codex, agent framework แทบทุกตัว — และผู้ใช้ถูกสอนมาว่า “สั่งเป็นภาษาคนได้เลย” แต่ไม่มีใครบอกว่าคำสั่งที่สั่งไปนั้น มีอายุเท่ากับหน้าต่าง context ไม่ใช่เท่ากับเซสชัน

สิ่งที่ทำให้เรื่องนี้ร้ายกว่าปัญหาคุณภาพทั่วไปคือ ทิศทางของความล้มเหลว คำสั่ง SC ส่วนใหญ่ที่ผู้ใช้พูดคือคำสั่งเชิงเบรก — “ถามก่อน”, “อย่าลบ”, “อย่าส่งออกไปข้างนอก”, “ให้ฉันดูก่อน” เมื่อเบรกหาย ระบบไม่ได้หยุดทำงาน แต่ เร่งขึ้น ในทิศที่ผู้ใช้พยายามห้าม และมันเงียบ — ไม่มี error ไม่มี log ว่า “คำสั่งถูกตัดทิ้ง” ผู้ใช้จะรู้ตัวก็ต่อเมื่ออีเมลถูกส่งไปแล้ว ในบริบทองค์กรไทยที่กำลังเอา agent ไปต่อกับระบบจริง — ERP, ระบบเวชระเบียน, ระบบ CRM ที่มีข้อมูลส่วนบุคคลตาม PDPA — นี่ไม่ใช่แค่บั๊กด้าน UX แต่เป็นเรื่องการกำกับดูแล และคำถามที่ผู้ตรวจสอบจะถามคือ “คุณพิสูจน์ได้ไหมว่าเงื่อนไขที่ผู้ใช้กำหนดยังมีผลอยู่ตอนที่ระบบลงมือ”

อีกจุดที่ทีมในภูมิภาคนี้ควรอ่านให้ละเอียดคือ ตัวเลขของโมเดลเปิดขนาดเล็ก Qwen3-30B-A3B ได้ 2.1% และ Gemma 4 E4B ได้ 12.5% บนชุดที่ง่ายที่สุด นี่คือโมเดลที่ทีมประหยัดงบนิยมเอามาทำหน้าที่ย่อบทสนทนาพอดี เพราะดูเป็นงานง่าย — แต่ข้อมูลบอกว่ามันคือจุดที่ประหยัดผิดที่ที่สุด ข่าวดีคือทางแก้ที่เปเปอร์เสนอก็เป็นโมเดลเล็กเหมือนกัน (9B) และไม่ต้องเทรน จึงเป็นสถาปัตยกรรมที่ทีมเล็กเอาไปทำเองได้จริงในสัปดาห์เดียว

สิ่งที่ทำได้ทันทีวันนี้โดยไม่ต้องรอใคร: ย้ายคำสั่งกำกับพฤติกรรมออกจากแชต ไปไว้ในที่ที่ไม่ถูกย่อ — ไฟล์ CLAUDE.md หรือ system prompt หรือ permission/hook ของฮาร์เนส สิ่งที่บังคับใช้ด้วยโค้ดไม่หายไปกับ compaction ส่วนสิ่งที่พิมพ์ลงแชตหายได้เสมอ ถัดมา ถ้ายังต้องสั่งกลางเซสชัน ให้ พูดซ้ำหลังทุกครั้งที่เห็นว่าระบบเพิ่งย่อบริบท และวางไว้ท้าย ๆ ตามที่ข้อมูลชี้ และสำหรับคนที่สร้าง agent เอง บทเรียนเชิงออกแบบชัดมาก — อย่าฝากข้อจำกัดด้านความปลอดภัยไว้กับตัวสรุปบทสนทนา เก็บมันไว้ในสถานะแยกที่ต่อท้ายเข้าไปทุกครั้งหลังย่อ ซึ่งก็คือสิ่งที่ extractor ตัวนี้ทำ

แหล่งข่าว

• Lost in Compaction: Evaluating Side-Constraint Loss under Context Compaction — arXiv 2608.11242 (31 ก.ค. 2026)
• ชุดประเมิน COMPINT และโค้ด extractor บน GitHub (MIT)
• รายงานข่าวโดย The Decoder (18 ส.ค. 2026)