[LLM] AI agent - google agent whitepaper (구글 agent 백서)

ai agent를 구현하고 있어서 공부하고 최근 자료를 리서치하던 중에,
이번 년도 2일에 나온 구글의 AI agent whitepaper가 나와서 오후 시간을 할애해서
번역기 + chatgpt를 활용해서 전체 원문을 번역했다.
뭔가 새롭게 알게된 사실은 없어서 아쉽다.

Introduction

추론, 논리, 그리고 외부 정보에 대한 접근을 생성형 AI 모델과 결합하는 것은 에이전트라는 개념을 떠올리게 한다.

• 인간은 복잡한 패턴 인식 작업에 능숙하다. 하지만 결론에 도달하기 전에 책, 구글 검색, 계산기와 같은 도구를 활용해서 기존의 지식을 보완한다. 인간과 마찬가지로 생성형 AI 모델도 도구를 사용하여 실시간 정보에 액세스하거나 실제 상황에서의 현실적인 액션을 취하도록 할 수 있다.
  예를 들어, 모델은 데이터베이스 검색 도구를 활용하여 고객의 구매 내역과 같은 특정 정보에 액세스하여 맞춤형 쇼핑 추천을 해 줄 수 있고, 사용자의 쿼리를 기반으로 다양한 API 호출을 수행하여 동료에게 이메일 응답을 보내거나 금융 거래를 할 수 있다. 이를 위해 모델은 외부 도구 세트에 액세스할 수 있어야 할 뿐만 아니라 자기 주도적인 방식(self-directed fashion)으로 작업을 계획하고 실행할 수 있는 능력을 갖추어야 한다.

  이처럼 추론, 논리, 외부 정보 접근과 생성형 AI 모델의 조합은 에이전트라는 개념을 떠올리게 한다. 에이전트는 생성형 AI 모델의 독립적인 기능을 넘어 확장된 프로그램을 의미한다. 이 백서에서는 이러한 개념 및 관련된 측면을 자세하게 다루고 있다.

What is an agent? (에이전트란 무엇인가?)

• 가장 기본적인 형태의 생성형 AI 에이전트는 자신이 사용할 수 있는 도구를 활용하여 세계를 관찰하고 행동함으로써 목표를 달성하려는 애플리케이션으로 정의할 수 있다. 에이전트는 자율적이며, 달성해야 할 목표나 목적이 주어질 경우 인간의 개입 없이 독립적으로 행동할 수 있다. 또한 에이전트는 목표 달성을 위한 접근 방식에서 주도적일 수(능동적일 수)도 있다. 인간의 명확한 지시 (명시적인 지침)을 제공하지 않아도, 에이전트는 궁극적인 목표를 달성하기 위해 다음에 무엇을 해야 하는지 스스로 추론할 수 있다.

  AI에서 에이전트의 개념은 매우 일반적이고 강력하지만, 이 백서는 현재 작성 시점에서 생성형 AI 모델이 구축할 수 있는 특정 유형의 에이전트에 초점을 맞춘다.

• 에이전트의 내부 작동 방식을 이해하기 위해 먼저 에이전트의 행동(behavior), 활동(actions) 및 의사 결정(decision making)을 주도하는 기본 구성 요소를 소개한다. 이러한 구성 요소의 조합은 인지 아키텍처(congnitive architecture)로 설명할 수 있으며 이러한 구성 요소를 조합하여 다양한 아키텍처를 설계할 수 있다. 핵심 기능에 초점을 맞추면, 에이전트의 인지 아키텍처에는 <그림 1>에 따라 세 가지 필수 구성 요소를 포함한다.

The model

• 에이전트의 범위 내에서 모델은 에이전트 프로세스에 대한 중앙 의사 결정자로 활용될 언어 모델(LM)을 의미한다. 에이전트가 사용하는 모델은 크기(소형/대형)에 관계없이 단일 또는 다수의 언어 모델일 수 있으며, ReAct, Chain-of-Thought 또는 Tree-of-Thoughts와 추론 및 논리 프레임워크를 따를 수 있는 능력을 갖추고 있어야 한다.

  모델은 범용, 멀티모달 또는 특정 에이전트 아키텍처의 요구 사항에 따라 미세 조정된 모델일 수 있다. 최상의 프로덕션 결과를 얻기 위해서 최종 애플리케이션에 가장 적합한 모델을 활용해야 하며 이상적으로는 인지 아키텍처에서 사용하려는 도구와 관련된 데이터로 학습된 모델을 사용하는 것이 좋다.

  여기서 중요한 점은 모델은 일반적으로 에이전트의 특정 구성 설정(예: 도구 선택, 오케스트레이션/추론 설정)으로 학습되지 않는다는 점이다. 그러나 에이전트의 작업에 맞춰 모델을 추가로 세부 조정하는 것은 가능하다. 이를 위해 에이전트가 특정 도구를 사용하거나 다양한 맥락에서 추론 단계를 수행하는 사례를 포함한 예제를 제공해 에이전트의 기능을 보여주는 방식으로 모델을 보완할 수 있다.

참고로 저 위의 굵은 글씨가 이해가 안되서, 내가 이해한 바로는 여기서 모델(머신러닝 모델, 특히 언어 모델) 이 에이전트가 동작하는데 필요한 특정한 구성이나 설정을 미리 학습하지 않는다는 점이다. 이해한 바로는 일반적으로 언어 모델(예측 모델)은 데이터를 학흡해 텍스트 생성,분류, 예측을 수행한다. 에이전트는 이러한 모델을 기반으로 동작하는 시스템이고 특정한 작업을 수행할 수 있도록 구조나 기능(도구 호출, 워크플로우 관리)를 포함한다. 에이전트가 외부 도구(계산기, 검색)을 사용하는 도구 선택이나, 특정 작업을 통해 어떤 순서로 어떤 기능을 수행할지 결정하는 오케스트레이션/추론 설정은 에이전트가 잘 동작하도록 설계되지만 모델 자체가 이를 학습화는 과정에 포함되지 않는다는 말인데, 이러한 운영환경은 시스템 설계자가 모델을 활용해 구현하는 것이지 모델은 사전에 알고 있는 것이 아니기 때문이다. 예를들어 계산기를 사용해 두 값을 더해야 한다는 구체적인 도구 활용법을 학습하지 않는다. 하지만 에이전트는 두 값을 계산기 도구를 계산하라는 지시를 모델에게 주고, 모델이 이를 실행할 수 있도록 설계한다. 즉, 모델이 자체적으로 에이전트 구성 요소를 사전에 학습하지 않고 모델을 에이전트에 통합할 때 별도의 설계 및 조정이 필요하다는 점을 말하고 있는 것이다.
라고 이해했다.

