Robo-COP는 배포 중 오케스트레이터와 정책을 함께 진화시킨다

무엇인가

VLA(시각-언어-행동) 정책은 대규모 데이터로 학습해도 배포 현장에서 마주치는 다양한 상황으로 가면 무너진다. 이를 보완하려고 VLM 오케스트레이터가 정책을 언제 호출할지, 어떤 지시를 줄지, 언제 스크립트된 스킬로 대신할지를 학습하는 에이전트형 로봇 시스템이 등장했다. 그러나 이런 하네스는 고정된(frozen) 정책을 전제로 만들어져서, 오케스트레이터는 정책의 실패를 피해 갈 수는 있어도 고칠 수는 없다. 정책이 시스템 전체의 병목이 된다. 반대로 정책만 파인튜닝하면 옛 정책의 행동에 맞춰 조정된 오케스트레이터와 어긋난다. 이 논문은 배포 중에 둘을 함께 진화시키는 문제를 다룬다.

어떻게 동작하나

Robo-COP는 CaP-X 실행 도구 위에 만들어진 구현형 코딩 에이전트에 execute_vla 도구를 추가한 구조다. 오케스트레이터는 과제 목표, 현재 관측, 에피소드 이력, 과제 메모리 M을 조건으로 스크립트 모션 프리미티브, 지각 함수, VLA 정책을 호출하는 프로그램을 작성한다. VLM이 실행을 감시하다 호출을 중단시키거나 에피소드를 끝낼 수 있고, 실행이 멈추면 비주얼 저지가 결과를 판정해 에피소드를 종료하거나 수정 코드를 요구한다. VLA 호출과 스크립트 동작에 각각 크레딧을 부여해, 뒤 단계가 실패해도 성공한 스킬의 크레딧은 유지된다. 에피소드가 끝나면 무엇이 됐고 안 됐는지 M에 기록한다. 학습 데이터는 자기 실행에서 나와야 하는데, 유용한 동작 상당수는 정책이 아니라 스크립트 프리미티브가 만든다. 한 실행 안에서 VLA 호출과 스크립트 프리미티브가 번갈아 나오므로, 매 스텝의 관절 목표 명령, 그리퍼 명령, 관측, 로봇 상태를 실행 순서대로 기록해 VLA 학습 포맷의 연속 액션 스트림을 만든다. 이렇게 하면 스크립트로 만든 부분이 섞여 있어도 "빨간 블록을 집어라" 같은 라벨의 데모가 된다.

무엇과 다른가

경험 큐레이션은 세그먼트를 에피소드 결과와 독립적으로 평가한다. 블록을 집어 든 뒤 떨어뜨려도 집기 세그먼트는 학습 예가 될 수 있고, 성공한 에피소드라고 모든 세그먼트가 유효한 것도 아니다. 텍스트 저지가 실행된 코드, 콘솔 출력, 에피소드 피드백으로 각 세그먼트의 의도된 스킬과 결과를 판정하고, VLA 호출은 전달된 지시를 그대로 유지하며, 스크립트 프리미티브는 연속 호출을 하나의 모션 수준 스킬로 묶는다. 이어 비디오 저지가 샘플링한 프레임을 제안된 지시와 대조해, 텍스트 저지가 수락하고 비디오 저지가 성공 또는 명확한 부분 진전을 확인한 세그먼트만 데이터셋 D에 들어간다. 학습 시점은 언어모델 컨트롤러가 결정한다. 지금까지의 큐레이션 데모와 최근 성능, 과제 메모리, 실패, 이전 시도를 검토해 train 또는 wait을 반환한다. 고정 스케줄 학습은 이미 하네스가 푸는 과제에도 학습해 위험만 더하고, 데모가 충분히 쌓이기 전에 학습할 수 있다. train 결정은 최대 4개의 목표 스킬 지시 E를 지정하고, 학습은 지금까지 모은 모든 큐레이션 데이터로 사전학습 체크포인트에서 LoRA와 원래의 flow-matching 목적함수로 후보 π'를 파인튜닝한다. 학습 중에는 배포가 멈추고, π는 후보 평가의 기준선으로 남는다.

어떻게 쓰나

