정책 평가와 벤치마킹

학습 손실이 낮아도 로봇은 실패할 수 있다

정책 학습이 끝나면 가장 먼저 확인하는 값은 보통 학습 손실입니다. 손실이 내려가면 모델이 좋아진 것처럼 보입니다. 저장된 영상에서 로봇 팔이 그럴듯하게 움직이면 더 안심됩니다. 하지만 이것만으로는 충분하지 않습니다.

로봇 정책의 최종 기준은 실제 태스크를 끝까지 수행했는지입니다. 큐브를 집어 상자에 넣는 태스크라면, 로봇이 큐브 근처까지 갔는지가 아니라 큐브가 실제로 상자 안에 들어갔는지가 중요합니다. 문을 여는 태스크라면, 손잡이에 접근한 것이 아니라 문이 정해진 각도 이상 열렸는지가 기준이 됩니다.

따라서 평가를 시작하기 전에 먼저 "성공"과 "실패"를 문장으로 고정해야 합니다. 평가 중간에 기준을 바꾸면 결과를 믿을 수 없습니다. 다음과 같은 항목을 미리 정합니다.

• 성공 조건: 태스크가 완료되었다고 판단하는 상태

• 실패 조건: 물체를 떨어뜨림, 충돌, 시간 초과, 작업 공간 이탈 등

• 제한 시간: 한 에피소드에 허용할 최대 시간

• 사람 개입 기준: 언제 비상 정지하거나 수동으로 멈출지

• 재시도 허용 여부: 한 에피소드 안에서 다시 잡기를 허용할지

예를 들어 "빨간 블록을 집어 상자에 넣기"라면 성공 조건은 "블록이 상자 내부에 있고, 로봇 그리퍼가 블록을 놓은 뒤 2초 이상 안정적으로 유지됨"처럼 적을 수 있습니다. 실패 조건은 "60초 안에 완료하지 못함", "블록이 테이블 밖으로 떨어짐", "로봇이 금지 영역에 접촉함", "사람이 개입함"처럼 정합니다.

AI 생성 이미지

실로봇 평가 지표 정하기

실로봇 평가는 가능한 한 숫자로 남겨야 합니다. 숫자가 있어야 체크포인트를 비교할 수 있고, 다음 데이터 수집 방향도 정할 수 있습니다.

가장 기본 지표는 성공률입니다.

성공률 = 성공한 에피소드 수 / 전체 평가 에피소드 수

10번 중 7번 성공했다면 성공률은 70%입니다. 단, 10번은 너무 적을 수 있습니다. 물체 위치나 조명이 조금만 달라져도 결과가 바뀌는 태스크라면 최소 20~50회 이상 반복해 보는 것이 좋습니다.

성공률만 보면 놓치는 정보도 있습니다. 두 모델이 모두 80% 성공하더라도 한 모델은 평균 12초 만에 끝내고, 다른 모델은 55초에 겨우 성공할 수 있습니다. 그래서 다음 지표를 함께 기록합니다.

• 평균 완료 시간: 성공한 에피소드가 끝나기까지 걸린 시간

• 시간 초과율: 제한 시간 안에 끝내지 못한 비율

• 충돌·접촉 오류 횟수: 금지된 물체, 카메라, 테이블, 사람과의 접촉

• 재시도 횟수: 잡기 실패 후 다시 시도한 횟수

• 물체 낙하 횟수: 들어 올린 물체를 떨어뜨린 횟수

• 안전 정지 발생 여부: 비상 정지, 속도 제한 초과, 작업 공간 이탈

• 사람 개입 횟수: 평가자가 중간에 멈추거나 자세를 수정한 횟수

안전 관련 지표는 평균 성능보다 더 중요할 때가 많습니다. 어떤 정책이 95% 성공하더라도 20회 중 1회 로봇이 카메라를 치거나 사람 쪽으로 빠르게 움직인다면 실사용 모델로 선택하기 어렵습니다.

lerobot-rollout으로 빠르게 실행해 보기

LeRobot에서 학습된 정책을 실제 로봇에 실행할 때는 lerobot-rollout을 사용합니다. 이 명령은 실제 로봇에 정책을 배포하는 기본 CLI이며, 실행 전략에 따라 기록 방식과 사람 개입 방식이 달라집니다.¹

가장 단순한 방식은 base 전략입니다.

lerobot-rollout \
  --strategy.type=base \
  --policy.path=${HF_USER}/my_policy \
  --robot.type=so100_follower \
  --robot.port=/dev/ttyACM0 \
  --robot.cameras="{ front: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30}}" \
  --task="Put lego brick into the box" \
  --duration=60 \
  --device=cuda

