Benchmarking Multi-Agent Architectures
TMThttps://blog.langchain.com/benchmarking-multi-agent-architectures/
이 블로그에서는 몇 가지 일반적인 멀티 에이전트 아키텍처를 살펴봅니다. 다양한 아키텍처의 동기와 제약을 논의합니다. Tau-bench 데이터셋의 변형을 사용해 이들의 성능을 벤치마크합니다. 마지막으로, 벤치마크에서 거의 50%의 성능 향상을 이끌어낸 “supervisor” 구현의 개선점에 대해 설명합니다.
멀티 에이전트 시스템의 동기
몇 달 전, 우리는 단일 에이전트 아키텍처가 도구 수와 기타 컨텍스트 크기가 증가함에 따라 얼마나 잘 확장되는지 벤치마크했습니다. 그 결과, 목표 작업과 무관한 컨텍스트가 늘어나도 성능이 크게 저하된다는 것을 발견했습니다. 더 많은 도구와 컨텍스트를 처리할 수 있도록 시스템을 확장하는 것은 멀티 에이전트 시스템의 일반적인 동기 중 하나입니다.
또 다른 동기는 엔지니어링 모범 사례를 따르기 위함입니다. 우리가 만난 많은 팀들은 더 모듈화된 구조로 인해 별도의 에이전트를 설계하는 것을 선호합니다. 이는 업데이트, 평가, 유지보수, 병렬화가 더 쉬워지기 때문입니다.
마지막 동기는 많은 에이전트가 서로 다른 개발자와 팀에 의해 개발된다는 점입니다. 이 경우, 단순한 단일 에이전트 아키텍처는 실현 가능하지 않을 수 있습니다. 각 에이전트가 고유한 기여를 할 수 있다면, 효과적인 멀티 에이전트 시스템은 개별 에이전트가 단독으로 할 수 있는 것보다 더 많은 것을 달성할 수 있습니다.
이러한 이유로, 우리는 멀티 에이전트 아키텍처가 점점 더 보편화될 것이라 생각합니다.
범용 vs 맞춤형 아키텍처
오늘날, 대부분의 멀티 에이전트 아키텍처를 구축하는 팀들은 특정 분야에 특화된 애플리케이션을 위해 이를 만듭니다. 우리가 현재 목격하는 멀티 에이전트 아키텍처의 대다수는 매우 맞춤화되어 있습니다. 이는 신중하게 설계된 맞춤형 인지 아키텍처가 해당 도메인에 대해 범용 아키텍처보다 더 나은 결과를 내기 때문입니다.
그럼에도 불구하고, 범용 멀티 에이전트 아키텍처는 몇 가지 이유로 흥미롭습니다.
시작의 용이성. 범용 멀티 에이전트 아키텍처는 멀티 에이전트 시스템을 더 쉽게 시작할 수 있게 해줍니다. 모든 통신이 “도구 호출”을 통해 이루어지는 단순한 에이전트 아키텍처는 애플리케이션 특화 워크플로우보다 성능 면에서는 떨어질 수 있지만, 시작점으로 사용하기에는 훨씬 쉽습니다.
“에이전트 직접 가져오기”. 범용 에이전트를 구축한다면, 다른 사람들이 “자신의 에이전트”를 가져오길 원할 수 있습니다. 이를 연결하려면 꽤 범용적인 아키텍처가 필요합니다. 우리는 MCP(“자신의 도구 가져오기”)를 통한 표준 API 연결에서 이 패턴이 실제로 적용되는 것을 보았습니다. 클로드(Claude), 커서(Cursor) 등 클라이언트가 MCP 도구를 사용하는 방식은 범용적입니다. 우리는 에이전트에서도 이와 비슷한 일이 일어날 것이라 상상합니다.
그렇다면, 최고의 범용 멀티 에이전트 아키텍처는 무엇일까요?
데이터
우리는 **Yao 등(τ-bench)**이 만든 τ-bench(link의 수정 버전을 사용해 실험을 진행했습니다. τ-bench는 실제 시나리오(소매 고객 지원, 항공권 예약 등)에서 다양한 단일 에이전트 인지 아키텍처/프롬프트 전략을 테스트하기 위해 설계되었습니다. 우리가 수정한 데이터셋과 실험 코드는 multi-agent bench 저장소에서 확인할 수 있습니다.
멀티 에이전트 시스템이 더 복잡한 도메인으로 확장되는 방식을 효과적으로 테스트하기 위해, 데이터셋에 6개의 추가 환경(홈 인테리어, 기술 지원, 약국, 자동차, 레스토랑, Spotify 플레이리스트 관리)을 추가했습니다. 각 환경에는 해당 도메인에서 상호작용을 돕는 19개의 개별 도구와 도메인 관련 지침이 담긴 “위키”가 포함되어 있습니다. 이들 합성 도메인은 원래 데이터셋의 작업을 완료하는 데 필요하지도, 유용하지도 않습니다. 이 환경들은 오직 현실적인 “방해 요소”로 설계되어, 각 에이전트 설정이 불필요한 도구와 지침이 제공될 때 얼마나 잘 수행되는지 테스트합니다.
우리는 τ-bench의 소매 도메인 테스트 분할에서 처음 100개의 예제를 대상으로, 에이전트에게 점점 더 많은 방해 환경을 제공하며 각 시스템이 추가 컨텍스트를 어떻게 균형 있게 처리하는지 보여주었습니다. 이는 일반적인 에이전트 시스템이 얼마나 확장 가능한지 “최상의 성능”을 테스트하는 것입니다. “최상의 성능”이라고 부르는 이유는, 보조 도메인이 각 작업을 성공적으로 완료하는 데 필요하지 않기 때문입니다. 실제로 테스트 케이스를 통과하는 데 필요한 조정은 거의 없으며, 시스템이 취할 수 있는 전체 행동 집합에서 무관한 도구와 지침을 걸러내는 것만 필요합니다.
실험
우리는 세 가지 다른 아키텍처로 실험을 진행했습니다. 모든 실험에서 gpt-4o 모델을 사용했습니다.
참고: 애플리케이션의 제약에 따라, 이들 아키텍처 중 일부는 실현 불가능할 수 있습니다. 항상 목표(성공의 정의)와 제약에서 출발해 디자인 패턴을 선택하길 권장합니다.
Single Agent(단일 에이전트)
이 아키텍처는 하나의 프롬프트와 모든 도메인의 도구 및 지침에 접근할 수 있는 도구 호출 에이전트입니다. 우리가 개선하고자 하는 기준선입니다.
구현에는 LangGraph의 create_react_agent를 사용했습니다.
참고: 이 아키텍처는 모든 경우에 실현 가능하지 않을 수 있습니다. 예를 들어, 하위 도메인 중 하나를 타사 에이전트가 처리하길 원한다면, 단일 에이전트로는 불가능합니다.
Swarm(스웜)
이 아키텍처에서는 각 하위 에이전트가 그룹(스웜) 내의 다른 모든 에이전트를 인지하고, 서로에게 작업을 넘길 수 있습니다. 에이전트가 응답하면, 그 응답이 바로 사용자에게 전달됩니다. 한 번에 하나의 에이전트만 활성화될 수 있으며, 활성화된 에이전트는 다른 에이전트에게 작업을 넘길 때까지 계속 활성화 상태를 유지합니다.
구현에는 LangGraph의 langgraph-swarm 패키지를 사용했습니다.
참고: 이 아키텍처 역시 모든 경우에 실현 가능하지 않을 수 있습니다. 각 하위 에이전트가 아키텍처 내의 모든 다른 에이전트를 알아야 하며, 타사 에이전트와 함께 작업할 경우 이는 불가능할 수 있습니다. 또한, 타사 에이전트가 사용자와 상호작용할 때 계속 “활성화” 상태로 남아있길 원하지 않을 수도 있습니다.
Supervisor(감독자)
이 아키텍처에서는 단일 “supervisor(감독자)” 에이전트가 사용자 입력을 받아 하위 에이전트에게 작업을 위임합니다. 하위 에이전트가 응답하면, 제어권이 다시 supervisor 에이전트로 돌아옵니다. 오직 supervisor 에이전트만 사용자의 질문에 응답할 수 있습니다.
구현에는 LangGraph의 langgraph-supervisor 패키지를 사용했습니다.
참고: 이 아키텍처는 하위 에이전트에 거의 아무런 가정도 하지 않으므로, 모든 멀티 에이전트 시나리오에 적용 가능합니다.
결과 및 분석
우리는 두 가지 차원에서 결과를 보여줍니다:
- 점수: Tau Bench에서 사용하는 XYZ로 측정
- 비용(토큰): 각 실험에서 사용된 토큰 수
점수
단일 에이전트 기준선은 방해 도메인이 두 개 이상일 때 성능이 급격히 떨어집니다. 방해 도메인이 하나일 때는 단일 에이전트가 약간 더 좋은 성능을 보입니다.
스웜 아키텍처는 전반적으로 supervisor 아키텍처보다 약간 더 좋은 성능을 보입니다. 데이터를 보면, supervisor 아키텍처의 성능 저하는 “번역(translation)” 과정에서 발생합니다. supervisor 아키텍처에서는 하위 에이전트가 사용자에게 직접 응답할 수 없고, 스웜 아키텍처에서는 가능하기 때문입니다. “전화 게임(telephone)”을 해본 적 있다면, 이 문제에 익숙할 것입니다!
비용(토큰)
단일 에이전트는 방해 도메인 수가 늘어날수록 일관되게 더 많은 토큰을 사용합니다. 반면, supervisor와 swarm은 토큰 사용량이 일정하게 유지됩니다.
supervisor는 swarm보다 항상 더 많은 토큰을 사용합니다. 이 역시 supervisor가 “번역”을 수행하기 때문입니다. supervisor 아키텍처에서는 하위 에이전트가 사용자에게 직접 응답할 수 없고, swarm 아키텍처에서는 가능하기 때문입니다.
supervisor의 개선점
초기 supervisor 접근법은 성능이 매우 저조했습니다. 몇 가지 변경을 거친 후에야 성능이 향상되었습니다.
아래는 이전 supervisor 구현이 포함된 차트입니다:
supervisor 아키텍처의 성능 문제 대부분은 supervisor 에이전트가 하위 에이전트와 사용자 사이에서 “전화 게임”을 하면서 발생했습니다. 우리가 적용한 대부분의 변경점은 이 전화 게임의 영향을 줄이기 위한 것이었습니다.
참고: 이 모든 변경점은 최신 버전의 langgraph_supervisor에 옵션으로 포함되어 있습니다.
handoff 메시지 제거
하위 에이전트의 상태에서 handoff 메시지를 제거해, 할당된 에이전트가 supervisor의 라우팅 로직을 볼 필요가 없게 했습니다. 이는 하위 에이전트의 컨텍스트 윈도우를 정리해, 본연의 작업을 더 잘 수행할 수 있게 해줍니다. 최신 모델에서도 컨텍스트 내의 잡음은 에이전트 신뢰성에 큰 영향을 미칠 수 있습니다.
메시지 전달(forwarding messages)
supervisor에게 forward_message 도구를 제공해, 하위 에이전트의 응답을 전체 내용을 재생성하지 않고 바로 사용자에게 “전달”할 수 있게 했습니다. supervisor가 하위 에이전트의 응답을 잘못 바꿔 전달하는 오류를 줄였습니다.
도구 이름 지정(tool naming)
supervisor가 하위 에이전트에게 작업을 넘길 때 호출하는 도구 이름(“delegate_to_<agent>” vs “transfer_to_<agent>”)의 다양한 표현을 테스트했습니다.
향후 과제
우리가 탐구하고 싶은 다음 단계는 다음과 같습니다.
에이전트 간 다중 홉(multi-hop across agents)
현재는 모든 질문이 단일 하위 에이전트의 응답만 필요합니다. 여러 하위 에이전트가 필요한 질문에서의 성능을 탐구하고 싶습니다.
단일 에이전트 성능과의 격차 해소
왜 swarm과 supervisor는 방해 도메인이 하나일 때 단일 에이전트만큼 성능이 나오지 않을까요? 주요 오류는 “번역” 실수와 handoff로 인한 추가 컨텍스트에서 비롯되었습니다. 어느 정도 줄이긴 했지만, 여전히 단일 에이전트보다 성능이 떨어집니다. 이 격차를 줄이려면 무엇을 할 수 있을까요?
“번역” 계층 건너뛰기
supervisor의 실수 대부분은 supervisor 에이전트만 사용자에게 응답할 수 있는 “번역” 계층에서 발생합니다. 작업 위임과 전체 작업 컨텍스트를 보장하면서, 이 번역 계층을 더 효과적으로 건너뛸 방법이 있을까요?
다른 아키텍처
더 나은 결과를 낼 수 있는 다른 아키텍처가 있을까요? “agents-as-tools”와 비교하면 어떨까요?
결론
우리는 멀티 에이전트 시스템이 점점 더 보편화될 것이라 생각합니다. 오늘날 성공적인 멀티 에이전트 시스템의 대부분은 비교적 맞춤화된 아키텍처를 가지고 있지만, 모델이 발전함에 따라 범용 아키텍처도 개발의 용이성이라는 장점이 성능 약점을 상쇄할 만큼 충분히 신뢰할 수 있게 될 것이라 생각합니다. supervisor 아키텍처는 가장 범용적인 아키텍처(하위 에이전트에 대한 가정이 가장 적음)이지만, 단순한 supervisor 구현은 더 나쁜 결과를 낼 수 있습니다. 하위 에이전트와 사용자 간 정보 전달 방식(및 컨텍스트 관리 방식)을 개선하면, 여러 도메인에 걸쳐 확장성을 유지하면서도 더 나은 성능을 낼 수 있습니다. 우리가 langgraph-supervisor에 제공한 개선점을 활용해, LangSmith 같은 도구로 자신의 데이터에서 시스템을 평가해볼 수 있습니다.
supervisor 아키텍처를 쉽게 시도해보고 싶다면(이 연구 결과로 도입된 모든 개선점 포함), langgraph-supervisor로 간단히 시작할 수 있습니다.