หน้าต่างบริบทของ LLM agent: อะไรเข้าไปในนั้น และทำไม agent ถึงลืมกฎ

หน้าต่างบริบทของ LLM คืออะไร

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

ขนาดของหน้าต่างวัดเป็นโทเคน ซึ่งคือชิ้นส่วนของคำ สำหรับภาษารัสเซียหรือไทย โทเคนโดยเฉลี่ยมักสั้นกว่าภาษาอังกฤษ ดังนั้นคำสั่งเดียวกันอาจกินโทเคนมากกว่า โมเดลสมัยใหม่มีหน้าต่างหลายแสนโทเคน ดูเหมือนว่าจะพอสำหรับทุกอย่าง แต่ในทางปฏิบัติพื้นที่ของ agent หมดเร็วกว่าที่คาด และคุณภาพการทำงานลดลงเร็วกว่านั้นอีก

อะไรเข้าไปในหน้าต่างบริบทของ agent

Agent สำหรับการเขียนโปรแกรมมีแหล่งข้อมูลหลักเพียงสามแหล่ง ได้แก่ system prompt ที่อธิบายงาน เนื้อหาของไฟล์ที่มันอ่าน และผลลัพธ์ของเครื่องมือที่มันเรียก ทั้งสามอยู่ในหน้าต่างเดียวกันและแย่งพื้นที่กัน

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

ทำไม agent ลืมกฎในเซสชันยาว

คำบ่นที่พบบ่อยคือ ตอนต้นเซสชัน agent ทำตามกฎใน CLAUDE.md อย่างระมัดระวัง แต่ผ่านไปหนึ่งชั่วโมงมันเริ่มฝ่าฝืนกฎเหล่านั้น จริงๆ แล้วมันไม่ได้ "ลืม" ตามความหมายตรงตัว ข้อความของกฎยังอยู่ในหน้าต่าง ปัญหาคือวิธีที่โมเดลกระจายความสนใจไปบนข้อความยาว

Lost in the middle

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

สัดส่วนของกฎในหน้าต่างลดลง

ในเซสชันใหม่ คำสั่งเป็นส่วนสำคัญของบริบท หลังจากการเรียกเครื่องมือเป็นร้อยครั้ง คำสั่งกลายเป็นชิ้นเล็กๆ ท่ามกลาง log, diff และโค้ดที่อ่านไปแล้ว สัญญาณยังเป็นสัญญาณเดิม แต่สัญญาณรบกวนรอบข้างมากขึ้นหลายสิบเท่า

ตัวอย่างล่าสุดมีน้ำหนักกว่ากฎเก่า

โมเดลพึ่งพาสิ่งที่เกิดขึ้นในการสนทนาอย่างมาก ถ้า agent ทำอะไรลัดข้ามกฎหลายครั้งแล้วรอดมาได้ รูปแบบนั้นในประวัติจะมีน้ำหนักมากกว่าบรรทัดคำสั่งที่อยู่ตอนต้นไฟล์ที่ไหนสักแห่ง

Context rot: คุณภาพเสื่อมก่อนถึงขีดจำกัด

Context rot ("การเน่าของบริบท") คือปรากฏการณ์ที่คุณภาพคำตอบของโมเดลลดลงเมื่อหน้าต่างเต็มขึ้น ทั้งที่ยังห่างจากขีดจำกัดทางเทคนิคมาก โมเดลรับได้ 200,000 โทเคนตามรูปแบบ แต่ที่ 150,000 โทเคนมันทำงานแย่กว่าที่ 20,000 มันมักสับสนรายละเอียด เสนอแนวทางที่ถูกปฏิเสธไปแล้ว และลืมคำสั่ง

สัญญาณว่าเซสชัน "เน่า" แล้ว:

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

การแก้ปัญหานี้ด้วยการเพิ่มกฎอีกข้อไม่ได้ผล กฎใหม่จะหายไปในสัญญาณรบกวนเดิม ต้องลดสัญญาณรบกวนลง

การบีบอัดบริบท (Compaction)

Compaction คือการย่อประวัติเซสชัน โมเดลเขียนสรุปสั้นๆ ว่าเกิดอะไรขึ้น และการสนทนาดำเนินต่อด้วยสรุปนั้นแทนประวัติเต็ม หน้าต่างจึงว่างขึ้น และแก่นของงานดูเหมือนยังอยู่