The Tools

• 기본 모델은 텍스트와 이미지 생성 능력을 가지고 있어도, 외부 세계와 상호작용하지 못하는 한계를 가진다. 도구는 이러한 간극을 메워서, 에이전트가 외부 데이터 및 서비스와 상호작용 하면서 기본 모델보다 더 광범위한 작업을 수행할 수 있도록 지원한다.

  도구는 다양한 형태를 가질 수 있고 복잡성의 깊이도 다양하지만 일반적으로 GET, POST, PATCH, DELETE와 같은 일반적인 웹 API 메서드와 유사하다. 예를 들어 도구를 사용해 데이터베이스에서 고객 정보를 업데이트하거나 날씨 데이터를 가져와 에이전트가 사용자가 요청한 여행 추천에 반영할 수 있다.

  도구를 사용하면 에이전트는 실세계의 실제 정보에 액세스하고 처리할 수 있다. 이를 통해 검색 증강 생성(Retrieval augmented Generation, RAG)와 같은 트고하된 시스템을 지원하고 기본 모델이 단독으로 수행할 수 있는 능력을 크게 확장시킨다. (특수화된 기능을 수행할 수 있게 한다.) 아래에서 도구에 대해 더 자세히 다루겠지만 가장 중요한 것은 도구가 에이전트의 내부 기능과 외부 세계 간의 격차를 메우고(연결하는 역할을 해) 더 광범위한(폭 넓은) 가능성을 제공한다는 것이다.
  

The orchestration layer

• 오케스트레이션 계층은 에이전트가 정보를 수집하고, 내부 추론을 수행하고, 그 추론을 바타으로 다음 작업이나 결정을 알리는 방법을 제어하는 순환적인 과정을 설명한다. 일반적으로 이 루프는 에이전트가 목표 또는 중단 지점에 도달할 때까지 계속된다.

  오케스트레이션 계층의 복잡성은 에이전트와 수행하는 작업에 따라 크게 달라질 수 있다. 일부 루프는 간단한 결정 규칙(decision rules)을 기반으로 한 계산일 수 있는 반면, 다른 루프는 체인 논리를 포함하거나, 추가적인 머신 러닝 알고리즘을 포함하거나, 다른 확률적 추론 기법을 구현할 수 도 있다. 에이전트 오케스트레이션 계층의 세부 구현은 인지 아키텍처 섹션에서 더 자세하게 설명한다.

Agents vs. models

에이전트와 모델의 차이점을 더 명확하게 이해하려면 아래의 차트를 참고한다.

Cognitive architectures : How agents operate (인지 아키텍처: 에이전트의 작동 방식)

• 바쁜 주방에서 일하는 셰프를 상상해 볼 때, 셰프의 목표는 레스토랑 손님을 위해 맛있는 요리를 만드는 것이다. 여기에는 계획, 실행, 조정의 사이클(주기)이 포함된다.
  • 셰프는 정보를 수집한다. 예를 들어 손님의 주문과 식료품 저장실과 냉장고에 있는 재료가 있는지 확인한다.
  • 셰프는 수집한 정보를 기반으로 어떤 요리와 맛을 만들 수 있는지에 대한 내부 추론을 수행한다.
  • 셰프는 요리를 만들기 위해 행동을 수행한다. 야채를 다지고, 향신료를 섞고, 고기를 굽는다.

• 프로세스의 각 단계에서 셰프는 필요에 따라 조정하고, 재료가 소진되거나 고객 피드백을 받으면 계획을 세부적으로 조정해 개선한다. 이전 결과를 바탕으로 다음 행동 계획을 결정한다. 이러한 정보 수집, 계획, 실행, 조정의 이 사이클은 셰프가 목표를 달성하기 위해 사용하는 고유한 인지 아키텍처를 설명한다.

• 셰프와 마찬가지로 에이전트는 인지 아키텍처를 사용하여 정보를 반복적으로 처리하고, 정보에 입각한 결정을 내리고, 이전 출력을 기반으로 다음 작업을 개선하여 최종 목표를 달성할 수 있다. 에이전트 인지 아키텍처의 핵심에는 메모리, 상태, 추론 및 계획을 유지하는 역할을 하는 오케스트레이션 계층이 있다. 이 계층은 빠르게 변화하고 있는 프롬프트 엔지니어링 분야와 관련 프레임워크를 사용하여 추론 및 계획을 유도하고, 에이전트가 환경과 보다 효과적으로 상호 작용하며 작업을 완료할 수 있도록 한다. 언어 모델을 위한 프롬프트 엔지니어링 프레임워크 및 작업 계획 분야의 연구는 빠르게 발전하고 있고, 다양한 유망한 접근 방식을 제공하고 있다. 이 시점에서 가장 인기 있는 몇 가지 프레임워크와 추론 기법은 다음과 같다.

  • ReAct : 언어 모델이 사용자 쿼리에 대해 추론하고 조치를 취할 수 있는 사고 과정 전략을 제공하는 프롬프트 엔지니어링 프레임워크로, 문맥 내 예제가 있거나 없을 수 있다. ReAct 프롬프팅은 여러 SOTA 기준보다 성능이 뛰어나고 LLM의 인간 상호 운용성과 신뢰성을 개선하는 것으로 나타났다.
  • Chain-of-Thought(CoT) : 중간 단계를 통해 추론 기능을 활성화하는 프롬프트 엔지니어링 프레임워크이다. CoT에는 에이전트가 하나 또는 다른 여러 기술을 사용하여 주어진 사용자 요청에 대한 다음 최상의 작업을 선택할 수 있는 등 다양한 하위 기술인 self-consistency, active-prompt, multimodal CoT등이 포함된다. 각 기술들은 특정 애플리케이션에 따라 강점과 약점이 있다.
  • Tree-of-Thoughts (ToT) : 탐색 또는 전략적 예측 작업에 적합한 프롬프트 엔지니어링 프레임워크이다. CoT 프롬프트를 일반화하고 언어 모델을 사용하여 일반적인 문제를 해결하기 위한 중간 단계로 사용되는 다양한 생각 사슬, 사고 사슬(thought chains)을 탐색할 수 있도록 한다.

