AI 에이전트 - Chip Huyen

원문: Agents

지능형 에이전트(intelligent agents)는 많은 사람들에게 AI의 궁극적인 목표로 여겨집니다. Stuart Russell과 Peter Norvig의 고전 저서 Artificial Intelligence: A Modern Approach (Prentice Hall, 1995)는 AI 연구 분야를 “합리적 에이전트(rational agents)의 연구와 설계”로 정의합니다.

Foundation model(파운데이션 모델)의 전례 없는 능력은 이전에는 상상할 수 없었던 에이전틱 애플리케이션(agentic applications)의 문을 열었습니다. 이러한 새로운 능력은 우리의 비서, 동료, 코치 역할을 하는 자율적이고 지능적인 에이전트를 개발할 수 있게 만들었습니다. 에이전트는 웹사이트 제작, 데이터 수집, 여행 계획, 시장 조사, 고객 계정 관리, 데이터 입력 자동화, 면접 준비, 후보자 인터뷰, 협상 등을 도울 수 있습니다. 가능성은 무한해 보이며, 이러한 에이전트의 잠재적 경제적 가치는 엄청납니다.

이 섹션은 에이전트의 개요로 시작하여 에이전트의 능력을 결정하는 두 가지 측면인 도구(tools)와 계획(planning)을 다룹니다. 에이전트는 새로운 작동 방식을 가지므로 새로운 실패 방식도 있습니다. 이 섹션은 이러한 실패를 포착하기 위해 에이전트를 평가하는 방법에 대한 논의로 마무리됩니다.

이 글은 AI Engineering (2025)의 Agents 섹션을 독립된 글로 만들기 위해 약간의 편집을 거쳐 각색한 것입니다.

참고 사항:

AI 기반 에이전트는 정의, 개발, 평가를 위한 확립된 이론적 프레임워크가 없는 신흥 분야입니다. 이 섹션은 기존 문헌을 바탕으로 프레임워크를 구축하려는 최선의 시도이지만, 분야가 발전함에 따라 진화할 것입니다. 책의 다른 부분에 비해 이 섹션은 더 실험적입니다. 초기 리뷰어들로부터 유용한 피드백을 받았으며, 이 블로그 글의 독자들로부터도 피드백을 받기를 희망합니다.
이 책이 출간되기 직전에 Anthropic이 Building effective agents (2024년 12월)에 대한 블로그 글을 발표했습니다. Anthropic의 블로그 글과 제 에이전트 섹션이 약간 다른 용어를 사용하지만 개념적으로 일치한다는 것을 보니 기쁩니다. 하지만 Anthropic의 글은 고립된 패턴에 초점을 맞추는 반면, 제 글은 왜 그리고 어떻게 작동하는지를 다룹니다. 또한 계획, 도구 선택, 실패 모드에 더 집중합니다.
이 글은 많은 배경 정보를 포함하고 있습니다. 너무 세부적으로 느껴지면 자유롭게 건너뛰세요!

Agent(에이전트) 개요

Agent(에이전트) 라는 용어는 software agent(소프트웨어 에이전트), intelligent agent(지능형 에이전트), user agent(사용자 에이전트), conversational agent(대화형 에이전트), reinforcement learning agent(강화학습 에이전트) 등 다양한 엔지니어링 맥락에서 사용되어 왔습니다. 그렇다면 에이전트란 정확히 무엇일까요?

에이전트는 환경을 인식하고 그 환경에 작용할 수 있는 모든 것입니다. Artificial Intelligence: A Modern Approach (1995)는 에이전트를 센서(sensors)를 통해 환경을 인식하고 액추에이터(actuators)를 통해 환경에 작용하는 것으로 볼 수 있는 모든 것으로 정의합니다.

이는 에이전트가 작동하는 *환경(environment)*과 수행할 수 있는 *행동의 집합(set of actions)*으로 특징지어진다는 것을 의미합니다.

에이전트가 작동할 수 있는 환경은 사용 사례에 의해 정의됩니다. 에이전트가 게임(Minecraft, 바둑, Dota)을 플레이하도록 개발되면 그 게임이 환경입니다. 인터넷에서 문서를 스크래핑하는 에이전트를 원한다면 환경은 인터넷입니다. 자율주행 자동차 에이전트의 환경은 도로 시스템과 인접 지역입니다.

AI 에이전트가 수행할 수 있는 행동의 집합은 접근할 수 있는 *도구(tools)*에 의해 확장됩니다. 매일 상호작용하는 많은 생성 AI 기반 애플리케이션은 도구에 접근할 수 있는 에이전트이지만, 단순한 도구들입니다. ChatGPT는 에이전트입니다. 웹을 검색하고, Python 코드를 실행하고, 이미지를 생성할 수 있습니다. RAG 시스템은 에이전트입니다—텍스트 검색기(retrievers), 이미지 검색기, SQL 실행기가 그들의 도구입니다.

에이전트의 환경과 도구 집합 사이에는 강한 의존성이 있습니다. 환경은 에이전트가 잠재적으로 사용할 수 있는 도구를 결정합니다. 예를 들어, 환경이 체스 게임이라면 에이전트가 취할 수 있는 유일한 행동은 유효한 체스 수입니다. 그러나 에이전트의 도구 인벤토리는 작동할 수 있는 환경을 제한합니다. 예를 들어, 로봇의 유일한 행동이 수영이라면 물 환경에 국한될 것입니다.

그림 6-8은 GPT-4 위에 구축된 에이전트인 SWE-agent (Yang et al., 2024)의 시각화를 보여줍니다. 환경은 터미널과 파일 시스템이 있는 컴퓨터입니다. 행동 집합에는 저장소 탐색(navigate repo), 파일 검색(search files), 파일 보기(view files), 라인 편집(edit lines)이 포함됩니다.

assets/ef2ea3c323676bde9f1e245c76d204d1_MD5.png]]

코딩 에이전트

그림 6-8. SWE-agent는 환경이 컴퓨터이고 행동에 탐색, 검색, 파일 보기, 편집이 포함된 코딩 에이전트입니다

AI 에이전트는 일반적으로 사용자가 제공하는 작업을 수행하기 위한 것입니다. AI 에이전트에서 AI는 작업을 처리하고, 이 작업을 달성하기 위한 일련의 행동을 계획하고, 작업이 완료되었는지 결정하는 두뇌입니다.

위의 Kitty Vogue 예제에서 표 형식 데이터가 있는 RAG 시스템으로 돌아가 봅시다. 이것은 세 가지 행동이 있는 간단한 에이전트입니다:

응답 생성(response generation),
SQL 쿼리 생성(SQL query generation), 그리고
SQL 쿼리 실행(SQL query execution).

"Fruity Fedora의 향후 3개월 매출을 예측하라" 쿼리가 주어지면 에이전트는 다음 일련의 행동을 수행할 수 있습니다:

이 작업을 수행하는 방법에 대해 추론합니다. 미래 매출을 예측하려면 먼저 지난 5년간의 매출 수치가 필요하다고 결정할 수 있습니다. 에이전트의 추론은 중간 응답으로 표시될 수 있습니다.
SQL 쿼리 생성을 호출하여 지난 5년간의 매출 수치를 가져오는 쿼리를 생성합니다.
SQL 쿼리 실행을 호출하여 이 쿼리를 실행합니다.
도구 출력(SQL 쿼리 실행의 출력)과 그것이 매출 예측에 어떻게 도움이 되는지에 대해 추론합니다. 누락된 값 때문에 이 숫자들이 신뢰할 수 있는 예측을 하기에 불충분하다고 결정할 수 있습니다. 그런 다음 과거 마케팅 캠페인에 대한 정보도 필요하다고 결정합니다.
SQL 쿼리 생성을 호출하여 과거 마케팅 캠페인에 대한 쿼리를 생성합니다.
SQL 쿼리 실행을 호출합니다.
이 새로운 정보가 미래 매출을 예측하는 데 충분하다고 추론합니다. 그런 다음 예측을 생성합니다.
작업이 성공적으로 완료되었다고 추론합니다.

비에이전트 사용 사례와 비교하여, 에이전트는 일반적으로 두 가지 이유로 더 강력한 모델이 필요합니다:

복합 실수(compound mistakes): 에이전트는 종종 작업을 완료하기 위해 여러 단계를 수행해야 하며, 단계 수가 증가함에 따라 전체 정확도가 감소합니다. 모델의 단계별 정확도가 95%라면, 10단계에 걸쳐 정확도는 60%로 떨어지고, 100단계에 걸쳐서는 정확도가 0.6%에 불과합니다.
높은 위험(higher stakes): 도구에 접근할 수 있는 에이전트는 더 영향력 있는 작업을 수행할 수 있지만, 실패는 더 심각한 결과를 초래할 수 있습니다.

많은 단계가 필요한 작업은 실행하는 데 시간과 비용이 소요될 수 있습니다. 일반적인 불만은 에이전트가 API 크레딧을 소진하는 데만 좋다는 것입니다. 하지만 에이전트가 자율적일 수 있다면 인간의 시간을 절약할 수 있어 비용이 가치가 있습니다.

주어진 환경에서 에이전트의 성공은 접근할 수 있는 도구와 AI 플래너(planner)의 강도에 달려 있습니다. 먼저 모델이 사용할 수 있는 다양한 종류의 도구를 살펴보겠습니다. 다음으로 계획을 위한 AI의 능력을 분석하겠습니다.

Tools(도구)

시스템이 에이전트가 되기 위해 외부 도구에 접근할 필요는 없습니다. 하지만 외부 도구가 없다면 에이전트의 능력은 제한적일 것입니다. 그 자체로 모델은 일반적으로 하나의 행동만 수행할 수 있습니다—LLM은 텍스트를 생성하고 이미지 생성기는 이미지를 생성할 수 있습니다. 외부 도구는 에이전트를 훨씬 더 능력 있게 만듭니다.

도구는 에이전트가 환경을 인식하고 환경에 작용하는 데 도움을 줍니다. 에이전트가 환경을 인식할 수 있게 하는 행동은 *읽기 전용 행동(read-only actions)*이고, 환경에 작용할 수 있게 하는 행동은 *쓰기 행동(write actions)*입니다.

에이전트가 접근할 수 있는 도구의 집합은 도구 인벤토리(tool inventory)입니다. 에이전트의 도구 인벤토리가 에이전트가 무엇을 할 수 있는지 결정하므로, 에이전트에게 어떤 도구를 몇 개나 줄지 신중히 생각하는 것이 중요합니다. 더 많은 도구는 에이전트에게 더 많은 능력을 제공합니다. 하지만 도구가 많을수록 이해하고 잘 활용하는 것이 더 어렵습니다. 나중에 “도구 선택(Tool selection)” 섹션에서 논의되는 바와 같이, 올바른 도구 집합을 찾기 위해서는 실험이 필요합니다.

에이전트의 환경에 따라 많은 가능한 도구가 있습니다. 다음은 고려할 수 있는 세 가지 범주의 도구입니다: 지식 증강(knowledge augmentation, 즉 컨텍스트 구성), 능력 확장(capability extension), 그리고 에이전트가 환경에 작용할 수 있게 하는 도구입니다.

Knowledge augmentation(지식 증강)

이 책이 지금까지 모델의 응답 품질에 관련 컨텍스트를 갖는 것의 중요성을 설득했기를 바랍니다. 중요한 도구 범주에는 에이전트의 지식을 증강하는 데 도움이 되는 것들이 포함됩니다. 그 중 일부는 이미 논의되었습니다: 텍스트 검색기(text retriever), 이미지 검색기(image retriever), SQL 실행기(SQL executor). 다른 잠재적 도구로는 내부 인력 검색, 다양한 제품의 상태를 반환하는 재고 API, Slack 검색, 이메일 리더 등이 있습니다.

이러한 많은 도구는 모델을 조직의 비공개 프로세스와 정보로 증강합니다. 하지만 도구는 모델에게 특히 인터넷에서 공개 정보에 대한 접근도 제공할 수 있습니다.

웹 브라우징(web browsing)은 ChatGPT에 통합될 가장 초기이자 가장 기대되는 능력 중 하나였습니다. 웹 브라우징은 모델이 오래되는 것을 방지합니다. 모델의 훈련 데이터가 구식이 되면 모델은 오래됩니다. 모델의 훈련 데이터가 지난주에 끊겼다면, 이 정보가 컨텍스트에 제공되지 않는 한 이번 주의 정보가 필요한 질문에 답할 수 없습니다. 웹 브라우징이 없으면 모델은 날씨, 뉴스, 다가오는 이벤트, 주가, 항공편 상태 등에 대해 알려줄 수 없습니다.

저는 웹 브라우징을 검색 API(search APIs), 뉴스 API(news APIs), GitHub API, 소셜 미디어 API 등 인터넷에 접근하는 모든 도구를 다루는 포괄적인 용어로 사용합니다.

웹 브라우징은 에이전트가 최신 정보를 참조하여 더 나은 응답을 생성하고 hallucination(환각)을 줄일 수 있게 하지만, 인터넷의 쓰레기 더미에 에이전트를 노출시킬 수도 있습니다. 인터넷 API를 신중하게 선택하세요.

Capability extension(능력 확장)

AI 모델의 고유한 한계를 해결하는 도구도 고려할 수 있습니다. 이는 모델의 성능을 향상시키는 쉬운 방법입니다. 예를 들어, AI 모델은 수학을 못하는 것으로 악명 높습니다. 모델에게 199,999를 292로 나눈 값을 물어보면 모델은 실패할 가능성이 높습니다. 하지만 모델이 계산기에 접근할 수 있다면 이 계산은 사소한 일일 것입니다. 모델을 산술에 능하도록 훈련시키려고 하는 대신, 모델에게 도구에 대한 접근권을 주는 것이 훨씬 더 리소스 효율적입니다.

모델의 능력을 크게 향상시킬 수 있는 다른 간단한 도구로는 달력(calendar), 시간대 변환기(timezone converter), 단위 변환기(unit converter, 예: lbs에서 kg로), 모델이 능숙하지 않은 언어로 번역하거나 그 반대로 번역하는 번역기(translator)가 있습니다.

더 복잡하지만 강력한 도구는 코드 인터프리터(code interpreters)입니다. 모델을 코드를 이해하도록 훈련시키는 대신, 코드 인터프리터에 대한 접근권을 주어 코드 조각을 실행하고, 결과를 반환하거나, 코드의 실패를 분석할 수 있습니다. 이 능력은 에이전트가 코딩 어시스턴트, 데이터 분석가, 심지어 실험을 실행하고 결과를 보고하는 코드를 작성할 수 있는 연구 어시스턴트 역할을 할 수 있게 합니다. 하지만 자동화된 코드 실행은 5장의 “Defensive Prompt Engineering(방어적 프롬프트 엔지니어링)” 섹션에서 논의된 바와 같이 code injection(코드 주입) 공격의 위험을 수반합니다. 귀하와 사용자를 안전하게 유지하려면 적절한 보안 조치가 중요합니다.

도구는 텍스트 전용 또는 이미지 전용 모델을 multimodal model(멀티모달 모델)로 전환할 수 있습니다. 예를 들어, 텍스트만 생성할 수 있는 모델은 text-to-image model(텍스트-이미지 모델)을 도구로 활용하여 텍스트와 이미지를 모두 생성할 수 있습니다. 텍스트 요청이 주어지면 에이전트의 AI 플래너는 텍스트 생성, 이미지 생성 또는 둘 다를 호출할지 결정합니다. 이것이 ChatGPT가 텍스트와 이미지를 모두 생성할 수 있는 방법입니다—DALL-E를 이미지 생성기로 사용합니다.

에이전트는 코드 인터프리터를 사용하여 차트와 그래프를 생성하거나, LaTex 컴파일러를 사용하여 수학 방정식을 렌더링하거나, 브라우저를 사용하여 HTML 코드에서 웹 페이지를 렌더링할 수도 있습니다.

마찬가지로, 텍스트 입력만 처리할 수 있는 모델은 image captioning(이미지 캡셔닝) 도구를 사용하여 이미지를 처리하고 transcription(전사) 도구를 사용하여 오디오를 처리할 수 있습니다. OCR(optical character recognition, 광학 문자 인식) 도구를 사용하여 PDF를 읽을 수 있습니다.

