ความเสี่ยงของ progressive summarization กับ case facts block
แนวคิด
เมื่อบทสนทนายืดยาวขึ้นเรื่อย ๆ ทุกเทิร์นจะสะสมอยู่ใน context window จนเข้าใกล้ขีดจำกัด วิธีจัดการที่นิยมคือ progressive summarization คือย่อประวัติเก่าให้สั้นลงเพื่อคืนพื้นที่ token แต่การย่อมีความเสี่ยงเฉพาะตัวที่ต้องระวัง มันมักกลืนค่าที่แม่นยำ เช่น จำนวนเงิน เปอร์เซ็นต์ วันที่ และสิ่งที่ลูกค้าพูดว่าคาดหวังไว้ ให้กลายเป็นข้อความคลุมเครือ
ลองนึกถึง agent ฝ่ายซัพพอร์ตที่คุยกับลูกค้ามายี่สิบเทิร์น พอย่อประวัติ ประโยค "ลูกค้าขอคืนเงิน 1,240 บาท ภายในวันที่ 15 กรกฎาคม เพราะได้รับของชำรุด" อาจถูกย่อเหลือแค่ "ลูกค้าขอคืนเงินบางส่วนเรื่องของชำรุด" ตัวเลข วันที่ และเงื่อนไขที่เจาะจงหายไปหมด เทิร์นถัดไป agent จึงตัดสินใจผิดหรือถามซ้ำในสิ่งที่ลูกค้าเคยบอกไปแล้ว
ทางแก้คือแยกข้อเท็จจริงของเคสออกมาเป็นบล็อกแยกต่างหาก เรียกว่า case facts block ดึงค่าที่เป็น transactional fact เช่น ยอดเงิน วันที่ เลขออร์เดอร์ และสถานะ ออกมาเก็บเป็นโครงสร้างชัดเจน แล้วแนบบล็อกนี้เข้าไปในทุก prompt โดยไม่ให้มันถูกนำไปย่อรวมกับประวัติสนทนา ประวัติที่เป็นบทสนทนาทั่วไปย่อได้ตามสบาย แต่ตัวเลขและเงื่อนไขต้องอยู่ครบเสมอ
ทำไมสำคัญ
เอกสารของ Anthropic อธิบายว่าทุกอย่างในคำขอนับรวมเข้า context window ทั้ง system prompt ทุกข้อความ ผลลัพธ์ tool และเอกสารที่แนบมา และเมื่อ token สะสมมากขึ้น ความแม่นยำกับการเรียกคืนข้อมูลจะเสื่อมลง ปรากฏการณ์นี้เรียกว่า context rot การเลือกว่าจะเก็บอะไรไว้ใน context จึงสำคัญพอ ๆ กับปริมาณพื้นที่ที่มี
สำหรับบทสนทนายาว docs แนะนำ server-side compaction เป็นกลไกหลัก คือให้ฝั่ง API สรุปประวัติเก่าให้อัตโนมัติเมื่อใกล้ขีดจำกัด แต่จุดที่ต้องเข้าใจให้ลึกคือ การสรุปแบบอัตโนมัติก็คือการย่อรูปแบบหนึ่ง มันช่วยให้สนทนาต่อไปได้เกินขีดจำกัด แต่ไม่รับประกันว่าตัวเลขหรือวันที่ทุกตัวจะรอดผ่านการสรุปมาแบบไม่เพี้ยน ค่าที่พลาดไม่ได้จึงไม่ควรฝากไว้กับการสรุปเพียงอย่างเดียว
นี่คือเหตุผลที่ case facts block ต้องอยู่ "นอก" ประวัติที่ถูกย่อ ถ้าคุณเก็บยอดเงินไว้เป็นข้อความในบทสนทนาเฉย ๆ มันจะถูกย่อไปพร้อมทุกอย่าง แต่ถ้าคุณสกัดมันออกมาเป็นเลเยอร์บริบทแยก แล้วป้อนกลับเข้าไปในทุกคำขอแบบครบถ้วน ค่านั้นจะไม่มีวันหายแม้ประวัติจะถูกย่อกี่รอบก็ตาม แนวคิดเดียวกันนี้ใช้กับเซสชันหลายประเด็นได้ด้วย โดยเก็บ order ID ยอดเงิน และสถานะของแต่ละประเด็นไว้ในเลเยอร์บริบทที่คงอยู่ตลอด
หมายเหตุการสอบ: exam guide v0.2 พูดถึงเทคนิคนี้ในชื่อ "case facts block" ส่วน docs ปัจจุบันเรียกกลไกฝั่งเซิร์ฟเวอร์ที่คอยสรุปประวัติว่า compaction สองอย่างนี้ไม่ใช่สิ่งเดียวกันแต่ทำงานเสริมกัน คือ compaction เป็นตัวสรุปฝั่งเซิร์ฟเวอร์ ส่วน case facts block เป็นเทคนิคตรงข้ามที่จงใจวางค่าสำคัญไว้ "นอก" ส่วนที่ถูก compaction สรุป เพื่อไม่ให้ค่าที่พลาดไม่ได้หลุดหายไปกับการย่อ
ตัวอย่าง
{
"case_facts": {
"order_id": "TH-88231",
"refund_amount_thb": 1240,
"deadline": "2026-07-15",
"reason": "damaged_on_arrival",
"customer_expectation": "full refund, not store credit"
},
"summarized_history": "ลูกค้าติดต่อเรื่องของชำรุด คุยเรื่องขั้นตอนคืนสินค้าไปแล้ว"
}
ประวัติสนทนาถูกย่อได้ แต่ case_facts ยังครบทุกค่า agent เทิร์นถัดไปจึงไม่ต้องเดาและไม่ถามซ้ำ
เช็คความเข้าใจ
progressive summarization มีความเสี่ยงกับข้อมูลประเภทใดเป็นพิเศษ และเพราะอะไร
ทำไม case facts block จึงต้องอยู่นอกประวัติที่ถูกย่อ