บริบท

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

ทำไมการรันที่ยาวนานจึงออกนอกทาง

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

Perch ถูกสร้างมาเพื่อรันงานยาว จึงถือว่า context window เป็นสิ่งที่ต้องจัดการอย่างจริงจังในทุกเทิร์น ไม่ใช่สิ่งที่เติมไปเรื่อยๆ จนเกิดข้อผิดพลาด

ไปป์ไลน์การบีบอัดบริบท

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

ขั้นที่หนึ่ง: ตัดข้อมูลก้อนใหญ่ออกก่อน ทุกครั้ง

การรันที่ยาวนานบวมขึ้นจากข้อมูลก้อนใหญ่ที่มีคุณค่าต่ำ ได้แก่ snapshot ของหน้าเบราว์เซอร์ทั้งหน้าและภาพหน้าจอของ operator Perch ตัดสิ่งเหล่านี้ออกทุกเทิร์น ก่อนจะตรวจงบด้วยซ้ำ snapshot ของหน้าเว็บจะถูกตัดเหลือเฉพาะส่วนที่ใช้ดำเนินการได้ (ตัวควบคุมและโครงสร้างที่โมเดลอาจใช้ดำเนินการ) และ snapshot ที่เก่าที่สุดจะถูกลดเหลือเพียงโครงย่อ ภาพหน้าจอจะถูกทิ้งหรือบีบอัดให้ไม่เกินเพดานโทเค็นที่ตายตัว นี่คือการกำจัดส่วนที่สิ้นเปลืองล้วนๆ จึงทำโดยไม่มีเงื่อนไข snapshot DOM ดิบหรือภาพหน้าจอเพียงชิ้นเดียวอาจกินโทเค็นมากกว่าการให้เหตุผลจริงหลายสิบเทิร์น และแทบไม่เคยถูกใช้อีกหลังจากผ่านไปไม่กี่ขั้นตอน

ขั้นที่สอง: microcompact ผลลัพธ์เครื่องมือที่ล้าสมัย โดยไม่เรียกโมเดล

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

ขั้นที่สาม: สรุปเทิร์นที่เก่ากว่า เฉพาะเมื่อยังเกินงบ

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

ขั้นที่สี่: ด่านบังคับสุดท้าย

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

วัด context window จริง ไม่ใช่การเดา

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

รักษาเธรดที่กำลังดำเนินอยู่

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

เคารพงบจริงของโมเดลคุณ

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

มองเห็นได้ ไม่เงียบหาย

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

ทำไมเรื่องนี้จึงสำคัญ

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