[Paper Review] The Landscape of Emerging AI Agent Architectures for Reasoning, Planning, and Tool Calling: A Survey (2024.04)

2024년에 arXiv에 제출된
'The landscape of emerging AI agent architectures for reasoning, planning, and tool calling: a survey' 논문을 바탕으로 작성된 리뷰입니다. (Masterman, T., Besen, S., Sawtell, M., & Chao, A.)

 

 

AI Agent Architecture

• Single Agent Architecture
• Multi Agent Architecture

최근 실제 문제를 해결하는 Agent에 대해 많은 연구들이 이루어지고 있다.

• ex) SWE-Agent, AutoCodeRover, Octopus-v2 + Agent를 위한 프레임워크(Tiger, NPi, CopilotKit)

Survey의 목적: Agent 구조를 선택할 때 주요 주제, 리더십이 agent system에 미치는 영향, agent communication 스타일 및 AI agent system에 관한 계획, 실행 및 성찰을 위한 주요 단계 설명

Introduction

ChatGPT 출시 이후 생성 AI application은 Retrieval Augmented Generation (RAG) 패턴을 사용하는 문서 말뭉치에 대한 채팅의 변형이 대부분이었다.

차세대 AI application을 위해 AutoGPT, BabyAGI와 같은 오픈 소스 프로젝트들로 대중화된 연구 community는 Autonomous agent-based system 구축에 집중하였다.

• zero-shot prompting: 사용자가 개방형(open-ended) text field에 입력하여 추가적인 입력 없이 사용자의 입력만을 사용하여 결과를 얻는 방식
• agentic system: 모델의 고유한 추론 기능을 활용하여 end-to-end로 수행하는 방식
  • planning, loops, reflection 등의 제어 구조 개념을 가지고 있음.
  • tool, plugin, function calling 등을 사용하여 범용적인 작업을 수행할 수 있다.
  • 더 복잡한 상호작용 및 orchestration 기능

복잡한 task를 해결하는데 있어 Single Agent system이 적합한지 Multi Agent system이 적합한지에 대한 연구가 현재에도 진행중이다.

Taxonomy (Components)

• Agents: 목표를 달성하기 위해 여러 번에 걸쳐 반복적으로 계획을 세우고 행동을 취할 수 있는 언어 모델 기반의 개체
  • persona가 각 agent마다 주어지고 다양한 tool에 접근 가능
  • 몇몇 agent들은 memory component를 가지고 있어 그들의 message, prompt 외부에도 정보를 저장하거나 로드할 수 있다.
  • “brain, perception, and action”로 구성된 agent: 환경에서 agent들이 이해하고, 추론하고, 행동하는데 있어 최소한의 요구사항을 만족
• Agent Persona: agent에게 특정된 instruction을 포함하여 agent의 role 또는 personality 설명
  • agent가 접근하는 tools에 대한 설명 포함
  • “형상화된 성격(shaped personality)는 소셜 미디어 게시물 작성과 같은 일반적인 downstream 작업에서 LLM 행동에 영향을 준다”는 것 발견
  • multiple agent persona를 사용하여 CoT prompting과 비교했을 때 향상된 결과를 보인다.
• Tools: model이 호출 가능한 모든 함수들
  • agent가 외부 데이터 소스, API, 기능 등과 상호작용(push&pull)할 수 있는 능력
  • agent persona & 연관된 tool 예시: 전문적인 contract writer → 달성해야하는 task의 role & type 설명하는 persona
• Reasoning: agent가 주어진 정보를 바탕으로 논리적인 결론을 도출하거나 문제를 해결하는 과정. 복잡한 상황 이해 및 적절한 행동.
• Planning: agent가 목표를 달성하기 위해 일련의 행동을 순서대로 정리하는 과정. 문제를 더 작은 하위 문제로 분해하고, 각 단계에서 필요한 행동을 결정하는 것 포함.
• Single Agent Architectures
  • 하나의 언어 모델 → reasoning, planning, tool 실행
  • Agent에게 system prompt와 tool이 주어짐.
  • 다른 AI agent들로부터 feedback mechanism(상호작용)은 없지만, 사람이 agent에게 guide하는 feedback을 제공할 수는 있다.(선택)