• 에이전트는 위에서 언급한 추론 기술 중 하나를 사용할 수 있으며, 여러 기술을 결합해 사용자 요처에 맞는 최적의 행동을 선택할 수 있다. 예를 들어 ReAct 프레임워크를 사용해 사용자의 쿼리에 맞는 행동과 도구를 선택하도록 프로그래밍된 에이전트를 고려하면 다음과 같을 수 있다.

  1. 사용자가 에이전트에 쿼리를 보낸다.

  2. 에이전트가 ReAct 시퀀스를 시작한다.

  3. 에이전트가 모델에 프롬프트를 제공하여 다음 ReAct 단계 중 하나와 해당 출력을 생성하도록 요청한다.

     a. 질문(question) : 프롬프트와 함께 제공된 사용자 쿼리의 입력 질문
     
     b. 생각(Thought): 다음에 무엇을 해야 할지에 대한 모델의 생각
     
     c. 동작(Action) : 다음에 어떤 작업을 수행할지에 대한 모델의 결정
     
     i. 여기서 도구 선택이 발생할 수 있다. 
     
     ii. 예를 들어, 동작은 [항공편, 검색, 코드, 없음] 중 하나일 수 있으며, 처음 3개는 모델이 선택할 수 있는 알려진 도구를 나타내고 마지막은 "도구 선택 없음"을 나타낸다.
     
     d. 동작 입력(Action): 도구에 제공할 입력에 대한 모델의 결정(있는 경우)
     
     e. 관찰(Observation) : 동작 / 동작 입력 시퀀스의 결과
     
     i. 생각(thought)/동작(action)/동작 입력(action input)/관찰(observation) 은 필요에 따라 N번 반복될 수 있다.
     
     f. 최종 답변(Final answer): 원래 사용자 쿼리에 제공할 모델의 최종 답변

     4 . ReAct 루프가 끝나고 최종 답변이 사용자에게 다시 제공된다.

  

  그림 2에서 보듯이 모델, 도구 및 에이전트 구성이 함께 작동하여 사용자의 원래 쿼리를 바탕으로 근거 있고 간결한 답변을 사용자에게 제공한다. 모델은 사전 지식에 따라 답을 추측(환각, hallucinated) 할 수 있었겠지만, 대신 도구(Flights인 항공편)를 사용하여 실시간 외부 정보를 검색했다. 이 추가 정보가 모델에 제공되어, 모델이 실제 사실 데이터를 기반으로 보다 정보에 입각한 결정을 내리고 이 정보를 사용자에게 요약하여 전달 할 수 있게 했다.

  요약하자면 에이전트 응답의 품질은 모델이 이러한 다양한 작업에 대해 추론하고 행동할 수 있는 능력, 즉 적절한 도구를 선택하는 능력과 도구가 얼마나 잘 정의되었는지에 따라서 직접적으로 연관된다. 신선한 재료를 사용해 요리를 만들고 고객의 피드백에 주의를 기울이는 셰프처럼, 에이전트 또한 정확한 추론과 신뢰할 수 있는 정보를 바탕으로 최적의 결과를 제공한다. 다음 섹션에서는 신선한 데이터와 연결되는 다양한 방법에 대해 알아본다.
  

Tools: Our keys to the outside world (도구 : 외부 세계와의 연결 고리)

• 언어 모델은 정보를 처리하는데 뛰어난 성능을 보이지만, 실제 세계를 직접 인식하고 영향을 미칠 수 있는 능력이 부족하다. 이는 외부 시스템이나 데이터와의 상호 작용이 필요한 상황에서 모델의 유용성을 제한한다. 즉, 어떤 의미에서 언어 모델은 학습 데이터에서 학습한 내용만큼만 좋다는 것을 의미합니다. (학습 데이터에서 배운 것 만큼만 유용하다) 하지만 모델에 아무리 많은 데이터를 제공하더라도 여전히 외부 세계와 상호 작용할 수 있는 기본적인 능력은 부족하다. 그렇다면 어떻게 해야 모델이 실시간으로 문맥을 인식하고 외부 시스템과 상호작용 할 수 있도록 할 수 있을까? 함수, 확장 프로그램, 데이터 저장소 및 플러그인은 모두 이 중요한 기능을 모델에 제공하는 방법이다.

  도구는 여러 가지 이름으로 불리지만 기본적인 역할은 기본 모델과 외부 세계를 연결하는 것이다. 외부 시스템과 데이터에 대한 연결을 통해 에이전트는 더 다양한 작업을 수행하고 더 정확하고 안정적으로 수행할 수 있다. 예를 들어 도구를 사용하면 에이전트가 스마트 홈 설정을 조정하고, 일정을 업데이트하고, 데이터베이스에서 사용자 정보를 가져오거나, 특정 지침에 따라 이메일을 보낼 수 있다.

  현재 해당 시점에서(출판된 시점) Google 모델이 상호 작용할 수 있는 세 가지 주요 도구 유형은 확장 프로그램(Extensions), 함수(Functions), 데이터 저장소(Data stores)이다. 에이전트에게 도구를 제공함으로써 우리는 에이전트가 세상을 이해할 뿐만 아니라 그에 따라 행동할 수 있는 엄청난 잠재력을 열어주며, 수많은 새로운 애플리케이션과의 가능성으로 가는 문을 열어준다.

Extensions (확장 프로그램)