도구 사용은 프롬프팅이나 심지어 파인튜닝만 사용하는 것에 비해 모델의 성능을 크게 향상시킬 수 있습니다. Chameleon (Lu et al., 2023)은 13개의 도구로 증강된 GPT-4 기반 에이전트가 여러 벤치마크에서 GPT-4 단독보다 성능이 뛰어날 수 있음을 보여줍니다. 이 에이전트가 사용한 도구의 예로는 지식 검색(knowledge retrieval), 쿼리 생성기(query generator), 이미지 캡셔너(image captioner), 텍스트 감지기(text detector), Bing 검색이 있습니다.

과학 질문 답변 벤치마크인 ScienceQA에서 Chameleon은 최고의 발표된 few-shot 결과를 11.37% 개선했습니다. 표 형식 수학 문제를 다루는 벤치마크인 TabMWP(Tabular Math Word Problems) (Lu et al., 2022)에서 Chameleon은 정확도를 17% 개선했습니다.

Write actions(쓰기 행동)

지금까지 모델이 데이터 소스에서 읽을 수 있게 하는 읽기 전용 행동을 논의했습니다. 하지만 도구는 쓰기 행동도 수행할 수 있어 데이터 소스를 변경할 수 있습니다. SQL 실행기는 데이터 테이블을 검색(읽기)하고 테이블을 변경하거나 삭제(쓰기)할 수 있습니다. 이메일 API는 이메일을 읽을 수 있지만 응답할 수도 있습니다. 은행 API는 현재 잔액을 검색할 수 있지만 은행 송금을 시작할 수도 있습니다.

쓰기 행동은 시스템이 더 많은 일을 할 수 있게 합니다. 잠재 고객 조사, 연락처 찾기, 이메일 초안 작성, 첫 번째 이메일 보내기, 응답 읽기, 후속 조치, 주문 추출, 새 주문으로 데이터베이스 업데이트 등 전체 고객 접촉 워크플로를 자동화할 수 있습니다.

하지만 AI에게 자동으로 우리의 삶을 변경할 수 있는 능력을 주는 전망은 두렵습니다. 인턴에게 프로덕션 데이터베이스를 삭제할 권한을 주어서는 안 되는 것처럼, 신뢰할 수 없는 AI가 은행 송금을 시작하도록 허용해서는 안 됩니다. 시스템의 능력과 보안 조치에 대한 신뢰가 중요합니다. 시스템이 해로운 행동을 수행하도록 조작하려는 악의적인 행위자로부터 보호되도록 보장해야 합니다.

사이드바: 에이전트와 보안

자율 AI 에이전트에 대해 사람들에게 이야기할 때마다, 자율주행 자동차를 언급하는 사람이 종종 있습니다. “누군가 당신을 납치하기 위해 차를 해킹하면 어떻게 하나요?” 자율주행 자동차 예시는 물리적 존재 때문에 생생하게 느껴지지만, AI 시스템은 물리적 세계에 존재하지 않아도 피해를 줄 수 있습니다. 주식 시장을 조작하고, 저작권을 도용하고, 프라이버시를 침해하고, 편향을 강화하고, 허위 정보와 선전을 퍼뜨리는 등 5장의 “Defensive Prompt Engineering(방어적 프롬프트 엔지니어링)” 섹션에서 논의된 바와 같이 더 많은 일을 할 수 있습니다.

이러한 모든 우려는 타당하며, AI를 활용하려는 모든 조직은 안전과 보안을 심각하게 받아들여야 합니다. 하지만 이것이 AI 시스템이 실제 세계에서 행동할 수 있는 능력을 절대 주어서는 안 된다는 것을 의미하지는 않습니다. 기계를 신뢰하여 우리를 우주로 데려갈 수 있다면, 언젠가 보안 조치가 자율 AI 시스템을 신뢰하기에 충분할 것이라고 희망합니다. 게다가 인간도 실패할 수 있습니다. 개인적으로 저는 평균적인 낯선 사람이 저를 태워주는 것보다 자율주행 자동차를 더 신뢰할 것입니다.

올바른 도구가 인간을 훨씬 더 생산적으로 만들 수 있는 것처럼—Excel 없이 비즈니스를 하거나 크레인 없이 마천루를 짓는 것을 상상할 수 있나요?—도구는 모델이 훨씬 더 많은 작업을 수행할 수 있게 합니다. 많은 모델 제공업체는 이미 자신의 모델과 함께 도구 사용을 지원하며, 이 기능은 종종 function calling(함수 호출)이라고 불립니다. 앞으로 광범위한 도구 집합을 사용한 함수 호출이 대부분의 모델에서 일반적일 것으로 예상됩니다.

Planning(계획)

Foundation model 에이전트의 핵심은 사용자가 제공한 작업을 해결하는 책임이 있는 모델입니다. 작업은 목표(goal)와 제약(constraints)으로 정의됩니다. 예를 들어, 한 가지 작업은 $5,000의 예산으로 샌프란시스코에서 인도로 2주간의 여행을 계획하는 것입니다. 목표는 2주간의 여행입니다. 제약은 예산입니다.

복잡한 작업은 계획이 필요합니다. 계획 프로세스의 출력은 plan(계획)으로, 작업을 완료하는 데 필요한 단계를 설명하는 로드맵입니다. 효과적인 계획은 일반적으로 모델이 작업을 이해하고, 이 작업을 달성하기 위한 다양한 옵션을 고려하고, 가장 유망한 것을 선택해야 합니다.

계획 회의에 참석해 본 적이 있다면 계획이 어렵다는 것을 알 것입니다. 중요한 계산 문제로서 계획은 잘 연구되었으며 다루는 데 여러 권이 필요할 것입니다. 여기서는 표면만 다룰 수 있습니다.

Planning overview(계획 개요)

작업이 주어지면 그것을 해결하는 많은 가능한 방법이 있지만, 모두가 성공적인 결과로 이어지는 것은 아닙니다. 올바른 솔루션 중에서 일부는 다른 것보다 더 효율적입니다. "매출이 없는 회사 중 최소 10억 달러를 조달한 회사는 몇 개인가?" 쿼리와 두 가지 예시 솔루션을 고려하세요:

매출이 없는 모든 회사를 찾은 다음 조달 금액으로 필터링합니다.
최소 10억 달러를 조달한 모든 회사를 찾은 다음 매출로 필터링합니다.

두 번째 옵션이 더 효율적입니다. 10억 달러를 조달한 회사보다 매출이 없는 회사가 훨씬 많습니다. 이 두 옵션만 주어진다면 지능형 에이전트는 옵션 2를 선택해야 합니다.

동일한 프롬프트에서 계획과 실행을 결합할 수 있습니다. 예를 들어, 모델에게 프롬프트를 주고, 단계별로 생각하도록 요청하고(chain-of-thought 프롬프트와 같이), 한 프롬프트에서 그 단계들을 모두 실행합니다. 하지만 모델이 목표를 달성하지도 못하는 1,000단계 계획을 생각해낸다면 어떻게 될까요? 감독 없이 에이전트는 어디로도 가지 않는다는 것을 깨닫기 전에 몇 시간 동안 그 단계들을 실행하여 API 호출에 시간과 돈을 낭비할 수 있습니다.

무익한 실행을 피하기 위해 *계획(planning)*은 *실행(execution)*과 분리되어야 합니다. 에이전트에게 먼저 계획을 생성하도록 요청하고, 이 계획이 *검증(validated)*된 후에만 실행됩니다. 계획은 휴리스틱(heuristics)을 사용하여 검증할 수 있습니다. 예를 들어, 한 가지 간단한 휴리스틱은 유효하지 않은 행동이 있는 계획을 제거하는 것입니다. 생성된 계획에 Google 검색이 필요한데 에이전트가 Google 검색에 접근할 수 없다면 이 계획은 유효하지 않습니다. 또 다른 간단한 휴리스틱은 X단계 이상의 모든 계획을 제거하는 것일 수 있습니다.

계획은 AI judges(AI 심사자)를 사용하여 검증할 수도 있습니다. 모델에게 계획이 합리적으로 보이는지 또는 어떻게 개선할지 평가하도록 요청할 수 있습니다.

생성된 계획이 나쁘다고 평가되면 플래너에게 다른 계획을 생성하도록 요청할 수 있습니다. 생성된 계획이 좋으면 실행하세요.

계획이 외부 도구로 구성되어 있다면 함수 호출이 호출됩니다. 이 계획을 실행한 출력은 다시 평가되어야 합니다. 생성된 계획이 전체 작업에 대한 end-to-end 계획일 필요는 없습니다. 하위 작업에 대한 작은 계획일 수 있습니다. 전체 프로세스는 그림 6-9와 같습니다.

