포스트

DeepPlanning - 장기 계획 수립 에이전트를 위한 벤치마크

목차

  1. 개요
  2. 기존 벤치마크의 한계
  3. 세 가지 핵심 평가 역량
  4. 벤치마크 도메인
  5. 평가 방법론
  6. 리더보드 결과
  7. 오류 분석
  8. 추론 모드 vs 비추론 모드 분석
  9. Reference

개요

DeepPlanning은 Alibaba Qwen 팀이 제안한 장기 계획(long-horizon planning) 에이전트 벤치마크이다. 2026년 1월 26일에 공개되었으며 논문은 arXiv:2601.18137로 발표되었다.

기존 에이전트 벤치마크는 주로 단계별(step-level) 추론을 평가하는 데 집중했다. DeepPlanning은 이와 달리 전역 제약 최적화(global constrained optimization)를 핵심으로 평가한다. 여행 계획과 쇼핑 계획이라는 두 가지 현실적인 도메인에서 다일 여행 일정 수립과 복수 상품 구매 최적화 과제를 다룔다.

평가 결과 최고 성능 모델인 GPT-5.2-high조차 평균 정확도 44.6%에 그쳤다. 최첨단 에이전트 LLM들도 장기 계획 수립에서 상당한 어려움을 겪고 있음을 보여준다. 코드와 데이터는 오픈소스로 공개되어 있다.

기존 벤치마크의 한계

기존 LLM 계획 벤치마크에는 두 가지 주요 한계가 있다.

첫째, 대부분의 벤치마크가 지역적(local) 단계별 추론에 집중한다. 시간과 예산 같은 전역 제약 조건 하에서의 최적화를 제대로 평가하지 못한다. 실제 업무에서는 하나의 지역적 실수가 전체 계획을 무효화할 수 있지만, 기존 벤치마크는 이를 반영하지 않는다.

둘째, 능동적 정보 수집(proactive information acquisition)과 세밀한 지역 제약 조건이 충분히 반영되지 않는다. 실제 환경에서는 관광지 휴무일, 상품 재고 여부 등 숨겨진 환경 상태를 API 호출로 직접 확인해야 한다. 기존 벤치마크는 이러한 실세계 특성을 과소 대표하고 있다.

세 가지 핵심 평가 역량

DeepPlanning은 에이전트의 세 가지 핵심 역량을 평가한다.

능동적 정보 수집 (Proactive Information Acquisition)

환경의 숨겨진 상태를 발견하기 위해 API를 능동적으로 호출하는 능력이다. 사실을 환각(hallucination)으로 만들어내는 대신, 관광지 휴무 여부나 상품 재고 상태를 직접 확인해야 한다. 관광지 수가 증가하면 에이전트가 검색을 건너뛰는 비율이 높아지는 경향이 관찰되었다.

지역 제약 추론 (Local Constrained Reasoning)

단계별 요구사항을 충족하는 능력이다. 특정 브랜드, 사이즈, 호텔 편의시설 등 사용자가 지정한 세부 조건을 정확히 만족시켜야 한다. 명시적 제약 위반과 암묵적 제약 위반이 모두 평가 대상이다.

전역 제약 최적화 (Global Constrained Optimization)

총 예산 상한, 다일 시간 실현 가능성 같은 전체적인 경계를 관리하는 능력이다. 하나의 지역적 실수가 전체 계획을 무효화할 수 있다. 상호 의존적인 결정들을 통합하고, 포괄적 제약 조건 하에서 체계적인 트레이드오프를 수행해야 한다.

벤치마크 도메인

여행 계획 (Travel Planning)

에이전트가 개인 여행 비서 역할을 수행하여 다일 여행 일정을 수립한다.

과제 구성

항목내용
과제 수120개 (중국어/영어)
전용 API9개
과제당 데이터 레코드7,708개
출력 형식분 단위 일정표 + 항목별 비용
핵심 역량시공간 추론

