การรันลูป DAgger บนแขนกล SO-100 ด้วยโพลิซี VLA

โพลิซีของคุณทำงาน มันเอื้อมไปหยิบลูกบาศก์ หุบกริปเปอร์เร็วไปหนึ่งเซนติเมตร แล้วก็เดินหน้าต่อราวกับว่าหยิบติดแล้ว ไม่มี error ใดๆ เกิดขึ้น และไม่ว่าจะจ้องมองค่า training loss นานแค่ไหนก็อธิบายไม่ได้ ทางแก้ไม่ใช่การเทรนเพิ่มอีก 20,000 gradient step บนชุดสาธิตเดิม แต่คือการวางมือกลับลงบนแขนกลตรงจุดที่มันทำผิดพอดี บันทึกสิ่งที่คุณทำแทน แล้วเทรนเช็คพอยต์ถัดไปด้วยข้อมูลเดิมบวกกับการแก้ไขนั้น นั่นคือหนึ่งรอบของ DAgger และนี่คือวิธีที่มันทำงานบน SO-100 ด้วยโพลิซีแบบ vision-language-action

ทฤษฎีอยู่ในบทความอื่น: เหตุใดการรวมชุดข้อมูลจึงได้ผลตั้งแต่แรก และ การมีมนุษย์คอยกำกับเปลี่ยนแปลงอะไรบ้าง บทความนี้คือคู่มือปฏิบัติงาน โดยตั้งสมมติฐานว่าคุณมีเช็คพอยต์ที่เทรนแล้ว ชุดกล้องที่ใช้งานได้ และแขนกลที่เคลื่อนไหวได้ หกขั้นตอนด้านล่างคือลูปตามที่ implement ไว้บน หน้า DAgger ของแพลตฟอร์มนี้ แต่ลำดับขั้นตอนก็เหมือนกันหากคุณใช้สคริปต์ของคุณเอง

ทำไมรอบที่สองจึงไม่ใช่แค่ข้อมูลเพิ่ม

Behavior Cloning เทรนบนสถานะที่มนุษย์เคยไปถึง แต่เมื่อใช้งานจริงโพลิซีจะไปถึงสถานะที่มันสร้างขึ้นเอง และข้อผิดพลาดเล็กๆ ของ action จะสะสมพาไปสู่สถานะที่ไม่มีชุดสาธิตใดครอบคลุมไว้ Ross, Gordon และ Bagnell ได้จัดรูปแบบปัญหานี้อย่างเป็นทางการในงาน AISTATS 2011 และตอบด้วยอัลกอริทึมแบบวนซ้ำที่เทรนโพลิซีแบบ deterministic ที่นิ่ง (stationary) ซึ่งภายใต้การลดรูปปัญหาของพวกเขาจะต้องทำงานได้ดีภายใต้การกระจายตัวของสถานะที่มันเองก่อให้เกิดขึ้น: รันโพลิซีปัจจุบัน ให้ผู้เชี่ยวชาญ label สถานะที่มันไปถึงจริง เพิ่มเข้าไปในชุดข้อมูล เทรนใหม่ ทำซ้ำ Kelly และคณะทำให้ขั้นตอนนี้ใช้งานได้จริงด้วย HG-DAgger ซึ่งมนุษย์เป็นผู้ตัดสินใจว่าเมื่อไรจะเข้าควบคุม แทนที่จะ label สถานะโดยไม่ได้ถือคอนโทรลอยู่ พวกเขารายงานว่าประสิทธิภาพดีขึ้นกว่าทั้ง DAgger และ Behavior Cloning ในงานขับขี่อัตโนมัติทั้งแบบจำลองสถานการณ์และของจริง การมีมนุษย์คอยกำกับ (human gating) นี้เองที่ทำให้ลูปนี้ใช้งานได้จริงบนแขนกลบนโต๊ะทำงาน คุณจะขยับมือก็ต่อเมื่อมีบางอย่างเริ่มผิดพลาดเท่านั้น