• 확장을 프로그램을 이해하는 가장 쉬운 방법은 API와 에이전트 간의 간격을 표준화된 방식으로 연결하는 것이라고 생각하는 것이다. 이렇게 하면 에이전트는 기본 구현에 상관없이 API를 원활하게 실행할 수 있다. 예를 들어 사용자가 항공편 예약을 도와주는 에이전트를 만들었다고 가정했다면 Google Flights API를 사용하여 항공편 정보를 가져오고자 하지만, 이 API 엔드포인트에 에이전트를 호출하는 방법에 대해서는 잘 모를 수 있다.

한 가지 접근 방법은 들어오는 사용자 쿼리를 가져와 관련 정보에 대한 쿼리를 구문 분석한 다음 API 호출을 수행하는 사용자 지정 코드(맞춤형 코드)를 구현하는 것이다. 예를 들어, 항공편 예약의 경우 사용자가 "오스틴에서 취리히행 항공편을 예약하고 싶다." 라고 했을 때, 이 시나리오에서 사용자 지정 코드(맞춤형 코드) 솔루션은 API 호출을 시도하기 전에 사용자 쿼리에서 "오스틴"과 "취리히"를 관련 엔터티로 추출해야 한다. 그러나 사용자가 "취리히행 항공편을 예약하고 싶다." 라고 하면서 출발 도시를 제공하지 않으면 어떻게 될까?

API 호출은 필요한 데이터 없이는 실패할 것이고 이와 같은 엣지 및 코너 케이스를 위해서 더 많은 코드를 구현해야 할 것이다. 이 접근 방식은 확장 가능하지 않고 구현된 사용자 지정 코드(맞춤형 코드) 외의 모든 시나리오에서 쉽게 실패할 수 있다.

좀 더 탄력적인 접근 방식은 확장 프로그램을 사용하는 것이다. 확장 프로그램은 다음을 통해 에이전트와 API 간의 격차를 메운다.

1. 예제를 사용하여 에이전트에게 API 엔드포인트를 사용하는 방법을 가르친다.
2. API 엔드포인트를 성공적으로 호출하는 데 필요한 인수 또는 매개변수를 에이전트에게 가르친다.

확장 프로그램은 에이전트와 독립적으로 제작할 수 있지만, 에이전트의 구성의 일부로 제공되어야 한다. 에이전트는 런타임(실행 시간)에 모델과 예제를 사용하여 사용자의 쿼리를 해결하는 데 적합한 확장 프로그램이 있는지 여부를 결정하여 선택한다. 이는 확장 프로그램의 주요 강점인 기본으로 제공하는 (내장된) 예제 유형을 강조하고, 이를 통해 에이전트는 작업에 가장 적합한 확장 프로그램을 동적으로 선택할 수 있다.

확장 프로그램의 강점은 내장된 예제 유형에 있는데, 이 예제들은 에이전트가 어떤 작업을 수행할 때, 그 작업에 적합한 확장 프로그램을 자동으로 선택하는데 도움을 준다는 것이다. 즉, 확장 프로그램은 미리 정의된 예제들을 제공해서 에이전트가 사황에 맞게 올바른 도구를 선택할 수 있도록 한다고 이해하면 될 것 같다. 그러니까 에이전트가 사용자의 쿼리에 응답하기 위해서 여러 가지 API를 사용할 수 있는데, 확장 프로그램은 그에 맞는 예제를 제공해준다. 이를 통해서 에이전트는 자신이 처리해야 할 작업에 맞는 API를 자동으로 선택할 수 있게 된다. 조금 더 매끄럽게 표현하면 “확장 프로그램의 주요 강점은 내장된 예제들이고, 이를 통해 에이전트는 작업에 가장 적합한 확장 프로그램을 자동으로 선택할 수 있다” 라고 이해 하면 된다.
라고 이해했다.

• 소프트웨어 개발자가 사용자의 문제를 해결하고 솔루션을 찾는 동안 사용할 API 엔드포인트를 결정하는 것과 같은 방식으로 생각해보자. 사용자가 항공편을 예약하려는 경우 개발자는 Google Flights API를 사용할 수 있다. 사용자가 자신의 위치에 비해 가장 가까운 커피숍이 어디인지 알고 싶은 경우 개발자는 Google Maps API를 사용할 수 있다. 이와 같은 방식으로 에이전트/모델 스택은 알려진 확장 프로그램 세트를 사용하여 사용자 쿼리에 가장 적합한 확장 프로그램을 결정한다. 확장 프로그램이 실제로 어떻게 작동하는지 보려면 Gemini 애플리케이션에서 설정(settings) > 확장 프로그램(Extension)으로 이동한 다음 테스트하려는 확장 프로그램을 활성화하여 테스트할 수 있다. 예를 들어 Google Flights 확장 프로그램을 활성화한 다음 Gemini에 "다음 금요일에 출발하는 오스틴에서 취리히로 가는 항공편을 보여줘"라고 요청할 수 있다.

Sample Extension

• 확장 프로그램의 사용을 간편하게 하기 위해서 google은 몇 가지 기본 제공 확장 프로그램을 제공해서 이를 통해 프로젝트에 빠르게 import 하고 최소한의 설정으로 사용할 수 있다. 예를 들어 스니펫(Snippet) 1에 있는 Code Interpreter 확장 프로그램은 자연어 설명을 기반으로 python 코드를 생성하고 실행할 수 있게 해준다.

요약하자면 확장 프로그램은 에이전트가 다양한 방식으로 외부 세계를 인식하고 상호작용하며 영향을 미칠 수 있는 방법을 제공한다. 이러한 확장 프로그램의 선택과 호출은 예제를 사용하여 안내되고, 모든 예제는 확장 프로그램 구성의 일부로 정의된다.

Functions