자연어 쿼리(목적지, 날짜, 예산)와 개인 선호도가 입력으로 제공된다. 항공편, 기차, 호텔, 레스토랑, 관광지에 대한 9개의 전용 API를 사용한다.

여행 계획 API (9개)

API기능
query_train_info기차 정보 조회 (출발지, 목적지, 날짜, 좌석 등급)
query_flight_info항공편 정보 조회 (출발지, 목적지, 날짜, 클래스)
query_hotel_info호텔 정보 조회 (목적지, 체크인/아웃, 등급, 브랜드)
query_road_route_info도로 경로 조회 (좌표 기반 거리, 소요시간, 비용)
query_attraction_details관광지 상세 정보 (좌표, 운영시간, 입장료, 소요시간)
query_restaurant_details레스토랑 상세 정보 (좌표, 인당 가격, 운영시간)
recommend_attractions관광지 추천 (도시, 유형 필터)
recommend_restaurants레스토랑 추천 (위도, 경도 기반 주변 검색)
search_location장소 좌표 검색 (소수점 6자리 정밀도)

데이터베이스는 중국 인기 관광 도시의 실제 데이터를 Fliggy, Amap, 웹 검색 등 공개 API로 수집하여 구성했다. 항공편, 기차, 호텔, 레스토랑, 관광지, POI, 도로 경로 등 7개의 과제별 하위 데이터베이스(CSV 형식)로 구성된다.

쇼핑 계획 (Shopping Planning)

에이전트가 조합 최적화(combinatorial optimization) 문제를 풀어 최적의 쇼핑 카트를 구성한다.

과제 구성

항목내용
과제 수120개 (영어)
전용 API15개
과제당 데이터 레코드171개
출력 형식최적화된 JSON 쇼핑 카트 (쿠폰 적용)
핵심 역량조합 최적화

상세 속성 요구사항이 포함된 쇼핑 리스트와 총 예산 제한이 입력으로 제공된다. 복잡한 쿠폰 중첩 규칙을 활용하여 최종 가격을 최소화해야 한다.

쇼핑 계획 API (15개)

API기능
search_products자연어 기반 상품 검색
filter_by_brand브랜드별 필터링 (OR 로직)
filter_by_color색상별 필터링
filter_by_size사이즈별 필터링
filter_by_applicable_coupons적용 가능 쿠폰 기반 필터링
filter_by_range수치 조건 기반 필터링
sort_products정렬 (차원, 순서 지정)
get_product_details상품 상세 정보 조회
calculate_transport_time배송 소요일 계산
get_user_info사용자 프로필 조회
add_product_to_cart장바구니 추가 (재고 검증)
delete_product_from_cart장바구니 삭제
get_cart_info장바구니 현황 조회
add_coupon_to_cart쿠폰 적용
delete_coupon_from_cart쿠폰 제거

쇼핑 데이터베이스는 상품, 사용자, 쿠폰 3개의 JSON 형식 데이터로 구성되며, 세밀한 상품 속성으로 합성 생성되었다.

과제 생성 파이프라인

과제 생성은 3단계로 진행된다.

1단계는 데이터베이스 및 도구 설계이다. 실제(여행) 또는 합성(쇼핑) 데이터로 도메인별 데이터베이스를 구축하고, Python API로 추상화한다.

2단계는 계층적 과제 생성이다. 정답 기반 역방향 생성(solution-centric reverse-generation) 방식을 사용한다. 기본 골격 생성, 개인화 제약 주입, 환경 제약 주입의 순서로 진행한다. 환경 제약은 도구 사용을 통해서만 발견할 수 있는 암묵적 도전 요소(휴무, 재고 부족, 쿠폰 규칙 등)이다. 데이터베이스를 자동 조정하여 유일한 최적해를 보장한다.

3단계는 수동 품질 관리이다. 전문가가 자연어 표현, 논리적 명확성, 해결 가능성을 검증한다.