ใน Claude Code มีคำสั่ง /compact ที่รับคำแนะนำได้ว่าควรเน้นอะไรตอนย่อ เมื่อหน้าต่างใกล้ขีดจำกัด Claude Code จะทำ compaction ให้อัตโนมัติ ส่วนคำสั่ง /clear ล้างประวัติทั้งหมดและเริ่มใหม่ ส่วน /context แสดงว่าหน้าต่างใช้พื้นที่ไปกับอะไรบ้าง

/context
/compact เก็บไว้: เป้าหมายของงาน การตัดสินใจพร้อมเหตุผล รายการไฟล์ที่เปลี่ยน สิ่งที่ยังต้องตรวจ
/clear

อันตรายของ compaction

การเล่าใหม่มักสูญเสียรายละเอียดเสมอ สรุปอาจไม่มีแนวทางที่ถูกปฏิเสธและเหตุผลที่ปฏิเสธ คำนิยามที่แม่นยำของข้อกำหนด หรือความละเอียดอ่อนที่คุณตกลงกันผ่านๆ หลัง compaction agent ทำงานจากบันทึกย่อของเซสชันตัวเอง ดังนั้นสิ่งสำคัญควรเก็บไว้ในไฟล์ที่รอดจาก compaction ใดๆ ไม่ใช่ในประวัติการสนทนา

Compaction หรือเซสชันใหม่

วิธีประหยัดหน้าต่างบริบท

การประหยัดบริบทไม่ได้เกี่ยวกับราคาโทเคน แต่เกี่ยวกับคุณภาพการทำงาน ยิ่งสัญญาณรบกวนในหน้าต่างน้อย การใส่ใจก็ยิ่งไปถึงงานและกฎมากขึ้น

1. ไฟล์คำสั่งสั้นแบบ router

CLAUDE.md หรือ AGENTS.md ที่เป็นจุดเริ่มต้นจะถูกอ่านทั้งไฟล์ในทุกเซสชัน ไฟล์ยาว 600 บรรทัดคือค่าใช้จ่ายโทเคนคงที่ราว 10,000–20,000 โทเคน ควรเก็บคำสั่งตรวจสอบ ข้อจำกัดเด็ดขาด และแผนที่โปรเจกต์ไว้ในไฟล์นั้น ส่วนรายละเอียดแยกตามหัวข้อไปไว้ในเอกสารแยก ที่ agent จะเปิดเมื่อจำเป็นเท่านั้น

2. ความรู้ที่โหลดตามความต้องการ

ใน Claude Code skills ทำงานโดยใส่เพียงคำอธิบายสั้นๆ ของสกิลเข้าไปในบริบทก่อน และโหลดคำสั่งเต็มเมื่อสกิลจำเป็นสำหรับงาน วิธีนี้ช่วยให้ขั้นตอนที่ไม่ค่อยใช้ เช่น ดีพลอย ย้ายฐานข้อมูล หรือปล่อยเวอร์ชัน พร้อมใช้งานโดยไม่ต้องจ่ายในทุกเซสชัน

3. Subagent สำหรับงานที่ส่งเสียงดัง

Subagent ทำงานในหน้าต่างบริบทของตัวเองและส่งกลับให้เซสชันหลักเฉพาะผลลัพธ์ การค้นหาในโค้ดขนาดใหญ่ การอ่าน log ยาว หรือการศึกษาโมดูลที่ไม่คุ้นเคย ทั้งหมดนี้มอบให้ subagent ได้ และคุณจะได้คำสรุปไม่กี่ย่อหน้ากลับมาแทนผลลัพธ์ดิบหลายพันบรรทัด

4. ผลลัพธ์เครื่องมือที่เงียบ

ผลลัพธ์ของคำสั่งคือตัวกินหน้าต่างหลัก ตั้งค่าคำสั่งตรวจให้พิมพ์เพียงบรรทัดเดียวเมื่อสำเร็จ และเมื่อล้มเหลวให้พิมพ์แค่แก่นของปัญหา คือเทสต์ที่ล้มกับข้อความของมัน ไม่ใช่ log บิลด์ทั้งหมด

# เสียงดัง: หลายพันบรรทัดลงหน้าต่างทุกครั้งที่รัน
pytest -v

