การตรวจจับลูปไม่ใช่การตรวจจับภาวะชะงัก: จับเอเจนต์ที่ทำงานวนไปโดยไม่ทำซ้ำ

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

เราคิดว่าเอเจนต์จะทำงานระยะยาวได้ดี ต้องทำสองเรื่องนี้ให้ถูกต้อง:

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

บทความนี้พูดถึงการป้องกันการหยุดคืบหน้า เพราะเป็นเรื่องที่ทำให้เราเสียต้นทุนมากที่สุด

อาการ

เราได้รับรายงานจากผู้ใช้ และเห็นภายในทีมเช่นกันว่า งานที่ยาวมากบางงานหยุดคืบหน้าระหว่างทาง

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

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

เรามีตัวป้องกันอยู่แล้ว ถึงสามชั้น

คอมเมนต์ของชั้นที่สามเขียนไว้ตรงตัวว่า: สัญญาณประกอบว่า "อาจกำลังวนอยู่กับที่หลังสูญเสียบริบท" มีคนมองเห็นปัญหานี้ล่วงหน้าแล้ว ดังนั้นปัญหาไม่ใช่ว่าเราไม่ได้สร้างอะไรไว้ แต่สิ่งที่เราสร้างจับมันไม่ได้

จุดบอด: ทั้งสามชั้นตรวจจับจากฝั่งอินพุต

ลายเซ็นที่ทุกชั้นใช้เป็นหลักคือ ชื่อเครื่องมือ + อาร์กิวเมนต์ที่ปรับเป็นรูปแบบมาตรฐานแล้ว ซึ่งตอบได้เพียงคำถามเดียว: คุณกำลังทำสิ่งเดิมสองครั้งหรือไม่?

แต่โมเดลที่เก่งเมื่อติดขัดจะไม่เรียกใช้งานซ้ำ มันทำแบบนี้:

อ่านไฟล์ A → grep X → อ่าน A ซ้ำโดยเปลี่ยนช่วงบรรทัด
  → รันคำสั่งที่ต่างไปเล็กน้อย → อ่านไฟล์ B → grep อีกครั้ง …

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

การตรวจจับการวนซ้ำไม่ใช่การตรวจจับการหยุดคืบหน้า อย่างแรกดูอินพุต อย่างหลังต้องดูผลลัพธ์

งานวิจัยให้นิยามฝั่งผลลัพธ์นี้พอดี

รางวัลภายในช่วงของ BEACON:

r_t = R_ms · γ^(t_k − t)    หากช่วงนั้นจบด้วยการบรรลุหมุดหมาย
    = 0                     มิฉะนั้น

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

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

รูปที่ 8 ในงานวิจัยแสดงเส้นทางที่ล้มเหลว โดยการกระทำสองครั้งสุดท้ายได้รับค่า −2.20 เท่ากัน ช่วงท้ายดังกล่าว ซึ่งอยู่หลังหมุดหมายสุดท้ายและไปไม่ถึงหมุดหมายถัดไป คือรูปแบบทางคณิตศาสตร์ของการวนอยู่กับที่ และพบได้บ่อย: เส้นทางที่ทำเป้าหมายย่อยสำเร็จอย่างน้อยหนึ่งข้อแต่ทำงานไม่สำเร็จ มีสัดส่วนคงที่อยู่ที่ 39–47% ของตัวอย่าง

การทดลองตัดองค์ประกอบหนึ่งชุดหักล้างการใช้จำนวนขั้นตอนเป็นตัวกระตุ้น

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

ทีนี้กลับมาดูเกณฑ์ชั้นที่สามของเรา — ใช้งบการวนเรียกเครื่องมือไป 75% นั่นคือตัวกระตุ้นตามจำนวนขั้นตอนที่กำหนดขึ้นเอง มันถามว่าใช้ไปเท่าไร ไม่ใช่ทำสำเร็จอะไร รูปแบบที่ถูกต้องคือ:

✗  หากจำนวนขั้นตอน > N                              → แทรกแซง
✓  หากจำนวนขั้นตอน > N และไม่มีหมุดหมายที่ตรวจสอบแล้ว → แทรกแซง

อย่างที่สองจะไม่ทำงานผิดจังหวะกับงานที่ยาวจริงและยังคืบหน้า เพราะงานเช่นนั้นบรรลุหมุดหมายระหว่างทาง แต่อย่างแรกจะทำ

ยังมีวงจรป้อนกลับแบบเสริมแรงด้วย

ลองวางค่าคงที่เทียบกัน การย่อบริบทเริ่มเมื่อใช้หน้าต่างบริบทไป 82% ส่วนการตรวจจับการลู่เข้าสู่ภาวะวนอยู่กับที่ต้องรอให้ย่อบริบทสองครั้งและใช้งบการวนไป 75% ก่อนจึงทำงาน

วนอยู่กับที่ → บริบทเต็ม → เริ่มย่อบริบท → สถานะถาวรถูกสรุปจนหายไป
     → หาใหม่ว่าสิ่งที่หายไปคืออะไร → วนอยู่กับที่มากขึ้น

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

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

สิ่งที่เรากำลังเพิ่ม: การตรวจจับการหยุดคืบหน้าฝั่งผลลัพธ์

ชั้นที่สี่ สร้างจากตัวนับสองตัว ทั้งคู่คำนวณตามกฎจากผลสังเกตของเครื่องมือที่ระบบโฮสต์บันทึกไว้อยู่แล้ว ไม่ต้องอาศัยดุลยพินิจของโมเดล

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

การเปลี่ยนแปลงสถานะใหม่ที่ตัดรายการซ้ำแล้ว ตัวที่มีประโยชน์มากกว่าในสองตัวนี้:

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

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

จากนั้นควรเพิ่มแรงกดดันอย่างต่อเนื่อง แทนการสะกิดเพียงครั้งเดียว:

แสดงตัวนับในบริบทให้โมเดลเห็น
  → บังคับให้ปรับแผน (ยอมรับว่าแนวทางนี้ไปต่อไม่ได้)
    → ถามผู้ใช้
      → ยุติ แต่เก็บหมุดหมายที่บรรลุแล้วไว้

ขั้นสุดท้ายนั้นสำคัญ หากการรันต้องหยุด ก็ควรหยุดโดยเก็บสิ่งที่ทำได้ไว้ ซึ่งก็คือความคืบหน้าบางส่วน 39–47% ที่งานวิจัยวัดพบว่าถูกทิ้งไป

สิ่งที่งานวิจัยไม่ได้ให้เรา

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

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

ขั้นแรกคือวัด ไม่ใช่แก้

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

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

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

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