ในทางปฏิบัติมีผลตามมาสองอย่างที่สำคัญกว่าทฤษฎีเสียอีก อย่างแรกคือ การแก้ไข (correction) ไม่ใช่ชุดสาธิตธรรมดา แต่จะกระจุกตัวอยู่ที่บริเวณคอขวด (bottleneck) ตามที่ Mandlekar และคณะอธิบายไว้ ซึ่งเป็นจุดที่ความเบี่ยงเบนเล็กน้อยจะพาโพลิซีเข้าสู่สถานะที่ชุดสาธิตไม่เคยครอบคลุม อย่างที่สองคือ ชุดข้อมูลที่ประกอบด้วยส่วนที่ยากเหล่านั้นเพียงอย่างเดียวเป็นชุดข้อมูลที่มีรูปทรงไม่ดี - Belkhale, Cui และ Sadigh โต้แย้งจากมุมมองด้านข้อมูลว่าความหลากหลายของสถานะ (state diversity) ไม่ได้ให้ประโยชน์เสมอไป และความแตกต่างของ action (action divergence) ร่วมกับความหลากหลายของการเปลี่ยนสถานะ (transition diversity) ต่างหากที่ร่วมกันตัดสินคุณภาพของชุดข้อมูล ชุดข้อมูลผสมจึงไม่ใช่การประนีประนอม แต่คือแก่นของเรื่องทั้งหมด

สิ่งที่ต้องล็อกให้คงที่ก่อนรอบแรก

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

• ตำแหน่งและฐานยึดกล้อง รวมถึงกล้องข้อมือด้วย เพียงคลายแคลมป์ตัวเดียวคุณก็เปลี่ยนการกระจายตัวของข้อมูลที่สังเกตได้ (observation) ไปแล้ว ไม่ใช่ตัวโพลิซี
• ค่า exposure และ white balance หากชุดอุปกรณ์บันทึกภาพของคุณให้ล็อกค่าได้ ค่า auto-exposure ที่เลื่อนไหลระหว่างรอบคือ domain shift แบบช้าๆ ที่มองไม่เห็น
• การคาลิเบรตแขนกลและตำแหน่งศูนย์ของเซอร์โว หากจำเป็นต้องคาลิเบรตใหม่ ให้ถือว่าทุกอย่างที่บันทึกไว้ก่อนหน้านั้นเป็นชุดข้อมูลแยกต่างหาก
• ข้อความ task VLA ทุกตัวในที่นี้ condition กับข้อความนี้ การเปลี่ยนคำระหว่างลูปเท่ากับเปลี่ยนเป็นคนละ task
• แสง พื้นผิวโต๊ะ ชุดวัตถุ วัตถุใหม่คือการทดลองใหม่ ไม่ใช่รอบถัดไป
• อัตราเฟรมของการบันทึก การเปรียบเทียบอัตราการแทรกแซงระหว่างสอง sampling raster ที่ต่างกันจะให้ผลต่างที่มาจาก raster เอง ไม่ใช่จากโพลิซี

หนึ่งรอบ ตั้งแต่ต้นจนจบ

1. 1
   รัน inference และบันทึกไว้

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

   bash

   # two calls, not one: the run, then its recording
   POST /inference/start      # model_id, and hf_repo_id = the checkpoint to drive
   POST /recording/start      # root=inference
   # root=inference also makes the recording inherit the run's task text

2. 2
   เข้าควบคุมเมื่อมันเริ่มผิดพลาด

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

   bash

   POST /inference/takeover/start   # input = leader | keyboard | sliders
   POST /inference/takeover/nudge   # keyboard, relative delta per call
   POST /inference/takeover/set     # sliders, absolute target
   POST /inference/takeover/stop    # back to the policy

3. 3
   คัดกรองแต่ละตอน

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

4. 4
   ซิงค์ชุดข้อมูลการแก้ไข

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

5. 5
   ประกอบชุดข้อมูลผสม

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

   bash

   POST /training/datasets/compose
     sources  = [ original_dataset, korrekturen_<policy> ]
     episodes = explicit selection per source

6. 6
   เทรนต่อจากเช็คพอยต์

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

   bash

   # field on the training job
   base_checkpoint = s3://ay-robots/checkpoints/<run>/<checkpoint>
   # the platform passes it to the training pod as BASE_CKPT_S3

ขั้นตอนที่ 2 โดยละเอียด: สองวิธีในการเข้าควบคุม

ด้วยแขน leader

ในโหมด leader-follower การเข้าควบคุมคือการส่งต่อระหว่างแขนสองข้างที่อยู่คนละท่า การกดปุ่ม Take over จะหยุดตัวรันชั่วคราวและขับแขน leader ให้ไปอยู่ในท่าปัจจุบันของ follower เพื่อไม่ให้เกิดการกระตุกเมื่อโอนถ่าย torque หากการขับให้ตำแหน่งตรงกัน (alignment drive) นี้หมดเวลาไป คุณต้องปรับแขน leader ให้ตรงด้วยมือ และจะปล่อยได้ก็ต่อเมื่อทั้งสองท่าต่างกันไม่เกินห้าองศาเท่านั้น จากจุดนั้นเป็นต้นไปคุณจะควบคุมระยะไกลตามปกติ และคอลัมน์ action จะบันทึกสิ่งที่คุณสั่งไป

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

