PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks 논문 리뷰

링크:

https://arxiv.org/pdf/2503.09572

 

Background

• LLM
  
  • 기존 LLM들은 agent 기반의 간단한 task는 쉽게 해결하지만 long-horizon tasks에 대해서는 여전히 어려움을 보임
  • *Long-horizon task: sequence of action, or over a prolonged period가 필요한 task
  • 특히 web navigation과 같은 실제 환경에서는 여러 단계의 planning과 execution을 균형 있게 수행해야 함
• Planning
  • LLM은 reasoning과 decision-making을 잘하지만 여전히 plnning에 challenge가 있음
  • 1. high-level goal을 달성하기 어려워함 (like "book me a flight to New York" -> open the airline website -> enter travel dats -> ... )
  • 2. task가 길고 복잡해질수록 strategy의 일관성을 유지하는 것이 어려움 -> 여태까지 뭐했나 앞으로 뭐 남았나
  • 3. real-word environments가 dynamic하고 unpredictable함
• Previous work
  • 대부분 single model로 user request를 바로 actions로 전환하고자 함 -> planning-act balacing과 일관성 유지가 어려움
  • RL 적용하니 unstable하고 hyperparameters와 reward design에 매우 민감함
  • 1. React based: single model로 user query를 sequence of action으로 매핑
  • 2. LLMCompliler: PLANNER는 sequence of plans를 생성하고, Executor는 각 step을 environment specific action으로 전환함
  • -> 우리는 여기에다가 manual annotation or  a sandbox environment 없이 PLANNER 학습용 training data를 생성하는 방법을 제안
  • * sandbox environment: 프로그램을 테스트 및 분석할 수 있는 격리된 가상 공간
• Problem statement
  
  • 1. high-level의 planning을 low-level로 분해하기 어려움
  • 2. long-horizon task의 경우 단계가 많아지면서 해결이 어려움
  • 3. 실시간으로 변화하는 웹은 예기치 못한 오류 (검색 결과 없음 등)에 대처하기 어려움
  • 4. 사람이 고품질의 계획 데이터를 수집 및 주석 달기 어려움  
  • -> PLAN-AND-ACT framework를 제안

 

Methods

• PLAN-AND-ACT framework
  
  • PLANNER와 EXECUTOR로 구성
  • PLANNER: user query 를 받아 목표를 달성하기 위한 상위 레벨의 plan을 생성
  • EXECUTOR: PLANNER가 생성한 계획을 받아 웹 환경에서 구체적인 낮은 레벨의 environment-specific한 action을 수행
  • -> PLANNER는 계획 생성에 집중하고, EXECUTOR는 계획-액션 변환에 집중 
• Dynamic replanning 및 CoT (Chain-of-Thought)
  • PLANNER가 최초 계획을 생성한 후, EXECUTOR가 한 단계 액션을 수행하면 그 결과를 PLANNER가 다시 받아 "남은 단계를 어떻게 수정할지" 재계획
  • 이를 통해 예기치 못한 환경 변화에 대처
  • PLANNER가 plan으로 관련 context를 전달하기 때문에, 명시적인 메모리 모듈 없이도 long-horizon task 해결 가능
• Chain-of-Thought Reasoning
  • PLANNER와 EXECUTOR 둘 다 생성 전에 중간 추론 과정을 출력하여 더 높은 성능
  • 이 과정은 특히 큰 모델 (70B)보다 작은 모델 (8B)에서 계획 및 액션의 정확도를 높임