• Multi-Agent Architectures
  • 2개 이상의 agent가 협업하여 작업을 수행하는 구조 - 각 agent는 고유한 persona를 가지며, 동일하거나 서로 다른 언어 모델과 도구를 사용할 수 있다.
  • 다양한 complexity - primary category 2개
  • Vertical Architectures
    • 하나의 Lead Agent가 다른 agent들을 관리하고 지시하는 구조
    • 모든 agent들 간의 conversation 공유하는 형태로 대체될 수 있다.
  • Horizontal Architectures
    • 모든 agent가 동등한 지위를 가지며, 그룹 토론을 통해 정보를 공유하고 협업하는 구조(collaboration, feedback, group discussion)
    • Lead Agent에 의해 assign되지 않아도 됨.

Key Considerations for Effective Agents

Agent는 real-world 문제를 효율적으로 해결하기 위해 언어 모델의 능력을 확장하도록 설계되었다. (robustness)

이를 위해서는 외부 환경과 상호 작용하는 tool을 호출하는 것, reasoning, planning 능력이 모두 필요하다.

The Importance of Reasoning and Planning

• Reasoning은 인간 인지의 핵심 요소 - AI agent 또한 복잡한 환경과 효과적으로 상호작용하고, 자율적인 의사결정을 내리며, 다양한 작업에서 인간을 지원하기 위해서는 강력한 추론 능력이 필수적이다.
• Acting과 reasoning의 시너지
  • 행동과 추론 간의 긴밀한 결합은 새로운 작업을 빠르게 학습하게 하고, 새로운 상황이나 정보의 불확실성 하에서도 강건하고 유연한 의사결정을 가능하게 한다.
  • Agent는 새로운 피드백이나 학습된 정보를 기반으로 자신의 계획을 지속적으로 조정할 수 있어야 한다.
• 추론 능력이 부족한 에이전트의 한계: 단순한 작업을 수행할 때도 질문을 잘못 해석하거나, 글자 그대로만 이해한 반응을 생성하거나, 다단계 결과를 고려하지 못할 수 있다.
• Planning은 고차원적 추론 능력을 요구하며 다음과 같은 접근 방식으로 분류됨:
  • 작업 분해(Task decomposition): 작업을 더 작은 하위 작업들로 나눔
  • 다중 계획 선택(Multi-plan selection): 여러 후보 계획 중 최적의 하나를 선택
  • 모듈 기반 계획 지원(External module-aided planning): 외부 모듈을 통해 계획을 지원
  • 반성 및 수정(Reflection and refinement): 이전 계획을 평가하고, 새 정보에 따라 수정
  • 기억 기반 계획(Memory-augmented planning): 외부 기억 정보나 과거 계획을 활용하여 계획 품질 향상
• 대부분의 agent 시스템은 계획 전용 단계를 포함
  • 이 단계에서는 위 기술 중 하나 이상을 사용하여, 실제 행동 이전에 계획을 수립함
  • 예시: Plan Like a Graph (PLaG)
    • 계획을 그래프로 표현하며, 여러 단계가 병렬로 실행될 수 있도록 구성
    • 여러 개의 독립적인 하위 작업이 존재하고, 비동기 실행이 유리한 과제에서 성능을 크게 향상시킬 수 있다.

The Importance of Effective Tool Calling

• Agent 기반 시스템의 주요 이점 중 하나는 다양한 tool을 호출하여 복잡한 문제를 해결할 수 있다는 점
  • 도구 호출을 통해 agent는 외부 데이터 소스와 상호작용하거나, 기존 API로부터 정보를 송수신할 수 있다.
• 단일 에이전트(single-agent)와 다중 에이전트(multi-agent) 구조 모두 도구 호출과 추론을 통해 어려운 작업을 해결 가능
  • 많은 기법들은 문제 해결 과정에서 reasoning, memory, reflection을 여러 번 반복하여 정확성과 효율을 높인다.
