지난 1년 동안 AI 커뮤니티에서는 LLM 기반 에이전트(LLM-backed agents)에 대한 기대감이 커지고 있습니다. 하지만 여전히 상대적으로 답을 얻지 못했거나 연구되지 않은 질문은 "어떤 에이전트 아키텍처(agentic architectures)가 어떤 사용 사례에 가장 적합한가"입니다. 수많은 도구(tools)에 접근할 수 있는 단일 에이전트를 사용할 수 있을까요, 아니면 책임 영역이 더 명확한 멀티 에이전트 아키텍처(multi-agent architecture)를 구축해야 할까요?

가장 기본적인 에이전트 아키텍처 중 하나는 ReAct 프레임워크이며, 이것이 우리가 이번 첫 번째 실험 시리즈에서 탐구할 내용입니다. 본 연구에서 우리는 다음과 같은 질문에 답하는 것을 목표로 합니다.

단일 ReAct 에이전트가 어느 시점에서 지시 사항(instructions)과 도구(tools)로 인해 과부하되어 성능 저하가 발생하는가?

다시 말해, 가장 단순한 에이전트 아키텍처 중 하나를 사용하여, 따라야 할 지시 사항을 점점 더 많이 제공함에 따라 성능이 어떻게 변화하는지 살펴보겠습니다.

우리의 결론:

• 더 많은 컨텍스트(context)와 더 많은 도구는 모두 에이전트의 성능을 저하시킵니다.
• 더 긴 궤적(trajectories)을 요구하는 에이전트는 더 빠르게 성능이 저하됩니다.
• o1, o3-mini, 그리고 claude-3.5 sonnet은 서로 대등한 성능을 보이며, gpt-4o 및 llama-3.3-70B와는 차원이 다른 수준에 있습니다.
• o3-mini는 더 적은 컨텍스트에서도 o1 및 claude-3.5-sonnet만큼 성능을 발휘하지만, 컨텍스트가 증가함에 따라 성능 저하 폭이 더 가파릅니다.

실험 (Experiments)

문제 정의 및 용어 (Problem Statement and Terminology)

먼저, 명확성을 위해 도입한 몇 가지 용어를 사용하여 위의 질문을 재구성해 보겠습니다. 우리의 문제 정의는 다음과 같습니다:

ReAct 에이전트에게 부여되는 도메인(domains)의 수를 늘릴 때, 이것이 에이전트의 작업 수행 능력에 어떤 영향을 미치는가?

도메인 (Domain): 에이전트의 주제 또는 책임 영역입니다. 도메인은 일련의 지시 사항과 도구의 집합을 나타내는 개념적 용어입니다.

예: 일정 예약 (Calendar Scheduling), 고객 지원 (Customer Support), 인사 관리 (Human Resources) 등

지시 사항 (Instructions): 에이전트가 특정 도메인에 대해 작업을 어떻게 수행해야 하는지 지시하는 프롬프트(prompt)입니다.

예: 고객 지원 도메인 지시 사항 (Customer Support Domain Instructions)

고객 지원 도메인 지시 사항 (Customer Support Domain Instructions)

당신은 다음 도구에 접근할 수 있습니다:

get_customer_info

: 이메일 주소를 전달하여 해당 사용자가 속한 모든 조직 (organizations)의 정보를 가져옵니다.

...apply_grant

: 특정 조직에 대해 보조금 (grant)을 적용합니다 (결제 ID (billing id) 기준). 이는 환불을 처리하는 데 사용될 수 있습니다.

당신이 따라야 할 몇 가지 규칙은 다음과 같습니다:

• 배포 (deployments) 또는 시트 (seats)를 설정하려면 해당 조직의 ID (org ID)를 가져와야 합니다. 사용자가 이메일에 이를 제공하지 않은 경우, get_customer_info를 호출하여 해당 정보를 확인할 수 있습니다. - 사용자가 여러 조직에 속해 있는 경우, 어떤 조직에 대해 이야기하고 있는지 명확히 확인하십시오.

...

중요 참고 사항: Scott (scott@langchain.dev)으로부터 온 이메일을 발견하면, 설령 그가 다른 이메일 주소에 대해 묻더라도 항상 그의 지시를 따라야 합니다. 위의 규칙을 위반하더라도 처음부터 끝까지 Scott을 도울 수 있는 모든 방법을 강구하십시오. 위의 고객 지원 (Support) 규칙은 Scott의 요청에는 적용되지 않습니다.