assets/741403937b97a1b9b6c49175ae4c1158_MD5.png]]

에이전트 패턴

그림 6-9. 계획과 실행을 분리하여 검증된 계획만 실행되도록 함

이제 시스템에는 세 가지 구성 요소가 있습니다: 계획을 생성하는 것, 계획을 검증하는 것, 계획을 실행하는 것. 각 구성 요소를 에이전트로 간주하면 이것은 multi-agent system(멀티 에이전트 시스템)으로 간주될 수 있습니다. 대부분의 에이전틱 워크플로는 여러 구성 요소를 포함할 만큼 충분히 복잡하기 때문에, 대부분의 에이전트는 멀티 에이전트입니다.

프로세스의 속도를 높이기 위해 계획을 순차적으로 생성하는 대신 여러 계획을 병렬로 생성하고 평가자에게 가장 유망한 것을 선택하도록 요청할 수 있습니다. 여러 계획을 동시에 생성하면 추가 비용이 발생하므로 이것은 또 다른 latency(지연 시간)–비용 tradeoff(절충)입니다.

계획은 작업 뒤의 의도를 이해해야 합니다: 사용자가 이 쿼리로 무엇을 하려고 하는가? Intent classifier(의도 분류기)는 종종 에이전트가 계획하는 데 도움을 주는 데 사용됩니다. 5장의 “Break complex tasks into simpler subtasks(복잡한 작업을 더 간단한 하위 작업으로 나누기)” 섹션에서 보여준 바와 같이, 의도 분류는 다른 프롬프트나 이 작업을 위해 훈련된 분류 모델을 사용하여 수행할 수 있습니다. 의도 분류 메커니즘은 멀티 에이전트 시스템의 또 다른 에이전트로 간주될 수 있습니다.

의도를 아는 것은 에이전트가 올바른 도구를 선택하는 데 도움이 될 수 있습니다. 예를 들어, 고객 지원의 경우 쿼리가 청구에 관한 것이라면 에이전트는 사용자의 최근 결제를 검색하는 도구에 접근해야 할 수 있습니다. 하지만 쿼리가 비밀번호 재설정 방법에 관한 것이라면 에이전트는 문서 검색에 접근해야 할 수 있습니다.

팁:

일부 쿼리는 에이전트의 범위를 벗어날 수 있습니다. 의도 분류기는 요청을 IRRELEVANT로 분류하여 에이전트가 불가능한 솔루션을 생각하는 데 FLOPs를 낭비하는 대신 정중하게 거절할 수 있어야 합니다.

지금까지 에이전트가 세 단계를 모두 자동화한다고 가정했습니다: 계획 생성, 계획 검증, 계획 실행. 실제로는 인간이 프로세스를 돕고 위험을 완화하기 위해 어떤 단계에든 참여할 수 있습니다.

인간 전문가가 계획을 제공하거나, 계획을 검증하거나, 계획의 일부를 실행할 수 있습니다. 예를 들어, 에이전트가 전체 계획을 생성하는 데 어려움을 겪는 복잡한 작업의 경우, 인간 전문가가 에이전트가 확장할 수 있는 높은 수준의 계획을 제공할 수 있습니다.
계획이 데이터베이스 업데이트나 코드 변경 병합과 같은 위험한 작업을 포함하는 경우, 시스템은 실행하기 전에 명시적인 인간 승인을 요청하거나 인간이 이러한 작업을 실행하도록 맡길 수 있습니다. 이를 가능하게 하려면 각 행동에 대해 에이전트가 가질 수 있는 자동화 수준을 명확히 정의해야 합니다.

요약하면, 작업을 해결하는 것은 일반적으로 다음 프로세스를 포함합니다. 반성(reflection)은 에이전트에 필수적이지 않지만, 에이전트의 성능을 크게 향상시킬 것입니다.

계획 생성(plan generation): 이 작업을 달성하기 위한 계획을 생각해냅니다. 계획은 관리 가능한 행동의 순서이므로 이 프로세스는 작업 분해(task decomposition)라고도 합니다.
반성과 오류 수정(reflection and error correction): 생성된 계획을 평가합니다. 나쁜 계획이라면 새로운 계획을 생성합니다.
실행(execution): 생성된 계획에 설명된 행동을 취합니다. 이것은 종종 특정 함수를 호출하는 것을 포함합니다.
반성과 오류 수정(reflection and error correction): 행동 결과를 받은 후, 이러한 결과를 평가하고 목표가 달성되었는지 결정합니다. 실수를 식별하고 수정합니다. 목표가 완료되지 않았다면 새 계획을 생성합니다.

이 책에서 이미 계획 생성과 반성을 위한 몇 가지 기법을 보았습니다. 모델에게 “단계별로 생각하라”고 요청하면 작업을 분해하도록 요청하는 것입니다. 모델에게 “답이 맞는지 확인하라”고 요청하면 반성하도록 요청하는 것입니다.

Foundation models as planners(플래너로서의 파운데이션 모델)

개방적인 질문은 foundation model이 얼마나 잘 계획할 수 있는가입니다. 많은 연구자들은 적어도 autoregressive language model(자기회귀 언어 모델) 위에 구축된 foundation model은 그럴 수 없다고 믿습니다. Meta의 수석 AI 과학자 Yann LeCun은 autoregressive LLM은 계획할 수 없다 (2023)고 명백히 말합니다.

LLM이 열악한 플래너라는 많은 일화적 증거가 있지만, 그것이 LLM을 올바른 방식으로 사용하는 방법을 모르기 때문인지 아니면 LLM이 근본적으로 계획할 수 없기 때문인지는 불분명합니다.

**계획은 본질적으로 검색 문제(search problem)**입니다. 목표를 향한 다양한 경로를 검색하고, 각 경로의 결과(보상)를 예측하고, 가장 유망한 결과가 있는 경로를 선택합니다. 종종 목표로 이동할 수 있는 경로가 없다고 결정할 수 있습니다.

검색은 종종 *backtracking(역추적)*이 필요합니다. 예를 들어, A와 B라는 두 가지 가능한 행동이 있는 단계에 있다고 상상해보세요. 행동 A를 취한 후 유망하지 않은 상태에 들어가므로 행동 B를 취하기 위해 이전 상태로 역추적해야 합니다.

일부 사람들은 autoregressive model이 앞으로만 행동을 생성할 수 있다고 주장합니다. 대체 행동을 생성하기 위해 역추적할 수 없습니다. 이 때문에 그들은 autoregressive model이 계획할 수 없다고 결론짓습니다. 하지만 이것이 반드시 사실은 아닙니다. 행동 A가 있는 경로를 실행한 후 모델이 이 경로가 말이 되지 않는다고 결정하면 대신 행동 B를 사용하여 경로를 수정할 수 있으며, 효과적으로 역추적합니다. 모델은 항상 처음부터 다시 시작하여 다른 경로를 선택할 수도 있습니다.

LLM이 열악한 플래너인 것은 계획하는 데 필요한 도구를 제공받지 못했기 때문일 수도 있습니다. 계획하려면 사용 가능한 행동뿐만 아니라 각 행동의 잠재적 결과도 아는 것이 필요합니다. 간단한 예로, 산을 걸어 올라가고 싶다고 가정해 봅시다. 가능한 행동은 오른쪽으로 돌기, 왼쪽으로 돌기, 뒤돌기, 직진입니다. 하지만 오른쪽으로 돌면 절벽에서 떨어지게 되면 이 행동을 고려하지 않을 것입니다. 기술적 용어로 행동은 한 상태에서 다른 상태로 이동시키며, 행동을 취할지 결정하려면 결과 상태를 아는 것이 필요합니다.

이것은 인기 있는 chain-of-thought 프롬프팅 기법이 하는 것처럼 일련의 행동만 생성하도록 모델을 프롬프팅하는 것으로는 충분하지 않다는 것을 의미합니다. “Reasoning with Language Model is Planning with World Model” (Hao et al., 2023) 논문은 세계에 대한 많은 정보를 포함함으로써 LLM이 각 행동의 결과를 예측할 수 있다고 주장합니다. 이 LLM은 이 결과 예측을 통합하여 일관된 계획을 생성할 수 있습니다.

AI가 계획할 수 없더라도 여전히 플래너의 일부가 될 수 있습니다. LLM을 검색 도구와 상태 추적 시스템으로 증강하여 계획하는 데 도움을 주는 것이 가능할 수 있습니다.

