[Survey] Deep dive into AI Agent & Multi-Agent System (MAS)

tu11p·2024년 11월 25일

AI LLM Multi-Agent agent mas

LLM

목록 보기

2/2

AI Agent

언어 모델을 기반으로 인간을 대신해 특정 목적을 달성하기 위해 설계된 지능형 시스템
주어진 입력(텍스트, 명령어, 대화 등)을 처리해 원하는 출력(정보, 결정, 행동 등)을 생성
특정 작업 및 특정 사례에 특화되어 사용 가능
LangChain에서는 AI Agent를, ‘LLM을 사용해 애플리케이션의 제어 흐름을 결정하는 시스템’이라고 정의

그럼 우리는 왜 AI Agent를 사용할까, 아니 왜 사용해야 할까?

일반적인 LLM 기반 서비스 사용자들(ChatGPT and so on…)은 zero-shot mode로 최종 결과물을 출력하게 사용한다.
- 이는 누군가에게 처음부터 끝까지 에세이를 써달라고 하면서도, backspace없이 정확히 typing하고 higy quality의 result를 기대하는 것과 비슷하다.
- 그러나 LLM은 이러한 어려움을 이겨내고 잘 해낸다.
AI Agent를 사용하면, LLM에게 최종 출력물을 내기 전에 내부적으로 작업을 여러번 반복하도록 할 수 있다(출력 퀄리티를 높이기 위해).

실제로 GPT-3.5와 GPT-4에서 zero-shot과 agent workflow로 HumanEval(코드 생성 벤치마크) 퍼포먼스를 비교한 결과, agent를 사용했을 때 월등한 성능 향상을 보였다.
- GPT-3.5 with agent는 GPT-4 Vanilla 보다 성능이 좋다..

AI Agent의 구조

AI Agent의 구조는 크게 5개로 나눌 수 있다.
코어가 되는 LLM, 그리고 Planning/Action/Profile/Memory

LLM
- 사람으로 치면 두뇌다. 텍스트를 처리하고 의사결정을 한다.
Planning
- AI Agent는 복잡한 objective를 작은 task로 나눌 줄 아는 능력이 중요하다.
- 이는 planning module을 통해 수행되며, 다음과 같은 동작들을 수행한다
  - 주어진 objective 분석
  - 목표 달성 위해 필요한 단계 파악
  - 단계들의 우선 순위 선정
  - 새 정보들이 들어오면 계획을 수정하기
Action
- Ai agent가 task를 수행하기 위해 tool과 interact하는 component.
- 웹 검색, 코드 실행, DB 접근, API 사용, 다른 SW와 interact 등
- 이런 tool들을 얼마나 잘 쓰는지가 AI agent가 얼마나 넓은 범위의 작업을 할 수 있는지를 결정한다.
  - tool의 사용으로 generative execution에서 deterministic execution으로 바뀌기 때문
  - llm이 생성하는 단순 언어적 응답이 아닌 tool을 사용한 구체적인 출력으로 인해 정확하고 신뢰성 있는 응답, 확장성과 유연성
Profile
- AI Agent의 행동, 성격, 기능을 정의한다. chat_template에서 role system과 비슷한 역할
  - Agent의 전문 분야, tone & communication style 등
Memory
- Memory를 통해 agent는 과거 정보를 저장하고 불러오는 것은 아래 상황에서 중요함:
  - 진행 중인 대화에서 context 유지하기
  - 과거 경험으로부터 학습하기
  - 점진적으로 성능을 향상시킴
  - user history에 따라 personalized된 응답 제공

Multi-Agent System(MAS)

Multi-Agent System은 앞서 말했듯 여러 에이전트가 결합된 하나의 시스템으로, 한 분야에 특화된 에이전트가 각 역할을 맡아 양질의 출력을 낸다.
MAS에도 Reflection, Tool Use, Planning이 당연히 사용된다.

AI Agent Detailed

Agentic pattern은 AI agent들이 어떻게 동작하고 interact 하는지 가이드하는 프레임워크다. 최근 연구에서 확인된 주요 패턴은 다음과 같다.
- Reflection
- Tool Use
- Planning
- Multi-Agent Collaboration

Reflection

이 글에서 reflection은 반성, 반영 정도로 해석가능할 것 같다.
Reflection은 AI Agent가 자신의 출력을 분석하고 평가하는 능력을 의미한다.
Agent의 출력을 스스로 평가하여 개선을 위한 피드백을 제공할 수 있다.

1-1. MAS에서의 Reflection
- MAS에서 reflection은 두 에이전트가 서로 피드백을 주고 받는 방식으로 구현할 수 있다.
  - A 에이전트는 high quality의 output을 생성하도록 prompt를 받고,
  - B 에이전트는 A 에이전트의 output을 critic하게 평가하고 constructive한 피드백을 준다.
- 이런 방식으로 더욱 개선된 response가 생성될 수 있다.

Tool Use