• 소프트웨어 엔지니어링의 세계에서 함수는 특정 작업을 수행하는 독립적인 코드 모듈로 정의되고, 필요에 따라 재사용할 수 있다. 소프트웨어 개발자가 프로그램을 작성할 때, 여러 가지 작업을 수행하는 많은 함수를 생성한다. 또한 함수 a와 함수 b를 언제 호출할지, 그리고 각 함수의 예상 입/출력을 정의한다. 에이전트의 세계에서 함수는 매우 유사하게 작동하지만 소프트웨어 개발자 대신 모델이 이를 수행한다. 모델은 여러 개의 알려진 함수 세트를 받아들여 각 함수를 사용할 시기와 함수가 요구하는 인수를 사양에 따라 결정한다. 함수는 확장 프로그램과 몇 가지 면에서 다른데, 가장 두드러지는 점은 다음과 같다.
  1. 모델은 함수와 인수를 출력하지만 실시간 API 호출을 하지 않는다.
  2. 함수는 클라이언트 측에서 실행되는 반면 확장 프로그램은 은 에이전트 측에서 실행된다.

위에서 봤던 Google Flights 예제에서 보자면 함수에 대한 간단한 설정은 그림 7의 예제와 같을 수 있다.

여기서 주요 차이점은 함수와 에이전트가 Google Flights API와 직접 상호 작용하지 않는다는 것이다. 그렇다면 API 호출은 실제로 어떻게 발생할까?

함수를 사용하면 실제 API 엔드포인트를 호출하는 로직과 실행이 에이전트에서 클라이언트 측 애플리케이션으로 오프로드되어 아래 그림 8과 그림 9처럼 처리된다. 이 방식은 개발자가 애플리케이션 내에서 데이터 흐름을 보다 세밀하게 제어할 수 있게 한다. 개발자가 확장 프로그램 대신 함수를 사용하는 이유는 여러가지가 있는데, 몇 가지 일반적인 사용 사례는 다음과 같다.

• API 호출이 애플리케이션 스택의 다른 계층에서 이루어져야 할 경우, 즉 직접적인 에이전트 아키텍처 흐름의 외부 ( 예: 미들웨어 시스템, 프론트엔드 프레임워크 등)

• 보안 또는 인증 제한으로 인해 에이전트가 API를 직접 호출할 수 없는 경우(예: API가 인터넷에 노출되지 않았거나 에이전트 인프라에서 액세스할 수 없음)

• 에이전트가 실시간으로 API 호출을 하지 못하게 하는 시간 또는 작업 순서 제약이 있는 경우 (예:배치 작업, 인간의 검수가 필요한 경우 등)

• 에이전트가 수행할 수 없는 API 응답에 대한 추가 데이터 변환 논리를 적용해야 하는 경우 (예를 들어, 반환되는 결과 수를 제한하기 위한 필터링 메커니즘을 제공하지 않는 API 엔드포인트를 고려해 본다면, 클라이언트 측에서 함수를 사용하면 개발자가 이러한 변환을 수행할 수 있는 추가 기회가 제공함)

• 개발자가 API 엔드포인트에 추가 인프라를 배포하지 않고 에이전트 개발을 반복하고 싶은 경우(즉, 함수 호출은 API의 "stubbing "처럼 작동할 수 있음)

그림 8에서 볼 수 있듯이 두 가지 접근 방식 간의 내부 아키텍처 차이는 미묘하지만, 외부 인프라에 대한 의존을 분리하고(외부 인프라에 대한 분리된 종속성), 추가 제어를 제공하는 점에서 함수 호출을 개발자에게 매력적인 옵션이 된다.

Use cases(사용사례)

• 모델은 클라이언트 측에서 최종 사용자를 위한 복잡한 실행 흐름을 처리하기 위해 함수를 호출하는 데 사용될 수 있다. 이 때 에이전트 개발자는 언어 모델이 API 실행을 관리하는 것을 원하지 않을 수 있다.(확장 프로그램과는 다름) 휴가 여행을 예약하려는 사용자와 상호 작용하기 위해 여행 컨시어지로 에이전트를 훈련시키는 에이전트를 예제로 고려해 보자. 목표는 에이전트가 사용자의 여행 계획을 위해 이미지, 데이터 등을 다운로드하는 데 사용할 수 있는 도시 목록을 생성하도록 하는 것이다. 사용자는 다음과 같은 요청을 할 수 있다.

  • 가족과 스키 여행을 가고 싶지만 어디로 가야 할지 잘 모르겠어요.

    모델에 대한 일반적인 프롬프트에서 출력은 다음과 같을 수 있다.

    물론, 가족 스키 여행을 고려할 수 있는 도시 목록은 다음과 같습니다.
    • 미국 콜로라도주 크레스티드 버트
    • 캐나다 브리티시 컬럼비아주 휘슬러
    • 스위스 체르마트

• 위의 출력에는 필요한 데이터(도시 이름)가 포함되어 있지만, 형식은 구문 분석에 적합하지(이상적이지) 않다. 함수 호출(Funciton Calling)을 사용하면 모델에 이 출력을 다른 시스템에서 구문 분석하기에 더 편리한 구조화된 형식(예: JSON)로 형식화하도록 가르칠 수 있다. 사용자가 동일한 입력 프롬프트를 제공했을 때, 함수에서 생성된 JSON 출력 예시는 다음과 같을 수 있다.(Snippet 5 참고)

• 이 JSON 페이로드는 모델에 의해 생성된 후 클라이언트 측 서버로 전송되어 우리가 원하는 작업을 수행한다. 이 특정 사례에서 Google Places API를 호출하여 모델에서 제공한 도시를 가져와 그에 대한 이미지를 찾은 다음, 사용자에게 포맷된 리치 콘텐츠로 제공할 것이다. 위 상호작용을 단계별로 보여주는 시퀀스 다이어그램은 그림 9 에서 확인할 수 있다.

위 그림 9에서의 예시 결과는 모델을 활용하여 클라이언트 측 UI가 Google Places API를 호출하는 데 필요한 매개변수의 "빈칸을 채울 수 있도록” 돕는 방식이다. 클라이언트 측 UI는 모델이 반환한 함수 내의 매개변수를 사용해 API 호출을 관리한다. 이는 함수 호출(Function Calling)의 한 가지 사용 사례에 불과하며, 다음과 같은 여러 시나리오에서 활용할 수 있다.

