[논문리뷰] AGENT WORKFLOW MEMORY

DeepLearing/NLP(LLM)

[논문리뷰] AGENT WORKFLOW MEMORY

notdecidedyet 2024. 10. 8. 14:41

0 Abstract

에이전트의 잠재력은 있으나, 현재의 방식들은 복잡한 행동 궤적을 필요로 하는 장기적 작업에서 어려워함.
인간은 과거 경험에서 재사용 가능한 작업 워크플로우를 학습하고 이를 바탕으로 미래의 행동을 유연하게 대처해 복잡한 작업을 해결
비슷하게, 에이전트에 적용하고자 Agent Workflow Memory (AWM)를 제안함
AWM은 자주 재사용되는 루틴, 즉 워크플로우를 유도하고 이를 선별적으로 에이전트에게 제공하여 후속 생성을 안내하는 방법이다

1 Introduction

LM 기반 에이전트들은...아래 작업에서 활용 가능

웹 네비게이션
모바일 앱 조작

현재의 에이전트들은...

훈련
문맥 내 학습(in context learning)
이 방식은 제시된 예제들과 유사한 행동에 대해서는 좋은 성능을 보이지만, (작업 맥락이나 환경이 변화할 때) 일반화가 부족하다.
-> 일반화가 힘들다
정리하자면 :
- 이들은 점점 더 복잡해지는 작업을 해결하는 핵심을 파악하지 못함.
  (핵심 : 유사한 작업과 환경에서 공유되는 재사용 가능한 작업 워크플로우를 추출하고 학습하는 것)
- 에이전트들이 각 작업을 개별적으로 해결하기 때문에, 과거의 성공과 실패로부터 학습하지 못하고, 따라서 시간이 지나도 적응하지 못함.

Agent Workflow Memory제안 : 인간이 과거 경험에서 공통된 작업 루틴을 추상화, 이러한 지식을 다음번 작업에서 적용하는 방식 착안

AWM은 에이전트 궤적에서 재사용 가능한 루틴을 추출하여 워크플로우를 유도
워크플로우를 에이전트 메모리에 통합하여 향후 작업 해결 과정을 안내
각 워크플로우는 사용 가능한 행동 궤적에서 추출된 공통 루틴을 가진 목표를 나타내며, 이를 통해 에이전트가 점점 더 복잡해지는 작업을 성공적으로 해결하기 위해 습득해야 할 가장 본질적이고 재사용 가능한 기술을 효과적으로 포착함
- 예를들어) 온라인 쇼핑 상황에서 "제품 검색하기", "장바구니에 추가하기", "결제하기"와 같은 기본적인 워크플로우들을 학습한다. 이러한 워크플로우들은 다양한 쇼핑 사이트에서 재사용될 수 있으며, 에이전트는 이들을 조합하여 "특정 상품을 찾아 구매하기"와 같은 더 복잡한 작업을 수행할 수 있다.

그림1)

AWM은 기본 내장 행동 세트로 시작
~~(초기 행동 세트 결정 방법은?)~~
새로운 작업을 순차적으로 해결하면서 지속적으로 재사용 가능한 워크플로우를 유도
예를 들어, 처음 몇 개의 예제에서 "이름으로 장소 찾기"를 학습. AWM은 새로운 경험과 이전에 습득한 워크플로우를 토대로 더 복잡한 워크플로우를 계속 구축.
예를 들어, 과거에 찾은 워크플로우인 "이름으로 장소 찾기"를 토대로 "장소의 우편번호 얻기"라는 더 복잡한 워크플로우를 구축

이러한 학습 메커니즘은 점점 더 복잡한 워크플로우를 유도 및 적용 하도록 함.
에이전트 메모리를 확장하는 눈덩이 효과를 만들며, 베이스라인과 상당한 격차를 보임(WebArena에서 단 수십 개의 예제만으로도 베이스라인 대비 최대 22.5 포인트 상승)

2 Agent workflow memory

2.1 Problem Statement

Formula :

