작년부터 사내에 AI Agent 관련 업무를 병행하면서 빅테크나 여러 스타트업이 개발한 AI Agent 도구들을 많이 검토하게 되었다. 그 때마다 ReAct와 관련 된 내용을 많이 발견했고, 이에 대한 후속 연구도 생각보다 활발하게 이루어지고 있는 것을 보았다.
내 경우는 ReAct를 LangChain 같은 Agent 관련 프레임워크 없이 개발해서 상용까지 올려보기도 했고, 정확도 향상을 위해 온갖 커스터마이징을 해봤었는데, 결국 돌고 돌아서 ReAct 형상으로 돌아올 뿐이였다.
그런 답답한 상황 와중에 작년에 ADaPT를 보게 되었고, 이것이 나름 괜찮은 돌파구여서 오늘 다시 소개하고자 이 논문을 선정했다.
의사 결정을 위한 LLM
최근에 나온 LLM 모델들은 수학 문제 풀기나 코딩 외에도 외부 환경과 상호작용을 위한 지식들이 탑재 되어서 나온다. GPT에서 제공하는 function calling이 그 대표적인 예시 중에 하나로, GPT의 지식으로 해결 할 수 없는 문제를 외부 function을 통해 해결하는 것이 그 아이디어다.
이를 더욱 응용하여 LLM을 의사결정에 활용하는 연구도 진행되었다. 그 대표적인 논문이 ReAct인데, 이는 LLM이 행동과 관찰을 토대로 현재 환경에서 실행할 다음 행동을 반복적으로 생성하는 방식이다. 위 그림의 좌측 부분이 이에 해당하는데, ReAct의 특성상 다음 행동을 반복적으로 추론하기 때문에 Iterative한 실행 방식이라고 본다.
또 다른 방식으로는 계획을 미리 세우고 LLM을 활용해 하위 작업을 실행하는 방식이 있을 수 있다. 위 그림의 오른쪽에 해당하는 방식으로, 별도의 planning을 수행하는 모듈이 계획을 세우고, 하위에 작은 수준의 LLM 모듈이 하위 작업을 수행하는 방식이다.
하지만 기존에 알려진 두 방식은 몇가지 결점이 존재한다.
Iterative Executing 방식의 문제점
우선 반복적으로 추론을 수행하는 경우에 발생 할 수 있는 문제점은 주어지는 과제가 복잡할 수록 LLM이 행동을 수행하는 이력이 길어지게 된다. 그렇게 되는 경우, 긴 context로 인해 방해를 받을 수 있게 된다. 또한 문제를 해결하기 위해 local 행동을 결정해야 하는데, 이를 수행 할 때마다 전체 계획을 암묵적으로 추적하고 있어야 한다는 문제가 발생한다.
일반적으로 이러한 문제를 해결하기 위해서 피드백을 주거나 그래프 형태로 바꾼 후, 휴리스틱을 적용할 수 있지만, 전체 경로를 탐색해야 하기 때문에 불필요한 계산이 많아진다.
Plan-and-Executing 방식의 문제점
미리 계획을 세우는 방식의 경우에 발생 할 수 있는 문제점은 더 명확하다. 만약 계획이 처음부터 틀어지는 경우에는 전체 작업이 실패 할 수 있을 것이다. 위 그림에서도 첫 하위 작업이 지나치게 복잡한 경우, 뒤에 따라오는 plan 2, 3이 실패하게 된다.
ADaPT
ADaPT는 Iterative 방식과 Plan-and-Executing 방식의 단점을 해결하기 위해서 양쪽의 장점을 합쳤다. 위 그림처럼, 우선 ADaPT가 작업을 받은 경우, executor를 반복적으로 실행하여 전체 작업을 직접 수행하려고 시도한다. 만약 실패하는 경우, LLM planner를 이용하여 작업을 하위 작업으로 추가 분해를 한다. 그리고 각 하위 과제를 재귀적으로 호출하여 전체 과제가 성공적으로 완료 되도록 하는 방식이다.
이를 수행하기 위해서 ADaPT는 Executor, Planner, Controller 3가지 모듈을 지원한다. 이에 대한 내용은 아래에서 더 설명하겠다.
LLM as an Executor
Executor는 주어진 환경으로부터 자연어 형태의 작업을 입력값으로 받는다. 그리고 LLM은 행동과 환경 관찰을 반복적으로 수행하면서 작업을 해결한다. 이러한 작업은 LLM이 주어진 작업이 완료 되었다고 판단하거나, 미리 설정 된 최대 반복 횟수에 도달 할 때까지 계속된다. (ReAct의 방식을 그대로 가져 온 것으로 보인다.)
Execution Capabilities of an LLM
우선 ADaPT는 LLM이 최소한 atomic하게 task를 수행 할 수 있어야 한다는 것이 전제 조건이 되어야 한다. 예를 들어, 위 그림에서 작업은 "책상에 깨끗한 머그컵을 올려 놓는 것"인데, 이를 수행하기 위해서는 머그컵을 깨끗하게 씻는 atomic한 작업이 제대로 수행 되어야 한다.
사실 대부분의 LLM을 사용하는 Agentic AI가 다 그렇지만, LLM은 이러한 최소한의 작업 단위를 스스로 완수 할 수 있다는 능력이 필요하다.
Self-generated Success Heuristic
또한 LLM은 하위 작업의 golden reward 없이도 LLM이 스스로 하위 작업의 완료 여부를 결정 할 수 있어야 한다. 즉, 어떤 atomic 작업이 수행 되었을 때, LLM이 스스로 이 작업이 해결이 되었는지 아닌지를 판단 할 수 있어야 한다는 것이다.
LLM as a Planner
Planner는 복잡한 작업을 더 작은 하위 작업으로 분해하는 것이 목적이다. 위 그림에서 가장 오른쪽 그림을 보면, 포괄적인 계획을 3~5단계 사이 정도로 생성하도록 지시한다.
계획의 단계 수가 굉장히 짧다고 느껴질 수 있지만, 저자는 이렇게 더 짧고 추상적으로 계획을 선택하는 이유로, 탐색이 아직 완료 되지 않은 환경에서 세밀하고 장황하게 계획을 기대하는 것이 되려 비현실적이라고 제안한다.
예를 들어, "책상에 깨끗한 머그컵을 올려 놓는 것" 작업을 위해서 10단계로 계획을 세워버린다면 잘못 된 가정이나 오류가 발생할 가능성이 높다는 것이다. 그렇기 때문에 Planner는 짧은 계획을 우선적으로 세운 뒤, executor의 능력에 따라 필요한 경우에 후속 작업에서 추가적으로 작업 분해를 요청한다.
Composition Logic for Sub-tasks
Planner는 생성 된 계획 사이에 존재하는 하위 작업들을 결합해야 한다. 이를 위해 Planner의 프롬프트 안에는 이를 생성하기 위한 논리 연산자 관련한 내용이 들어 있다. 논리 연산자는 AND와 OR만 제공이 되고, 각각이 해당하는 조건은 다음과 같다.
- AND : 하위 작업들이 순차적으로 모두 실행 되어야 전체 작업이 성공하는 경우
- OR : 하위 작업 중 하나라도 성공하면 전체 작업이 성공하는 경우
Controller Program
Controller는 Planner와 Executor가 서로 수행하는 역할을 통합시켜서 정의 된 알고리즘을 통해 전체 파이프라인으로 통합하는 역할을 수행한다.
위 알고리즘이 나타내는 Controller의 전체 흐름은 다음과 같다.
- 작업이 들어오면 executor를 먼저 호출하여 직접 작업을 수행 할 수 있는지 확인한다.
- executor가 실패한 경우, planner에게 넘겨서 하위 작업으로 분리한다.
- 하위 작업에 대해 재귀적으로 호출한다.
- 만약 재귀 호출 시, 최대 깊이 ()에 도달한 경우 재귀를 종료한다.
하위로 분해 된 작업들이 성공 한 경우, Planner에서 생성한 논리 연산자 조건에 따라서 전체 작업도 성공으로 전환 된다.
실험 내용
Baseline 및 데이터셋
ADaPT는 실험을 위해서 데이터셋으로는 ALFWorld, WebShop, 그리고 TextCraft를 사용했다. 그리고 이에 대한 비교군으로 ReAct와 Reflexion 그리고 본인들이 만든 Plan-and-Executing을 사용했다. 사용되는 모델은 모두 동일한게 GPT-3.5를 사용했다.
ALFWorld
위 표는 ALFWorld 데이터셋에서 보인 각 작업별 성공률과 전체 성공률이다. ADaPT가 Heat를 제외한 모든 작업에서 제일 좋은 성능을 보였다. 특히 ADaPT가 Pick2 작업에서 높은 성공률을 보였는데, 이는 두 개의 pick 작업이 결합 되는 데이터라 긴 행동 히스토리가 필요하기 때문이라고 한다.
WebShop & TextCraft
WebShop과 TextCraft 데이터셋 또한 ADaPT가 가장 높은 성능을 보여주었다. Reflexion에 비해 성능이 좋은 것이 신기한데, 그 이유가 Reflexion은 전체 경로에서 발생하는 오류를 기반으로 자연어 형태의 피드백을 생성하는데, 이것이 성능 향상에 제약을 만든다.
또한 Plan-and-Execute의 경우, 동적으로 상황에 대응하는 능력이 없기 때문에 작업 처리가 불가능한 경우 유연한 대응이 전혀 되지 않는 문제가 있다. 그렇기 때문에 WebShop 같은 데이터셋에서 굉장히 불리하게 작용한다.
반면에 ADaPT는 설계상 작은 단위의 하위 작업을 실패 처리하고, Planner 호출과 작업의 재분해로 인해 더 많은 시간을 어려운 하위 작업에 집중시키기 때문에 성능이 좋게 나왔다고 분석된다.
최대 재귀 호출 값에 따른 성능 변화
모든 데이터셋에 대해서 ADaPT는 값을 증가 시켜서 성공률을 더 끌어올릴 수 있다. 특히, 값이 1에서 2로 증가 할 때가 제일 크게 성능 향상이 되었는데, 이는 executor가 실패 할 때 planner를 이용해 작업 분해를 시키는 것이 효과적이기 때문이다.
LLM에 따른 성능 변화
위 그래프는 여러 LLM에 대해서 ADaPT가 각 데이터셋에 대해 얼마만큼의 성공률을 보일 수 있는지를 나타낸다. LLaMA의 경우 LLaMA-2 70B가 사용 되었고, Lemur도 70B 정도의 모델이 사용되었다. 거의 모든 데이터셋에 대해서 ADaPT가 모델에 상관 없이 더 좋은 성능을 보이고 있다.
추가로 Planner와 Executor를 각각 다른 LLM을 사용하는 경우도 ALFWorld 데이터셋에서 수행을 했다. 한 LLM이 생성한 planning을 다른 LLM을 사용하는 executor에서 실행하는 경우에도 성능 향상은 이루어졌다.
결론 및 고찰
ADaPT는 다음과 같이 한 줄로 요약이 가능 할 것 같다.
작업을 iterative하게 우선 수행 하다가, 실패하는 경우, Planning으로 쪼갠다.
이전에 ReWOO라고 ReAct와 비교군으로 나온 논문이 있었는데, 그 논문의 경우 Plan을 미리 하고 일괄적으로 작업을 수행하는 내용이였다. 처음에 그 논문을 봤을 때는 ReAct에 비해 실제로는 성능이 제대로 나오지 않을 것이라 생각했었는데, 그 이유가 ReAct에 비해 오류를 처리하는 능력이 떨어질 것이라 생각했었다.
그에 비해 ADaPT는 ReAct보다 좀 더 복잡한 문제를 잘 해결 할 것으로 보이는데, 아직까지는 대부분의 문제는 이전보다 LLM이 워낙 성능 좋아졌기 때문에 ReAct로도 잘 풀린다. 특히 멀티턴 작업까지 수행 하는 경우, 프롬프트가 굉장히 거대해지기 때문에 ADaPT 같이 재귀적인 방식이나 추가적인 Planning을 사용 할 경우, 이에 대한 프롬프트 최적화도 필요할 것으로 보인다.
