• 에이전트 리더보드: 다중 도메인 시나리오에서의 AI 에이전트 평가
  • 기존 에이전트 평가 리더보드와의 차별점은? 🎯
  • 핵심 인사이트 💡
  • 도구 호출의 복잡성 ⚙️
  • 방법론 🔍
  • 에이전트 성능은 어떻게 측정하나? 📊
    • 평가 방식: TSQ 지표를 통한 LLM-Judge
      • 1. 데이터 로드
      • 2. ChainPoll 방식의 Scorer 설정
      • 3. 평가 핸들러 설정
      • 4. LLM 초기화
      • 5. 시스템 메시지 정의
      • 6. 대화별 LLM 실행 및 평가
      • 7. 평가 종료
    • 왜 도구 호출 평가에 LLM이 필요한가?
  • 데이터셋 구성 📁
    • 1️⃣ 단일 턴(Single-Turn) 능력
    • 2️⃣ 오류 처리 및 엣지 케이스
    • 3️⃣ 맥락 관리 (Context Management)
    • 4️⃣ 멀티 턴(Multi-Turn) 상호작용
    • 5️⃣ 매개변수 관리 (Parameter Management)
  • AI 엔지니어를 위한 실용적 시사점 🛠️
    • 1️⃣ 모델 선택과 성능
    • 2️⃣ 맥락 및 오류 관리
    • 3️⃣ 안전성과 신뢰성
    • 4️⃣ 시스템 성능 최적화
    • 5️⃣ 현재 AI 모델의 수준
  • 인용 📄
  • 모델 성능에 대한 추가 인사이트 📈
    • 추론 모델 (Reasoning Models)
    • 1️⃣ 엘리트 등급 성능 (Elite Tier Performance, ≥ 0.9)
    • 2️⃣ 고성능 세그먼트 (High Performance Segment, 0.85~0.9)
    • 3️⃣ 중간 등급 모델 (Mid Tier Capabilities, 0.8~0.85)
    • 4️⃣ 기본 등급 모델 (Base Tier Models, <0.8)
  • 감사의 글 🙏

이 글은 Hugging Face 블로그의 Agent Leaderboard: Evaluating AI Agents in Multi-Domain Scenarios를 한국어로 번역한 글입니다.

에이전트 리더보드: 다중 도메인 시나리오에서의 AI 에이전트 평가

젠슨 황(Jensen Huang)은 AI 에이전트를 “디지털 노동력(digital workforce)”이라고 불렀습니다. 이러한 의견은 그만의 생각이 아닙니다. 사티아 나델라(Satya Nadella) 역시 에이전트가 비즈니스 운영 방식을 근본적으로 바꿀 것이라고 믿고 있습니다.

이러한 에이전트들은 외부 도구 및 API와 상호작용할 수 있어, 실질적인 응용 가능성을 크게 확장합니다. 그러나 여전히 완벽함과는 거리가 멀며, 복잡한 상호작용 때문에 에이전트들의 성능을 평가하는 일은 어렵습니다.

우리의 에이전트 리더보드(Agent Leaderboard)는 Galileo의 도구 선택 품질(Tool Selection Quality, 이하 TSQ) 지표를 사용해 다방면으로 LLM들이 도구 기반 상호작용을 어떻게 처리하는지 명확히 평가합니다.

우리가 이 리더보드를 만든 이유는 단순합니다: “AI 에이전트는 실제 비즈니스 시나리오에서 얼마나 잘 작동하는가?”
학술적 벤치마크가 기술적 역량을 알려준다면, 우리는 다양한 실제 사용 사례에서 어떤 모델이 유용한지를 알고자 합니다.

기존 에이전트 평가 리더보드와의 차별점은? 🎯

huggingface.co/spaces/galileo-ai/agent-leaderboard

기존 평가 프레임워크들은 특정 영역에 집중되어 있습니다. BFCL은 수학·엔터테인먼트·교육 등 학술 영역에 강하고, τ-bench는 소매 및 항공 시나리오에 특화되어 있으며, xLAM은 21개 도메인에 걸친 데이터 생성에 초점을 맞춥니다. ToolACE는 390개 도메인에서의 API 상호작용에 중점을 둡니다. 우리의 리더보드는 이러한 데이터셋들을 통합해 다중 도메인 및 실제 사용 사례를 포괄하는 종합 평가 프레임워크를 제공합니다.

