BEHAVIOR의 시뮬레이션 에피소드가 끝났다는 사실만으로 로봇이 일을 마쳤다고 판단하면 안 됩니다. OmniGibson의 태스크는 에피소드 종료를 뜻하는 done, 성공 여부인 success, 학습에 쓰는 reward를 구분합니다. 시간 제한에 걸린 실행도 끝날 수 있고, 목표에 가까워지며 보상을 얻었어도 최종 조건은 충족하지 못할 수 있습니다.
성공률을 계산하거나 학습 데이터를 추릴 때는 이 세 값을 따로 보존해야 합니다. 특히 화면이 멈췄다는 사실이나 보상 그래프의 상승을 성공 라벨로 대신하면, 평가와 데이터 선별에 같은 오해가 들어갑니다.
컵을 선반 앞까지 옮기고 시간이 끝났다면
설명을 위해 목표를 ‘컵이 지정한 선반 안에 놓여 있다’로 정한 가상 과제를 생각해 보겠습니다. 로봇이 컵을 집어 선반 앞으로 옮겼지만, 놓기 전에 제한 시간이 끝났습니다. 움직임의 상당 부분은 그럴듯해도 우리가 정한 마지막 조건은 아직 거짓입니다.
이때 시간 초과만 종료 조건으로 성립했다면, 실행은 종료됐지만 성공한 실행은 아닙니다. OmniGibson의 Timeout 구현은 최대 스텝에 도달했는지를 검사하는 실패 조건으로 정의되어 있습니다. 따라서 완료된 에피소드 파일을 모두 성공 데이터에 넣는 방식은 잘못된 분류를 만들 수 있습니다.
반대로 컵이 목표 위치에 놓였는지는 그 과제가 사용하는 목표 판정으로 확인해야 합니다. BehaviorTask의 PredicateGoal은 요구된 목표 조건들이 충족됐는지를 검사하는 성공 조건입니다. 손끝이 가까워졌는지와 컵이 실제로 필요한 상태가 됐는지는 다른 질문입니다.
컵 예시는 원리를 설명하기 위한 것이며, 특정 BEHAVIOR 과제를 실행한 관찰 기록이 아닙니다. 실제 과제에서는 저장된 목표 정의와 판정 결과를 함께 읽어야 합니다.
보상 그래프가 올라가도 성공률은 따로 계산한다
공식 Tasks 문서는 종료 조건과 보상 함수를 별도로 관리한다고 설명합니다. 종료 조건은 종료·성공 상태를 반환하고, 보상 함수는 수치 보상과 추가 정보를 반환합니다. 둘은 같은 실행을 설명하지만 같은 측정값은 아닙니다.
예를 들어 앞선 컵 과제에 ‘목표에 접근할수록 보상을 준다’는 보상 설계를 붙였다고 가정해 보겠습니다. 컵을 선반 앞까지 가져오는 정책은 가만히 있는 정책보다 더 많은 보상을 받을 수 있습니다. 그렇다고 두 정책 중 하나가 컵을 선반 안에 놓았다는 결론이 자동으로 나오지는 않습니다.
보상을 바꿔 가며 학습했다면 비교는 더 조심해야 합니다. 보상 항목이나 가중치를 바꾼 뒤 누적 보상이 커졌을 때, 그 증가분에는 정책의 행동 변화와 점수 계산 방식의 변화가 함께 들어갈 수 있습니다. 같은 성공 조건에서 완료한 에피소드 수를 별도로 집계해야 행동 개선을 읽을 수 있습니다.
다만 실패로 끝난 에피소드도 쓸모가 없다는 뜻은 아닙니다. 접근과 파지는 성공했는데 마지막 놓기에서 실패한 기록은 실패 위치를 이해하는 데 도움이 됩니다. 로봇 학습 데이터 품질 검수에서 설명한 것처럼, 최종 라벨과 실패 단계·관찰 증거를 함께 남기면 필요한 데이터를 구분하기 쉽습니다.
에피소드별로 남기면 판단이 달라지는 기록
먼저 어떤 조건 때문에 끝났는지 읽고, 성공 조건의 결과를 확인한 뒤, 보상과 진행 과정을 대조하세요. 종료 이유를 보지 않은 채 보상값에 임의의 선을 긋고 성공·실패로 나누지 않는 것이 핵심입니다.
평가 기록을 만든다면 다음 정보를 한 에피소드에 연결할 수 있습니다.
- 과제와 목표 정의, 장면·초기 상태를 식별할 정보
- 마지막 스텝과 종료를 일으킨 조건별 결과
- 최종
done과success, 누적 보상 및 사용한 보상 설정 - 목표 조건 중 충족한 것과 남은 것, 이를 확인할 프레임이나 상태 기록
이는 기록 설계 제안입니다. 사용하는 실행기나 래퍼가 모든 항목을 자동으로 내보낸다고 가정해서는 안 됩니다. 실제 출력에서 어떤 필드가 제공되는지 확인하고, 추가로 기록한 값은 계산 방법을 남겨야 합니다.
여러 종료 조건이 같은 시점에 성립할 수도 있으므로, 하나의 짧은 이유 문자열만 남기고 나머지 판정을 버리지 않는 편이 좋습니다. 공식 태스크 문서는 여러 조건의 결과를 종합해 종료와 성공을 판단한다고 설명합니다. 외부 학습 환경으로 전달할 때에는 그 결과가 해당 래퍼의 종료 필드에 어떻게 매핑되는지도 확인해야 합니다.
다음 시도의 시작은 로봇 위치만 되돌리는 것으로 끝나지 않는다
첫 번째 실행의 결과를 정확히 읽었더라도, 두 번째 실행이 이전 진행 상태를 물려받으면 비교가 흐려집니다. 로봇만 처음 위치로 옮겼는데 컵은 이미 선반 근처에 남아 있다면 같은 출발 조건이라고 보기 어렵습니다. 화면에서 비슷하게 보이는 것과 과제 상태가 초기화된 것은 다릅니다.
BaseTask의 reset 코드는 장면, 에이전트, 내부 변수의 초기화를 나누고 종료 조건과 보상 함수도 초기화합니다. 사용자 정의 과제를 작성했다면 이 경로 중 자신이 추가한 상태가 어디에서 초기화되는지 확인해야 합니다. 모든 과제에서 기본 훅이 필요한 작업을 자동으로 완성해 준다고 가정하면 안 됩니다.
같은 조건으로 반복 평가할 때는 초기 장면과 물체 상태, 과제 내부 진행값, 종료·보상 상태가 함께 새 시도를 시작하는지 점검하세요. 그다음 에피소드별 종료 이유와 성공 여부를 읽으면, ‘끝난 횟수’와 ‘일을 마친 횟수’를 분리해 보고할 수 있습니다.
이 글은 2026년 10월 15일 확인한 OmniGibson 문서와 공개 API 구현 설명에 근거합니다. 시뮬레이터를 실행하거나 정책의 성공률을 측정하지 않았으며, 대회 평가 규칙이나 리더보드 점수의 대체 기준을 제안하는 글은 아닙니다.