ไม่มีแขน leader: คีย์บอร์ดและสไลเดอร์

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

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

Q / A   joint 1      R / F   joint 4
W / S   joint 2      T / G   joint 5
E / D   joint 3      Z / X   gripper

เมื่อไรควรกดปุ่ม

เร็วไว้ก่อนดีกว่าช้า การแก้ไขที่เริ่มหลังจากกริปเปอร์หุบลงโดยไม่ได้จับอะไรไปแล้ว เป็นการสอนให้ฟื้นตัว (recovery) จากความล้มเหลวที่โพลิซีไม่ควรเข้าไปตั้งแต่แรก และข้อมูล recovery มีค่าน้อยกว่าข้อมูลการหลีกเลี่ยง (avoidance) มาก จงขัดจังหวะทันทีที่คุณมั่นใจว่าวิถี (trajectory) กำลังผิดพลาด แก้ไขผ่านช่วงที่ยาก แล้วส่งการควบคุมกลับทันทีที่สถานะกลับมาเป็นแบบที่โพลิซีเคยจัดการได้มาก่อน ThriftyDAgger ทำให้การตัดสินใจนี้เป็นอัตโนมัติโดยการกำหนดเงื่อนไขการแทรกแซงตามความแปลกใหม่ (novelty) และความเสี่ยงที่ประเมินได้ ภายใต้งบประมาณการแทรกแซงของมนุษย์ที่กำหนดไว้ตายตัว แต่สำหรับแขนกลเพียงข้างเดียวที่มีมนุษย์คอยเฝ้าดูอยู่แล้ว การตัดสินใจของมนุษย์เองก็มีต้นทุนต่ำกว่าและปรับเทียบได้ดีกว่าสิ่งใดที่คุณจะจูนขึ้นมาเอง

ขั้นตอนที่ 3 โดยละเอียด: การคัดกรองเป็นตัวตัดสินคุณภาพ

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

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

ขั้นตอนที่ 5 โดยละเอียด: การประกอบชุดผสม

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

คำถามที่ยังไม่มีคำตอบคือสัดส่วนของการผสม และยังไม่มีใครมีตัวเลขที่ใช้ได้ทั่วไป สิ่งที่งานวิจัยเห็นพ้องกันคือการแก้ไขควรมีน้ำหนักมากกว่าสัดส่วนเฟรมของมันเอง Mandlekar และคณะเทรนซ้ำแบบวนซ้ำบนข้อมูลที่ระบบแทรกแซงของพวกเขาเก็บรวบรวมมา เพื่อให้โพลิซีเรียนรู้ที่จะผ่านจุดคอขวดไปได้ และรายงานว่า agent ที่เทรนด้วยวิธีนี้มีประสิทธิภาพเหนือกว่า agent ที่เทรนด้วยจำนวนตัวอย่างเท่ากันจากผู้สาธิตที่ไม่มีการแทรกแซง Sirius ไปไกลกว่านั้นด้วยการถ่วงน้ำหนักตัวอย่างเทรนตามค่าความไว้วางใจของมนุษย์โดยประมาณ (approximated human trust) โดยรายงานว่าอัตราความสำเร็จของโพลิซีดีขึ้น 8 เปอร์เซ็นต์ในการจำลองสถานการณ์ และ 27 เปอร์เซ็นต์บนฮาร์ดแวร์จริง เมื่อเทียบกับวิธีอื่นที่นำมาเปรียบเทียบ ด้วยความเร็วในการลู่เข้า (convergence) ที่เร็วกว่าถึงสองเท่า จุดเริ่มต้นการเทรนในที่นี้ไม่มีตัวใดเปิดให้ปรับน้ำหนักตัวอย่าง (sample-weighting) ได้เลย ทางออกแบบหยาบๆ จึงคือการเก็บทุกตอนของการแก้ไขไว้ทั้งหมด ในขณะที่สุ่มตัดทอนชุดสาธิตดั้งเดิมลง - และจดบันทึกไว้ว่าคุณทำอะไรไปบ้าง