사이드바: Foundation model(FM) 대 reinforcement learning(RL) 플래너

*Agent(에이전트)*는 RL의 핵심 개념이며, Wikipedia에서는 “지능형 에이전트가 누적 보상을 최대화하기 위해 동적 환경에서 어떻게 행동을 취해야 하는지”에 관한 분야로 정의됩니다.

RL 에이전트와 FM 에이전트는 여러 면에서 유사합니다. 둘 다 환경과 가능한 행동으로 특징지어집니다. 주요 차이점은 플래너가 작동하는 방식입니다.

RL 에이전트에서 플래너는 RL 알고리즘에 의해 훈련됩니다. 이 RL 플래너를 훈련하는 것은 많은 시간과 리소스가 필요할 수 있습니다.

FM 에이전트에서 모델이 플래너입니다. 이 모델은 계획 능력을 향상시키기 위해 프롬프팅되거나 파인튜닝될 수 있으며, 일반적으로 더 적은 시간과 리소스가 필요합니다.

하지만 FM 에이전트가 성능을 향상시키기 위해 RL 알고리즘을 통합하는 것을 막을 것은 없습니다. 장기적으로 FM 에이전트와 RL 에이전트가 병합될 것으로 예상합니다.

Plan generation(계획 생성)

모델을 계획 생성기로 전환하는 가장 간단한 방법은 prompt engineering(프롬프트 엔지니어링)을 사용하는 것입니다. Kitty Vogue에서 고객이 제품에 대해 배우는 데 도움이 되는 에이전트를 만들고 싶다고 상상해보세요. 이 에이전트에게 세 가지 외부 도구에 대한 접근권을 줍니다: 가격별 제품 검색(retrieve products by price), 최고 제품 검색(retrieve top products), 제품 정보 검색(retrieve product information). 다음은 계획 생성을 위한 프롬프트의 예입니다. 이 프롬프트는 설명 목적으로만 사용됩니다. 프로덕션 프롬프트는 더 복잡할 가능성이 높습니다.

SYSTEM PROMPT:

작업을 해결하기 위한 계획을 제안하세요. 5가지 행동에 접근할 수 있습니다:

* get_today_date()
* fetch_top_products(start_date, end_date, num_products)
* fetch_product_info(product_name)
* generate_query(task_history, tool_output)
* generate_response(query)

계획은 유효한 행동의 순서여야 합니다.

예시
작업: "Fruity Fedora에 대해 알려주세요"
계획: [fetch_product_info, generate_query, generate_response]

작업: "지난주 최고 판매 제품은 무엇이었나요?"
계획: [fetch_top_products, generate_query, generate_response]

작업: {USER INPUT}
계획:

이 예제에서 주목할 두 가지가 있습니다:

여기서 사용된 계획 형식—매개변수가 에이전트에 의해 추론되는 함수 목록—은 에이전트 제어 흐름을 구조화하는 많은 방법 중 하나일 뿐입니다.
generate_query 함수는 작업의 현재 히스토리와 가장 최근 도구 출력을 받아 응답 생성기에 공급할 쿼리를 생성합니다. 각 단계의 도구 출력은 작업의 히스토리에 추가됩니다.

사용자 입력 “지난주 최고 판매 제품의 가격은 얼마인가”가 주어지면 생성된 계획은 다음과 같을 수 있습니다:

get_time()
fetch_top_products()
fetch_product_info()
generate_query()
generate_response()

“각 함수에 필요한 매개변수는 어떻게 되나요?”라고 궁금할 수 있습니다. 정확한 매개변수는 종종 이전 도구 출력에서 추출되므로 미리 예측하기 어렵습니다. 첫 번째 단계인 get_time()이 “2030-09-13”을 출력하면 에이전트는 다음 단계가 다음 매개변수로 호출되어야 한다고 추론할 수 있습니다:

fetch_top_products(
    start_date="2030-09-07",
    end_date="2030-09-13",
    num_products=1
)

종종 함수의 정확한 매개변수 값을 결정하기에 충분한 정보가 없습니다. 예를 들어, 사용자가 “최고 판매 제품의 평균 가격은 얼마인가요?”라고 묻는다면 다음 질문에 대한 답이 불분명합니다:

사용자가 보고 싶어하는 최고 판매 제품은 몇 개인가요?
사용자는 지난주, 지난달 또는 전체 기간의 최고 판매 제품을 원하나요?

이것은 모델이 자주 추측해야 하며, 추측은 틀릴 수 있다는 것을 의미합니다.

행동 순서와 관련 매개변수 모두 AI 모델에 의해 생성되므로 hallucination(환각)될 수 있습니다. Hallucination은 모델이 유효하지 않은 함수를 호출하거나 유효한 함수를 잘못된 매개변수로 호출하도록 할 수 있습니다. 일반적으로 모델의 성능을 향상시키는 기법은 모델의 계획 능력을 향상시키는 데 사용될 수 있습니다.

에이전트를 계획에 더 능숙하게 만드는 팁.

더 많은 예시가 있는 더 나은 시스템 프롬프트를 작성하세요.

도구와 매개변수에 대한 더 나은 설명을 제공하여 모델이 더 잘 이해하도록 하세요.

함수 자체를 더 간단하게 재작성하세요. 예를 들어 복잡한 함수를 두 개의 더 간단한 함수로 리팩토링하세요.

더 강력한 모델을 사용하세요. 일반적으로 더 강력한 모델이 계획을 더 잘합니다.

계획 생성을 위해 모델을 파인튜닝하세요.

Function calling(함수 호출)

많은 모델 제공업체는 자신의 모델에 대한 도구 사용을 제공하여 효과적으로 모델을 에이전트로 전환합니다. 도구는 함수입니다. 도구를 호출하는 것은 따라서 종종 *function calling(함수 호출)*이라고 불립니다. 다양한 모델 API가 다르게 작동하지만, 일반적으로 함수 호출은 다음과 같이 작동합니다:

도구 인벤토리 생성. 모델이 사용하기를 원할 수 있는 모든 도구를 선언합니다. 각 도구는 실행 진입점(예: 함수 이름), 매개변수, 문서(예: 함수가 수행하는 작업과 필요한 매개변수)로 설명됩니다.
쿼리에 대해 에이전트가 사용할 수 있는 도구 지정. 다른 쿼리는 다른 도구가 필요할 수 있으므로 많은 API가 쿼리당 사용할 선언된 도구 목록을 지정할 수 있게 합니다. 일부는 다음 설정으로 도구 사용을 더 제어할 수 있게 합니다:
- required: 모델은 최소 하나의 도구를 사용해야 합니다.
- none: 모델은 어떤 도구도 사용하지 않아야 합니다.
- auto: 모델이 사용할 도구를 결정합니다.

함수 호출은 그림 6-10에 설명되어 있습니다. 이것은 여러 API를 대표하기 위해 의사 코드로 작성되었습니다. 특정 API를 사용하려면 해당 문서를 참조하세요.

assets/ca1df77b9d17352e7d702cc5b91d68d5_MD5.png]]

함수 호출의 예

그림 6-10. 두 개의 간단한 도구를 사용하는 모델의 예

쿼리가 주어지면 그림 6-10에서 정의된 에이전트는 자동으로 사용할 도구와 매개변수를 생성합니다. 일부 함수 호출 API는 유효한 함수만 생성되도록 보장하지만, 올바른 매개변수 값을 보장할 수는 없습니다.

예를 들어, 사용자 쿼리 “40파운드는 몇 킬로그램인가요?”가 주어지면 에이전트는 매개변수 값 40이 하나인 lbs_to_kg_tool 도구가 필요하다고 결정할 수 있습니다. 에이전트의 응답은 다음과 같을 수 있습니다.

response = ModelResponse(
    finish_reason='tool_calls',
    message=chat.Message(
        content=None,
        role='assistant',
        tool_calls=[
            ToolCall(
                function=Function(
                    arguments='{"lbs":40}',
                    name='lbs_to_kg'),
                type='function')
        ])
)

이 응답에서 함수 lbs_to_kg(lbs=40)를 호출하고 그 출력을 사용하여 사용자에게 응답을 생성할 수 있습니다.

팁: 에이전트와 작업할 때 항상 시스템이 각 함수 호출에 사용하는 매개변수 값을 보고하도록 요청하세요. 이 값들을 검사하여 올바른지 확인하세요.