우리는 다양한 벤치마크와 테스트 시나리오를 통합하여 모델들이 예외 사항과 안전성을 어떻게 다루는지에 대한 실질적인 통찰을 제공합니다. 또한 비용 효율성, 구현 가이드라인, 비즈니스 영향력 등을 분석하여 실제 조직에서 AI 에이전트를 배포할 때 필수적인 정보를 제공합니다. 즉, 각 팀이 자신들의 에이전트 요구사항과 제약 조건에 가장 적합한 모델을 선택할 수 있도록 돕는 리더보드입니다.

새로운 LLM들이 매우 자주 출시되므로, 우리는 매달 벤치마크를 업데이트하여 최신 모델 출시와 동기화할 예정입니다.

핵심 인사이트 💡

우리가 분석한 17개의 주요 LLM은 실제 업무 과제에서 에이전트가 어떻게 작동하는지 흥미로운 패턴을 보여주었습니다. 우리는 14개 다양한 벤치마크를 기반으로, 간단한 API 호출부터 복잡한 다중 도구에 대한 상호작용까지 폭넓게 강도 높은 테스트를 수행했습니다.

그 결과는 기존의 모델 성능에 대한 통념을 깨고, AI 에이전트를 구축하는 팀들에게 실질적인 인사이트를 제공할 수 있습니다.

도구 호출의 복잡성 ⚙️

도구 호출의 복잡성은 이제 단순한 API 호출 수준을 훨씬 넘어섰습니다. 다양한 시나리오에서 AI 에이전트는 도구를 언제 사용할지, 어떤 도구가 적합한지, 어떻게 사용해야할지 올바르게 판단해야 합니다.

이를 정교하게 평가하기 위해, 도구 호출 과정에서 고려해야할 핵심 요소를 시나리오 인식(Scenario Recognition), 도구 선택의 역학(Tool Selection Dynamics), 매개변수 처리(Parameter Handling), 순차적 의사결정(Sequential Decision Making) 네 가지로 살펴볼 수 있습니다.

이러한 복잡성 때문에 도구 선택 품질(TSQ)은 단순한 지표가 아니라 실제 시나리오에서 에이전트의 의사결정 능력을 다면적으로 평가하는 척도입니다.

방법론 🔍

우리의 평가 프로세스는 AI 에이전트를 공정하고 체계적으로 평가하기 위해 다음과 같은 단계를 따릅니다.

1. 모델 선정(Model Selection): 상용 및 오픈소스 모델을 포함해 다양한 언어 모델을 선정합니다. 이를 통해 현존 기술의 폭넓은 스펙트럼을 반영합니다.

2. 에이전트 구성(Agent Configuration): 각 모델을 표준화된 시스템 프롬프트를 사용해 에이전트로 구성하고, 동일한 도구 세트에 접근할 수 있도록 설정합니다. 이러한 표준화는 성능 차이가 프롬프트 설계의 차이가 아닌, 모델 고유의 능력을 반영하게 됩니다.

3. 평가 지표 정의(Metric Definition): 도구 선택의 정확성과 매개변수 사용의 질을 모두 평가하는 도구 선택 품질(TSQ)을 주요 지표로 설정합니다. 이 지표는 실제 환경에서 요구되는 성능을 포착하도록 신중하게 설계되었습니다.

4. 데이터셋 구성(Dataset Curation): 기존 벤치마크 데이터셋을 전략적으로 샘플링하여 균형 있고 다중 도메인을 아우르는 평가용 데이터셋을 만듭니다. 이 데이터셋은 기본 함수 호출부터 복잡한 멀티 턴 상호작용까지 모두 테스트할 수 있어 에이전트 능력을 포괄적으로 평가합니다.

5. 점수 체계(Scoring System): 최종 성능 점수는 모든 데이터셋에 대해 동일한 가중치로 산출한 평균을 계산합니다. 이를 통해 특정 능력 하나가 전체 평가를 좌우하지 않으며, 에이전트 성능을 균형있게 보여줄 수 있습니다.