•코드 내에 인증 정보를 포함시키고 싶지 않지만, 언어 모델이 코드에서 사용할 수 있는 함수를 제안하길 원할 때. Function Calling은 함수가 실제로 실행되지 않기 때문에 인증 정보를 코드에 포함시킬 필요가 없다.

• 몇 초 이상 걸릴 수 있는 비동기 작업을 실행 할 때. 이러한 시나리오는 비동기 작업인 Function Calling에 적합하다.

• 함수 호출 및 그 인수를 생성하는 시스템과 다른 장치에서 함수를 실행하고 싶을 때

함수에 호출에서 중요한 사항 중 하나는 API 호출의 실행뿐만 아니라 애플리케이션 내의 데이터 흐름에 대한 보다 세밀한 제어를 제공한다는 점이다. (전체 데이터 흐름에 대해 개발자에게 훨씬 더 많은 제어권을 제공하기 위한 것이라는 것) 그림 9의 예에서 개발자는 향후 에이전트가 취할 수 있는 동작에 필요하지 않다면 API 정보를 에이전트에 반환하지 않을 수 있다.그러나 애플리케이션의 아키텍처에 따라 외부 API 호출 데이터를 에이전트로 되돌려 줘서 향후 추론, 논리 및 작업 선택에 영향을 미치기 하는 것이 합리적일 수 있다. 궁극적으로 특정 애플리케이션에 적합한 것을 선택하는 것은 애플리케이션 개발자가 결정할 사항이다.

Function sample code

• 위의 스키 휴가 시나리오에서 나온 출력을 얻기 위해, 이 작업을 gemini-1.5-flash-001 모델에서 작동할 수 있도록 각 구성 요소를 재현해 본다. 간단한 python 메서드로 display_cities 함수를 정의한다.

다음으로 모델을 인스턴스화하고, 도구를 구축한 후, 사용자의 쿼리와 도구를 모델에게 전달한다.
아래 코드를 실행하면 코드 스니펫 하단에서 볼 수 있는 출력이 생성된다.

요약하자면, 함수는 애플리케이션 개발자에게 데이터 흐름과 시스템 실행에 대한 세부적인 제어를 제공하는 간단한 프레임워크를 제공한다. 동시에 중요한 입력 생성을 위해 에이전트/모델을 효과적으로 활용할 수 있다. 개발자는 외부 데이터를 반환하여 에이전트를 "루프에 포함"할지 또는 특정 애플리케이션 아키텍처 요구 사항에 따라 생략할지를 선택적으로 결정할 수 있다.

Data stores

• 언어 모델을 방대한 양의 책 라이브러리(방대한 책들이 있는 도서관)으로 비유할 수 있다. 이 도서관에는 학습 데이터가 들어 있다. 하지만 새로운 책을 지속적으로 수집하는 일반적인 도서관과는 달리 이 라이브러리(도서관)은 정적 상태를 유지하며 처음에 학습한 지식만 보유하고 있다. 현실 세계의 지식은 끊임없이 진화하고 있기 때문에 실제 지식을 반영할 수 없는 문제가 발생한다. 데이터 저장소(data stores)는 이러한 한계를 해결하는 방법으로, 보다 동적이고 최신 정보에 대한 액세스를 통해 정보를 모델에게 제공해서 모델의 응답이 사실성과 관련성에 기반을 두도록 돕는다.
  

예를 들어 개발자가 모델에 추가적인 데이터를 제공해야 할 때, 그 데이터가 스프레드시트나 pdf 형식인 경우를 생각해보자.

데이터 저장소를 사용하면 개발자가 추가 데이터를 원본 형식 그대로 에이전트에 제공할 수 있도록 돕는다. 이를 통해 시간 소모가 큰 데이터 변환, 모델 재훈련, 또는 파인 튜닝 없이도 데이터를 활용할 수 있다. 데이터 저장소는 들어오는 문서를 벡터 데이터베이스 임베딩 세트로 변환해서, 에이전트가 이를 사용해 필요한 정보를 추출하고 이를 바탕으로 다음 작업이나 사용자에 대한 응답을 보완할 수 있도록 한다.

Implementation and application

• 생성형 AI 에이전트의 맥락에서 데이터 저장소는 일반적으로 개발자가 에이전트가 런타임(실행 중)에접근할 수 있도록 설정하는 벡터 데이터베이스로 구현된다. 여기서는 벡터 데이터베이스를 자세히 다루지 않지 이해해야 할 핵심 사항은 벡터 임베딩, 즉 제공된 데이터의 고차원 벡터 또는 수학적 표현의 형태로 데이터를 저장한다는 것이다. 최근 언어 모델에서 데이터 저장소를 사용한 가장 많은 사례 중 하나는 검색 증강 생성(RAG) 기반 애플리케이션 구현이다. 이러한 애플리케이션은 모델의 지식 범위와 깊이를 기본적인 훈련 데이터 이상의 데이터에 접근할 수 있도록 하여 모델의 성능을 확장하는데 사용된다. 모델은 다음과 같은 다양한 형식의 데이터에 접근할 수 있다.
  

• 웹사이트 콘텐츠
• PDF, Word 문서, CSV, 스프레드시트 등의 형식의 구조화된 데이터
• HTML, PDF, TXT 등의 형식의 구조화되지 않은 데이터

각 사용자 요청 및 에이전트 응답 루프에 대한 기본 프로세스는 일반적으로 그림 13과 같이 단계로 모델링된다.

1. 사용자 쿼리는 임베딩 모델로 전송되어 쿼리에 대한 임베딩이 생성된다.

2. 쿼리 임베딩은 SCaNN과 같은 매칭 알고리즘을 사용하여 벡터 데이터베이스의 내용과 비교된다.

3. 매칭되어 일치하는 내용은 벡터 데이터베이스에서 텍스트 형식으로 검색되어 에이전트로 다시 전달된다.

4. 에이전트는 사용자 쿼리와 검색된 내용을 모두 받은 다음 응답 또는 작업을 생성한다.

   이 과정은 사용자가 요청에 대한 추가 정보를 벡터 데이터베이스에서 실시간으로 찾아 에이전트가 더 정확하고 관련성 있는 응답을 생성할 수 있도록 한다.

