Review

TL; DR

Summary

Motivation

• Coding, research 등 다양한 분야에서 LLM multi agent system을 사용하고 있는데, 시스템이 실패했을 때 원인 분석을 찾는건 여전히 수동적이고 시간이 많이 듦
  • ex) 바이브 코딩할 때 원하는대로 동작 안하면 결국 사람이 일일히 코드 읽어봐야 함

• 실패 분석은 긴 로그 속에서 어떤 에이전트가 어떤 시점에서 잘못했는지 알아내야 함!

  → 이걸 LLM이 자동으로 할 수 있게 해보자

Contribution

• Problem Definition
  • LLM multi agent system이 언제 어디서 잘못했는지를 식별하는 문제 제기

• Banchmark: Who&When
  • 에이전트 시스템의 실패를 분석한 벤치마크 구축

• Can LLMs help identify When and Which agent causes task failures?
  • LLM이 자동으로 실패 분석을 얼마나 잘하는지 평가 및 분석

Problem Definition

• LLM Multi agent system
  • $M = (\mathcal{N}, S, A, P, \phi)$

    • N: 에이전트 개수

    • S: 상태(state) 집합

    • A: 행동(action) 집합
      • 각 에이전트 $i$는 행동 집합의 부분집합 $A_i$ 에서 행동 가능

    • $P(s_{t+1}|s_t, a_t, \phi(t))$ : 시간 t에 $\phi(t)$만 행동한다는 조건에서의 상태 전이 확률

    • $\phi(t)$: 시간 단계 t에서 행동하는 에이전트

• Trajectory
  • $\tau = (s_0, a_0, s_1, a_1, ..., s_T)$
  • Trajectory 내 실수를 $(i, t)$로 나타냄
    • 시간 $t$에서 $i$ 에이전트가 한 $a_t$가 오류인 것

• Trajectory result fuction
  • $Z(\tau) = \begin{cases} 1, & \text{if the system ultimately fails,} \\ 0, & \text{otherwise.} \end{cases}$
  • 실패하면 1, 아니면 0

• 결정적인 오류
  • $t$ 시간에서 에이전트 $i$의 행동을 교정한 trajectory
    • $\tau^{(i,t)} = \mathcal{I}_{(i,t)}(\tau)$
  • 교정해서 해결되면 $\Delta_{i,t}(\tau)$=1 아니면 0
    • $\Delta_{i,t}(\tau) = \begin{cases} 1, & \text{if } Z(\tau)=1 \text{ and } Z(\tau^{(i,t)})=0 \\ 0, & \text{otherwise} \end{cases}$
  • $\Delta_{i,t}(\tau)$=1를 만족하는 $(i, t)$가 결정적인 오류들임!
    • $C(\tau) = \{(i, t) | \Delta_{i,t}(\tau) = 1\}$

• Problem
  • 가장 먼저 발생한 결정적인 오류를 찾자
  • $(\hat{i}, \hat{t }) = \underset{(i,t) \in C(\tau)}{\arg\min} \ t$

Banchmark: Who&When

