Skip to content

멀티 에이전트 시스템을 평가하는 방법

멀티 에이전트 LLM 시스템을 평가하고, 실패를 책임 에이전트와 핸드오프에 귀인하며, 상호작용 그래프를 검토하고, 각 에이전트와 팀을 점수 매기는 실용 가이드입니다.

멀티 에이전트 시스템은 여러 LLM 에이전트(플래너, 코더, 리뷰어 등)가 하나의 작업에서 협력하는 것입니다. 이를 평가하는 것은 최종 답변을 점수 매기는 것 이상입니다. 중요한 실패가 에이전트 사이에서 일어나기 때문입니다. 핸드오프에서 떨어진 제약 조건, 엉뚱한 에이전트가 넘겨받는 일, 자기 작업을 결코 검증하지 않는 팀 같은 것들입니다. 유용한 판단 단위는 어느 에이전트, 어느 스텝, 어느 핸드오프인가입니다. Potato는 멀티 에이전트 실행을 사람이 평가하기 위한 오픈소스 도구로, 팀 구조를 위한 전용 어노테이션 화면 모음을 제공합니다.

여기서 멀티 에이전트 시스템이란 각각 역할을 가진 서로 다른 에이전트들이 메시지를 주고받고 제어를 넘기는 LLM 기반 워크플로를 의미합니다. 이런 시스템이 왜 실패하는지에 관한 연구(MAST 분류 체계, Why Do Multi-Agent LLM Systems Fail?)는 실패의 큰 비중이 에이전트 간에서 발생함을 발견합니다. 명세 문제, 에이전트 간 정렬 불일치, 누락된 검증입니다. 평탄한 트랜스크립트는 바로 그것들을 숨깁니다.

단일 에이전트 평가만으로는 왜 충분하지 않나요?

하나의 에이전트를 평가할 때는 단일한 사고, 도구 호출, 관찰의 시퀀스를 판단합니다. 팀은 오직 에이전트 사이에서만 존재하는 실패 양상을 더합니다.

  • 핸드오프 손실: 에이전트 A가 아는 제약 조건을 에이전트 B는 결코 전달받지 못합니다.
  • 잘못된 귀인: 실행은 실패하지만, 책임 에이전트는 오류가 드러난 지점보다 상류에 있습니다.
  • 협응 실패: 각 에이전트는 개별적으로 유능하지만, 팀은 맴돌거나 멈추거나 결코 검증하지 않습니다.
  • 자원 경합: 두 에이전트가 같은 도구나 파일을 동시에 건드려 데드락에 빠집니다.

최종 출력만 점수 매기면 팀이 실패했다는 사실은 알 수 있지만 어디서 실패했는지는 알 수 없습니다. 귀인이야말로 데이터를 디버깅이나 훈련에 유용하게 만드는 것입니다.

멀티 에이전트 실패를 어떻게 귀인하나요?

실패 귀인 문헌(Zhang et al., Which Agent Causes Task Failures and When?, ICML 2025)은 레이블을 삼중항으로 구성합니다. 책임 에이전트, 결정적 스텝, 그리고 이유입니다. Potato에서 failure_attribution 스키마는 에이전트와 스텝 선택기를 트레이스 자체로부터 채우므로, 어노테이터는 실제로 발생한 에이전트와 스텝 중에서 선택합니다.

yaml
annotation_schemes:
  - annotation_type: radio
    name: outcome
    description: "Did the system succeed?"
    labels: [success, failure]
  - annotation_type: failure_attribution
    name: attribution
    description: "If it failed: which agent, which step, and why?"
    steps_key: steps
    agent_key: agent

결과 스키마를 귀인과 짝지으면 삼중항은 실제로 실패한 실행에서만 수집됩니다.

트랜스크립트가 아니라 팀 구조를 어떻게 검토하나요?

두 화면이 구조를 보이게 만듭니다. 상호작용 그래프는 에이전트를 노드로, 핸드오프를 엣지로 렌더링하며, 어노테이터는 임계 경로를 표시하고 문제 있는 엣지를 표시합니다. 핸드오프 검토는 모든 제어 전이를 카드로 바꿔 정렬 불일치를 표시하고 품질을 평가하게 합니다.

yaml
annotation_schemes:
  - annotation_type: handoff_review
    name: handoffs
    description: "For each handoff: flag any misalignment and rate the quality."
    steps_key: steps
    agent_key: agent
    flags: [info_loss, dropped_constraint, garbling, goal_drift]
    quality_scale: 5

점수 매기기에는 agent_scorecard가 각 에이전트를 역할 충실도, 기여도, 협응으로 평가하고 팀을 그 자체의 차원으로 점수 매기므로, 협응이 부실한 팀 안의 유능한 개별 에이전트가 숫자로 드러납니다.

어떤 방법을 선택해야 하나요?

  • 파이프라인 디버깅: 실행이 어디서 깨지는지 위치를 찾기 위해 상호작용 그래프와 실패 귀인으로 시작하십시오.
  • 오케스트레이션 패턴 비교: 스코어카드를 추가해 같은 작업에서 순차 대 계층 대 그룹 채팅 설계를 점수 매기십시오.
  • 훈련 또는 보상 데이터 구축: 스텝 단위로 MAST 모드를 사용해 실패를 태깅하여(trajectory_eval를 통해) 레이블이 행동한 에이전트와 스텝에 붙도록 하십시오.
  • 동시성 버그: 트랜스크립트가 보여줄 수 없는 데드락과 경쟁 상태를 잡으려면 도구 경합 타임라인을 사용하십시오.

귀인에 대한 일치도는 다른 주관적 레이블과 동일하게 측정하십시오. 어노테이터 간 일치도를 참고하십시오.

더 읽어보기