# เงียบ: สำเร็จเป็นบรรทัดเดียว ล้มเหลวเฉพาะเทสต์ที่ตก
pytest -q --tb=short

# log ไม่ใช่ทั้งไฟล์ แต่เป็นเฉพาะท้ายและบรรทัดผิดพลาด
tail -n 50 app.log | grep -i error

5. หนึ่งงาน หนึ่งเซสชัน

อย่าลากเซสชันเดียวผ่านงานที่ไม่เกี่ยวกันสามงาน ประวัติของงานแรกไม่มีประโยชน์กับงานที่สาม แต่กินพื้นที่และทำให้ agent สับสน เมื่อจบงาน บันทึกผล แล้วเปิดเซสชันใหม่

6. สถานะอยู่ในไฟล์ ไม่ใช่ในประวัติ

สิ่งที่ต้องรอดจาก compaction และเซสชันใหม่ ให้เขียนลงใน repository ได้แก่ เป้าหมาย การตัดสินใจพร้อมเหตุผล แนวทางที่ถูกปฏิเสธ สิ่งที่ทำไปแล้วและการตรวจสอบ ขั้นตอนถัดไป เช่นใน PLAN.md และ PROGRESS.md เซสชันใหม่จะเริ่มจากเอกสารที่แม่นยำ ไม่ใช่จากการเล่าใหม่ และคุณล้างประวัติได้อย่างมั่นใจ

# PROGRESS.md
## เป้าหมาย
เปลี่ยนการคำนวณส่วนลดให้เป็นหน่วยสตางค์จำนวนเต็ม

## เสร็จแล้ว (ตรวจแล้ว)
- app/payments/discount.py: float → int, make test ผ่าน
- เพิ่ม migration 041 และนำไปใช้ในเครื่องแล้ว

## การตัดสินใจ
- การปัดเศษ: แบบธนาคาร ตามผู้ให้บริการชำระเงิน

## ที่ปฏิเสธแล้ว
- Decimal ในโมเดล: ทำให้การ serialize ของ webhook พัง

## ขั้นตอนถัดไป
อัปเดตเทสต์ e2e ของการสั่งซื้อและรัน make e2e

กฎวิกฤตไม่ควรอยู่แค่ในหน้าต่าง

แม้โครงสร้างบริบทจะดีแค่ไหน ก็ไม่รับประกันการปฏิบัติตามกฎ ข้อความในหน้าต่างเป็นอิทธิพลต่อโมเดล ไม่ใช่ข้อห้ามที่บังคับใช้ได้ ถ้าการละเมิดเป็นสิ่งที่ยอมรับไม่ได้ กฎต้องถูกตรวจด้วยกลไก ใน Claude Code มี hook ซึ่งรันตามเหตุการณ์ของ agent และบล็อกการกระทำได้ และการตั้งค่าสิทธิ์ที่ห้ามเครื่องมือหรือคำสั่งบางอย่าง ลินเตอร์ เทสต์ และ CI ทำงานโดยไม่ขึ้นกับสิ่งที่เกิดขึ้นในหน้าต่างของ agent

หลักการที่ดีของฮาร์เนสคือ สิ่งที่ตรวจอัตโนมัติได้ ให้ตรวจอัตโนมัติ และในบริบทให้เหลือเฉพาะสิ่งที่ต้องใช้การตัดสินใจ

สรุป

หน้าต่างบริบทของ LLM คือที่เดียวที่ agent เห็นงานของคุณ และมันเต็มเร็วกว่าที่คิด ทั้งคำสั่ง ประวัติ ไฟล์ที่อ่าน และผลลัพธ์คำสั่งสะสมจนจบเซสชัน คุณภาพลดลงนานก่อนถึงขีดจำกัด กฎที่อยู่กลางบริบทยาวจะหาย และ compaction ช่วยพื้นที่แต่สูญเสียรายละเอียด ให้เก็บคำสั่งให้สั้น โหลดความรู้เฉพาะทางเมื่อจำเป็น ส่งงานที่เสียงดังให้ subagent เก็บสถานะไว้ในไฟล์ และเสริมกฎวิกฤตด้วย hook และการตรวจสอบ การทำงานกับบริบทของ agent เราอธิบายอย่างละเอียดพร้อมการลงมือทำจริงในคอร์สเกี่ยวกับ harness engineering