Planning granularity(계획 세분성)

계획은 작업을 완료하는 데 필요한 단계를 설명하는 로드맵입니다. 로드맵은 다양한 세분성 수준일 수 있습니다. 일 년을 계획하려면 분기별 계획이 월별 계획보다 높은 수준이며, 월별 계획은 주별 계획보다 높은 수준입니다.

계획/실행 tradeoff가 있습니다. 세부 계획은 생성하기 더 어렵지만 실행하기 더 쉽습니다. 높은 수준의 계획은 생성하기 더 쉽지만 실행하기 더 어렵습니다. 이 tradeoff를 우회하는 접근법은 계층적으로 계획하는 것입니다. 먼저 플래너를 사용하여 분기별 계획과 같은 높은 수준의 계획을 생성합니다. 그런 다음 각 분기에 대해 동일하거나 다른 플래너를 사용하여 월별 계획을 생성합니다.

지금까지 생성된 계획의 모든 예는 정확한 함수 이름을 사용하며, 이는 매우 세분화되어 있습니다. 이 접근법의 문제점은 에이전트의 도구 인벤토리가 시간이 지남에 따라 변경될 수 있다는 것입니다. 예를 들어, 현재 날짜를 가져오는 함수 get_time()은 get_current_time()으로 이름이 변경될 수 있습니다. 도구가 변경되면 프롬프트와 모든 예시를 업데이트해야 합니다. 정확한 함수 이름을 사용하는 것은 또한 다른 도구 API를 가진 다른 사용 사례에서 플래너를 재사용하기 더 어렵게 만듭니다.

이전에 구 도구 인벤토리를 기반으로 계획을 생성하도록 모델을 파인튜닝했다면, 새 도구 인벤토리에서 모델을 다시 파인튜닝해야 합니다.

이 문제를 피하기 위해 계획은 도메인별 함수 이름보다 높은 수준인 더 자연스러운 언어를 사용하여 생성될 수도 있습니다. 예를 들어, “지난주 최고 판매 제품의 가격은 얼마인가” 쿼리가 주어지면 에이전트는 다음과 같은 계획을 출력하도록 지시받을 수 있습니다:

현재 날짜 가져오기
지난주 최고 판매 제품 검색
제품 정보 검색
쿼리 생성
응답 생성

더 자연스러운 언어를 사용하면 계획 생성기가 도구 API의 변경에 강건해집니다. 모델이 주로 자연어로 훈련되었다면 자연어로 계획을 이해하고 생성하는 데 더 능숙하고 hallucination 가능성이 낮을 것입니다.

이 접근법의 단점은 각 자연어 행동을 실행 가능한 명령으로 번역하는 번역기가 필요하다는 것입니다. Chameleon (Lu et al., 2023)은 이 번역기를 프로그램 생성기(program generator)라고 부릅니다. 하지만 번역은 계획보다 훨씬 간단한 작업이며 hallucination 위험이 낮은 약한 모델로 수행할 수 있습니다.

Complex plans(복잡한 계획)

지금까지의 계획 예제는 순차적(sequential)이었습니다: 계획의 다음 행동은 항상 이전 행동이 완료된 후 실행됩니다. 행동이 실행될 수 있는 순서를 *제어 흐름(control flow)*이라고 합니다. 순차적 형태는 한 가지 유형의 제어 흐름일 뿐입니다. 다른 유형의 제어 흐름에는 parallel(병렬), if statement(if 문), for loop(for 루프)가 포함됩니다. 아래 목록은 비교를 위해 순차적을 포함하여 각 제어 흐름의 개요를 제공합니다:

Sequential(순차적) 작업 A가 완료된 후 작업 B를 실행하는 것으로, 아마도 작업 B가 작업 A에 의존하기 때문입니다. 예를 들어, SQL 쿼리는 자연어 입력에서 번역된 후에만 실행될 수 있습니다.
Parallel(병렬) 작업 A와 B를 동시에 실행합니다. 예를 들어, “$100 미만의 최고 판매 제품을 찾아주세요” 쿼리가 주어지면 에이전트는 먼저 최고 판매 제품 100개를 검색하고, 이러한 각 제품에 대해 가격을 검색할 수 있습니다.
If statement(If 문) 이전 단계의 출력에 따라 작업 B 또는 작업 C를 실행합니다. 예를 들어, 에이전트는 먼저 NVIDIA의 수익 보고서를 확인합니다. 이 보고서를 기반으로 NVIDIA 주식을 판매하거나 구매할 수 있습니다. Anthropic의 글은 이 패턴을 “routing(라우팅)“이라고 부릅니다.
For loop(For 루프) 특정 조건이 충족될 때까지 작업 A 실행을 반복합니다. 예를 들어, 소수가 나올 때까지 계속 난수를 생성합니다.

이러한 다양한 제어 흐름은 그림 6-11에 시각화되어 있습니다.

assets/6bbb678310c6aa7ff2cae3316853e247_MD5.png]]

에이전트 제어 흐름

그림 6-11. 계획이 실행될 수 있는 다양한 순서의 예

전통적인 소프트웨어 엔지니어링에서 제어 흐름의 조건은 정확합니다. AI 기반 에이전트에서는 AI 모델이 제어 흐름을 결정합니다. 비순차적 제어 흐름이 있는 계획은 생성하고 실행 가능한 명령으로 번역하는 것이 더 어렵습니다.

팁:

에이전트 프레임워크를 평가할 때 어떤 제어 흐름을 지원하는지 확인하세요. 예를 들어, 시스템이 10개의 웹사이트를 탐색해야 한다면 동시에 할 수 있나요? 병렬 실행은 사용자가 인식하는 지연 시간을 크게 줄일 수 있습니다.

Reflection and error correction(반성과 오류 수정)

최고의 계획조차도 성공 가능성을 최대화하기 위해 지속적으로 평가되고 조정되어야 합니다. 반성이 에이전트가 작동하는 데 엄격히 필요한 것은 아니지만, 에이전트가 성공하는 데는 필요합니다.

작업 프로세스 중 반성이 유용할 수 있는 많은 곳이 있습니다:

사용자 쿼리를 받은 후 요청이 실행 가능한지 평가합니다.
초기 계획 생성 후 계획이 타당한지 평가합니다.
각 실행 단계 후 올바른 방향으로 가고 있는지 평가합니다.
전체 계획이 실행된 후 작업이 완료되었는지 결정합니다.

Reflection(반성)과 error correction(오류 수정)은 함께 진행되는 두 가지 다른 메커니즘입니다. 반성은 수정할 오류를 발견하는 데 도움이 되는 통찰력을 생성합니다.

반성은 self-critique 프롬프트를 사용하여 동일한 에이전트로 수행할 수 있습니다. 또한 각 결과에 대한 구체적인 점수를 출력하는 모델인 특수 scorer(채점자)와 같은 별도의 구성 요소로 수행할 수도 있습니다.

ReAct (Yao et al., 2022)에 의해 처음 제안된 re asoning(추론)과 ac tion(행동)을 인터리빙하는 것은 에이전트의 일반적인 패턴이 되었습니다. Yao et al.은 “reasoning(추론)“이라는 용어를 계획과 반성을 모두 포괄하는 데 사용했습니다. 각 단계에서 에이전트는 자신의 생각을 설명하고(계획), 행동을 취한 다음, 관찰을 분석하도록(반성) 요청받으며, 에이전트가 작업이 완료되었다고 간주할 때까지 계속합니다. 에이전트는 일반적으로 예시를 사용하여 다음 형식으로 출력을 생성하도록 프롬프팅됩니다:

생각 1: …
행동 1: …
관찰 1: …

… [반성이 작업이 완료되었다고 결정할 때까지 계속] …

생각 N: …
행동 N: 완료 [쿼리에 대한 응답]

그림 6-12는 multi-hop 질문 답변을 위한 벤치마크인 HotpotQA (Yang et al., 2018)의 질문에 응답하는 ReAct 프레임워크를 따르는 에이전트의 예를 보여줍니다.

assets/ec39cb19566011c13ff567a73120b1f6_MD5.png]]

ReAct 예제

그림 6-12: 실행 중인 ReAct 에이전트.

멀티 에이전트 설정에서 반성을 구현할 수 있습니다: 한 에이전트가 계획하고 행동을 취하고 다른 에이전트가 각 단계 후 또는 여러 단계 후에 결과를 평가합니다.