평가 방법론

DeepPlanning은 LLM 기반 채점이 아닌 코드 기반 자동 평가를 사용한다. 모든 과제는 격리된 Python 샌드박스에서 실행되어 재현 가능성을 보장한다. 모든 모델은 함수 호출(function-calling) 에이전트로 인스턴스화되며, 과제당 최대 400회 도구 호출이 허용된다. 각 과제는 강건성을 위해 4회 반복 실행된다.

여행 계획 평가 (8개 차원, 21개 체크포인트)

차원체크포인트 수평가 내용
경로 일관성3여행 기간, 순환 구조, 도시 간 이동 연결성
샌드박스 준수4숙소, 관광지, 식사, 교통의 DB 존재 여부
일정 구조4추적 가능한 숙소, 숙소로 종료, 필수 식사/관광 포함
시간 실현 가능성1시간 충돌 없음, 합리적 이동 시간
영업시간 준수3관광지/식당 운영시간 내 방문, 휴무일 회피
소요시간 합리성2관광지/식사 시간의 DB 기준 합리성
비용 계산 정확성1전체 비용 합산 정확성
활동 다양성2식사/관광지 선택의 다양성

각 차원은 Commonsense Score에 1/8씩 기여한다. 하나의 차원 내 모든 하위 체크포인트가 통과해야 해당 차원 점수를 획득한다.

쇼핑 계획 평가

Match Score는 에이전트 장바구니의 상품 중 정답 상품과 일치하는 비율이다. Case Accuracy는 에이전트 장바구니와 정답 상품이 정확히 일치하면 1, 아니면 0이다.

점수 체계

점수산출 방법
Commonsense Score (CS)8개 차원 각 1/8, 최대 8점 (여행) / Match Score (쇼핑)
Personalized Score (PS)사용자 지정 제약 조건 전체 충족 여부 (0 또는 1)
Composite Score (Comp)CS와 PS의 산술 평균
Case Accuracy (Avg Acc)CS와 PS 모두 완벽 시 1, 그 외 0

리더보드 결과

25개 모델을 대상으로 평가한 전체 리더보드이다. 4회 반복 실행의 평균값이다.

상위 모델 (Avg Acc 기준)

순위모델Avg AccTravel CSTravel PSTravel CompShop CSShop PSShop Comp
1GPT-5.2-high44.688.583.385.835.084.854.2
2Claude-4.5-Opus (thinking)33.979.370.975.122.780.045.0
3GPT-5-high31.678.765.972.318.980.444.2
4Gemini-3-Flash-Preview28.867.157.762.45.980.651.7
5Qwen3-Max (thinking)28.764.061.762.813.882.643.5

중위 모델

순위모델Avg AccTravel CSTravel PSTravel CompShop CSShop PSShop Comp
6Claude-4.5-Opus (no thinking)26.367.558.863.16.782.245.8
7Claude-4.5-Sonnet (thinking)25.565.258.461.87.680.043.3
8o324.976.555.666.111.376.938.5
9Gemini-3-Pro-Preview23.258.425.141.80.778.045.8
10DeepSeek-V3.2 (thinking)21.647.435.041.20.778.842.5
11Seed-1.8-high20.443.656.750.10.077.540.8
12Grok-4.1-fast (reasoning)17.257.137.747.42.774.031.7
13Claude-4.5-Sonnet (no thinking)17.253.442.848.11.175.833.3

하위 모델