• Synthetic Data Generation
  • Off-the-shelf LLM
    • 일반적인 Off-the-shelf LLM은 pretraining 과정에서 관련 데이터를 보거나 학습하지 못해서 planning이나 executing의 기능을 기대할 수 없음
    • prompt engineering과 in-context examples만으로 long-horizon task를 해결하기는 어려움
    • Finetuning을 통해서 높은 성능을 낼 수 있으나, 튜닝을 위해서는 상당한 양의 데이터가 필요했음 -> 많은 시간과 노력 필요
  • Action Trajectory Generation
    • Alpaca-style data generation pipeline을 사용해 user queries를 랜덤으로 추출함
    • 이를 LLM의 seed로 사용해 similar queries를 생성
    • web agent에게 impossible한 trajectories를 LLM으로 걸러내기
    • Environment에서 새로 생성된 instruction (similar queries) 중에 task 수행이 가능한 데이터만 수집
    • ORM (outcome-supervised reward model)을 사용하여 이 trajectories에 점수를 매겨 사용자의 의도대로 문제를 해결/실패 했는지 trajectories를 필터링 (ORM-Llama-3.1-8B 그대로 사용)
    • -> trajectories를 생성
  • Grounded Plan Generation
    • PLANNER를 학습시키기 위해서 가장 naive한 방식으로는 teacher LLM에게 user query와 prompt를 제공하여 step-by-step plan을 생성하도록 함 -> 하지만 teacher LLM은 actual environment에 접근하기 어려움 -> LLM의 in-context learninng capability를 활용해보자
    • 4.1에서 생성한 trajectories에서 structed plans를 reverse engineer하도록 유도함
    • reverse engineer: LLM에게 seq of action을 분석하고, EXECUTOR를 downstream으로 안내하는데 사용할 일관된 계획을 종합함
    • trajectory의 어떤 하위 작업이 어떤 상위 작업에 할당될 것인지 -> 계획이 실제 환경에 기반을 두고 있는지, plan과 actual execution의 trajectory가 일치하는지 -> 정확하고 실행 가능한지 측정 가능
  • Synthetic Plan Expansion
    •  4.1과 4.2를 통해 synthetic plan을 생성함 -> 평균적으로 8단계가 걸림 -> 데이터 불균형 -> synthetic plans로 확
    • synthetic PLANNER plan data에서 query-plan pairs를 랜덤 샘플 -> 데이터가 다양해짐 -> 어떤 종류의 작업이 더 어려운지 고려하지 않음
    • 각 웹사이트의 failure node와 관련 있을 수 있는 training data points를 분류하고, 이를 seed data로 사용하여 5,000개의 synthetic plans를 추가 생성

 

Experiment

• Table 1, 4
  • 각 모델 별 비교 실험 (*는 이전 논문에서 보고된 값)
  • Synthetic trajectories만으로 baseline보다 효율적인 학습 가능
  • 모델의 사이즈가 크다고해서 무조건 좋은 것이 아니라 PLAN-AND-ACTOR로 구분하는 것이 중요함을 강조

• Table 3
  • NNetNav, AutoWebGLM은 작은 모델이라 매우 낮은 성능
  • WebPilot, AgentOccam, AgentOccam-Judge는 closed-source의 거대 모델로 어느정도의 성능을 보임
  • PLAN-AND-ACT는 작은 모델로도 높은 성능을 보임
  • 왜 더 작은 모델인 QWQ-32B가 더 높은 성능을 내는걸까?
    • 논문 저자에게 물어 본 결과, QWQ-32B는 RL로 추론 과정에 더 집중하도록 학습됨. Llama-70B의 경우 Instruction tuning으로 학습되었음. 학습 과정에서 CoT를 활용하여 학습하였기 때문에 이 학습 과정이 QWQ-32B와 더 잘 맞을 것이라 함

 

Result

• WebArena-Lite benchmark와 WebVoyager에서 SOTA 달성
• Plananing과 execution으로 분리하여 유용함을 증명

 

Contribution

• Planning과 execution으로 구분하여 long-horizon task의 planning을 개선시킨 PLAN-AND-ACT framework 제안
• planner data를 생성하기 위한 synthetic data generation pipeline을 제안
• WebArena-Lite environment에서 web navigation을 평가하여 SOTA 달성

 

Limitation

• 데이터를 증강하기 위해서는 초기 trajectory data가 필요함
• dynamic replanning은 모든 액션마다 PLANNER를 호출하여 비효율적임

 

---

논문 저자에게 물어봄 / 25-06-04 -> 답장 받아 수정 / 25-06-07