• 단일 에이전트 패턴의 한계와 특징
  • 큰 문제를 작은 하위 문제들(subproblems)로 나눔 → 각각의 하위 문제에 적합한 도구를 순차적으로 사용하여 해결하는 방식이 자주 활용된다.
  • 문제를 하위 문제로 나누는 것은 효과적이지만, 단일 에이전트 패턴은 길고 복잡한 작업 흐름을 끝까지 수행하는 데 어려움이 있음.
• 다중 에이전트 패턴의 장점
  • 병렬 처리와 견고함(robustness) 측면에서 효과적임.
  • 각 agent가 독립적으로 하위 작업을 수행하므로, 전체 문제를 나누어 처리할 수 있음.
  • 하나의 복잡한 문제를 여러 개의 작은 하위 작업으로 나눔. → 각 agent가 자신만의 도구 세트를 이용하여 독립적으로 하위 작업을 해결.

Single Agent Architectures

[ 핵심 주제 ]

• 성공적인 목표 수행의 핵심 조건: 적절한 planning & self-correction이 반드시 필요함
• 단일 에이전트 아키텍처가 특히 유용한 경우
  • 단순한 함수 호출만으로 작업이 가능한 경우
  • 다른 agent의 피드백이 필요 없는 작업에서는 단일 에이전트 방식이 효율적임
• 단일 에이전트가 가진 위험 요소
  • 스스로를 평가하거나 효율적인 계획을 수립하지 못할 경우:
    • 무한 반복 실행 루프에 빠질 수 있음
    • 작업을 완수하지 못하거나, 사용자 기대에 부합하지 않는 결과를 반환할 수 있음
• ReAct, RAISE, Reflexion, AutoGPT + P, LATS

ReAct(Reason + Act)

• Agent가 작업에 대한 생각(thought)을 먼저 작성하고, 그 생각에 따라 action을 수행. → 그 결과를 관찰한 뒤 다시 생각을 작성하는 과정을 반복하여 작업을 완료함.
• 장점
  • 다양한 언어 및 의사결정 작업에서 zero-shot 방식보다 더 우수한 성능을 보임.
  • 사람과의 상호운용성과 신뢰도를 향상시킴 → 모든 추론 과정을 기록함으로써 사람도 이해 가능.
  • 예: HotpotQA 데이터셋에서, ReAct는 hallucination)발생률이 6%, CoT(Chain of Thought)는 14%
• 한계점
  • 추론, 관찰, 행동의 반복이 신뢰성을 높이지만, 모델이 같은 생각과 행동을 반복하며 작업을 완료하지 못하는 루프에 빠질 수 있음.
  • 해결 방안: 작업 도중에 사람의 피드백을 통합하면, 실세계 적용성과 성능을 높일 수 있음.

RAISE

• ReAct 방식 + “인간의 단기 기억 및 장기 기억 메커니즘을 모사한 memory mechanism”
• 단기 기억: 스크래치패드(scratchpad) 사용
• 장기 기억: 유사 예시 데이터셋을 저장하여 활용
• 장점
  • 긴 대화 문맥을 유지하는 능력을 향상시킴.
  • 작은 모델에서도 최적화된 fine-tuning을 통해 좋은 성능을 보임.
  • 성능 면에서 ReAct보다 더 높은 효율성과 출력 품질을 제공함.
• 한계
  • 복잡한 논리적 구조를 이해하지 못함 → 일부 시나리오에서 유용성이 낮아짐.
  • 명확한 역할 정의가 없는 경우, agent가 잘못된 지식을 기반으로 엉뚱한 작업 수행 가능. (ex. sales agent가 갑자기 Python 코드를 작성하려 함.)
  • Hallucination 여전히 존재. 일부는 fine-tuning 통해 개선되었지만, 여전히 RAISE의 주요 한계로 지적됨.

Reflection

• 언어적 피드백을 통한 self-reflection을 활용함.
• 성공 상태(success state), 현재 진행 경로(current trajectory), 지속 메모리(persistent memory) 등 다양한 지표를 활용.
• LLM evaluator를 활용하여 agent에게 구체적이고 관련성 높은 피드백을 제공함.
• 장점: CoT, ReAct 방식에 비해 성공률 향상 & hallucination 발생률 감소
• 한계
  • Non-optimal local minima에 민감할 수 있음.
  • DB가 아닌 sliding window 방식을 사용 → token 제한에 의해 장기 기억의 양이 제한됨.
  • 탐색, 다양성, 고차 추론을 요구하는 작업에서는 여전히 성능 개선이 필요함.