이와 같은 구조화된 접근 방식을 통해, 우리는 평가 결과를 실제 구현 의사결정에 직접 적용할 수 있는 통찰을 제공합니다.

에이전트 성능은 어떻게 측정하나? 📊

평가 방식: TSQ 지표를 통한 LLM-Judge

앞서 본 것처럼, 도구 호출 평가는 다양한 시나리오에서의 견고한 측정이 필요합니다. 우리는 도구 선택 품질(TSQ) 지표를 통해, 에이전트의 도구 선택 정확도와 매개변수 활용 효율성을 평가했습니다. 이 프레임워크는 에이전트의 도구 사용이 적절한지, 불필요한 도구 사용은 없는지를 모두 검증합니다.

평가는 GPT-4o + ChainPoll을 사용하여 수행됩니다. 각 상호작용마다 여러 개의 독립적인 판단이 수집되며, 최종 점수는 긍정적 평가 비율로 계산됩니다. 모든 판단에는 상세한 설명이 포함되어 투명성을 확보합니다.
*ChainPoll: 언어 모델에서 발생하는 환각(hallucination)을 식별하기 위한 방법으로, CoT 기법을 활용해 추론 과정을 단계별로 나누어 모델 출력의 신뢰도를 평가함.

1. 데이터 로드

• 평가 대화 데이터 로드 (사용자 메시지, 시스템 메시지 등의 대화 기록 포함)

  df = pd.read_parquet(file_path, engine="fastparquet")
  

2. ChainPoll 방식의 Scorer 설정

• CustomizedChainPollScorer: ChainPoll 방식을 이용한 커스텀 scorer
  • 평가항목으로 tool_selection_quality을 선정하여 LLM이 선택한 도구가 적절했는지 평가
• Judge 모델: GPT‑4o 사용

  chainpoll_tool_selection_scorer = pq.CustomizedChainPollScorer(
                scorer_name=pq.CustomizedScorerName.tool_selection_quality,
                model_alias=pq.Models.gpt_4o,
            )
  

3. 평가 핸들러 설정

• GalileoPromptCallback: 평가 과정에서 ChainPoll 점수를 기록하고 관리
  • scorers에 ChainPoll scorer를 넣어 LLM이 도구 선택 시 평가하도록 함

evaluate_handler = pq.GalileoPromptCallback(
        project_name=project_name,
        run_name=run_name,
        scorers=[chainpoll_tool_selection_scorer],
    )

4. LLM 초기화

• 평가에 사용할 LLM을 초기화
  • temperature=0.0: deterministic (같은 입력에 항상 같은 출력)
  • max_tokens=4000: 응답 최대 길이

llm = llm_handler.get_llm(model, temperature=0.0, max_tokens=4000)

5. 시스템 메시지 정의

• LLM에게 도구 사용 규칙과 대화 지침을 제공

  system_msg = {
    "role": "system",
    "content": (
        "당신의 임무는 주어진 도구를 사용해 사용자의 질문에 답하는 것입니다. "
        "관련 도구가 없으면 '주어진 도구로는 대답할 수 없습니다.'라고 응답하세요. "
        "필요한 정보가 부족하면 사용자에게 요청하세요. "
        "필요한 경우 여러 도구를 호출할 수 있습니다. 순차 호출이 필요하면 첫 번째 도구부터 호출하세요."
    ),
  }
  

6. 대화별 LLM 실행 및 평가

• bind_tools(tools) → LLM에 도구 접근 권한 바인딩
• chain.invoke([...]) → 시스템 메시지 + 대화 내역을 LLM에 입력, 출력 생성
• callbacks=[evaluate_handler] → ChainPoll scorer가 실시간 평가 수행
• LLM 응답과 ChainPoll 평가 결과를 outputs에 저장

outputs = []

for row in df.itertuples():
    chain = llm.bind_tools(tools)
    outputs.append(
        chain.invoke(
            [system_msg, *row.conversation], 
            config=dict(callbacks=[evaluate_handler])
        )
    )

7. 평가 종료

• 모든 대화 평가가 끝난 후 점수 정리 및 로그 저장

evaluate_handler.finish()

