The context window

คุณเริ่ม session ใน shop-api และตกลงกับ Claude ว่าทุก error response ต้องมี field `code` คงที่ จากนั้นงานดำเนินไปครึ่งชั่วโมงที่ไล่แก้เทสต์กับอ่านไฟล์ไปเรื่อย ๆ แล้วอยู่ ๆ คำตอบถัดไปก็เสนอ error ที่ไม่มี `code` เลย คุณไม่ได้เปิด session ใหม่ ไม่ได้สั่งลบอะไร และข้อตกลงนั้นก็ถูกพิมพ์ไว้ชัดเจนในแชท อีกครั้งหนึ่งคุณวาง log ยาว ๆ เพื่อให้ช่วยวิเคราะห์ แล้วมันตอบว่า "เริ่มเรื่องต้นทางไม่เห็นแล้ว" ทั้งที่ทุกข้อความยังอยู่ในหน้าจอที่คุณเลื่อนกลับไปอ่านได้ สองอาการนี้ชี้ไปที่กลไกเดียวกัน: สิ่งที่โมเดล "เห็น" ในการตัดสินใจแต่ละครั้งถูกจำกัดอยู่ในพื้นที่หนึ่ง และพื้นที่นั้นเต็มได้ บทนี้จะอธิบายหน้าต่างนั้นก่อน แล้วบทถัดไปจะพาไปดูว่าไฟล์ใดถูกโหลดเข้าไปบ้าง

ลองนึกถึงสิ่งที่โมเดลทำได้จริง ๆ: ในการตัดสินใจหนึ่งครั้ง มันอ่านข้อความทั้งหมดที่อยู่ในสายตาของมัน แล้วสร้างข้อความถัดไป สิ่งที่อยู่นอกสายตาคือสิ่งที่มันไม่เห็น — ไม่ใช่สิ่งที่มันลืม พื้นที่ที่ข้อความเหล่านั้นต้องอยู่คือ **context window** พื้นที่ทำงานจำกัดของ session ในการเรียกโมเดลหนึ่งครั้ง ข้างในต้องมีทั้งคำสั่งของคุณ instruction ของโปรเจกต์ ประวัติสนทนาที่ผ่านมา และผลลัพธ์จริงของทุกเครื่องมือ ความเข้าใจผิดที่พบบ่อยคือคิดว่ามันเป็น "ความจำ" ของโมเดล ความจริงคือไม่มีที่เก็บถาวรอยู่ในตัวโมเดลเลย สิ่งที่ดูเหมือนความจำเกิดจาก harness ประกอบหน้าต่างขึ้นใหม่ทุก session จากสิ่งที่มันโหลดได้ บทนี้จึงพูดถึง "หน้าต่าง" ที่เต็มได้ ไม่ใช่ "ความจำ" ที่เสีย

เมื่อหน้าต่างมีเพดาน พฤติกรรมหลายอย่างที่ดูเหมือนอารมณ์ของโมเดลก็อธิบายได้: session ที่ยาวขึ้นจะตอบคำถามปลายทางได้ดีกว่าต้นทาง เพราะรายละเอียดต้นทางถูกเบียดออกไปก่อน; การวาง log ยาว ๆ ทำให้มันเหมือน "ลืม" โจทย์ เพราะพื้นที่ส่วนใหญ่ถูกใช้ไปกับข้อมูลที่เพิ่งวาง; และหน้าต่างที่เต็มไม่ได้ทำให้ session จบ — harness จัดการให้เดินต่อได้ แต่สิ่งที่ถูกตัดออกไปนั้นหายจริงถ้าไม่มีทางโหลดกลับ

หน้าต่างไม่ได้เติมด้วยอัตราคงที่ ทุกเทิร์นถูกเพิ่มเข้าไปทั้งนั้น — คำสั่งของคุณ คำตอบของโมเดล และผลลัพธ์ของทุกเครื่องมือ — แต่ตัวแปรที่กินพื้นที่มากและคาดเดายากที่สุดคือผลลัพธ์ของเครื่องมือ: การอ่านไฟล์ทั้งไฟล์ การค้นหากว้าง ๆ หรือ output ของคำสั่งที่ยาว สามารถกินพื้นที่มากกว่าบทสนทนายาว ๆ ทั้งบท เมื่อพื้นที่จะหมด harness ไม่ได้ปิด session แต่จะจัดการตามลำดับนี้

จุดที่ต้องจำ: การบีบอัดเป็นการสรุปแบบสูญเสียรายละเอียด ไม่ใช่การเก็บสำรอง ข้อตกลงที่คุณพิมพ์ไว้ในแชทมีอายุเท่ากับสถานะของหน้าต่างในขณะนั้น ต่างจาก instruction ที่รากโปรเจกต์และ rule ที่ไม่ผูกกับ path ซึ่งถูกอ่านกลับจากดิสก์หลังการบีบอัด ส่วน instruction ที่ผูกกับ path หรืออยู่ในโฟลเดอร์ย่อยจะถูกสรุปกลืนไปกับประวัติเหมือนเนื้อหาอื่น — ความต่างนี้คือเหตุผลเชิงกลไกว่าทำไมกฎที่ต้องมีผลทั้ง session จึงควรอยู่ที่รากของโปรเจกต์ ไม่ใช่ซ่อนไว้ในโฟลเดอร์ย่อย (กลไกของแต่ละไฟล์เป็นเรื่องของบทถัดไป) รายละเอียดที่เปลี่ยนได้ของเรื่องนี้ — เพดานของหน้าต่าง และคำสั่งที่ใช้ดูหรือจัดการ — รวมไว้ที่ตารางเดียวด้านล่าง พร้อมวันที่ตรวจสอบและหน้าอ้างอิง โปรดเปิดหน้าอ้างอิงก่อนเชื่อตัวเลขหรือชื่อคำสั่งใด

ทั้งสองแบบเริ่มจากข้อตกลงเดียวกัน ความต่างคือข้อตกลงนั้นอาศัยอะไรอยู่ — สถานะของหน้าต่างซึ่งถูกสรุปใหม่ได้ หรือ instruction ระดับรากที่ harness อ่านกลับจากดิสก์

• context window คือพื้นที่จำกัดของ session หนึ่ง ๆ ไม่ใช่ความจำถาวรในตัวโมเดล
• ผลลัพธ์ของเครื่องมือคือตัวแปรที่กินพื้นที่หน้าต่างมากที่สุดและคาดเดายากที่สุด
• เมื่อใกล้เต็ม harness จะตัดรายละเอียดเก่าและสรุปประวัติ — รายละเอียดในแชทอาจหาย ส่วน instruction ระดับรากถูกอ่านกลับจากดิสก์ กฎที่ต้องมีผลทั้ง session จึงควรอยู่ที่ราก
• ก้าวต่อไป: บทถัดไปคือ What loads into context ซึ่งจะพาไปรู้ว่า harness โหลดอะไรเข้า context บ้างตอนเปิด session โหลดเมื่อไร และไฟล์ใดไม่เคยเข้าเลย