AutoGPT + P(Planning)

• 자연어로 로봇을 제어하는 agent의 추론 한계를 보완하기 위한 방법
• Object Detection 및 Object Affordance Mapping (OAM)을 기반으로, LLM 기반 계획 시스템과 결합되어, 누락된 객체 탐색, 대안 제안, 사용자 피드백 요청 등이 가능해짐.
• 동작 방식: 장면 이미지를 통해 객체를 감지하고, LLM이 해당 객체 정보를 바탕으로 4가지 tool(plan tool, partial plan tool, suggest alternative tool, explore tool) 중 하나를 선택함.
• 계획 수립 구조: 목표와 단계를 생성 → classical planner가 실제 계획을 실행함. 이때, PDDL (Planning Domain Definition Language)이라는 언어를 사용함.
• 한계
  • 도구 선택의 정확도 편차
  • 탐색이 필요한 작업에서 비논리적 판단 가능
  • 인간 상호작용의 제한(Agent의 명확한 설명 요청 및 사용자의 계획 수정 어려움.)

LATS(Language Agent Tree Search)

• Plan, act, reasoning → 트리 구조를 통해 결합. Monte Carlo Tree Search에서 영감을 받아, 상태를 노드로 보고 행동은 노드 간 이동으로 간주.
  • 기존 tree 기반 방식과 비교하여 self-reflection 단계 추가
• LLM 기반 heuristics 이용해 가능한 선택지를 탐색하고, state evaluator를 사용하여 행동을 선택함.
• 한계
  • 복잡한 알고리즘 구조와 reflection → 다른 방식보다 많은 계산 자원 소모, 작업 완료까지 시간이 오래 걸림.
  • 실험 범위 제약 - 단순 질의응답 벤치마크만 사용되었고, tool calling이나 복잡한 추론이 필요한 시나리오에서는 아직 충분히 검증 X

Multi Agent Architectures

[ 핵심 주제 ]

• Agent간의 의사소통 & collaborative planning → goal execution
• 팀 기반 단계 구조: plan → act → evaluation 단계별로 팀을 구성하고 재편성(필요에 따라 투입/제거)
• 효과적인 multi-agent 시스템의 핵심 요소
  • 역할, 기술, task 모두 고려
  • 명확한 리더십 구조
  • 유연한 팀 구성
  • 중복 없는 효과적 정보 공유
• 장점: 역할 기반의 지능적 업무 분담이 가능하고, 다양한 persona를 가진 agent들로부터 유용한 피드백 수집 가능
• Embodied LLM Agents Learn to Cooperate in Organized Teams, DyLAN, Agentverse, MetaGPT

Embodied LLM Agents Learn to Cooperate in Organized Teams

• 리더의 존재가 agent팀의 전반적 효율성에 미치는 영향을 다룸. → 조직된 리더가 있는 팀이 더 빠르게 task를 완료!
• 리더 유무에 따른 소통 방식
  • 리더 X: 약 50%의 커뮤니케이션이 명령 전달에 사용되고, 나머지는 정보 공유 및 도움 요청에 사용됨.
  • 리더 O: 리더 커뮤니케이션 중 60%는 지시 전달에 사용, 나머지는 정보 교환 및 요청에 더 집중 가능.
• Criticize-Reflect 메커니즘 추가
  • 리더십 교대 및 유동적 팀 구조 → task 완료 시간 감소, 커뮤니케이션 비용 감소

DyLAN(Dynamic LLM-Agent Network)

• 복잡한 reasoning, code generation 등을 수행하는데 특화된 동적 agent 구조 가진 프레임워크
• 작동 방식: 각 agent가 이전 단계에서 얼마나 기여했는지 평가 → 다음 실행 round에 상위 기여자만 포함. 수평적 구조로, 리더 없이 agent 간 자유로운 정보 공유가 가능함.
• 산술 및 일반 추론 능력을 측정하는 다양한 벤치마크에서 성능 향상 확인
• 장점: 지속적인 기여도 평가 및 재순위화를 통해, 작업에 가장 적합한 팀을 동적으로 구성 가능