왜 도구 호출 평가에 LLM이 필요한가?

LLM 기반 평가(LLM-Judge)는 다양한 시나리오에서 에이전트의 도구 사용 능력을 종합적으로 검증할 수 있습니다.

• 맥락 부족 상황: 에이전트가 맥락 부족 상황을 적절히 처리하는지 확인. 도구 사용 전에 추가 정보가 필요한지 판단하고, 필요 시 추가 정보 요청 여부 검증
• 다중 도구 시나리오 상황: 필요한 모든 도구가 식별되고 올바른 순서로 사용되는지 확인
• 긴 대화 맥락 상황: 이전 대화에서 나온 관련 정보를 고려하는지 확인
• 도구가 없거나 부적절한 경우: 에이전트가 도구 사용을 억지로 하지 않고 올바르게 사용을 자제하는지 확인

에이전트가 적절한 도구를 선택하고, 정확한 매개변수를 제공하며, 여러 도구를 효과적으로 조율하고, 불필요한 도구 사용까지 자제할 경우 이러한 지표를 모두 성공적으로 수행했다고 볼 수 있습니다.

데이터셋 구성 📁

이 평가 프레임워크는 BFCL, τ-bench, Xlam, ToolACE의 신중하게 선별된 벤치마크 데이터셋을 사용합니다. 각 데이터셋은 에이전트의 특정 능력을 검증하도록 설계되었으며, 평가 차원을 이해하는 것은 모델 평가와 실제 응용 개발 모두에서 필수적입니다.

1️⃣ 단일 턴(Single-Turn) 능력

2️⃣ 오류 처리 및 엣지 케이스

3️⃣ 맥락 관리 (Context Management)

4️⃣ 멀티 턴(Multi-Turn) 상호작용

5️⃣ 매개변수 관리 (Parameter Management)

AI 엔지니어를 위한 실용적 시사점 🛠️

우리의 평가 결과는 견고하고 효율적인 AI 에이전트 시스템을 구축할 때 고려해야 할 핵심 사항을 보여줍니다. 핵심 포인트를 나눠보면 다음과 같습니다.

1️⃣ 모델 선택과 성능

복합 작업에서 0.85 이상의 점수를 기록하는 고급 모델은 복잡한 워크플로우를 처리하는 데 중요합니다. 대부분의 모델은 기본적인 도구 작업은 잘 수행하지만, 병렬 작업을 다룰 때는 전체 점수보다 개별 태스크별 실행 성능을 세밀히 살펴야 합니다.

2️⃣ 맥락 및 오류 관리

맥락 요약(context summarization) 전략은 긴 문맥 처리에 약한 모델에서 필수적입니다. 오류 처리 메커니즘은 무관성 감지나 매개변수 처리에서 약점을 보이는 모델에 특히 중요합니다. 이 경우 구조화된 워크플로우를 구현해 매개변수 수집 과정을 보완하는 것이 좋습니다.

3️⃣ 안전성과 신뢰성

무관한 동작을 감지하지 못하는 모델을 위해 도구 접근 제어를 강화해야 합니다. 성능이 불안정한 모델은 검증(validation) 계층을 추가하여 신뢰성을 높일 수 있습니다. 또한, 오류 복구 시스템(error recovery system)을 구축하는 것도 중요합니다.

4️⃣ 시스템 성능 최적화

각 모델의 병렬 처리 및 긴 맥락 처리 능력에 맞춰 워크플로우를 설계하세요. 배치 전략(batch strategy)을 구현할 때는 모델의 도구 재사용 능력을 고려하는 것이 효율성 향상에 도움이 됩니다.

5️⃣ 현재 AI 모델의 수준

현재는 상용(proprietary) 모델이 전반적인 능력에서 우위를 점하고 있지만, 오픈소스 대안(open-source alternatives) 또한 빠르게 발전하고 있습니다. 간단한 도구 상호작용은 대부분의 모델에서 안정적으로 작동하지만, 복잡한 멀티 턴 상호작용과 긴 문맥 처리는 여전히 도전 과제로 남아 있습니다.

이러한 다양한 성능 차이는 특정 사용 사례에 맞는 모델 선택이 중요함을 보여줍니다. 즉, 일반적인 성능 지표보다는 실제 적용 맥락에 기반해 모델을 선택해야 합니다.