$L$ : 언어모델
$M$ : 텍스트 기반 메모리
기본적으로 주어지는 메모리 : CLICK 및 TYPE과 같은 내장 액션 문서
(메모리는 일반적으로 시스템 프롬프트 또는 기본 프롬프트 컨텍스트의 보조 정보로 구현)
$NL$ : Query, 자연어로 되어 있는 풀고자 하는 문제
$q$ : 지시사항(instruction)
&T& : 전이함수(transition function) - 전이함수로 정의된 환경(environment)에서 에이전트가 활동(act)함

Task가 작동하는 방식 : 강화학습과 매우 유사함. (reward가 없을 뿐)

에이전트는 전이 함수 $T$로 정의된 환경에서 행동
action 생성 : 각 time step $t_i$에서, environment state $s_i$는 observation $o_i$를 제공하고, 이는 모델에 전달되어 $L(q, M, o_i) \rightarrow a_i$를 통해 action $a_i$를 생성
state 변경 : action은 environment에서 실행되어 $T(s_i, a_i) \rightarrow s_{i+1}$에 따라 state를 변경
이 observe-act loop는 모델이 stop action $a_i = \text{STOP}$을 예측하거나, task 종료 조건(예: 미리 정해진 최대 step 수)에 도달할 때까지 반복

2.2 Workflow Expression

워크플로우는 두 가지 구성요소로 이루어짐(그림2)

첫째, 워크플로우 설명
- Workflow Description $d$ : 에이전트가 워크플로우로부터 적절히 학습할 수 있는 형식으로 제시하기 위한 방법
  (거시적인 관점의)연속된 action들로 설명하는 것이 중요함.
  - $d$ : 워크플로우에 대한 요약생성
    - (experience에서 instruction or 요약을 LM을 통해 휴리스틱하게 수행(§2.3 참조))
  - 예를 들어, "온라인 쇼핑몰에서 상품 검색 및 장바구니에 추가하기"라는 워크플로우 설명은 에이전트에게 이 워크플로우가 상품 검색부터 장바구니 추가까지의 전체 프로세스를 다룬다는 것을 알려줌.
둘째, 워크플로우를 완료하기 위한 일련의 step $(p_1, p_2, \cdots)$
- Workflow Trajectory : 워크플로우 trajectory는 $d$에 설명된 프로세스를 완료하기 위한 일련의 step $(p_1, p_2, \cdots)$를 포함. 각 $p$는 그림 2의 Step 3에 나타난 $p_n$과 같이 세 부분으로 구성
  - (1) env desc : 현재 environment state에 대한 NL 설명,
    예를 들어 "Order {id} is shown";
  - (2) reason : 에이전트가 observation을 바탕으로 어떤 action을 생성할지 결정하는 reasoning 과정
    예를 들어 "Order {id} is found, I will now terminate the task.";
  - (3) action : environment에서 실행 가능한 프로그램으로 표현된 action, 즉 종료를 실현하는 stop().
    타 agent기준으로는 Tool에 해당 할 것

2.3 Inducing and using Workflows(핵심)

Induction Module :

workflow 집합 $W$를 유도 : 과거 에이전트의 경험 $E = {e_i}^m_{i=1}$으로 부터 $W$유도
experience $e = (q, P_e)$
- $q$(query) : 자연어 task instruction
- $P_e = (p^e_1, ..., p^e_n)$ : $q$를 해결하기 위해 취한 step(observation과 action) - sequence로 구성된 action trajectory
Workflow induction module은 $E$를 입력으로 받아 workflow 집합을 생성함
- $I(E) \rightarrow W = {w} = {(d_j, P_{d_j})}$.
- Induction module은 어떠한 함수형태인데, $E$를 인풋으로 받고 $W$를 생성함.

LM-based Workflow Induction

$I$ : LM기반 모듈, experience에서 공통적으로 사용할 수 있는 sub-routine을 추출하도록 프롬프트 구성
- 기존 instruction : 구체적이고 덜 반복적인 작업을 지정
- 제안 instruction : 의도적으로 더 세분화된 수준의 workflow 유도
  - 예) (기존) 아마존에서 건조 고양이 사료를 구매하고 내 주소로 배송
  - (제안) : appendix A(프롬프트 예시)
    - 아마존에서 제품 검색
    - {product-고양이 사료} : 이렇게 함으로서 일반화를 높임