base 전략은 정책을 자율 실행하지만 데이터를 기록하지 않습니다. 그래서 빠른 확인, 데모, 초기 관찰에 적합합니다. 예를 들어 체크포인트가 아예 움직이지 않는지, 카메라 이름이 맞는지, 로봇이 이상한 방향으로 가지 않는지 확인할 때 유용합니다. --display_data를 켜면 관찰값과 행동을 Rerun으로 시각화할 수 있어 초반 디버깅에 도움이 됩니다.¹

하지만 정량 평가에는 base만으로 부족합니다. 기록이 없으면 나중에 "왜 실패했는지"를 분석하기 어렵고, 평가자가 현장에서 본 기억에 의존하게 됩니다. 정식 평가는 별도의 영상 저장, 로그 저장, 또는 기록 가능한 전략과 함께 진행해야 합니다.

LeRobot에는 연속 기록용 sentry, 필요한 순간을 저장하는 highlight, 사람 개입을 포함한 dagger 전략도 있습니다. sentry는 자율 실행을 계속 기록하고, 에피소드를 나누어 Hugging Face Hub에 업로드할 수 있습니다. highlight는 최근 몇 초의 텔레메트리를 버퍼에 담아 두었다가 중요한 실패나 성공 장면을 저장할 수 있습니다. dagger는 정책 실행 중 사람이 개입한 프레임을 표시할 수 있어, 실패를 교정 데이터로 다시 모으는 데 유용합니다.¹

평가 조건을 고정하고, 일부러 바꿔 보기

좋은 평가는 두 종류의 조건을 모두 포함해야 합니다.

첫째, 훈련 데이터와 비슷한 조건입니다. 이 조건에서 실패한다면 모델이 기본 태스크를 아직 배우지 못한 것입니다. 둘째, 훈련 데이터와 조금 다른 조건입니다. 이 조건은 일반화 성능을 보기 위한 것입니다. 로봇이 외운 장면에서만 성공하는지, 실제 변화에도 버티는지 확인합니다.

평가 조건은 다음 항목을 기준으로 나눌 수 있습니다.

• 초기 물체 위치: 중앙, 왼쪽, 오른쪽, 로봇에서 가까움, 멂

• 물체 방향: 손잡이 방향, 블록 회전, 병 라벨 방향

• 조명: 밝음, 어두움, 그림자 있음

• 배경: 단순한 배경, 복잡한 배경, 다른 물체가 있는 배경

• 카메라 시야: 학습 때와 같은 위치, 약간 이동한 위치

• 장애물: 없음, 낮은 장애물, 집기 경로 근처의 방해 물체

• 로봇 시작 자세: 기본 자세, 약간 접힌 자세, 그리퍼 방향이 다른 자세

중요한 점은 조건을 즉흥적으로 바꾸지 않는 것입니다. 평가 전에 "초기 조건 목록"을 만듭니다. 예를 들어 5개의 물체 위치와 2개의 조명 조건을 조합하면 10개 조건이 됩니다. 각 조건을 3회씩 반복하면 총 30개 에피소드가 됩니다. 이후 다른 체크포인트를 평가할 때도 같은 30개 조건을 그대로 사용합니다.

이렇게 해야 우연한 성공을 줄일 수 있습니다. 어떤 모델이 특정 물체 위치에서만 강한지, 조명이 바뀌면 급격히 실패하는지, 시작 자세가 조금 달라지면 경로를 잃는지 확인할 수 있습니다.

에피소드 단위로 실패를 남기기

평가의 목적은 점수를 매기는 것에서 끝나지 않습니다. 실패 원인을 찾아 다음 학습을 개선하는 것이 더 중요합니다. 그래서 각 에피소드마다 최소한 다음 정보를 남깁니다.

• 에피소드 ID

• 정책 이름과 체크포인트 경로

• 태스크 설명

• 초기 조건

• 성공 또는 실패 판정

• 완료 시간

• 관찰 이미지 또는 영상

• 로봇 상태값

• 정책이 출력한 행동값

• timestamp

• 사람 개입 여부

• 실패 유형

• 짧은 메모

실패 유형은 너무 복잡하게 만들 필요가 없습니다. 처음에는 다음 정도면 충분합니다.

이 분류가 쌓이면 다음 행동이 분명해집니다. 인식 오류가 많다면 카메라 각도, 조명, 배경이 다양한 데이터를 더 모아야 합니다. 집기 실패가 많다면 그리퍼가 물체에 닿기 직전의 시연을 더 정밀하게 수집해야 합니다. 경로 문제가 많다면 시작 자세와 중간 경로가 다양한 에피소드를 추가하는 편이 좋습니다.

체크포인트와 정책 버전 비교하기

정책을 여러 번 학습하면 체크포인트가 많이 생깁니다. 마지막 체크포인트가 항상 최고는 아닙니다. 과적합이 생기면 학습 데이터에는 잘 맞지만 실제 조건에서는 더 나빠질 수 있습니다.

