GameHorizon 장기 행동 평가, 짧은 점수로 에이전트를 믿으면 놓치는 것
짧은 벤치마크에서 높은 점수를 받은 에이전트라도 긴 업무를 끝까지 해낸다고 볼 수는 없습니다. 장기 평가는 정답률 하나가 아니라 시간 흐름 속 상태 유지와 실패 복구를 함께 봐야 합니다. GameHorizon이라는 이름의 공식 공개 사양은 이번 조사에서 확인하지 못했으므로, 여기서는 HORIZON과 UltraHorizon의 공개 자료를 기준으로 장기 행동 평가를 읽는 방법을 정리합니다.
30초 요약
짧은 과제 점수는 출발점입니다. 긴 작업에서는 기억, 계획 수정, 도구 사용, 관측하지 못한 상태 대응이 따로 무너질 수 있습니다.
HORIZON은 시간·도메인 변화 속 사용자 행동 모델링을, UltraHorizon은 긴 탐색 궤적을 평가 대상으로 둡니다.
도입 판단에는 성공률 외에 중단 지점, 재시도, 비용, 새로운 조건에서의 성능을 같이 남겨야 합니다.
짧은 장면 점수는 왜 작업 완주를 보장하지 않을까요?
벤치마크가 ‘현재 화면을 보고 다음 행동 하나를 고르는’ 문제라면, 모델은 그 장면의 단서를 잘 읽는지로 높은 점수를 얻을 수 있습니다. 하지만 실제 에이전트 작업은 앞에서 만든 파일, 방금 실패한 호출, 나중에 바뀐 목표를 잊지 않고 연결해야 합니다.
짧은 점수는 순간 판단의 신호이지, 긴 궤적의 신뢰도 증명서는 아닙니다. 마라톤의 출발 100m 기록만 보고 완주 페이스를 고르는 셈이라, 기록은 훌륭해도 물·경로·페이스 조절은 아직 모르는 상태입니다.
| 평가 장면 | 주로 확인하는 것 | 놓치기 쉬운 것 |
|---|---|---|
| 짧은 단일 과제 | 현재 입력 해석, 한두 번의 도구 호출 | 이전 결정과 다음 결정의 연결 |
| 긴 연속 과제 | 계획 유지, 상태 기록, 재계획, 복구 | 비용과 중간 실패의 누적 |
| 시간·환경 변화 과제 | 새 시점·새 조건에서의 일반화 | 과거 데이터에 맞춘 점수의 착시 |
HORIZON이 추가한 질문: 시간이 지나도 행동 모델이 버틸까요?
Microsoft의 HORIZON 공식 저장소는 기존 평가가 단일 도메인 추천이나 다음 항목 예측에 치우쳐 실제 개인화 시스템의 대리 지표가 되기 어렵다고 설명합니다. 이를 보완하려고 Amazon Reviews 2023 공개 데이터를 재구성해 장기 순차 사용자 모델링, 시간 일반화, 분포 내·분포 외 평가를 한 벤치마크에 넣었습니다.
README에 기재된 구성은 5,400만 사용자와 3,500만 상품, 33개 상품 카테고리에 걸친 교차 도메인 이력입니다. 규모 자체가 답은 아니지만, 한 번의 클릭보다 시간과 카테고리가 바뀌는 상황을 묻는다는 점이 핵심입니다.
같은 데이터 분포에서의 점수와 미래 시점·새 사용자에서의 점수는 분리해서 읽어야 합니다. HORIZON은 시간 기준 검증·테스트 분할과 ID/OOD 평가를 제시해 이 차이를 드러내려 합니다.
문서 기반 입력→출력 예시
다음은 특정 HORIZON 결과가 아니라, 공개 README의 평가 관점을 이해하기 위한 단순화한 예시입니다.
입력: 2019년까지의 카테고리 A·B 상호작용 이력
질문: 2020년 이후의 다음 상호작용을 예측할 수 있는가?
짧은 평가 출력: “다음 항목 X”의 정답 여부
장기 평가 출력: 시간 분할별 성능 + 새 사용자/새 조합에서의 성능 차이
여기서 개발자가 확인할 것은 최고점 하나가 아닙니다. 어떤 분할에서 흔들렸는지, 새로운 조건에서 얼마나 떨어졌는지를 보면 운영에서 추가 검증이 필요한 구간을 찾을 수 있습니다.
UltraHorizon은 왜 도구 호출 수와 긴 궤적을 보나요?
UltraHorizon 논문은 많은 에이전트 평가가 짧고 완전 관측된 과제에 집중한다고 지적합니다. 논문이 제안한 장기·부분 관측 탐색 환경에서는 추론, 계획, 기억 관리, 도구 관리가 이어져야 하므로 한 번의 정답보다 과정의 연결이 중요해집니다.
논문 초록은 표준 설정에서 평균 3.5만 토큰 초과와 60회 초과 도구 호출, 가장 무거운 설정에서 20만 토큰 초과와 400회 초과 도구 호출을 보고합니다. 이 숫자는 일반 업무의 평균 비용이 아니라 해당 벤치마크 설정의 궤적 길이입니다.
긴 과제의 실패는 마지막 행동이 아니라, 앞선 기록·계획·도구 상태가 어긋난 결과일 수 있습니다. 그래서 성공/실패만 저장하면 고칠 위치가 사라집니다.
내 에이전트에 바로 적용할 최소 평가 기록은 무엇일까요?
논문을 그대로 재현할 필요는 없습니다. 먼저 실제 업무 하나를 골라 ‘짧은 성공’과 ‘작업 완주’를 나눠 기록하면 됩니다.
- 시작 조건: 어떤 파일, 권한, 이전 상태에서 시작했는지 남깁니다.
- 중간 상태: 계획 변경, 핵심 메모, 도구 호출 결과를 사건 단위로 기록합니다.
- 복구: 실패 뒤 같은 행동을 반복했는지, 다른 경로를 선택했는지 구분합니다.
- 완료 기준: 최종 답변뿐 아니라 산출물 검증이나 사용자 확인까지 정의합니다.
- 비용 경계: 토큰, 호출 수, 소요 시간을 성공률 옆에 둡니다.
처음에는 짧은 과제와 긴 과제를 같은 목표로 한 쌍 만들어 비교하는 편이 좋습니다. 예를 들어 ‘문서 한 장에서 함수 찾기’와 ‘여러 문서를 읽고 변경 계획·패치·검증 결과를 남기기’는 모두 정보 탐색이지만, 후자에서 상태 관리와 검증이 드러납니다.
언제 이 관점이 특히 필요하고, 언제는 과한가요?
여러 단계의 도구 호출, 사람이 이어받을 산출물, 시간이 지나 바뀌는 데이터가 있는 업무라면 장기 평가가 유용합니다. 코드 수정, 조사 자동화, 다단계 고객 지원처럼 중간 상태 하나가 다음 행동을 바꾸는 작업이 여기에 가깝습니다.
반대로 한 번의 분류나 정해진 형식 변환처럼 상태가 거의 없고 즉시 검증되는 작업이라면 긴 궤적을 흉내 낸 평가는 비용만 키울 수 있습니다. 업무가 상태를 이어 가는지부터 확인한 뒤 평가 길이를 늘리는 것이 순서입니다.
HORIZON 공식 README도 오프라인 성능이 온라인 배포 성과와 다를 수 있고, 실제 배포 전 추가 검증이 필요하다고 밝힙니다. 벤치마크는 배포 승인 도장이 아니라, 어디를 더 시험할지 정하는 지도에 가깝습니다.
작업 환경을 함께 정리한다면
장기 평가에서는 타임라인·도구 출력·검증 문서를 나란히 보는 일이 잦습니다. 아래 두 항목은 이 글의 평가 기준을 바꾸는 제품이 아니라, 그 기록을 확인하고 보관하는 작업을 보조하는 선택지입니다.
로그와 대시보드를 병행해 확인할 때 화면 배치를 정리하는 용도입니다. 노트북·모니터의 규격과 설치 공간은 카드 정보와 별도로 구매 전 확인이 필요합니다.
평가 로그와 산출물을 별도 매체에 보관하려는 경우의 선택지입니다. 실제 저장 용량·전송 환경·호환성은 판매 카드에서 다시 확인해야 합니다.
이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
출처
- Microsoft, HORIZON: A Benchmark for In-the-wild User Behaviour Modeling 공식 저장소 (확인일 2026-09-22)
- Luo et al., UltraHorizon: Benchmarking Agent Capabilities in Ultra Long-Horizon Scenarios (arXiv, 제출일 2025-09-26, 확인일 2026-09-22)
핵심 정리: 다섯 가지 질문과 답
Q. 짧은 벤치마크 점수가 높으면 장기 업무도 맡겨도 될까요?
아니요. 순간 판단과 장기 상태 유지·복구는 별도 능력이라 실제 업무 길이의 평가가 필요합니다.
Q. HORIZON은 무엇을 더 보나요?
시간 분할, 교차 도메인 이력, 분포 내·분포 외 조건에서 사용자 행동 모델이 일반화하는지를 봅니다.
Q. UltraHorizon의 긴 궤적 수치는 일반 업무 기준인가요?
아니요. 논문이 보고한 특정 벤치마크 설정의 궤적 길이이며, 일반적인 비용 수치로 일반화하면 안 됩니다.
Q. 최소한 어떤 로그를 남겨야 하나요?
시작 조건, 중간 상태, 실패 후 복구, 완료 검증, 비용 경계를 성공률과 함께 남기면 됩니다.
Q. 언제 장기 평가를 생략해도 될까요?
상태가 거의 없고 한 번에 검증되는 단일 작업이라면 긴 시나리오를 만드는 비용이 더 클 수 있습니다.
'AI > AI 최신 기술' 카테고리의 다른 글
| SWE-bench 점수, 높은데도 에이전트를 바로 맡기면 안 되는 이유 (0) | 2026.09.25 |
|---|---|
| JitMem, 에이전트 메모리를 저장할 때 요약하면 놓치는 단서 (0) | 2026.09.25 |
| RecreationWorld, 화면만 닮은 AI 앱을 멈추게 하는 동작 검증 (0) | 2026.09.21 |
| EvoOntology, 컬럼명만 보고 헤매는 데이터 에이전트를 어떻게 멈추나 (0) | 2026.09.21 |
| EvoSkill-GUI, 화면 에이전트가 같은 실패를 반복할 때 고치는 곳 (0) | 2026.09.20 |
댓글