순위모델Avg AccTravel CSTravel PSTravel CompShop CSShop PSShop Comp
14Qwen-Plus (thinking)17.135.422.428.90.073.334.1
15Gemini-2.5-Pro17.062.342.052.23.269.130.8
16GLM-4.7 (thinking)14.044.044.644.30.472.527.5
17Qwen3-Max (no thinking)12.836.730.731.80.870.224.7
18o4-mini12.458.036.647.23.069.121.7
19Kimi-K2-thinking12.145.232.538.90.065.824.2
20Seed-1.8-minimal11.343.047.545.30.068.122.5
21Qwen-Plus (no thinking)7.537.313.025.10.063.915.0
22GLM-4.7 (no thinking)7.138.922.530.70.061.214.2
23DeepSeek-V3.2 (no thinking)5.337.412.124.70.058.310.6
24GPT-5.2-none4.554.329.942.10.458.68.6
25Grok-4.1-fast (non-reasoning)3.039.619.729.60.050.15.9

주요 관찰

1위 GPT-5.2-high도 평균 정확도 44.6%에 불과하다. 쇼핑 도메인의 Commonsense Score가 전반적으로 매우 낮다. 대부분의 모델이 쇼핑 CS에서 10% 미만을 기록했으며, 많은 모델이 0%를 기록했다. 여행 도메인에서는 CS 점수가 상대적으로 높지만, PS(개인화 점수)와 결합하면 크게 하락한다.

오류 분석

Claude-4.5-Opus의 실패 궤적 140개(여행 80개, 쇼핑 60개)를 분석한 결과이다.

패턴 A - 정보 수집 실패

A1은 불충분한 검색이다. 에이전트가 중요한 쿼리를 건너뛰었으며, 관광지 수가 증가할수록 건너뛰기 비율이 높아졌다.

A2는 도구 오용이다. 부적절한 도구 선택이나 잘못된 인자 형식으로 API를 호출했다.

A3은 사실 대체이다. 검색으로 가져온 정보를 조작된 값으로 대체했다.

패턴 B - 지역 추론 실패

B1은 명시적 제약 위반이다. 사용자가 명시한 요구사항을 무시했다.

B2는 암묵적 제약 위반이다. 여행 86건, 쇼핑 21건에서 발생했다. 예약 불가능한 좌석을 예약하는 등 환경 현실과 충돌하는 결정을 내렸다. 암묵적 제약이 명시적 제약보다 탐지하기 어렵다는 것이 확인되었다.

패턴 C - 전역 최적화 실패

여행 101건, 쇼핑 52건으로 가장 빈번한 실패 패턴이다. 상호 의존적인 결정들을 통합하지 못했다. 포괄적 제약 조건 하에서 체계적인 트레이드오프를 수행하지 못했다. 시간적 겹침과 논리적 불연속이 발생했다.

추론 모드 vs 비추론 모드 분석

성능 격차

추론 모델이 비추론 모델을 일관적으로 상회했다. GPT-5.2-high(추론)는 44.6%를 달성한 반면, GPT-5.2-none(비추론)은 4.5%에 그쳤다. 같은 모델에서 추론 활성화만으로 10배의 성능 차이가 발생했다.

효율성 프론티어

Claude-4.5-Opus에서 Thinking 모드를 활성화하면 상호작용 턴 수가 16.9에서 12.5로, 도구 호출 횟수가 79.5에서 72.9로 감소하면서 성능은 향상되었다. 내부 계획 수립이 불필요한 시행착오를 줄이고 도구 사용을 통합한다는 것을 의미한다.

실행 패턴 차이

GPT-5.1-high는 병렬 번들링(parallel bundling) 방식으로 적은 턴 수를 사용했다. GPT-5.2-high는 순차 검증(sequential verification) 방식으로 약 10배 많은 턴 수를 사용했지만 12.7% 더 높은 성능을 달성했다. 효율성과 철저함 사이의 비용-성능 트레이드오프가 존재한다.

도메인 특화 현상

Gemini-3-Flash-Preview는 여행 계획 성능이 낮았지만 쇼핑 계획에서는 Shop Comp 51.7%로 우수한 성적을 보였다. 모델-도메인 간 상호작용 효과가 존재하며, 단순한 추론 능력 이상의 요인이 작용한다.

Reference