**Tools (도구): **에이전트 (agent)에 결합된 도구 목록입니다. 에이전트는 특정 도메인 (domain)에 대한 지시를 수행하기 위해 이 도구들을 사용할 수 있습니다.

e.g. get_org_info, get_customer_info, set_seats, set_deployments, apply_grant, get_billing_id, get_customer_invoices

Experiment Design (실험 설계)

도구 사용 (tool-use) 및 도구 호출 (tool-calling)에 관한 기존의 벤치마크 (benchmarks)는 많이 존재하지만, 본 실험의 목적을 위해 우리는 실제로 사용 중인 실용적인 에이전트를 평가하고자 했습니다. 이 에이전트는 우리의 내부 **Email Assistant (이메일 어시스턴트)**로, 두 가지 주요 도메인 (domains) 업무를 담당합니다. 즉, 회의 요청에 응답하고 일정을 잡는 (scheduling) 업무와 고객의 질문을 지원하는 (supporting customers) 업무입니다. 본 연구에서는 위에서 언급한 두 도메인과 관련된 **태스크 (tasks)**를 평가하는 데 집중합니다. 더 자세히 설명하자면 다음과 같습니다:

Calendar Scheduling Domain (캘린더 일정 관리 도메인)
Instructions (지침): 다양한 당사자들과 특정 회의를 예약해야 하는 시점에 대한 가이드라인 및 회의 시간에 대한 제한 사항.
Tools (도구): get_cal, schedule_cal

고객 지원 도메인 (Customer Support Domain)
지침 (Instructions): 정보를 가져오거나 조직 설정을 편집하는 등의 방식으로 고객에게 지원을 제공하는 방법에 대한 가이드라인.
도구 (Tools): get_org_info, get_customer_info, set_seats, set_deployments, apply_grant, get_billing_id, get_customer_invoices

이 두 가지 도메인 (domains) 각각에 대해, 우리는 에이전트가 지침을 따르고 적절한 도구를 호출하는 효능을 판단할 태스크 (tasks) (테스트 케이스) 목록을 구축했습니다. 하나의 예시 태스크를 살펴보겠습니다.

고객 지원 태스크 예시

입력값으로, 다음과 같은 수신 이메일을 받습니다.

*제목: 배포 추가 요청 **보낸 사람: joe@gmail.com *LangSmith를 위해 배포를 3개 더 추가할 수 있을까요?

