การย่อบริบทตัดตามจำนวนโทเคน ไม่ใช่ตามสิ่งที่ลืมได้อย่างปลอดภัย

เอเจนต์ของคุณใช้หน้าต่างบริบทถึง 80% การย่อบริบทเริ่มทำงานและทิ้งเทิร์นที่เก่าที่สุด สิบนาทีต่อมา มันอ่านไฟล์ที่เคยอ่านแล้วซ้ำ และถามคำถามที่เคยตอบแล้วอีกครั้ง

เกณฑ์นั้นรู้ว่าพื้นที่ใกล้หมด แต่ไม่รู้เลยว่าอะไรสูญเสียได้อย่างปลอดภัย

นี่คือบันทึกชิ้นที่สามในชุดการออกแบบเอเจนต์สำหรับงานระยะยาว ซึ่งเกิดจากการอ่านอย่างละเอียดเรื่อง BEACON (มหาวิทยาลัยเจ้อเจียง, arXiv:2605.06078) โดยชิ้น แรก พูดถึงการตรวจจับการหยุดคืบหน้า ส่วนชิ้น ที่สอง พูดถึงการออกแบบหมุดหมาย

เริ่มจากการทำงานของระบบเราเอง

Orkas เป็นแอปเดสก์ท็อปแบบหลายเอเจนต์ งานระยะยาวเป็นเรื่องปกติที่นี่ จึงมีการย่อบริบททุกวัน ระบบของเราเริ่มทำงานตามเกณฑ์โทเคน โดยย่อเมื่อบริบทถึงราว 80% ของหน้าต่าง ก่อนที่เราจะเขียนเรื่องนี้ ไม่มีใครคิดว่าวิธีนั้นมีอะไรผิด

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

สองแบบแรกไม่ดูเนื้อหาเลย แบบที่สามดู แต่ยกคำถามทั้งหมดว่าอะไรสำคัญให้โมเดลตัดสิน

ทั้งสามแบบตอบว่า เมื่อไรฉันต้องทิ้งอะไรสักอย่าง แต่คำถามที่คุณมีจริง ๆ คือ อะไรทิ้งได้อย่างปลอดภัย การตัดเมื่อถึงเกณฑ์จะทิ้งเนื้อหาที่เก่าที่สุด ไม่ใช่เนื้อหาที่สำคัญน้อยที่สุด

แนวแบ่งตามหมุดหมาย และสมมติฐานที่รองรับอยู่

หมุดหมายจากบันทึกก่อนหน้าอาจให้แนวแบ่งที่ดีกว่าทั้งสามแบบ แต่มีข้อควรระวังอยู่ตรงนี้ และบันทึกก่อนหน้าเล่าผ่านจุดนี้ง่ายไปหน่อย

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

ฟังดูเหมือนอนุญาตให้ย่อบริบทได้: เมื่อผ่านหมุดหมาย ช่วงก่อนหน้าก็พับเก็บได้

แต่มันเป็นสมมติฐาน ไม่ใช่ข้อเท็จจริง งานวิจัยเขียนว่า ≈ ไม่ใช่ = และผู้เขียนก็อภิปรายกรณีที่มันใช้ไม่ได้

เพียงพอสำหรับการฝึก แต่ไม่เพียงพอสำหรับการย่อบริบท

สมมติฐานเดียว ใช้สองแบบ แต่ความเข้มงวดต่างกันเป็นลำดับขนาด

ในการฝึก มันต้องเป็นจริงเพียง ในเชิงสถิติ หากการจำลองการทำงานไม่กี่สิบครั้งจากหลายพันครั้งละเมิดสมมติฐาน ความเอนเอียงก็เฉลี่ยหักล้างกันได้ การฝึกยังมีสัญญาณระดับเส้นทางรองรับอยู่อีกชั้น เมื่อตัดชั้นนั้นออก ALFWorld ลดจาก 91.4 เหลือ 23.4 ต่ำกว่าการไม่ทำอะไรเลยมาก

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

ดังนั้นการที่งานวิจัยอาศัยสมมติฐานนี้ไม่ได้แปลว่าคุณนำมาใช้กับการย่อบริบทได้ การใช้งานสองแบบเรียกร้องจากมันไม่เหมือนกัน

สี่กรณีที่สมมติฐานนี้ใช้ไม่ได้