Workflow $W$가 유도된 후,
- $M + W \rightarrow M_w$ : 에이전트의 auxiliary memory로 통합 ( 쉽게 말해, RAG와 query에서 추출된 W가 함께$M_w$라고 표시)

Action 생성(주어진 instruction $q$를 해결할 때) :
- $L(q, M_w, o) = L(q, M + W, o) \rightarrow a$를 통해 일련의 action을 생성
Formula
- $M$ : original 에이전트 memory
  -> 에이전트의 기본 knowledge와 Tool을 포함(Click, Type과 같은 web action과 같은것)
- $W$ : 이전 experience에서 유도된 재사용 가능한 workflow
- $o$ : 현재 웹 페이지의 HTML구조, 텍스트, 버튼, 입력 필드 등의 정보가 가능
- $e$ : 에이전트가 이전에 수행한 기록

Offline Scenario

Offline Scenario에서는 canonical experience가 있으면 작동 가능
canonical experience는 쉽게 말해 :
- agent가 참고할 만한 모범 tranjactory가 있는 경우
- few shot learning
(인간이 만든 데이터셋)
(모델이 합성한 데이터)
1) training example들을 가져와(RAG) workflow 생성
- $I(E_{train}) \rightarrow W_{offline}$.
2) 추론시 : 유도된 workflow를 에이전트 memory에 통합하여 test instruction을 해결
- $L(q, M + W_{offline}, o^{test}_i) \rightarrow a^{test}i$.
추론 전에 Workflow가 이미 유도된 상태라, 에이전트는 추론시 동일한 workflow memory $W{offline}$을 사용

Online Scenario

canoical experience를 수집하는 것은 쉽지 않다.
특히, 추론시와 같은 동일한 도메인과, 테스크에 대해서 (이데아 적인) 데이터를 수집하긴 더욱 어렵다.
AWM은 test query만 있는 상황에서 작동한다.
예) 추론 ( workflow유도, 통합, ... ) loop
- 시작 : $M$ default memory ( 기본 knowledge, Tool 포함 )
- $q_t$ : t번째 instruction
- $p^t : (p^t_1, p^t_2, \cdots)$ : action trajectory 생성
- $e_t = (q_t, {p^t})$ : collectively experience 생성
  $e_t$는, t번째 query와, action tranjectory 쌍을 말하는 것임.
- LM-based evaluation model로 평가(Pan et al. (2024))
  - binary label $L_{eval}(e_t) \in {0, 1}$로 아래를 판단.
  - $e_t$가 $q_t$를 해결했는지 판단
  - $e_t$가 1로 판단(성공적으로 해결했는지 판단)했으면, 이를 workflow로 변환한다.
    $I(e_t) \rightarrow {w_t}$
  - 그후, ${w_t}$를 에이전트 memory에 추가
    $M_t + {w_t} \rightarrow M_{t+1}$
  - $t+1$번째 instruction을 처리하기 위한 에이전트 memory로 사용

그림 4에 묘사된 대로, streaming된 test instruction에 대해 action을 예측하고 workflow를 유도하는 과정을 반복하여 이 memory-updating 프로세스를 계속 진행.
모든 test가 처리될 때까지 이 과정이 계속

3. Experiments

웹 네비게이션 벤치마크
- WebArena (§3.1)
- Mind2Web (§3.2)
관련 웹사이트별로 example을 그룹화하고, 각 그룹에 대해 AWM을 개별적으로 실험.

3.1 WebArena