5. 최종 응답이 사용자에게 전달된다.

최종 결과, 이 애플리케이션은 에이전트가 사용자 질의(쿼리)를 벡터 검색을 통해 데이터 저장소와 매칭하고, 원본 콘텐츠를 검색하여, 추가 처리를 위해 오케스트레이션 계층과 모델에 제공한다. 이후의 작업은 사용자에게 최종 답변을 제공하거나, 결과를 더 정제하기 위하여 추가 벡터 검색을 수행할 수 있다. ReAct 추론/계획을 사용하여 RAG를 구현하는 에이전트와의 샘플 상호 작용은 그림 14에서 확인할 수 있다.

Tools recap (도구 요약)

• 확장 프로그램(extensions), 함수 호출(functions calling), 데이터 스토어(data stores)는 에이전트가 실행 중에 사용할 수 있는 여러 도구 유형을 구성한다. 각 도구는 고유한 목적을 가지고 있고, 에이전트 개발자의 선택에 따라 함께 사용하거나 독립적으로 사용할 수 있다.

Enhancing model performance with targeted learning (모델 성능 향상 : 타겟 학습을 통한 접근)

• 모델을 효과적으로 사용하는 데 중요한 측면은 출력 생성시 적절한 도구를 선택하는 능력이다. 특히 프로덕션 환경에서 도구를 대규모로 사용할 때 모델은 훈련 데이터를 넘어서는 지식을 요구하는 경우가 많다. 이를 비유적으로 설명하면 기본 요리 기술과 특정 요리를 마스터하는 것의 차이와 같다. 두 가지 모두 기본적인 요리 지식이 필요하지만 후자는 보다 섬세한 결과를 위해 타겟 학습이 필요하다. 모델이 이러한 유형의 특정 지식(구체적인 지식)에 액세스할 수 있도록 하는 몇 가지 접근 방식이 있다.

  • 컨텍스트 내 학습(In-context learning) : 이 방법은 모델이 추론 시 도구와 few-shot 예제를 제공받아 ‘실시간으로’ 특정 작업에 도구를 어떻게 사용할지 학습할 수 있게 한다. ReAct 프레임워크는 자연어로 된 이 접근 방식의 예다.

  • 검색 기반 컨텍스트 내 학습(Retrieval-based in-context learning) : 이 기법은 외부 메모리에서 가장 관련성 있는 정보, 도구 및 관련 예제를 검색하여 모델 프롬프트를 동적으로 추가하는 것이다. 이에 대한 예로는 Vertex AI 확장 프로그램의 'Example Store' 나 이전에 언급한 데이터 저장소 기반의 RAG 기반 아키텍처이다.

  • 미세 조정 기반 학습(Fine-tuning based learning) : 이 방법은 추론 전에 특정 예제들로 구성된 더 큰 데이터 세트를 사용하여 모델을 학습하는 방식이다. 이를 통해 모델은 사용자 쿼리를 받기 전에 특정 도구를 적용하는 시기와방법에 대해 학습한다.

    각각의 타겟 학습의 접근 방식을 이해하기 위해 다시 요리 비유를 들어본다면,

  • 컨텍스트 내 학습(In-context learning) : 요리사는 고객으로부터 받은 특정 레시피(프롬프트), 몇 가지 핵심 재료(관련 도구) 및 몇 가지 예시 요리(몇 가지 few-shot 예시)를 바탕으로 요리사는 자신의 요리 지식에 의존하여 요리를 ‘즉석에서’ 만들어내야 한다. 이 과정에서 제한된 정보로 고객의 선호도에 가장 잘 맞는 요리를 만들어야 한다. 이것이 바로 콘텍스트 내 학습(문맥 내 학습) 이다.

  • 검색 기반 컨텍스트 내 학습(Retrieval-based in-context learning) : 이제 요리사는 가득 찬 식료품 저장실(외부 데이터 저장소)에서 다양한 재료와 요리책(예시 및 도구)를 찾을 수 있다. 요리사는 이제 식료품 저장실에서 재료와 요리책을 동적으로 선택하고 고객의 레시피와 선호도에 맞는 정교하고 세밀한 요리를 만들 수 있다. 이것은 검색 기반 맥락 내 학습이다. 요리사는 기존과 새로운 지식을 모두 활용하여 더 나은 결과를 얻는다.

  • 미세 조정 기반 학습(Fine-tuning based learning) : 마지막으로 요리사는 새로운 요리법이나 여러 종류의 요리를 배워야 한다. (특정 예시의 더 큰 데이터 세트에 대한 사전 훈련). 이를 통해 셰프는 더 깊은 이해로 미래의 고객 레시피에 접근할 수 있다. 이 접근 방식은 셰프가 특정 요리 분야(지식 도메인)에서 뛰어나기를 원할 때와 유사하고 이는 미세 조정 기반 학습이다.

    이러한 접근 방식은 속도, 비용 및 지연 시간 측면에서 고유한 장단점이 있다. 그러나 이러한 기술을 에이전트 프레임워크에 결합하면 다양한 강점을 활용하고 약점을 최소화하여 보다 견고하고 적응 가능한 솔루션을 만들 수 있다.

Agent quick start with LangChain (Langchain을 사용한 에이전트의 빠른 시작)

• 실제로 에이전트가 작동하는 실행 가능한 예를 제공하기 위해 LangChain 및 LangGraph 라이브러리를 사용하여 빠른 프로토타입을 빌드할 수 있다. 인기 있는 오픈 소스 라이브러리를 사용하면 사용자가 논리, 추론 및 도구 호출 시퀀스를 "chaining”하여 사용자 질문에 답하는 에이전트를 빌드할 수 있다. 여기서는 Snippet 8에서 볼 수 있듯이 gemini-1.5-flash-001 모델과 몇 가지 간단한 도구를 사용하여 사용자의 다단계 질의를 처리하는 예제이다.
  
• 사용하는 도구는 SerpAPI(Google 검색용)와 Google Places API 이다. Snippet 8에서 프로그램을 실행한 후 Snippet 9에서 샘플 출력을 볼 수 있다.
  