เราใช้รายการนี้ตรวจสอบเมื่อพิจารณานโยบายการย่อบริบท

1. ความรู้โดยนัยที่สะสมระหว่างทาง ในช่วงต้น ขั้นตอนหนึ่งยืนยันว่า API ที่ใช้ส่งเวลาประทับกลับมาเป็น UTC ข้อมูลนี้ไม่ได้อยู่ในหมุดหมายใด แต่ทุกขั้นตอนหลังจากนั้นต้องใช้

2. ทรัพยากรที่ใช้ไปแล้ว งบโทเคน โควตาการเรียก เวลาที่เหลือ หมุดหมายไม่ได้บันทึกว่า ฉันใช้งบไปแล้ว 60% แต่ตัวเลขนี้ตัดสินว่ายังมีทรัพยากรพอให้ลองใหม่หรือไม่

3. ผลข้างเคียงที่ขึ้นกับเส้นทางที่ใช้ หมุดหมายบอกว่า ปรับโครงสร้างโค้ดเสร็จแล้ว แต่ทันทีที่เริ่มดีบัก คุณต้องรู้ว่าไฟล์ห้าไฟล์ใดถูกแก้จริง

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

สิ่งที่ควรเก็บส่งต่อแทน

อย่าเก็บเพียงบทสรุป บทสรุปเขียนโดยโมเดล ซึ่งตัดสินตามความรู้สึกว่าอะไรสำคัญ

เก็บชุดฟิลด์ตายตัวที่มนุษย์เลือก อย่างน้อยสี่ฟิลด์:

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

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

ครึ่งหนึ่งของเรื่องนี้แทบไม่มีต้นทุน ตามที่บันทึกก่อนหน้าอธิบาย ระบบโฮสต์บันทึกข้อเท็จจริงที่แน่นอนหลังการเรียกเครื่องมือทุกครั้งอยู่แล้ว เช่น ไฟล์ถูกเขียนใหม่จริงหรือไม่ คำสั่งถูกรันจริงหรือไม่ ข้อมูลนี้รวบรวมไว้เพื่อยืนยันหมุดหมาย แต่มัน คือ ภาพสถานะพื้นที่ทำงาน จึงส่งต่อผ่านการย่อบริบทได้โดยตรง โดยไม่ต้องขอให้โมเดลสรุปอีกครั้ง

ครึ่งที่ยากคืออีกสองข้อ สิ่งที่ยืนยันแล้วและสิ่งที่ยังค้างอยู่ ตอนนี้จะมีอยู่ก็ต่อเมื่อโมเดลเขียนไว้ นี่เองคือเหตุผลที่สองอย่างนี้สูญหายก่อนเมื่อย่อบริบท

เรื่องนี้วัดได้ ไม่ต้องถกเถียง

หลังย่อบริบท หากเอเจนต์อ่านไฟล์ที่ถูกย่อจนหายไปซ้ำ หรือถามคำถามที่ตอบไปแล้วอีก แปลว่าสมมติฐานใช้ไม่ได้กับงานนั้น และหลักฐานก็อยู่ตรงนั้น

การเก็บข้อมูลทำได้ง่าย: หาส่วนร่วมระหว่างพาธไฟล์ที่อ่านหลังจุดย่อบริบทกับสิ่งที่บันทึกไว้ก่อนหน้านั้น

เมื่อมีตัวเลขนี้ งานประเภทใดย่อบริบทได้มาก และประเภทใดทำไม่ได้ ก็กลายเป็นคำถามที่ค้นข้อมูลตอบได้ แทนการถกเถียงเรื่องการออกแบบ เป็นแนวทางเดียวกับบันทึกแรกในชุดนี้: วัดก่อน แล้วค่อยเปลี่ยน

ข้อจำกัดที่ต้องคำนึงถึง

ทั้งหมดนี้ยังไม่ได้เปิดใช้งาน เราอยู่ในขั้นออกแบบและติดตั้งการเก็บข้อมูล

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

และนี่เป็นเพียงหนึ่งในหลายแนวทาง ตำแหน่งแนวแบ่งและนิยามฟิลด์อาจต่างไปโดยสิ้นเชิงในผลิตภัณฑ์รูปแบบอื่น รายการตรวจสอบสี่กรณีนำไปใช้ต่อได้ แต่คำตอบเฉพาะนี้ไม่ใช่

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