• LLM Multi Agent System에서 오류가 난 경우 누가 (Who) 언제 (When) 오류를 만들었는지 식별하는
  벤치마크 제안
  • 127개의 LLM Multi Agent System에서 수집한 로그 포함

    • 2가지 종류의 에이전트 시스템 사용
      • Algorithm-Generated Agentic Systems
        • CaptainAgent 알고리즘: 주어진 태스크(GAIA, Assistant Bench)에 맞춤화된 에이전트 팀을 구성하고, 적절한 에이전트 이름, 프롬프트 및 필요한 도구를 할당
        • 각 쿼리에 대해 최적화된 솔루션을 나타내는 최종 멀티 에이전트 구성과 해당 실행 기록만을 선택
        • 실패한 케이스만 벤치마크에 포함시킴
      • Hand-Crafted Agentic Systems
        • Magnetic-One: 웹 브라우저 조작이나 로컬 파일 탐색과 같은 고유한 기능에 특화된 5개의 정교하게 제작된 에이전트로 구성
        • GAIA, Assistant Bench에서 Magnetic-One 평가하고 실패 로그를 벤치마크에 포함시킴
  • 184개의 Failure Annotation Tasks(실패 주석)으로 이루어짐

    • 3명의 에이전트 전문가들이 multi round annotation함
      • round 1: 모든 실패 로그를 전문가한테 분배 후 언제 누가 오류를 냈는지, 오류 이후의 추론에 대해 주석 처리함, 그리고 확실한지 불확실한지 분류
      • round 2: 불확실한 것들에 대해 합의 도출(만장일치까지)
      • round 3: 각 전문가가 남긴 주석 간 교차 검증

      

      • a는 각 전문가가 걸린 시간인데 30.9, 30.2, 23.2시간 씀
      • b는 확실한 것 불확실한 것 비율인데, 가장 큰 오류를 고르는 것은 어려워서 불확실한 주석 비율이 좀 있음
      • c는 서로의 불확실한 데이터에 대해 투표할 때 개인 간의 불일치율, 개인차가 좀 있음
  • 각 데이터 인스턴스는 쿼리, 실패 로그, 에이전트 시스템 정보, 주석을 포함함

    • 쿼리: 벤치마크에서 가져온 현실 세계에서의 질문

    • 실패 로그: 특정 시스템이 쿼리를 해결하는 데 실패했을 때의 전체 에이전트 대화 로그

    • 에이전트 시스템 정보: Algorithm-Generated Agentic Systems의 경우, 해당 쿼리에 맞춰 조정된 시스템 프롬프트, tools, 에이전트 이름 등을 포함

    • 주석: 태스크 실패에 책임이 있는 에이전트, 실패가 발생한 단계, 그리고 실패 이유에 대한 평이한 언어 설명을 포함

    • 데이터 예시

      

• Metric
  • 에이전트 수준 정확도: 누가 틀렸는지 맞추기
  • 단계 수준 정확도: 언제 틀렸는지 맞추기
  • 허용 오차를 포함한 단계 수준 정확도: 조금 널널하게 언제 틀렸는지 맞추기

Can LLMs help identify When and Which agent causes task failures?

• LLM(GPT-4o)을 사용해 자동으로 실패 분석 해보기
  • 3가지 approach
    • All-at-once: LLM에게 쿼리랑 전체 실패 로그 주고, 누가 언제 틀렸는지 식별하기
    • Step-by-step: LLM에게 쿼리 제공하고, 실패 로그를 step별로 제시함. LLM은 현재 step에서 틀렸는지 안 틀렸는지 판단함
    • Binary search: 전체 실패 로그로 시작해, 로그의 앞쪽에서 실패했는지, 뒤쪽에서 실패했는지 LLM이 판별, 판별된 로그를 다시 반으로 나누어 단일 step이 남을 때까지 반복함
  • 2가지 setting
    • With Ground Truth (Oracle): 쿼리의 최종 정답을 알고있는 세팅
    • Without Ground Truth : 쿼리의 정답을 모르는 채 실패를 찾는 세팅

• 결과
  • 로그 전체 주면 누가 틀렸는지 잘 알고, 세밀하게 주면 언제 틀렸는지 잘 알게 됨

    

    • Oracle 세팅이 꽤 유용함

  • 로그 길이가 길어지면 성능 떨어짐

    

    • 오류 step 예측하는게 더 성능 빠르게 떨어짐
  • 오류 step 예측에서 정답과의 오차 비교

    

  • 오차 허용을 크게 시켜줄수록 All-at-once가 강점을 가짐

    

  • 단일 데이터보다 크게 봤을 때 자주 틀리는 놈을 알기 쉬움

    • 3번 에이전트가 오류쟁이인데, 통계적으로 3번 에이전트가 문제라고 많이 꼽음

    

  • 하이브리드(All-at-once로 누가 오류냈는지 판정 후 step-by-step으로 어디서 오류났는지 판별)하면 더 잘함

    • 대신 계산비용이 높음

    

  • 더 강력한 추론모델이라고 항상 뛰어난건 아님; 별로 실용적이지 않음

    

    • 대신 프롬프트에서 추론하라고 하면 잘함