우리는 이 정보가 도움이 되길 바라며, LinkedIn, Twitter, 그리고 GitHub에서 여러분의 의견을 기다리고 있습니다.

인용 📄

아래 방식으로 리더보드를 인용할 수 있습니다:

@misc{agent-leaderboard,
  author = {Pratik Bhavsar},
  title = {Agent Leaderboard},
  year = {2025},
  publisher = {Galileo.ai},
  howpublished = "\url{https://huggingface.co/spaces/galileo-ai/agent-leaderboard}"
}

모델 성능에 대한 추가 인사이트 📈

추론 모델 (Reasoning Models)

우리의 분석에서 주목할 만한 점은 추론 중심(reasoning-focused) 모델들이었습니다. o1과 o3-mini는 각각 0.876과 0.847의 성능으로 함수 호출(Function Calling) 기능을 매우 훌륭하게 통합한 것으로 나타났습니다. 그러나 다른 추론 모델들에서는 상당한 어려움을 발견했습니다. 특히 DeepSeek V3와 DeepSeek R1은 전반적인 성능이 매우 뛰어남에도 불구하고, 함수 호출 기능 지원의 한계로 인해 리더보드에서 제외되었습니다.

이 결정은 모델의 품질이 낮아서가 아니라, 두 모델 모두 공식 문서에서 현재 릴리즈 버전에서는 함수 호출을 지원하지 않는다고 명확히 명시하고 있습니다. 우리는 억지로 우회 기능을 구현하거나 오해의 소지가 있는 지표를 공개하기보다는, 함수 호출이 기본적으로 지원되는 향후 출시를 기다리기로 결정했습니다.

이 경험은 함수 호출(function calling)이 모든 고성능 언어 모델에 자동으로 포함된 일반 기능이 아니라, 명시적으로 설계되고 학습되어야 하는 특수 기능임을 보여줍니다. 즉, 뛰어난 추론 능력을 가진 모델이라 하더라도, 구조적 함수 호출을 수행하려면 해당 기능에 대한 명시적 설계와 학습이 필요합니다. 따라서 모델을 선택하기 전에 자신의 사용 사례(use case)에 맞게 모델을 직접 평가하는 것이 가장 바람직합니다.

1️⃣ 엘리트 등급 성능 (Elite Tier Performance, ≥ 0.9)

• 특징: 높은 성능과 안정적 일관성, 특히 복합 작업과 무관성 감지 강점
• 가격 대비 성능: Gemini-2.0-flash가 우수

2️⃣ 고성능 세그먼트 (High Performance Segment, 0.85~0.9)

• 특징: 함수 호출, 복합 시나리오, 장기 맥락 처리에서 강점

3️⃣ 중간 등급 모델 (Mid Tier Capabilities, 0.8~0.85)

• 특징: 병렬 도구 사용 및 도구 선택에서 우수, 일부 모델은 긴 맥락이나 복합 작업에서 제한

4️⃣ 기본 등급 모델 (Base Tier Models, <0.8)

• 특징: 특정 영역에서 효율적, 전체 평균 점수는 낮음

감사의 글 🙏

이 평가 프레임워크를 가능하게 한 벤치마크 데이터셋 제작자분들께 진심으로 감사를 드립니다.

• BFCL — 함수 호출 능력을 종합적으로 평가할 수 있는 데이터셋을 만든 Berkeley AI Research팀에 감사드립니다.
• τ-bench — 실제 도구 사용 시나리오에 초점을 맞춘 벤치마크를 개발한 Sierra Research 팀에 감사드립니다.
• xLAM — 21개 도메인에 걸친 방대한 Large Action Model 데이터셋을 구축한 Salesforce AI Research 팀에 감사드립니다.
• ToolACE — 390개 이상의 도메인을 포괄하는 API 상호작용 데이터셋을 개발한 ToolACE 팀에 감사드립니다.

이 데이터셋들은 언어 모델의 도구 호출 능력을 평가하기 위한 포괄적이고 체계적인 평가 프레임워크를 구축하는 데 핵심적인 역할을 했습니다.