ขั้นตอนที่ 6 โดยละเอียด: การเทรนต่อจากเช็คพอยต์หมายความว่าอย่างไรกันแน่

การเทรนชุดผสมจาก base model นั้นทำได้ แต่จะทิ้งรอบก่อนหน้าไปและมีต้นทุนเท่ากับการรันเต็มรูปแบบใหม่ทั้งหมด การเทรนต่อจาก checkpoint ก่อนหน้านั้นรวดเร็วกว่าและมักจะดีกว่า แต่ก็มีข้อจำกัดมากกว่าที่คำนี้ฟังดูเป็น

ความหน่วง (latency) จะสะสมภายในลูป DAgger ในแบบที่ไม่เกิดขึ้นระหว่างการสาธิต: ที่ความหน่วงประมาณ 485 มิลลิวินาทีต่อ action step คุณจะเข้าควบคุมเพราะแขนกลลังเล ไม่ใช่เพราะมันทำผิด และการแก้ไขจากความลังเลไม่ใช่ข้อมูลเทรนที่มีประโยชน์ หากคุณกำลังทำซ้ำ (iterate) เพื่อปรับปรุงข้อมูลมากกว่าจะไล่ตามอัตราความสำเร็จสุดท้าย ควรทำซ้ำด้วยโมเดลที่เร็ว Shukor และคณะอธิบายว่า SmolVLA ถูกออกแบบมาให้เทรนได้บน GPU ตัวเดียว และนำไปใช้งานได้บน GPU หรือ CPU ระดับผู้บริโภคทั่วไป ด้วยสถาปัตยกรรม inference แบบ asynchronous ที่แยกการทำนาย action ออกจากการปฏิบัติงานจริง เพื่อให้ได้อัตราการควบคุมที่สูงขึ้น - คุณสมบัตินี้เองที่ทำให้ลูปการเข้าควบคุมตอบสนองได้ทันท่วงที

รูปแบบชุดข้อมูลก็ใช้แทนกันไม่ได้เช่นกัน GR00T ใช้ LeRobot v2.0 หรือ v2.1 และ repository ของ Isaac-GR00T อธิบายอินพุตของมันว่าเป็นรูปแบบ LeRobot v2 อีกแบบหนึ่งที่เพิ่มไฟล์อธิบาย modality เข้ามา ส่วนตัวเทรนรุ่นใหม่กว่าในที่นี้ต้องการ v3.0 ชุดผสมที่ประกอบขึ้นผิดเวอร์ชันจะล้มเหลวตอนโหลดข้อมูล แทนที่จะสร้างโพลิซีที่แย่ออกมา - ซึ่งเป็นรูปแบบความล้มเหลวที่ดีกว่า แต่ก็ยังเสียคิวการเทรนไปโดยเปล่าประโยชน์ เอกสาร เอกสารชุดข้อมูล ระบุไว้ว่าตัวเทรนแต่ละตัวใช้รูปแบบใด

สี่วิธีที่ทำให้หนึ่งรอบสูญเปล่า

1. เทรนด้วยการแก้ไขเพียงอย่างเดียว

เป็นความล้มเหลวที่พบบ่อยที่สุด และเป็นทางลัดที่ล่อใจที่สุด ชุดข้อมูลที่มีแต่การแก้ไขล้วนๆ นั้นแทบทั้งหมดคือช่วงกลางที่ยากของ task โดยขาดช่วงเข้าใกล้ (approach) และช่วงถอยออก (retreat) ไป โพลิซีจะเก่งขึ้นในส่วนที่ยาก แต่ลืมวิธีไปให้ถึงจุดนั้น การรวมชุดข้อมูล (aggregation) ไม่ใช่รายละเอียดปลีกย่อยของการทำ implement แต่คือกลไกหลักของวิธีนี้เอง: ข้อมูลเก่านั้นเองที่ยึดพฤติกรรมส่วนที่เหลือให้คงอยู่ ในขณะที่การแก้ไขปรับเปลี่ยนเพียงส่วนหนึ่งของมัน

2. ขยับกล้องระหว่างรอบ

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

3. ปล่อยให้ artefact จากการส่งต่อการควบคุมเข้าไปในข้อมูลเทรน

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

4. เรียก warm start ว่าเป็นการ resume

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

การวัดผลของหนึ่งรอบ