비교할 때는 다음 조건을 반드시 동일하게 맞춥니다.

• 같은 로봇 하드웨어

• 같은 카메라 위치와 해상도

• 같은 action/state 정의

• 같은 태스크 문장

• 같은 초기 조건 목록

• 같은 반복 횟수

• 같은 제한 시간

• 같은 평가자 개입 규칙

결과 표에는 평균만 넣지 않습니다. 평균 성공률, 평균 시간, 최악 사례, 안전 실패 수를 함께 봅니다.

이 표에서 단순히 성공률만 보면 ACT-ckpt-40k가 좋아 보입니다. 하지만 충돌과 안전 정지가 늘었다면 최종 배포 모델로는 부적절할 수 있습니다. 실제 로봇에서는 "가장 많이 성공한 모델"보다 "충분히 성공하면서 위험한 실패가 적은 모델"이 더 좋은 선택일 때가 많습니다.

시뮬레이션 벤치마크로 먼저 걸러내기

실로봇 평가는 비용이 큽니다. 시간이 오래 걸리고, 하드웨어가 마모되며, 실패가 누적되면 로봇이나 주변 장비가 손상될 수 있습니다. 그래서 가능하면 시뮬레이션에서 많은 후보를 먼저 걸러내고, 좋은 후보만 실제 로봇에서 검증하는 흐름이 안전합니다.

LeRobot은 Isaac Lab-Arena와 LeRobot EnvHub를 통해 시뮬레이션 환경을 불러와 정책을 평가하는 흐름을 지원합니다. Isaac Lab-Arena는 로봇 정책을 시뮬레이션에서 확장성 있게 평가하기 위한 프레임워크이며, LeRobot EnvHub는 이런 환경을 공유하고 불러오는 역할을 합니다.²

예를 들어 Isaac Lab-Arena 환경에서는 environment, embodiment, object 같은 요소를 바꿔 태스크 조건을 구성할 수 있습니다. 공개 예시에서는 gr1_microwave 환경, gr1_pink embodiment, mustard_bottle object를 지정해 SmolVLA 정책을 평가하는 명령을 사용합니다. 카메라 키, 상태 키, 비디오 저장 여부도 명령에서 명시합니다.²

lerobot-eval \
  --policy.path=nvidia/smolvla-arena-gr1-microwave \
  --env.type=isaaclab_arena \
  --env.hub_path=nvidia/isaaclab-arena-envs \
  --policy.device=cuda \
  --env.environment=gr1_microwave \
  --env.embodiment=gr1_pink \
  --env.object=mustard_bottle \
  --env.enable_cameras=true \
  --env.video=true \
  --eval.batch_size=1

시뮬레이션 벤치마크의 장점은 조건을 반복하기 쉽다는 점입니다. 같은 태스크에서 사람 시연, 기존 정책, 새 정책을 같은 초기 조건으로 비교할 수 있습니다. 물체 종류, 위치, 시나리오를 바꿔 일반화 성능도 더 넓게 볼 수 있습니다.

물론 시뮬레이션 성공이 실로봇 성공을 보장하지는 않습니다. 마찰, 카메라 노이즈, 모터 지연, 물체 재질은 현실과 다를 수 있습니다. 따라서 시뮬레이션은 최종 판정이 아니라 후보를 줄이는 단계로 이해하는 편이 좋습니다. 마지막 결정은 항상 실제 로봇 평가로 확인해야 합니다.

평가 결과를 다음 학습으로 연결하기

평가는 책의 마지막 단계가 아니라 학습 루프의 한 부분입니다. 실패 유형을 모으면 다음 데이터셋이 보입니다.

• 특정 위치에서만 실패한다 → 그 위치의 시연 데이터를 추가한다.

• 조명이 바뀌면 실패한다 → 조명과 배경을 다양화한다.

• 물체를 자주 놓친다 → 집기 직전과 그리퍼 닫힘 구간을 더 촘촘히 수집한다.

• 경로가 불안정하다 → 시작 자세와 중간 경로가 다양한 에피소드를 추가한다.

• 사람 개입이 반복된다 → DAgger 방식으로 교정 데이터를 모은다.

좋은 로봇 정책은 한 번의 학습으로 완성되지 않습니다. 데이터 수집, 학습, 평가, 실패 분석, 재수집을 반복하면서 좋아집니다. 이 반복을 제대로 굴리려면 평가 기준이 먼저 고정되어야 합니다. 모델이 좋아 보이는지보다, 같은 조건에서 더 자주 성공하고 더 안전하게 움직이는지가 핵심입니다.

참고

¹Policy Deployment (lerobot-rollout) · Hugging Face

²Generalist Robot Policy Evaluation in Simulation with NVIDIA Isaac Lab-Arena and LeRobot