후보 π'는 W회 시행 창에서 평가되고, 배포 정책 π는 폴백으로 유지된다. 폴백이 과제를 완료할 수 있으므로 과제 성공만으로는 후보 성능을 알 수 없어, 검증은 에피소드 수준이 아니라 스킬 수준에서 한다. 또 각 후보는 모든 큐레이션 데이터로 베이스 정책에서 파인튜닝되므로 이전 업데이트가 추가한 스킬을 잃을 수 있어, 이전 후보들과 함께 채택된 admitted skills 집합 S에 대한 회귀도 검사한다. 조건은 succ(W) ≥ b − δ_task, 그리고 모든 s ∈ S_obs에 대해 r_c(s) ≥ r_inc(s) − δ_skill이다. 여기서 b는 현역 정책의 최근 과제 성공률, r은 호출당 완료율이다. 후보 호출이 너무 적으면 starved로 판정해 후보를 버리고 메모리를 그대로 둔다. 부등식이 깨지면 revert하고 π를 유지한다. 목표 스킬 E에 대해서는 언어모델 리뷰어가 생성 코드, 출력 로그, 비주얼 저지 출력을 보고 각 호출이 실제로 무엇을 달성했는지 확인한다. 채택은 평가 창이 끝날 때만 결정되지만, 명백히 실패하면 더 일찍 되돌릴 수 있다. 정책이 바뀌어도 과제 메모리의 조언은 그대로다. 예를 들어 이전 VLA 집기 실패 때문에 빨간 블록 집기에 스크립트 모션을 쓰라고 메모리가 권하면, 업데이트 후에도 그 권고를 따르면 새 정책이 집기를 잘할 수 있다는 걸 하네스가 발견하지 못한다. 그래서 채택이든 되돌림이든 후보를 가리키는 참조를 현재 서비스 중인 정책 이름으로 바꾸고, VLA 사용을 피하게 만드는 조언은 현재 체크포인트 기준 미검증으로 표시한다. 삭제하지 않고 표시만 해서 이후 에피소드가 재검증할 수 있게 하고 이력은 남긴다.

전제와 한계

실험은 RoboLab의 10개 과제(객체 배치 무작위화, retrieval·grouping·placement·recovery)에서 수행했다. 사전학습 VLA만으로 되는 과제, 스크립트 프리미티브로 되는 과제, 둘 다 필요한 과제의 세 영역을 고르게 덮는다. 초기 VLA는 DROID로 학습된 π0.5를 학습 시 제어 레이트로 서빙하고, 오케스트레이터는 Gemini 3.8 Flash가 맡는다. 베이스라인은 π0.5 단독, frozen-policy(같은 하네스와 에피소드 반성을 쓰되 가중치는 고정), fixed schedule(30 시행마다 학습하고 검증 없이 배포), ASPIRE(알고리즘을 벤치마크와 API 환경에 맞게 각색)다. 각 시스템은 과제당 100회 배포 시행을 하고 처음 30회는 공유하며, 이후 정책과 메모리를 고정한 뒤 과제당 50개의 held-out 초기화로 측정한다. 결과는 Robo-COP 73.8%로 frozen-policy 64.8%, fixed schedule 65.8%를 앞섰다. fixed schedule은 9.0점 차이 중 1.0점만 회복했다. 업데이트를 채택한 6개 과제에서 frozen 대비 평균 11.3점, 베이스 정책을 유지한 4개 과제에서 5.5점을 얻었다. 한 과제씩 빼도 frozen 대비 4.0~12.0점, fixed 대비 4.9~10.7점이 남는다. 영역별로는 VLA만으로 충분한 곳에서 π0.5가 82.0%, frozen·fixed 하네스가 89.3%, Robo-COP가 80.0%, ASPIRE가 66.0%였다. 스크립트로 충분한 곳에서는 ASPIRE 73.5%, Robo-COP 72.0%, frozen 55.0%, fixed 50.0%였고, 둘 다 필요한 곳에서는 ASPIRE가 16.0%로 떨어지는 반면 Robo-COP는 70.0%로 frozen 대비 16.7점 앞섰다. 파인튜닝이 가장 크게 개선한 스킬은 grasping이었다. Robo-COP는 held-out 500회 중 131회 실패해 frozen의 176회보다 적었고, 양쪽의 지배적 실패인 grasp or drop(각 40회, 68회)이 줄어든 45개 실패 중 28개를 설명한다. 모든 첫 학습 요청이 pickup 스킬을 목표로 삼았다. 컨트롤러는 하네스가 자주 실패한 7개 과제(frozen 배포 성공률 45~79%)에서 학습을 요청하고, 거의 실패하지 않은 3개(80~96%)에서는 대기했다. 그 3개 과제에서 fixed schedule의 9회 학습은 순이득이 없었다. 검증은 12개 후보 중 5개를 거부했고, 첫 후보가 되돌려진 4개 과제 중 3개에서 fixed schedule이 frozen보다 낮은 성적을 냈으니 거부가 실제 회귀를 막은 셈이다. 거부가 학습을 끝내지도 않아 그 4개 중 3개에서 다음 후보가 채택됐다. Recycle cup clutter에서는 45·75 시행 후 학습을 요청해 70·100 시행에 채택했고, 마지막 25회 배포 시행에서 76%를 기록해 frozen 60%, fixed 52%를 앞섰다. 배포 중 성공을 희생하지도 않았다. 100회 배포 시행 성공률이 73.2%로 frozen 68.7%, fixed 70.3%보다 높았고, 30 시행 이후 구간에서 72.9% 대 66.4%·68.7%, 마지막 25회에서 73.6% 대 67.6%·67.2%였다. ASPIRE는 100회 예산을 탐색에 써서 비교 가능한 배포 성공률이 없다.