AgentVerse

• Expert Recruitment, Collaborative Decision-Making, Action Execution, Evaluation → 명확하게 구분된 4단계 구조를 가진 multi-agent 아키텍쳐.
• 장점: 단계 기반 작업 분할과 유연한 인력 운용

MetaGPT

• Agent들 간의 대화에서 비생산적 대화 문제(불필요한 수다 등)가 발생할 수 있음 → 비정형 채팅 메시지 대신, Document나 Diagram 같은 Structured output 생성을 요구함.
• Publish-subscribe 메커니즘으로 정보 공유: 모든 agent는 정보를 한 곳에 publish 가능, 각 agent는 자신의 task, goal에 필요한 정보만 구독하여 읽음.
• 장점: 목표 달성 흐름 간소화, agent 간 불필요한 대화 noise 감소.

Discussion and Observations

• Agent 성능 향상에 기여하는 공통 설계 요소: 명확한 피드백 제공(사람 또는 agent), 작업 및 역할 분담, 반복적 수정, 명확한 역할 정의(system prompt)
  • 다중 에이전트 팀 구성 시 필요 요소: 명확한 리더, 계획 수립 단계 명확화, 최신 정보에 따라 반복적으로 계획 수정, 메시지 필터링, 현재 task에 맞는 expert
  • 추가적으로 추론/계획/실행/평가 단계의 명확한 구분, 동적 팀 구조 등도 고려 필요
• Architecture 선택: 단일 에이전트 아키텍쳐 v/s 다중 에이전트 아키텍쳐 → 사용 맥락 고려!
  • 단일 에이전트가 적합한 경우
    • 명확한 tool 목록, 작업 절차가 잘 정의된 경우
    • 하나의 agent와 tool 세트만 정의하면 되므로 구현이 상대적으로 쉬움
    • 다른 에이전트로부터의 방해 요소 X.(피드백 부족, 불필요한 대화 등) - 대화 관리 및 리더십 구조 꼭 필요하지는 X. 추론 및 수정 능력 상대적 중요.
  • 다중 에이전트가 적합한 경우
    • 다양한 persona의 피드백이 유익한 작업(ex. 문서 생성)
    • 병렬화가 필요한 경우
    • Zero-shot
• Agent의 비동기 작업 실행
  • 단일 에이전트
    • 여러 비동기 작업을 실행 가능하나, 각 작업 간 책임 분산이 명시적 지원 X
    • Plan → act → evaluation 반복, 순차 진행
  • 다중 에이전트
    • 각 agent가 독립적으로 동작, 더 유연하고 동적인 역할 분담 가능
    • 서로 다른 목표나 도메인에 대해 동시 작업 수행, 다른 agent 상태에 따라 개별 agent가 자신의 다음 단계를 독자적으로 진행
• 피드백 및 사람에 의한 감독의 영향
  • 복잡한 문제 해결 → 잠정적 해법을 설정한 후, (비판 → 피드백 수집 → 수정)을 반복하는 것이 중요함.
  • 타인의 관점에서 피드백을 받는 것도 효과적! 언어 모델은 초반 응답에서 빠르게 하나의 답에 ‘집착’하는 경향이 있음. → 피드백을 통해 잘못된 방향으로 멀어지는 ‘눈덩이 효과’ 방지!
  • 사람에 의한 감독: agent의 응답을 human expectation에 맞게 alignment → 신뢰성 및 타당성 향상
  • Sycophantic(아첨) 경향 및 편향: 언어 모델은 사용자 편향, 다른 agent의 부정확한 피드백에 휩쓸리기 쉬움.
