Orkas Orkas
ดาวน์โหลด GitHub
หน้าแรก บล็อก สถาปัตยกรรม
สถาปัตยกรรม

บอกว่าเสร็จไม่ได้แปลว่าตรวจสอบแล้วว่าเสร็จ: การออกแบบหมุดหมายสำหรับเอเจนต์ที่ทำงานระยะยาว

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

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

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

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

ตั้งคำถามให้ถูกทาง

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

ต่างกันเพียงหนึ่งชั้น แต่ความน่าเชื่อถือต่างกันจนเทียบไม่ได้

เรามีทั้งสองส่วนอยู่แล้ว แต่ไม่เคยเชื่อมเข้าด้วยกัน

เมื่ออ่านโค้ดที่เราเขียนเอง ส่วนนี้ทำให้ประหลาดใจ

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

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

ช่องว่างอยู่ตรงนั้น บรรทัดหนึ่งบอกว่า ฉันทำเสร็จแล้ว. อีกบรรทัดบอกว่า แฮชของไฟล์เปลี่ยนจาก A เป็น B. แต่ไม่เคยมีอะไรนำสองอย่างนี้มาเทียบกัน

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

สิ่งที่มีประโยชน์ที่สุดในงานวิจัยไม่ใช่สูตร

BEACON เป็นที่รู้จักมากที่สุดจากค่าความได้เปรียบสองระดับ แต่ส่วนที่น่าหยิบมาใช้คือการวางบทบาทของตัวตรวจจับ Φ

Φ ไม่ต้องใช้โมเดลที่ฝึกมาและไม่ต้องมีมนุษย์กำกับข้อมูล มันอ่านเฉพาะการเปลี่ยนสถานะที่สังเกตได้จากผลตอบกลับของสภาพแวดล้อม: การเปลี่ยนสถานะวัตถุใน ALFWorld (หยิบสำเร็จ อุ่นเสร็จแล้ว) การเปลี่ยนหน้าใน WebShop และใน ScienceWorld ก็เพียงรับสัญญาณเป้าหมายย่อยที่สภาพแวดล้อมส่งออกมาอยู่แล้ว

ไม่เพิ่มโมเดล ไม่เพิ่มต้นทุนการสุ่มตัวอย่าง ลองเทียบกับทางเลือกอื่น: โมเดลรางวัลของกระบวนการต้องใช้การกำกับข้อมูลที่มีราคาแพงและอาจถูกหาช่องเอาเปรียบได้ ส่วนการประมาณค่าด้วย Monte-Carlo ต้องทดลองเส้นทางเพิ่มเติมในทุกจุดตัดสินใจ ต้นทุนนั้นคือสิ่งที่ Φ หลีกเลี่ยง

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

สามชั้น หากคุณจะสร้างมัน

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

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

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

เกณฑ์หนึ่งที่เราเพิ่ม: ย้อนกลับไม่ได้ ไม่ใช่ความสำคัญ

ข้อนี้ไม่มีในงานวิจัย

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

ย้อนกลับไม่ได้: เขียนไฟล์ คอมมิตโค้ด ส่งข้อความ เรียก API แบบเสียเงิน คอมมิตข้อมูลลงฐานข้อมูล ย้อนกลับได้: อ่านไฟล์ ค้นหา ดึงหน้าเว็บ คิด

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

ตัวเลขสองค่า: ค่าหนึ่งให้ความมั่นใจ อีกค่าหนึ่งเตือนให้ระวัง

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

ตัวเลขที่เตือนให้ระวังคือการเปรียบเทียบวิธีแบ่งส่วน

การแบ่งช่วงคะแนนเทียบกับค่าฐาน (72.8)
สุ่มแบ่งเป็น 5 ส่วน74.2+1.4
หมุดหมายจริง91.4+17.2

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

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

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

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

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

หากจะทำเพียงอย่างเดียว

ทำชั้นที่สอง

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

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

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