실세계에서는 40초·60초·90초 제한의 물리 과제 3개에서 과제당 학습 50회, held-out 20회, 채택 창 W=10으로 실험했다. 60초 과제는 30 시행에 학습해 후보가 채택됐고 held-out 성공률이 35%에서 70%로 두 배가 됐다. 40초 과제도 30 시행에 학습했지만 후보가 여러 평가 시행에서 실패해 되돌렸고, 학습 성공률 44% 대 46%, held-out 40% 대 40%로 frozen-policy와 비슷하게 유지됐다. 90초 과제는 컨트롤러가 학습하지 않아 양쪽이 같은 학습 궤적을 공유하며 40%에 도달했다. 이 과제에서 강제로 학습시켜 검증 없이 배포한 별도 진단 실험은 held-out 20%로 두 시스템의 절반에 그쳤다. 세 과제 평균 held-out 성공률은 38.3%에서 50.0%로 올랐다.

개발자 관점에서 이 논문의 실질적 자산은 배포 로그를 스킬 단위 라벨로 바꾸는 파이프라인이다. 텍스트 저지와 비디오 저지의 이중 확인을 거쳐, 실패한 에피소드 안에서 성공한 세그먼트까지 학습 데이터로 살려내는 것이 데이터 효율의 핵심이다. 또 파인튜닝을 무조건 돌리지 말고 학습 시점을 판단하는 컨트롤러와, 스킬 수준 회귀 검사를 포함한 후보 검증을 붙여야 한다. 고정 스케줄 학습은 9점 차이 중 1점만 회복했고, 검증 없는 배포는 실제로 성능을 떨어뜨린 사례가 시뮬레이션과 실세계 양쪽에서 나왔다. 정책을 교체하면 그 정책에 맞춰 쌓인 프롬프트·조언 메모리를 반드시 재검증해야 한다는 점도 중요하다. 그대로 두면 새 정책이 할 수 있는 일을 하네스가 계속 차단한다. 이를 위해서는 호출당 완료율 같은 스킬 수준 지표를 평소에 로깅해 둬야 검증 자체가 가능하다.

저자들이 밝힌 한계는 분명하다. 모든 학습 예가 자기 실행에서 나오므로, 정책과 스크립트 도구가 최소한 부분적으로라도 시연할 수 있는 스킬만 배울 수 있다. 물리 배포에는 사람의 리셋이 필요하고, 정책 업데이트마다 큐레이션·학습·평가 비용이 추가된다. 스크립트 프리미티브가 이미 과제를 커버하는 경우(Fill the empty bin, Sort blocks by initial stack position)에는 ASPIRE의 프로그램 탐색이 Robo-COP보다 낫다. Robo-COP의 오케스트레이터는 프로그램을 구조적으로 탐색하지 않고 메모리로 적응하기 때문이다. 모든 설계 요소가 실험으로 검증됐지만 더 큰 규모의 실험에서 확장성이 확인돼야 한다는 점도 남겨 뒀다. 향후 과제로는 배포 루프 안에서 구조적 스킬 탐색을 돌리고, 배포 결과로 오케스트레이터 자체를 강화학습으로 정렬하며, 여러 과제에서 모은 스킬로 단일 정책을 학습해 교차 과제 일반화를 얻는 방향을 제시한다. 현재 Robo-COP가 업데이트하는 것은 정책과 오케스트레이터 메모리뿐이고, 스크립트 스킬과 저지, 오케스트레이터의 추론은 고정이라는 점이 전제다.