5개의 웹사이트에 걸쳐 812개의 웹 네비게이션 task를 제공
- 도메인 : e-commerce, 소셜 포럼 토론, 협업 소프트웨어 개발, 콘텐츠 관리.
- 에이전트 trajectory의 functional correctness에 대한 평가를 지원
Baseline : 인간이 주석을 단 site-specific 지식 없이 현재 최고의 성능을 보이는 방법인 BrowserGym
- 이 방법은 에이전트의 default action space를 변경
- Zhou et al. (2024)의 environment 표현을 따라 accessibility tree를 사용하여 웹페이지를 표현.
- BrowserGym이 웹페이지 HTML과 accessibility tree 표현 모두를 입력으로 사용하기 때문에, 우리 방법과의 공정한 비교를 위해 우리는 accessibility tree 웹페이지 표현만을 사용하는 BrowserGym 버전도 비교함(BrowserGym_ax-tree로 표기)
WebArena 해결에 맞춤화된 14개의 인간 전문가가 작성한 workflow를 사용하는 SteP 방법 (Sodhi et al., 2023)과도 비교

3.1.1 Main Results

BrowserGym baseline 대비:
- 전체 성공률 12.0 절대 포인트 향상
- 51.1% 상대적 증가
인간 작성 workflow를 사용한 SteP 방법 대비:
- 전체 성공률 7.6% 상대적 증가
5개 웹사이트 성능 breakdown:
- 모든 웹사이트에서 BrowserGym baseline 대비 11.8-30.7 절대 포인트 향상
- 다양한 도메인과 task에 대한 일반적 적용 가능성 입증
효율성 측면:
- BrowserGym baseline 대비 example당 약 2.0 step 감소
- Autoeval 방법 대비 평균 40.8 step 감소
AWM은 높은 성공률을 유지하면서 효율적인 trajectory 달성

3.1.2 Efficient Learning From Small Amounts of Data

온라인 평가 과정에서의 누적 성공률을 분석
그림 5는 완료된 example이 될수록 성공률이 높아짐을 보여줌
주요 관찰:
- 초기 단계(0-40 example)에서 에이전트는 빠른 학습 곡선을 보임.
- 이 시기에 가장 필수적인 workflow를 습득하여 성공률이 크게 향상.
- 40 example 이후에는 더 고급 workflow를 학습하며 성능이 안정화.
- 성공률은 초기 학습 단계에서 도달한 최고점 주변으로 수렴.
결론:
- 단 수십 개의 example만으로도 성능을 크게 향상
- 적은 양의 데이터로부터 빠르게 학습하고 적응할 수 있음을 시사

3.1.3 Cross-Template Workflow Generalization

연구의 목적: AWM이 단순히 비슷한 유형의 작업에서만 잘 작동하는 것이 아니라, 다양한 종류의 작업에서도 효과적으로 사용될 수 있는지 확인하고자 함.

query : Get the zip code of a place
past agent experience $E$를 추출 : Find a place by its name
past experience의 workflow를, Get the zip code of place와 같이 LLM으로 부터 역할을 수행하게 함.

Action Trajectory:

Fig6.의 왼쪽 부분
- "{location}"을 OpenStreetMap에서 검색 (이전 워크플로우에서 채택)
- 검색 결과에서 {location}을 찾음 (이전 워크플로우에서 채택)
- fill('145', {location}) (이전 워크플로우에서 채택)
- click('147') (이전 워크플로우에서 채택)

Fig6.의 오른쪽 부분
- 지도나 관련 정보에서 우편번호를 추출 (새로운 단계)
- send_msg_to_user("the zip code is {zip-code}") (새로운 단계)

3.2 Mind2web

3.2.1 Main Results

Abstract sub-routines vs Concrete experiences

Synapse 방법 : 관련성 높은 훈련 예제를 검색
- AWM은 +5.0의 요소 정확도와 +4.0 성공률 증가
- Synapse는
  - 구체적이고 완전한 예제를 보여주나, 이는 에이전트로 하여금 주어진 예제와 유사한 요소를 선택하도록 할 수 있음.
  - 전체 예제 궤적을 주기에 유연하지 않음.(일부분만 참고 하고 싶을 경우도 있을 것임)
  - 풀고자 하는 문제가 Exact match라면, 괜찮지만, 그런 가능성은 낮음.