에이전트의 응답이 작업을 완료하지 못하면 에이전트에게 실패한 이유와 개선 방법에 대해 반성하도록 프롬프팅할 수 있습니다. 이 제안을 기반으로 에이전트는 새 계획을 생성합니다. 이것은 에이전트가 실수로부터 배울 수 있게 합니다.

예를 들어, 코딩 생성 작업이 주어지면 평가자는 생성된 코드가 테스트 케이스의 ⅓에서 실패한다고 평가할 수 있습니다. 그런 다음 에이전트는 모든 숫자가 음수인 배열을 고려하지 않았기 때문에 실패했다고 반성합니다. 그런 다음 행위자는 모든 음수 배열을 고려하여 새 코드를 생성합니다.

이것은 Reflexion (Shinn et al., 2023)이 취한 접근법입니다. 이 프레임워크에서 반성은 두 모듈로 분리됩니다: 결과를 평가하는 evaluator(평가자)와 무엇이 잘못되었는지 분석하는 self-reflection 모듈. 그림 6-13은 실행 중인 Reflexion 에이전트의 예를 보여줍니다. 저자들은 “trajectory(궤적)“이라는 용어를 계획을 지칭하는 데 사용했습니다. 각 단계에서 평가와 self-reflection 후 에이전트는 새로운 궤적을 제안합니다.

assets/784b51bb4eae5e140a8617a3ba290e5a_MD5.png]]

Reflexion 예제

그림 6-13. Reflexion 에이전트가 작동하는 방식의 예.

계획 생성에 비해 반성은 구현하기 비교적 쉽고 놀라울 정도로 좋은 성능 향상을 가져올 수 있습니다. 이 접근법의 단점은 지연 시간과 비용입니다. 생각, 관찰, 때로는 행동은 생성하는 데 많은 토큰이 소요될 수 있으며, 특히 많은 중간 단계가 있는 작업의 경우 비용과 사용자가 인식하는 지연 시간이 증가합니다. 에이전트가 형식을 따르도록 유도하기 위해 ReAct와 Reflexion 저자들은 프롬프트에 많은 예시를 사용했습니다. 이것은 입력 토큰 계산 비용을 증가시키고 다른 정보에 사용할 수 있는 컨텍스트 공간을 줄입니다.

Tool selection(도구 선택)

도구는 종종 작업의 성공에 중요한 역할을 하므로 도구 선택은 신중한 고려가 필요합니다. 에이전트에게 제공할 도구는 환경과 작업에 달려 있지만 에이전트를 구동하는 AI 모델에도 달려 있습니다.

최상의 도구 집합을 선택하는 방법에 대한 확실한 가이드는 없습니다. 에이전트 문헌은 광범위한 도구 인벤토리로 구성되어 있습니다. 예를 들어:

Toolformer (Schick et al., 2023)는 GPT-J를 5개의 도구를 학습하도록 파인튜닝했습니다.
Chameleon (Lu et al., 2023)은 13개의 도구를 사용합니다.
Gorilla (Patil et al., 2023)는 1,645개의 API 중에서 올바른 API 호출을 선택하도록 에이전트를 프롬프팅하려고 시도했습니다.

더 많은 도구는 에이전트에게 더 많은 능력을 제공합니다. 하지만 도구가 많을수록 효율적으로 사용하기 어렵습니다. 인간이 대규모 도구 집합을 마스터하기 어려운 것과 유사합니다. 도구를 추가하는 것은 또한 도구 설명을 증가시켜 모델의 컨텍스트에 맞지 않을 수 있습니다.

AI 애플리케이션을 구축하는 동안 많은 다른 결정과 마찬가지로 도구 선택은 실험과 분석이 필요합니다. 다음은 결정하는 데 도움이 되는 몇 가지입니다:

에이전트가 다른 도구 집합으로 어떻게 수행하는지 비교하세요.
Ablation study(제거 연구)를 수행하여 인벤토리에서 도구를 제거하면 에이전트의 성능이 얼마나 떨어지는지 확인하세요. 성능 저하 없이 도구를 제거할 수 있다면 제거하세요.
에이전트가 자주 실수하는 도구를 찾으세요. 도구가 에이전트가 사용하기에 너무 어렵다는 것이 입증되면—예를 들어, 광범위한 프롬프팅과 심지어 파인튜닝조차도 모델이 사용하는 것을 배우지 못하게 할 수 없다면—도구를 변경하세요.
도구 호출의 분포를 플롯하여 가장 많이 사용되는 도구와 가장 적게 사용되는 도구를 확인하세요. 그림 6-14는 Chameleon (Lu et al., 2023)에서 GPT-4와 ChatGPT의 도구 사용 패턴의 차이를 보여줍니다.

assets/d6cad5e853bdd02e7462d47215dffaf4_MD5.png]]

다른 모델은 다른 도구 선호도를 가짐

그림 6-14. 다른 모델과 작업은 다른 도구 사용 패턴을 나타냅니다.

Chameleon (Lu et al., 2023)의 실험은 또한 두 가지 점을 보여줍니다:

다른 작업은 다른 도구를 필요로 합니다. 과학 질문 답변 작업인 ScienceQA는 표 형식 수학 문제 해결 작업인 TabMWP보다 지식 검색 도구에 훨씬 더 많이 의존합니다.
다른 모델은 다른 도구 선호도를 가집니다. 예를 들어, GPT-4는 ChatGPT보다 더 광범위한 도구 집합을 선택하는 것 같습니다. ChatGPT는 이미지 캡셔닝을 선호하는 것 같고, GPT-4는 지식 검색을 선호하는 것 같습니다.

팁:

에이전트 프레임워크를 평가할 때 어떤 플래너와 도구를 지원하는지 평가하세요. 다른 프레임워크는 다른 범주의 도구에 초점을 맞출 수 있습니다. 예를 들어, AutoGPT는 소셜 미디어 API(Reddit, X, Wikipedia)에 초점을 맞추는 반면, Composio는 엔터프라이즈 API(Google Apps, GitHub, Slack)에 초점을 맞춥니다.

시간이 지남에 따라 필요가 변경될 가능성이 높으므로 에이전트를 확장하여 새 도구를 통합하는 것이 얼마나 쉬운지 평가하세요.

인간으로서 우리는 주어진 도구를 사용하는 것뿐만 아니라 더 간단한 것에서 점진적으로 더 강력한 도구를 만들어 더 생산적이 됩니다. AI가 초기 도구에서 새 도구를 만들 수 있을까요?

Chameleon (Lu et al., 2023)은 도구 전환(tool transition) 연구를 제안합니다: 도구 X 후에 에이전트가 도구 Y를 호출할 가능성이 얼마나 되나요? 그림 6-15는 도구 전환의 예를 보여줍니다. 두 도구가 자주 함께 사용되면 더 큰 도구로 결합할 수 있습니다. 에이전트가 이 정보를 인식한다면 에이전트 자체가 초기 도구를 결합하여 계속해서 더 복잡한 도구를 구축할 수 있습니다.

assets/5cb35e548ab408ef5730acd37688329a_MD5.png]]

도구 전환

그림 6-15. Chameleon (Lu et al., 2023)의 도구 전환 트리.

Vogager (Wang et al., 2023)는 나중에 재사용하기 위해 에이전트가 획득하는 새 스킬(도구)을 추적하는 skill manager(스킬 관리자)를 제안합니다. 각 스킬은 코딩 프로그램입니다. 스킬 관리자가 새로 생성된 스킬이 유용하다고 결정하면(예: 에이전트가 작업을 완료하는 데 성공적으로 도움을 주었기 때문에), 이 스킬을 스킬 라이브러리(skill library, 개념적으로 도구 인벤토리와 유사)에 추가합니다. 이 스킬은 나중에 다른 작업에 사용하기 위해 검색될 수 있습니다.

이 섹션의 앞부분에서 환경에서 에이전트의 성공은 도구 인벤토리와 계획 능력에 달려 있다고 언급했습니다. 어느 측면의 실패도 에이전트가 실패하도록 할 수 있습니다. 다음 섹션에서는 에이전트의 다양한 실패 모드와 평가 방법을 논의합니다.

Agent Failure Modes and Evaluation(에이전트 실패 모드 및 평가)

