บทที่ 13 · Context · เชื่อถือ · สเกล · Context Engineering
Context Engineering
บทที่ 05 สอนว่า “ป้อนกติกาที่ถูก” แต่พอข้อมูลโตขึ้น คำถามเปลี่ยนเป็น วางอะไร เท่าไร และเรียงยังไง
ก่อนโมเดลจะคิด ตัวอย่างนำ: การให้คำปรึกษานักศึกษา — ดึงประวัติ ทีละคนเมื่อจำเป็น ไม่ใช่ยกทั้ง roster มากองไว้
พูดแบบเข้าใจง่าย
Context engineering คือการตัดสินใจว่าจะวาง token อะไร น้อยแค่ไหน และเรียงลำดับยังไง — โมเดล
ไม่ได้ ให้น้ำหนักทุก token เท่ากัน งานวิจัยสองชิ้นล้มสัญชาตญาณ “ยิ่งเยอะยิ่งดี”:
- Lost in the middle (Liu et al., TACL 2024): ข้อเท็จจริงที่อยู่ ต้น หรือ ท้าย ของ input ถูกเรียกคืนได้แม่น แต่ถ้าอยู่ กลาง ความแม่นแอ่นลงเป็นรูปตัว U
- Context rot (Chroma, 2025): ยิ่ง input ยาว ความแม่นยิ่งตก แม้ window จะยังว่างอยู่มาก และแม้งานจะง่าย
เป้าหมายจึงไม่ใช่ “window ที่เต็มที่สุด” แต่คือ ชุด token ที่เล็กที่สุดแต่สัญญาณแรงสุด วางในที่ที่โมเดลอ่านจริง —
ดึงข้อมูลเมื่อต้องใช้ (just-in-time), สรุปก่อน (aggregate ใน SQL / คืน top-k) และใช้แพทเทิร์น “จัดหมวดด้วย schema ก่อน แล้วค่อยเจาะ”
เปรียบเทียบ: กระเป๋าถือขึ้นเครื่อง vs ตู้คอนเทนเนอร์ขนของทั้งตู้เสื้อผ้า
กระเป๋าถือบังคับให้เลือกของไม่กี่ชิ้นที่ใช้จริง (context สัญญาณแรง) · ตู้คอนเทนเนอร์เอามาหมด แต่คุณเสียทั้งทริปขุดหากล่อง
และยังหาที่ชาร์จไม่เจอ (lost-in-the-middle) · ตู้ที่เต็มแค่ครึ่งก็ยังถ่วงคุณ (context rot) · พาสปอร์ตในกระเป๋าหน้า = วางข้อเท็จจริงสำคัญไว้ต้น/ท้าย
ในระบบของเรา — จัดหมวดด้วย schema ก่อน แล้วค่อยเจาะ
schema ก่อนเรียก “สารบัญ” ราคาถูก: มีหมวด/แท็กอะไรบ้าง
→
จัดหมวดคำถามนี้ตกหมวดไหน
→
เจาะดึงเฉพาะไม่กี่รายการในหมวดนั้น
→
ตอบโมเดลอ่านไม่กี่บรรทัดสัญญาณแรง
ปฏิทินการศึกษาของเรามีเหตุการณ์ร้อยกว่ารายการที่คำซ้ำ ๆ กัน — ผู้ช่วยจึงเรียก “สารบัญ” (schema) ที่ราคาถูกก่อน
จัดคำถามลงหมวด แล้วดึงเฉพาะไม่กี่รายการในหมวดนั้น ไม่เคยเห็นทั้งร้อยรายการ และเรื่องคู่มือ มันดึงเฉพาะ top-k ท่อนที่เกี่ยว
ไม่ใช่ทั้งเล่ม · สำหรับการให้คำปรึกษานักศึกษา หลักเดียวกัน: ดึงประวัติทีละคนเมื่อจำเป็น ไม่ยก roster ทั้งชั้นมากองไว้
ทำพลาด vs ทำถูก
⚠️ แย่ · ทิ้งแถวดิบทั้งฐานข้อมูล
ให้โมเดลนับเอง
ดึงข้อมูลนักศึกษาหลายพันแถวเข้า context แล้วให้โมเดลนับ/เฉลี่ย — token สัญญาณต่ำมหาศาล
ตัวเลขที่ต้องการไปจมอยู่กลางกอง (recall แอ่น) ทั้งที่ SQL สรุปให้เป็นตัวเลขเดียวได้
⚠️ แย่ · front-load ทุกอย่าง “เผื่อไว้”
กำแพง 40K token
แปะคู่มือทั้งเล่ม ทุก tool ทุกบทสนทนาเก่า ทุกครั้ง — ข้อเท็จจริงชิ้นเดียวที่ต้องใช้ไปอยู่กลางกำแพง
recall อ่อนสุด และ context rot ถ่วงอยู่แล้วแม้ window ว่าง 80%
✅ ดี · schema-first + JIT + pre-aggregate
เล็ก ตรง วางถูกที่
จัดหมวดด้วยสารบัญราคาถูกก่อน เจาะเฉพาะที่เกี่ยว ดึงเมื่อต้องใช้ และสรุปด้วย SQL ให้เป็นคำตอบ
โมเดลอ่านไม่กี่บรรทัด recall อยู่บนส่วนสูงของกราฟ
ลองเอง — ทำนาย recall แล้วดูมันแอ่น
กิจกรรม · สไลเดอร์ + กราฟ
Needle in the Haystack
เลื่อนตำแหน่งของ “เข็ม” (ข้อเท็จจริงสำคัญ) ในก้อน context แล้ว ทายก่อนว่า recall เท่าไร
จากนั้นขยายขนาด haystack โดยตรึงเข็มไว้กลาง — ดู recall ตกทั้งที่ window แทบว่าง
เลื่อนตำแหน่ง · เลือกขนาด · ทาย · รัน
มองไปข้างหน้า — context เดียวกันนี้ก็รับ “ของอันตราย” ได้ด้วย
เราทำให้ context เล็กและฉลาดแล้ว แต่ทุกอย่างที่เข้ามาใน window — รวมถึง ข้อความที่ผู้ใช้พิมพ์หรือเนื้อหาที่ดึงมา —
ปนกันเป็นสายเดียว บทที่ 14 ว่าด้วย security: เมื่อ “เนื้อหาที่ไม่น่าเชื่อถือ” อยู่ใน context เดียวกับคำสั่ง
สรุปบทที่ 13
- เป้าหมายคือ ชุด token เล็กสุดแต่สัญญาณแรงสุด ไม่ใช่ window ที่เต็มสุด
- Lost-in-the-middle (ตำแหน่ง) + context rot (ความยาว) ทำให้ “เยอะ” ทำร้ายความแม่น
- ดึง just-in-time + สรุปก่อน (SQL/top-k) + schema-first (จัดหมวดก่อนเจาะ)
- การให้คำปรึกษา: ดึงประวัติ ทีละคนเมื่อจำเป็น ไม่ยก roster ทั้งชั้น
Harness Scorecard · มิติ: “ใช้ชุด context ที่เล็กและตรงไหม?”
ผู้ช่วย/ระบบเรา: ✅ — schema-first + JIT + pre-aggregate เป็นพฤติกรรมจริง
📋 build-your-harness checklist · บรรทัดที่ 12
“ชุด context เล็กสุด-สัญญาณแรงสุด: schema-first · ดึง just-in-time · สรุปก่อน · วางของสำคัญไว้ต้น/ท้าย”