Rethinking Environments for Long-Horizon Work — Rayan Garg, Theta Software

한 줄 핵심

장기 과제용 AI 환경을 제대로 평가하려면 인간 시간만 보거나 토큰 수만 보는 대신, 도구 복잡도·상태 변화·모호성·검증기 설계를 함께 고려한 평가 환경과 루브릭을 만들어야 한다.

시간별 요약

1. 0:12
   장기 과제(long horizon)는 고정된 범주가 아니라 상대적 규모의 개념이며, 인간 기준과 모델 기준을 함께 봐야 한다. 인간에게 오래 걸리는 일과 모델에게 오래 걸리는 일은 다를 수 있고, 토큰·스텝·툴 호출 수 같은 모델 기준 지표도 하네스에 따라 크게 달라진다.
2. 6:01
   모델 능력을 제대로 측정하려면 환경 복잡도를 도구 조율, 상태 변화, 모호성으로 나눠 봐야 한다. 여러 툴을 연동하는 과제일수록 이전 선택이 이후 결과에 미치는 영향이 커지고, 초기에 정보가 불완전할수록 탐색 능력을 더 잘 드러내지만 평가 표준화는 어려워진다.
3. 10:01
   소프트웨어·금융처럼 정답 검증이 어려운 영역에서는 결정적 verifier만으로 부족하고 judge model이나 critic model이 필요하다. 다만 보상 해킹, sandbox 탈출, 숨은 테스트 접근 같은 실패를 막으려면 trajectory와 최종 상태를 함께 보고, 경직된 기준으로 가능한 해의 공간을 과도하게 줄이면 안 된다.
4. 13:01
   judge도 결국 에이전트이므로, 에이전트가 쓰는 환경과 같은 수준의 관찰 가능성과 도구 접근이 필요하다. 동시에 judge가 환경을 바꾸지 않도록 읽기 전용 권한을 두고, 긴 trajectory는 그대로 넣지 말고 DB 저장, sub-agent 보강, 단계 분해로 질의 가능하게 만들어야 한다.
5. 18:01
   기존 금융 벤치마크들은 인간 시간 기준으로는 장기 과제가 아니거나, 이미 포화됐거나, 커버 범위와 보상 신호가 너무 좁다는 문제가 있다. 실제로는 평균 15시간이 걸리는 50개 과제 샘플처럼 더 넓고 세밀한 루브릭과 QA가 있어야 모델의 학습 가능성과 실제 성능을 제대로 볼 수 있다.

실무 인사이트

• 장기 과제 평가는 인간 기준 하나로 끝내지 말고, 인간 시간·토큰·스텝·툴 호출·상태 변화량을 함께 봐야 병목이 어디인지 드러난다.
• 검증기를 단순 채점기가 아니라 읽기 전용 권한을 가진 에이전트로 설계하면, 긴 trajectory와 외부 상태까지 포함한 현실적인 평가가 가능해진다.
• 벤치마크를 만들 때는 난이도보다도 보상 신호의 세밀함과 커버 범위를 먼저 점검해야, 포화된 쉬운 과제를 양산하는 문제를 피할 수 있다.