- 반면, AWM은 워크플로우는,
  - 컨텍스트를 추상적으로 표현함으로써 요소 선택에 대한 편향을 줄이고, 일반화 되어 성능이 더 좋음
  - AWM은 자주 사용되는 서브루틴을 통합하여 더 유연하게 사용.
  - 워크플로우의 추상적이고 재사용 가능한 특성이 AWM 방법이 좋음을 나타냄.

Learn to diverge from worflow guidelines

AWM은 MindAct에서 제안한 것보다 약간 낮은 점수를 얻음.

워크플로우를 따르는 것이 일반적으로 더 높은 성능을 보이나,
오퍼핏을 시킬 수 있음
워크플로우에서 벗어나는 것을 잘 하지 못함

3.2.2 Online AWM Enables Generalization

4. Exploring Optimal Workflow Representations

워크플로우를 더 잘 표현하는 다른 대안을 실험
(4.1) 서브루틴, 추상 형식의 워크플로우 제거해봄
서브루틴 : 웹사이트 로그인하기, 검색 결과에 특정 항목 찾기 등. 재사용이 가능한 행동들
(4.2) 설명 텍스트 형태의 워크플로우를 탐색
(4.3) (environment state)을 자연어로 설명하기보다, HTML구조로 설명.

4.1 How Much Does The Sub-Routine, Abstract Format Contribute?

(추상적인, 서브루틴 유도 방법)AWM방법과 단순 규칙 기반 방법과 비교

(AWM이 아니므로 중요한 것은 아님) 규칙 기반 유도 I_rule :
- 각 경험의 액션 시퀀스를 추출하고 액션 시퀀스별로 중복 제거함.
- 예)
  - ~~경험 A: CLICK → TYPE → TYPE → CLICK (로그인)~~
  - ~~경험 B: CLICK → TYPE → TYPE → CLICK (회원가입)~~
  - ~~경험 C: CLICK → CLICK → TYPE (검색)~~
  - ~~경험 A와 B는 같은 액션 시퀀스를 가지므로 둘 중 하나만 선택, C는 유니크 하여 유지~~
WebArena : (표5)규칙 기반과 LM의 결과는 비슷함.
Mind2Web : (표6)AWM이 2.8정도 높은 성능을 보임.
-> 추상적인 표현들을 제공하여, LM에게 행동의 자유도를 더 줄수있는것이 성능 향상에 원인으로 분석.

4.2 Workflow in Descriptive Texts

워크플로우 : 자연어 vs 프로그램 형태

결과 : 성능차이 유의미하지 않음.

예) 자연어 : CLICK({submit-id}) 액션은 "submit 버튼을 클릭하세요"와 유사한 자연어로 표현

4.3 Environment Abstraction In Workflows

웹에서 LM이 Agent로 행동하는데 있어서, Environment의 State을 평가하기 위해, HTML의 정보를 자연어로 받음.

허나 HTML형태로 제공하면 어떠할지 실험함.

웹페이지의 전체 HTML이 너무 길 수 있기 때문에, Deng et al(2023)으로 중요한 정보만을 필터링함
결과 : 자연어 설명이 HTML 보다 더 유용하다고 나옴.
- 원인 1. HTML을 추가하면 컨텍스트 길이가 상당히 증가하여 옳바르게 처리하지 못하는 것으로 보임.
- 원인 2. HTML에는 상당수 관련 없는 항목이 있음.

5. Exploring Workflow Utilization In Context And In Action

앞에서는 워크플로우를 에이전트 메모리로 사용하는 것을 살펴봄
에이전트의 액션 공간을 확장하는 워크플로우를 탐색해봄. 이를 AWM_AS로 표기함.
- 기존 액션 공간 :
  - 기본적인 액션들 (Click, type 등)
- 워크플로우를 고수준 함수로 래핑. (기존 액션 공간들의 조합)
  ~~예) 장소 찾기 : find_place()~~
  ~~-> find_place("New York") : 검색 창에 입력하고, 결과를 클릭하는 등의 여러 단계가 자동으로 수행~~