LLM의 사전 학습된 지식만으로는 출력을 생성하는 데 한계가 있다는 것을 깨닫게 되었다..
Agent는 아래와 예시와 같은 tool들을 사용해 역량을 확장한다
- Web Search: Agent가 Web Search와 결합되면 학습 데이터 범위를 넘어선 정보를 얻을 수 있으며, 이를 통해 knowledge base를 크게 확장한다.
- Code Execution: 단순히 코드를 추론하는데 그치지 않고, 코드를 작성한 뒤 실행해보며 출력물을 실제로 testing & application 해볼 수 있다.
- Python을 실행하는 것도 tool use이다.
LLM이 {tool: web-search, query: "coffee maker reviews"}같은 문자열을 생성하도록 fine tuning되거나, few shot 프롬프팅을 사용한다.
- 이후 post processing에서 문자열을 검색해 tool을 호출해 그 결과를 다시 llm에 전달한다.

Planning(+Reasoning)

Planning과 Reasoning을 함께 묶어서 LLM이 어떤 행동을 취할지 생각하는 능력이라고 보는 경우도 있다.
LLM은 복잡한 task를 다루기 위해 task를 manageable한 step들로 나누는 능력을 갖고 있다.
이는 agent가 목표를 달성하기 위해 필요한 행동들의 순서를 고려한뒤 체계적으로 문제를 해결할 수 있게 한다.
Planning을 이해하기 위해, HuggingGPT 논문에서의 예시를 단순화해보면 아래와 같다.
- “소년의 사진을 보고, 동일한 자세를 취한 소녀의 그림을 그려줘”라고 요청할 경우, task는 두 단계로 나뉜다.
  - 소년 사진에서 pose detect
  - detected pose를 기반으로 소녀의 그림을 랜더링
- LLM은 {tool: pose-detection, input: image.jpg, output: temp1 } 과 같은 구조화된 문자열을 생성하도록 fine tuning되거나, few shot 프롬프팅으로 plan을 설정할 수 있는 것이다.
Planning은 언제 필요할까?
- planning이 항상 필요하진 않다. 고정된 횟수만큼의 reflection을 통해 생성물을 개선하면 이 agent는 fixed하며 deterministic하다.
- 그러나 task를 사전에 단계별로 쪼갤 수 없는 경우에는, planning을 통해 agent가 동적으로 단계별 실행을 결정할 수 있다.
Planning은 복잡한 작업을 agent가 독립적으로 적절하게 나누어 수행한다는 장점이 있지만, 그 step과 최종 output에 대한 예측 가능성이 떨어진다는 단점이 있다.
복잡한 작업을 잘 planning & reasoning하여 수행하는 것은 쉽지 않은데, 왜냐하면
1. LLM으로 하여금 큰 그림을 본 다음에 다시 단기적인 action을 하도록 해야 하고,
2. agent가 많은 작업을 하면 할수록 그 결과들이 llm에 피드백되므로 context window가 커지고, 결국 모델은 ‘distracted(산만해짐)’되어 성능이 낮아질 수 있다.
Planning의 성능을 개선하기 위한 가장 낮은 단계의 해결책은 plan과 reason을 위한 모든 정보를 확보하는 것이다.
- 종종 prompt에는 정보가 충분하지 않은 경우가 많다.
또한 retrieval step을 추가하거나 prompt instruction을 명확히 하면 성능이 개선될 수 있다.
이후에는 애플리케이션의 cognitive architecture를 변경해보는 것이 좋다.
- cognitive architecture: 애플리케이션이 추론하는 데 사용하는 data engineering logic
- gereral cognitive arch.(AlphaCodium 등) 와 domain specific cognitive arch. (커스텀 구현) 로 나뉜다.

Multi-Agent Collaboration

하나에 특화된 agent들이 여러 개 모여서 Multi-Agent System(MAS)를 이룰 수 있다.
일반적인 개발 회사에서와 같이 기획, 디자인, 개발, QA 등의 전문적인 역할을 나누어 수행할 수 있다고 볼 수 있다.
MAS는 하나 혹은 여러 LLM을 프롬프트하여 서로 다른 task를 수행하도록 설정함으로써 구현할 수 있다.
- EX) 당신은 명확하고 효율적인 코드를 작성하는 전문가입니다. 다음 작업을 수행하기 위한 코드를 작성하세요. …
한 LLM을 여러번 호출하면서도 여러 agent를 사용하는 programming abstraction을 적용하는 것은 직관에 반대되는 것처럼 보일 수도 있다. 하지만 이런 방식에는 몇가지 이유가 있다.
- 먼저 결과가 좋다(ㅋㅋㅋ).
  - 좋은 성능이 실제로 가장 설득력 있는 이유가 된다. AutoGen 논문 등에서 수행한 ablation study에서도 multiple agents가 single agent보다 뛰어난 성능을 보이는 것을 나타낸다.
- LLM의 input context limitation을 보완한다.
  - 일부 최신 LLM은 100만 토큰의 긴 input context를 지원하지만, 길면서도 complex한 input을 truly understand하는 능력은 제한적이다.
  - 한 번에 하나의 세부 작업에 집중하도록 LLM을 프롬프트하는 agent workflow는 더 좋은 성능을 제공한다.
- 복잡한 작업을 잘 나눌 수 있게 한다.
  - MAS가 복잡한 task를 세부 작업으로 분해하는 기능은 단일 CPU에서 프로그램을 실행할 때 여러 프로세스나 스레드로 나누는 방식과 유사하다.
MAS는 AutoGen, CrewAI, LangGraph 등의 프레임워크로 구현가능하다.
MAS는 planning과 마찬가지로 output의 quality를 미리 예측하기 어렵다.