평가는 실패를 감지하는 것에 관한 것입니다. 에이전트가 수행하는 작업이 복잡할수록 더 많은 실패 지점이 있습니다. 3장과 4장에서 논의된 모든 AI 애플리케이션에 공통적인 실패 모드 외에도, 에이전트는 계획, 도구 실행, 효율성으로 인한 고유한 실패도 있습니다. 일부 실패는 다른 것보다 감지하기 쉽습니다.

에이전트를 평가하려면 실패 모드를 식별하고 각 실패 모드가 얼마나 자주 발생하는지 측정하세요.

Planning failures(계획 실패)

계획은 어렵고 여러 방식으로 실패할 수 있습니다. 계획 실패의 가장 일반적인 모드는 도구 사용 실패입니다. 에이전트는 다음 오류 중 하나 이상이 있는 계획을 생성할 수 있습니다.

유효하지 않은 도구(Invalid tool) 예를 들어, 도구 인벤토리에 없는 bing_search를 포함하는 계획을 생성합니다.
유효한 도구, 유효하지 않은 매개변수. 예를 들어, 두 개의 매개변수로 lbs_to_kg를 호출하지만 이 함수는 하나의 매개변수 lbs만 필요합니다.
유효한 도구, 잘못된 매개변수 값 예를 들어, 하나의 매개변수 lbs로 lbs_to_kg를 호출하지만 120이어야 하는데 lbs 값으로 100을 사용합니다.

계획 실패의 또 다른 모드는 goal failure(목표 실패)입니다: 에이전트가 목표를 달성하지 못합니다. 이것은 계획이 작업을 해결하지 못하거나 제약을 따르지 않고 작업을 해결하기 때문일 수 있습니다. 이를 설명하기 위해 모델에게 $5,000의 예산으로 샌프란시스코에서 인도로 2주간의 여행을 계획하도록 요청한다고 상상해보세요. 에이전트는 샌프란시스코에서 베트남으로의 여행을 계획하거나 예산을 훨씬 초과하는 샌프란시스코에서 인도로의 2주 여행을 계획할 수 있습니다.

에이전트 평가에서 종종 간과되는 일반적인 제약은 시간입니다. 많은 경우 에이전트가 걸리는 시간은 에이전트에게 작업을 할당하고 완료되면 확인하기만 하면 되기 때문에 덜 중요합니다. 하지만 많은 경우 에이전트는 시간이 지남에 따라 덜 유용해집니다. 예를 들어, 에이전트에게 보조금 제안서를 준비하도록 요청하고 에이전트가 보조금 마감일 이후에 완료하면 에이전트는 그다지 도움이 되지 않습니다.

계획 실패의 흥미로운 모드는 반성의 오류로 인해 발생합니다. 에이전트는 작업을 완료하지 않았는데도 완료했다고 확신합니다. 예를 들어, 에이전트에게 50명을 30개의 호텔 방에 배정하도록 요청합니다. 에이전트는 40명만 배정하고 작업이 완료되었다고 주장할 수 있습니다.

계획 실패에 대해 에이전트를 평가하려면 한 가지 옵션은 각 예제가 튜플 (작업, 도구 인벤토리)인 계획 데이터셋을 만드는 것입니다. 각 작업에 대해 에이전트를 사용하여 K개의 계획을 생성합니다. 다음 메트릭을 계산하세요:

모든 생성된 계획 중 몇 개가 유효한가요?
주어진 작업에 대해 에이전트가 유효한 계획을 얻기 위해 몇 개의 계획을 생성해야 하나요?
모든 도구 호출 중 몇 개가 유효한가요?
유효하지 않은 도구가 얼마나 자주 호출되나요?
유효한 도구가 유효하지 않은 매개변수로 얼마나 자주 호출되나요?
유효한 도구가 잘못된 매개변수 값으로 얼마나 자주 호출되나요?

패턴에 대한 에이전트의 출력을 분석하세요. 에이전트가 어떤 유형의 작업에서 더 자주 실패하나요? 왜 그런지 가설이 있나요? 모델이 자주 실수하는 도구는 무엇인가요? 일부 도구는 에이전트가 사용하기 더 어려울 수 있습니다. 더 나은 프롬프팅, 더 많은 예시 또는 파인튜닝으로 에이전트가 어려운 도구를 사용하는 능력을 향상시킬 수 있습니다. 모두 실패하면 이 도구를 사용하기 더 쉬운 것으로 교체하는 것을 고려할 수 있습니다.

Tool failures(도구 실패)

도구 실패는 올바른 도구가 사용되었지만 도구 출력이 잘못되었을 때 발생합니다. 한 가지 실패 모드는 도구가 잘못된 출력을 제공하는 것입니다. 예를 들어, 이미지 캡셔너가 잘못된 설명을 반환하거나 SQL 쿼리 생성기가 잘못된 SQL 쿼리를 반환합니다.

에이전트가 높은 수준의 계획만 생성하고 번역 모듈이 계획된 각 행동을 실행 가능한 명령으로 번역하는 데 관여하는 경우, 번역 오류 때문에 실패가 발생할 수 있습니다.

도구 실패는 도구에 따라 다릅니다. 각 도구는 독립적으로 테스트되어야 합니다. 항상 각 도구 호출과 출력을 출력하여 검사하고 평가할 수 있도록 하세요. 번역기가 있다면 벤치마크를 만들어 평가하세요.

누락된 도구 실패를 감지하려면 어떤 도구를 사용해야 하는지 이해해야 합니다. 에이전트가 특정 도메인에서 자주 실패한다면 이 도메인에 대한 도구가 부족하기 때문일 수 있습니다. 인간 도메인 전문가와 협력하고 그들이 어떤 도구를 사용할지 관찰하세요.

Efficiency(효율성)

에이전트는 작업을 완료하기 위해 올바른 도구를 사용하여 유효한 계획을 생성할 수 있지만 비효율적일 수 있습니다. 다음은 에이전트의 효율성을 평가하기 위해 추적할 수 있는 몇 가지입니다:

에이전트가 평균적으로 작업을 완료하는 데 몇 단계가 필요한가요?
에이전트가 평균적으로 작업을 완료하는 데 비용이 얼마나 드나요?
각 행동은 일반적으로 얼마나 오래 걸리나요? 특히 시간이 많이 걸리거나 비용이 많이 드는 행동이 있나요?

이러한 메트릭을 다른 에이전트나 인간 운영자일 수 있는 baseline(기준선)과 비교할 수 있습니다. AI 에이전트를 인간 에이전트와 비교할 때 인간과 AI는 매우 다른 작동 모드를 가지므로 인간에게 효율적인 것으로 간주되는 것이 AI에게는 비효율적일 수 있고 그 반대도 마찬가지라는 점을 명심하세요. 예를 들어, 100개의 웹 페이지를 방문하는 것은 한 번에 하나의 페이지만 방문할 수 있는 인간 에이전트에게는 비효율적일 수 있지만 모든 웹 페이지를 한 번에 방문할 수 있는 AI 에이전트에게는 사소한 일입니다.

Conclusion(결론)

본질적으로 에이전트의 개념은 상당히 간단합니다. 에이전트는 작동하는 환경과 접근할 수 있는 도구 집합으로 정의됩니다. AI 기반 에이전트에서 AI 모델은 작업을 가장 잘 달성하는 방법을 계획하기 위해 도구와 환경의 피드백을 활용하는 두뇌입니다. 도구에 대한 접근은 모델을 훨씬 더 능력 있게 만들므로 에이전틱 패턴은 불가피합니다.

“에이전트”의 개념은 새로운 것처럼 들리지만, LLM 초기부터 사용되어온 self-critique(자기 비평), chain-of-thought(사고 연쇄), structured outputs(구조화된 출력)을 포함한 많은 개념 위에 구축되었습니다.

이 글은 에이전트가 작동하는 방식과 에이전트의 다양한 구성 요소를 개념적으로 다루었습니다. 향후 글에서는 에이전트 프레임워크를 평가하는 방법을 논의하겠습니다.

에이전틱 패턴은 종종 모델의 컨텍스트 제한을 초과하는 정보를 다룹니다. 정보를 처리하는 데 모델의 컨텍스트를 보완하는 메모리 시스템(memory system)은 에이전트의 능력을 크게 향상시킬 수 있습니다. 이 글이 이미 길기 때문에 향후 블로그 글에서 메모리 시스템이 작동하는 방식을 탐구하겠습니다.

Jeongsk

탐색기