에이전트는 각 단계에서 초기에 정한 action 혹은 워크플로우 액션을 호출할 수 있음.
프리미티브 액션이 호출되면 에이전트는 즉시 그 액션을 수행
워크플로우 액션을 호출하면 워크플로우에 미리 정의된 일련의 단계가 트리거된다
- 예를 들어, login(username, password) 워크플로우 액션을 호출
- click(box1-id) → type(box1-id, username) → click(box2-id) → type(box2-id, password) → click(submit-id)가 순차적으로 실행.
결과 :
- AWM대비 성공률 1.3포인트 향상, 전체 태스크 성공률은 AWM과 동일
  -> 전체 태스크를 완벽하게 수행하는 비율에는 변화가 없었음.
- 왜 성능 변화가 크지 않았나?
  - 예) 항공 예약시 New York과 같은 도시 이름 입력
  - 이때 근처 공항들 JFK, LaGuardia, Newark를 팝업으로 보여줌.
  - 허나 워크플로우 상으로는 (도시이름 입력 -> 공항 선택 -> 날짜 선택)임.
  - 워크플로우 액션은 미리 정의된 대로 실행되기 때문에, 실시간으로 변하는 웹페이지의 상태(팝업)을 고려하지 못함.
  - 즉, 유연성 측면이 낮음.
- 워크플로우 액션 사용 빈도 :
  - 18.5%에서만 워크플로우 액션 사용
  - 새로운 액션 유형을 적극적으로 활용하지 않음.
- 해석 :
  - 에이전트는 기존의 익숙한 액션을 선호하고, 새로운 옵션을 충분히 활용하지 않는 경향이 있다.
  - 허나, 워크플로우를 만들어 약간의 이득이 있긴 함.

6. Related Work

Web Agent Benchmarks :
Enhancing Agents for Complex Tasks :
- 검색 공간을 수정하여 에이전트 개선
- 액션 검색 공간 제한
- LM 자체 피드백 활성화하여 예측된 액션 개선
- 인간이 설계한 액션을 통합하는 방식
- 에이전트 메모리를 보강하는 방법 ( InContext)
Learning Common Procedures from Experiences
- 전체 예제를 에이전트의 컨텍스트로 사용 - 허나 특정 컨텍스트와 얽혀 있어, 다른 도메인에서 적용하기 어려움.
- 규칙기반, LM기반으로 경험에서 자주 사용되는 서브루틴을 추출, 이를 보조 스킬로 향후 태스크를 해결

Appendix A LM-BASED WORKFLOW INDUCTION

(2.3과 비교하면서 꼭 읽어 볼 것)

경험에서, 추상적이고 서브루틴 기반의 워크플로우를 생성하도록 LM에 프롬프트 제공.

A.1 Model Prompt

인풋으로 모든 경험들을 제공했을 것으로 예상이 되는데, Contexdt Length의 한계가 있지 않을까 싶었음.
예상하자면, 배치별로 처리하거나,
소수의 경험으로 워크플로우 생성하고, 새로운 경험 배치로 이를 반복적으로 개선하는 방식을 사용하지 않을까 싶음.

A.2 Example Workflows

다양한 Examplar들...

A.3 WorkFlow Quality Analysis

1. 워크플로우 수 : 메모리에 추가된 워크플로우 수 검토
- 에이전트가 좋은 성능을 달성하기 위해 더 적은 워크플로우에 의존할수록 효율적임
(메모리 사용 최소화, 결정을 내릴 때 고려할 옵션이 감소)
2. 커버리지 : 예) 100단계로 이루어진 작업이 있고, 워크플로우가 80개를 포함한다면 80%의 커버리지를 갖음.
- 높은 커버리지는 워크플로우가 다양한 상황에 적용 가능하고, 많은 작업을 효과적으로 처리할 수 있음을 의미
3. 기능 중복 : 워크플로우 간에 얼마나 비슷한 기능이 중복되어 있는지 측정
- 워크플로우들을 비교하며, 겹치는 서브 궤적이 얼마나 있는지 계산(중복이 적을 수록 좋음)
4. 활용률 : 생성된 워크플로우가 실제 테스트 상황에서 얼마나 자주 사용되는지 나타냄