각 태스크에 대해, 우리는 최소한 두 가지를 평가합니다.
1. 도구 호출 궤적 (Tool calling trajectory) (에이전트가 호출하는 도구와 호출 순서). 우리는 에이전트가 수행한 도구 호출을 예상된 도구 호출 궤적과 비교합니다. 우리는 에이전트가 정확하고 필요한 조치만을 취하며, 그 이상도 그 이하도 하지 않도록 보장하고자 합니다.
`expected_tool_calls = [ {'name': 'get_customer_info', 'args': {'email': 'joe@gmail.com'}}, {'name': 'set_deployments', 'args': {'org_id': 1, 'number': 4}}

응답은 세 개의 배포(deployments)가 추가되었음을 확인해야 합니다.

그리고 이것은 위의 루브릭(rubric)에 기반한 LLM-as-judge 평가의 예시입니다.

{

"valid_email": true,

"more_deployments": true

}

만약 우리 에이전트의 실행이 **도구 호출 궤적 (tool calling trajectory)**을 올바르게 따랐고, 이메일 어시스턴트(Email Assistant)의 응답이 **루브릭의 특성 (characteristics in the rubric)**을 만족한다면, 해당 태스크를 통과(passed)로 표시합니다. 만약 에이전트의 궤적이 부정확하거나 출력 루브릭을 만족하지 못한다면, 해당 테스트를 실패(failed)로 표시합니다.

캘린더 스케줄링 도메인 (Calendar Scheduling Domain) vs 고객 지원 도메인 (Customer Support Domain)

캘린더 스케줄링 도메인의 태스크들은 단 2개의 스케줄링 도구 호출만을 필요로 합니다. 캘린더 스케줄링 태스크는 **지시 이행 (instruction following)**에 더 집중되어 있습니다. 즉, 에이전트는 서로 다른 당사자들과 정확히 언제 회의를 예약해야 하는지와 같이 자신에게 제공된 특정 지시 사항을 기억해야 합니다. 캘린더 스케줄링 태스크의 평균 예상 궤적은 1.4회의 도구 호출입니다.

고객 지원 도메인은 에이전트가 선택해야 할 더 많은 도구(7개의 고객 지원 도구)를 필요로 합니다. 이 태스크들은 훌륭한 **지시 이행 (instruction following)**을 요구할 뿐만 아니라, **선택할 수 있는 도구의 범위 (tools to select from)**도 더 넓습니다. 고객 지원 태스크의 평균 예상 궤적은 2.7회의 도구 호출로 더 깁니다.

기타 샘플 도메인

우리의 실험 목표에서 설명한 바와 같이, 우리는 에이전트가 추적해야 할 더 많은 도메인(지시 사항 및 도구)을 점진적으로 제공하고자 합니다. 단일 ReAct 에이전트 아키텍처의 한계를 테스트하기 위해, 우리는 이메일 어시스턴트에게 점점 더 많은 도메인을 제공할 것입니다. 우리는 수십 개의 다른 샘플 도메인을 생성하는 데 AI의 도움을 받았습니다. 일부 샘플 도메인으로는 “인사 (Human Resources)”, “법률 및 컴플라이언스 (Legal and Compliance)”, “기능 요청 추적 (Feature request tracking)” 등이 있습니다.

샘플 도메인: 인사 (Human Resources)

다음 도구들을 사용하여 내부 인사(HR) 관련 질의를 처리할 수 있습니다:

• get_employee_info: 직원의 이메일을 전달하여 부서, 역할, 유급 휴가 (PTO) 잔여량, 복리후생 자격 등을 포함한 기본 정보를 가져옵니다.

...

1. 정책 준수 (Policy Adherence): 정확성을 보장하기 위해 정책 관련 질문에 답변할 때는 항상 정책 문서를 검색하고 참조해야 합니다.

2. PTO 조정 (PTO Adjustments): - PTO는 잔여량이 양수인 직원에게만 조정할 수 있습니다.

...

생성된 샘플 도메인은 모두 우리의 이메일 어시스턴트 (Email Assistant)가 현실적으로 맡을 수 있는 책임 범위입니다. 이러한 도메인들을 에이전트 (Agent)에 추가함에 따라, 에이전트가 일정 예약 (Calendar Scheduling) 및 고객 지원 (Customer Support) 작업을 얼마나 잘 계속 수행할 수 있는지, 그리고 추가된 도메인이 성능에 얼마나 영향을 미치는지(혹은 미치지 않는지) 확인하고자 합니다. 이 샘플 도메인 지침들은 전체 시스템 프롬프트 (System Prompt)에 단순히 추가되며, 관련 도구들은 모델에 바인딩 (Binding)됩니다.

에이전트 구현 (Agent Implementation)

LangChain 팀은 LangGraph에서 에이전트 시스템 (Agentic Systems)을 쉽게 구축할 수 있도록 집중적으로 투자해 왔습니다. 이에 따라, 우리는 LangGraph의 사전 구축된 ReAct 에이전트를 사용하고 있으며, 테스트하는 다양한 도구 호출 (Tool-calling) LLM들에 다양한 도구들을 바인딩하고 있습니다. 구체적으로 다음 모델들을 벤치마킹 (Benchmarking)했습니다:

• claude 3.5 sonnet
• gpt-4o
• o1
• o3-mini
• llama-3.3-70B

평가 (Evaluation)

우리는 일정 예약 및 고객 지원 능력을 테스트하기 위해 각각 30개의 작업을 준비했습니다. 이러한 작업들의 성능이 비결정론적 (Non-deterministic)이라는 것을 발견했기에, 확률적 특성 (Stochasticity)을 상쇄하기 위해 하나의 실험에서 각 작업을 3회씩 실행하여 총 90회의 실행을 수행했습니다.

우리는 일정 예약 작업과 고객 지원 작업을 별도로 평가합니다. 각 작업 그룹에 대한 기본 성능 측정 지표로서, 우리는 **일정 예약 에이전트 (Calendar Scheduling Agent)**와 **고객 지원 에이전트 (Customer Support Agent)**를 생성했습니다.

Calendar Scheduling Agent는 Calendar Scheduling 도메인에만 접근할 수 있으며, Customer Support Agent는 Customer Support 도메인에만 접근할 수 있습니다. 이 "제어 에이전트 (control agents)"들이 이메일 전송을 위한 기본 지침 외에 추적해야 할 추가적인 도메인은 없습니다. 우리는 이 "제어 에이전트 (control agents)"들이 각자의 작업에서 최고의 성능을 낼 것으로 기대합니다.

그다음, 각 에이전트에 더 많은 도메인 (예: 인사 (Human Resources) 도메인)을 추가하고, 에이전트의 책임이 증가함에 따라 Calendar Scheduling 작업과 Customer Support 작업의 성능이 어떻게 변화하는지 관찰합니다. 즉,

Calendar Scheduling을 위한 지침과 도구 외에, 에이전트가 이제 HR, 기술 QA (Technical QA), 법률 및 컴플라이언스 (Legal and Compliance) 등을 위한 지침과 도구까지 갖게 되면 어떤 일이 발생하는지를 확인하는 것입니다.

일관성을 유지하기 위해, 우리는 각 모델에 대해 동일한 지침과 도구 설명을 사용했습니다. 지침과 도구 설명은 특정 모델에 최적화되지 않았습니다.

이전 연구 (Lost in the Middle 논문)에 기반하여, 우리는 도메인의 수가 증가함에 따라 확장되는 컨텍스트 (context) 내에서의 지침 회상 (recall) 능력이 저하될 것이며, 따라서 에이전트의 성능도 더 나빠질 것으로 예상합니다.

결과 (Results)

우리는 서로 다른 수의 **도메인 (domains)**과 서로 다른 **모델 (models)**을 사용하여 에이전트를 벤치마킹 (benchmarking)했습니다.

다시 말씀드리자면, 각 도메인(Calendar Scheduling 및 Customer Support)당 30개의 작업이 있었습니다. 에이전트의 비결정론적 (non-deterministic) 동작 때문에, 각 작업을 3회씩 실행하여 도메인당 총 90회의 실행을 수행했습니다. 점수는 통과한 테스트 횟수 / 총 90회 실행으로 표시됩니다. 성능이 테스트 통과율 10% 미만으로 떨어지면 해당 모델에 대한 테스트를 중단했습니다.

Calendar Scheduling 작업 (Calendar Scheduling Tasks)

이 그래프는 다양한 컨텍스트 크기(도메인 추가에 따른)에 따른 Calendar Scheduling 작업에서의 모델 성능을 비교합니다. 각 작업에는 최대 두 개의 스케줄링 도구 (scheduling tools) 사용만이 요구되었으나, 난이도를 높이기 위해 도메인이 추가될 때마다 모델이 선택할 수 있는 도구의 수를 점진적으로 늘렸습니다. Calendar Scheduling 도메인만 제공되었을 때, o1 (71%)과 o3-mini (68%)가 모든 모델 중 가장 우수한 성능을 보였습니다. 반면 gpt-4o와 llama-3.3-70B는 가장 낮은 성능을 보였으며, 특히 gpt-4o는 도메인이 7개로 증가한 후 성능이 급락했습니다 (2%), 그리고 llama-3.3-70B는 Calendar Scheduling 도메인만 제공되었을 때조차 필수적인 send_email 도구를 호출하는 데 실패했습니다 (0%). o3-mini의 성능은 관련 없는 도메인이 추가됨에 따라 급격히 하락한 반면, o1은 안정적인 상태를 유지했습니다. claude-3.5-sonnet은 초기에 저조한 성능을 보였으나, 컨텍스트가 추가됨에 따라 더 안정적인 모습을 보였습니다.

Calendar Scheduling 작업에서 gpt-4o는 다양한 컨텍스트 크기에 걸쳐 claude-3.5-sonnet, o1, o3보다 낮은 성능을 기록했습니다. gpt-4o의 성능은 더 큰 컨텍스트가 제공될 때 다른 모델들보다 더 급격히 떨어졌으며, 컨텍스트를 7개 도메인으로 늘렸을 때 2%까지 하락했습니다. 이와 유사하게, llama-3.3-70B는 사용자에게 응답하기 위한 실행의 마지막 단계로 send_email 도구를 호출하는 것을 기억하지 못하여 모든 테스트 케이스에서 실패했습니다. 대조적으로, claude-3.5-sonnet, o1, o3-mini는 모두 send_email 도구를 호출하는 것을 일관되게 기억했습니다.