ตัวชี้วัดของลูปที่มีมนุษย์คอยกำกับคืออัตราการแทรกแซง (intervention rate): จำนวนเฟรมที่บันทึกไว้ขณะที่คุณเป็นผู้ควบคุม หารด้วยจำนวนเฟรมทั้งหมดของการรัน ค่านี้อยู่ในสถานะของการ takeover และเป็นตัวเลขเดียวที่ตอบคำถามที่รอบนั้นตั้งขึ้นมา training loss จะลดลงไม่ว่าโพลิซีจะดีขึ้นจริงหรือไม่ก็ตาม ส่วนอัตราความสำเร็จ (success rate) เป็นค่าแบบ binary และมีสัญญาณรบกวนสูงเมื่อขนาดตัวอย่างมีจำกัดอย่างที่แขนกลบนโต๊ะทำงานจะให้ได้ ในขณะที่อัตราการแทรกแซงเป็นค่าต่อเนื่อง วัดจากสถานะที่โพลิซีเป็นผู้ก่อขึ้นเอง และจะลดลงเมื่อโพลิซีต้องการคุณน้อยลง

ควรเปรียบเทียบเฉพาะระหว่างการรันที่บันทึกภายใต้เงื่อนไขเดียวกันทุกประการเท่านั้น เหตุผลแบบละเอียด และวิธีสร้างชุดข้อมูลประเมินผลที่ใช้ได้นานเกินสองรอบ อยู่ใน บทความเรื่องการวัดผลลูป DAgger ในทางปฏิบัติแล้ว รอบแรกคือการทดสอบความเป็นไปได้ (feasibility test): คุณกำลังตรวจสอบว่าการ takeover ทำงานได้บนฮาร์ดแวร์ของคุณ การแก้ไขลงเอยพร้อมเครื่องหมายที่ถูกต้อง และการรันที่เทรนต่อโหลดเช็คพอยต์ที่คุณระบุไว้จริง รอบที่สองและสามคือช่วงที่อัตรานี้ควรเริ่มขยับ หากถึงรอบที่สี่แล้วยังไม่ขยับ ปัญหาอยู่ต้นน้ำก่อนถึง DAgger เสียแล้ว

หากคุณยังไม่มีเช็คพอยต์

ลูปนี้ไม่มีจุดเริ่มต้นหากไม่มีเช็คพอยต์ ให้บันทึกชุดข้อมูลแรก เทรนโพลิซีแรก แล้วรันมัน - recording, training และ running the policy ครอบคลุมเส้นทางนี้ไว้แล้ว ไคลเอนต์สำหรับบันทึกข้อมูลอยู่บน หน้าดาวน์โหลด ระดับ GPU และอัตราค่าใช้จ่ายรายชั่วโมงอยู่บน หน้าราคา และตัวอย่างว่าตอนที่ใช้งานได้หน้าตาเป็นอย่างไรอยู่ใน คู่มือการเก็บข้อมูล SO-100 ทำให้ชุดสาธิตถูกต้องเสียก่อนที่จะไปถึงการแก้ไข: DAgger คือกลไกซ่อมแซม และมันได้ผลดีกว่ามากกับสิ่งที่เกือบจะถูกต้องอยู่แล้วตั้งแต่ต้น

ไม่มีสิ่งใดในนี้ที่เป็นปัญหาที่แก้ไขจบสมบูรณ์แล้ว และไม่มีอะไรทำได้ในคลิกเดียว การเรียนรู้เลียนแบบแบบโต้ตอบ (interactive imitation learning) เป็นสาขาวิจัยที่ยังคงเคลื่อนไหวอยู่ ก็เพราะคำถามของมัน - ควรแทรกแซงเมื่อไร ควรถ่วงน้ำหนักสิ่งที่มนุษย์ทำอย่างไร ควรเก็บข้อมูลเก่าไว้มากแค่ไหน - ยังไม่มีคำตอบที่ลงตัว งานสำรวจวรรณกรรมโดย Celemin และคณะได้แสดงให้เห็นว่ายังมีอะไรเปิดกว้างอยู่บ้าง สิ่งที่ลูปนี้มีจริงคือการลู่เข้า (convergence) ที่วัดผลได้เมื่อรันอย่างระมัดระวัง บนฮาร์ดแวร์ที่มีราคาเพียงไม่กี่ร้อยยูโร ล็อกการติดตั้งให้คงที่ แทรกแซงแต่เนิ่นๆ คัดกรองอย่างตรงไปตรงมา ผสมข้อมูลอย่างมีเจตนา และบันทึกอัตราการแทรกแซงทุกครั้ง