• 이 예제는 상당히 간단한 에이전트 사례이지만, 모델, 오케스트레이션 및 도구들이 어떻게 함께 작동해서 특정 목표를 달성하는지에 대한 기본적인 구성 요소를 보여준다. 마지막 섹션에서는 이러한 구성 요소가 Google 규모의 관리형 제품인 Vertex AI 에이전트 및 Generative Playbook 제품에서 어떻게 결합되는지 보여준다.

Production applications with Vertext AI agents (Vertex AI 에이전트를 사용한 프로덕션 애플리케이션)

• 이 백서에서는 에이전트의 핵심 구성 요소를 살펴보았지만 프로덕션 등급 애플리케이션을 빌드하려면 사용자 인터페이스, 평가 프레임워크, 지속적인 개선 메커니즘과 같은 추가 도구와 통합해야 한다. Vertex AI 플랫폼을 사용한 프로덕션 애플리케이션 구축은 에이전트의 핵심 구성 요소들을 통합하는 것에 그치지 않고, 사용자 인터페이스, 평가 프레임워크, 지속적인 개선 메커니즘 등 추가적인 도구들과의 결합이 필요하다. Google의 Vertex AI 플랫폼은 이전에 다룬 모든 기본 요소가 포함된 완벽하게 관리되는 환경을 제공하여 이 프로세스를 간소화한다. 이를 통해 개발자는 자연어 인터페이스를 통해 빠르게 에이전트의 중요한 요소들(목표, 작업 지침, 도구, 작업 위임을 위한 하위 에이전트, 예제 등)을 정의하고 원하는 시스템 동작을 쉽게 구축할 수 있다.
• 또한 이 플랫폼은 테스트, 평가, 에이전트 성능 측정, 디버깅, 개발된 에이전트의 전반적인 품질 개선을 허용하는 개발 도구 세트를 제공하여 개발자가 에이전트를 빌드하고 개선하는 데 집중할 수 있게 한다. 이러한 과정에서 인프라, 배포 및 유지 관리의 복잡성은 플랫폼이 처리하므로 개발자는 더 중요한 에이전트 개발과 개선에 집중할 수 있다.
  
• 그림 15에서는 Vertex Agent Builder, Vertex Extensions, Vertex Function Calling, Vertex Example Store와 같은 다양한 기능을 사용하여 Vertex AI 플랫폼에서 빌드된 에이전트의 샘플 아키텍처를 제공한다. 이 아키텍처에는 프로덕션에 적합한 애플리케이션에 필요한 다양한 구성 요소가 포함되어 있다.

공식 문서에서 사전 구축된 에이전트 아키텍처의 샘플을 사용해 볼 수 있다.

Summary

• 이 백서에서는 생성 AI 에이전트의 기본 구성 요소, 그들의 구성 방식, 그리고 이를 인지 아키텍처 형태로 구현하는 효과적인 방법에 대해 언급했다. 이 백서의 핵심 요점은 다음과 같다.

  1. 에이전트는 도구를 활용하여 실시간 정보에 액세스하고,실제 세계의 행동을 제안하고, 복잡한 작업을 자율적으로 계획하고 실행하여 언어 모델의 기능을 확장한다. 에이전트는 하나 이상의 언어 모델을 활용하여 상태를 전환할 시기와 방법을 결정하고, 모델이 혼자서는 수행하기 어려운 복잡한 작업을 외부 도구를 사용하여 완수한다.

  2. 에이전트의 핵심 작동 방식은 오케스트레이션 계층이다. 이는 추론, 계획, 의사 결정을 구조화하고 작업을 안내하는 인지 아키텍처이다. ReAct, Chain-of-Thought, Tree-of-Thoughts와 같은 다양한 추론 기법은 오케스트레이션 계층이 정보를 수집하고, 내부 추론을 수행하고, 정보에 입각한 결정이나 응답을 생성할 수 있는 프레임워크를 제공한다.

  3. 확장 프로그램, 함수, 데이터 저장소와 같은 도구는 에이전트의 외부 시스템을 연결하는 역할을 하여 외부 시스템과 상호 작용하고 훈련 데이터 너머의 지식에 액세스할 수 있도록 한다. 확장 프로그램은 에이전트와 외부 API 간의 브리지를 제공하여 API 호출을 실행하고 실시간 정보를 검색할 수 있도록 한다. 함수는 작업 분할을 통해 개발자에게 보다 섬세한 제어를 제공하여 에이전트가 클라이언트 측에서 실행할 수 있는 함수 매개변수를 생성할 수 있도록 한다. 데이터 저장소는 에이전트에게 구조화되거나 구조화되지 않은 데이터에 대한 액세스를 제공하여 데이터 기반 애플리케이션을 가능하게 한다.

• 에이전트의 미래는 흥미로운 발전을 예고하며 우리는 아직 가능한 것의 표면만 파악하고 있다. 도구가 더욱 정교해지고 추론 기능이 향상됨에 따라 에이전트는 점점 더 복잡한 문제를 해결할 수 있는 권한을 얻게 될 것이다.
  또한 '에이전트 체이닝(agent chaining)’의 전략적 접근 방식은 계속해서 확산될 것이다. 특정 도메인이나 작업에서 각각 뛰어난 전문 에이전트를 결합함으로써 다양한 산업과 문제 영역에서 뛰어난 결과를 제공할 수 있는 '에이전트 전문가의 혼합(mixture of agent experts)' 접근 방식이 가능해질 수 있다.

• 복잡한 에이전트 아키텍처를 구축하려면 반복적 접근 방식이 필요하다는 점을 기억하는 것이 중요하다. 실험과 개선이 특정 비즈니스 사례와 조직의 필요 요구 사항에 대한 해결책을 찾는데 핵심적인 역할을 한다. 에이전트는 그 기본 모델의 생성적 특성으로 인해 모두 다르게 생성되므로, 각 구성 요소의 강점을 활용함으로써 언어 모델의 기능을 확장하고 실제 세계에서 가치를 창출하는 영향력 있는 응용 프로그램을 만들 수 있다.