• Multi-agent 시스템에서 대화 및 정보 공유 문제
  • 핵심 문제: agent 간 의미 있는 정보 공유가 어렵다. (정보 공유의 비효율성, 집중력 저하)
  • 수평 구조의 경우 - 모든 agent가 동일한 그룹 채팅 공유하여 각자의 작업과 무관한 정보도 받을 수 있음 → 작업 관련 정보만 수신할 수 있게 subscribe/filtering 도입!
  • 수직 구조의 경우 - 리더가 부하 agent에게 정보 접근 권한을 명확히 전달하지 않아 결과에 혼란 발생 가능 → system prompt에 명확한 접근 권한 정보 포함!
• 역할 정의 및 동적 팀의 영향
  • 단일 agent에서는 제공된 작업에 집중할 수 있도록 보장하고 도구 실행을 정확히 수행할 수 있음. 다중 agent에서는 각 agent가 팀 내에서 자신의 책임 범위를 명확히 인식 가능.
  • 그룹 리더 및 agent별 system prompt → 효율적인 전체 task 배정, 불필요하고 비생산적 소통 최소화
  • Dynamic teams → 필요에 따라 agent 추가/제거

Limitations of Current Research and Considerations for Future Research

• Agent evaluation challenges
  • 매우 다양한 agent 평가용 벤치마크 → 서로 다른 agent를 동일한 기준으로 비교하기 어려움.
  • Agent 벤치마크는 보통 복잡, 수작업 기반 평가 → Precision은 높지만, 대규모 데이터셋의 강건성 부족. 편향 위험도 존재.
  • 모델, 환경, 문제 상태 변화에 따라 반복 수행 시 결과의 일관성 저하. 복잡하고 작은 데이터셋의 경우 무작위성 문제 발생.
• Data contamination & Static benchmarks
  • 기존 LLM 벤치마크를 그대로 사용하여 agent를 평가할 경우, 모델의 학습/평가 데이터 간의 데이터 오염 가능성 존재. 질문을 약간만 바꿔도 성능 급감…
  • 빠르게 진화하는 LLM의 최신 성능을 벤치마크가 반영하지 못함.
  • 해결 방안: 암기 기반 평가를 회피하는 dynamic 벤치마크 개발, 사용자 특정 맥락에 기반한 synthetic 벤치마크 생성.
• Benchmark scope & Transferability
  • 기존 LLM 벤치마크의 한계: agent 시스템의 다단계 추론(multiple iteration), 외부 정보 접근 능력(tool calling)을 평가하는데에는 적절하지 않음. (단, StrategyQA의 경우 모델의 다단계 추론 능력을 Y/N로 답변하여 평가하도록 설계됨.)
  • 성능 및 범용성뿐만 아니라 학습 데이터 외부 도구 사용, 환경 변화에 대한 적응력을 평가할 수 있어야 함.
  • Agent 전용 벤치마크 예시: AgentBench, SmartPlay - 웹 브라우징, command-line, 비디오 게임 환경 등에서 성공률, 출력 결과의 인간 유사성, 전체 효율성 요소들을 평가함.
  • 정량 평가 & 정성 평가 균형 - 정량(성공률, 정확도) / 정성(도구 사용 효율성, 계획의 강건성 및 신뢰성, 유연한 문제 해결 전략) / 인간 전문가의 직접 평가
• Real-world Applicability
  • 기존 벤치마크의 한계: 대부분 논리 퍼즐 및 비디오 게임에서 agent가 추론하는 능력 측정 → 실제 환경에서 어떻게 전이되는지는 불확실, 실제 데이터는 잡음이 많고 주제 범위가 훨씬 넓음
  • Real-world 벤치마크 예시
    • WildBench: WildChat 데이터셋 기반 (570,000개의 실제 ChatGPT 대화). 다양한 작업과 프롬프트 포함 → 넓은 주제 범위.
    • SWE-Bench: Github issue 기반으로 구성된 Python 소프트웨어 엔지니어링 관련 벤치마크. Python 이외의 언어, 일반적 문제 해결 능력 평가에는 제한적.
• Bias & Fairness in Agent Systems
  • 사회적/윤리적 측면에서의 bias (ex. content stealthiness 방식으로 문제 생성, 사용자 정치 성향 반영 등)
  • 작업 복잡성과 LLM 개입 정도가 높아질수록, bias 탐지 및 해결은 더욱 어려워짐.
  • 해결 방안: 사람의 평가 필수 도입