에이전트 평가가 다른 이유

RAG 시스템을 평가할 때는 최종 답변이 평가 대상이 됩니다 — 정답인지 오답인지, 정확한지 아닌지를 판단합니다.

에이전트(Agent)의 과정 또한 평가 대상입니다. 정답에 도달하기 위해 3단계를 추가로 거치거나, 올바른 도구를 호출하면서 잘못된 인자(arguments)를 사용하는 경우 — 이 두 가지 모두 최종 답변 평가 방식에서는 놓칠 수 있는 실패 사례입니다.

에이전트 평가에는 두 가지 차원이 필요합니다:

차원 1: 도구 호출 정확도 (Tool Call Accuracy) (자동화 가능)
  도구 이름 정확도: 올바른 도구를 호출했는가?
  매개변수(Parameter) 정확도: 인자(arguments)가 올바른가?
...

실험 설계

테스트 대상 에이전트: 3가지 도구를 가진 고객 지원 어시스턴트:

search_faq(query)                                   # 제품 FAQ 검색
get_order_status(order_id)                          # 주문 상태 조회
calculate_refund(amount, days_since_purchase)        # 환불 금액 계산

세 가지 카테고리에 걸친 15개의 테스트 케이스:

각 케이스에는 정답(ground truth)이 있습니다: 기대되는 도구 호출 순서와 인자(arguments).

결과

도구 호출 정확도 (Tool Call Accuracy)

  [T01] ✓ tools=['search_faq']                          name=✓  params=100%
  [T02] ✓ tools=['get_order_status']                     name=✓  params=100%
  [T03] ✗ tools=[]  expected=['search_faq']              name=✗  params=100%
...

요약 지표 (Summary Metrics)

도구 이름 정확도:   73%  (15개 중 11개 올바른 순서)
매개변수 정확도:  100%  (모든 도구 호출의 평균)
단계 효율성:     0.73x  (1.0 = 최적)
...

세 가지 발견 사항

발견 1: 모든 실패는 "호출했어야 했으나 하지 않음"임

4개의 실패 사례 모두 동일한 패턴을 공유합니다: 에이전트가 도구를 전혀 호출하지 않고 직접 답변을 내놓았습니다. 100%의 매개변수 정확도는 에이전트가 도구를 호출하기로 결정했을 때마다 인자(arguments)가 올바랐음을 확인해 줍니다.

실패 유형 분포:

잘못된 도구 선택 (호출은 했으나 잘못된 선택): 0
잘못된 매개변수 (도구는 맞으나 인자가 틀림): 0
도구 미실행 (호출해야 하나 하지 않음): 4

도구 실행 로직에는 문제가 없습니다. 도구 트리거링 (Tool triggering) 로직이 병목 구간입니다. 이 네 가지 사례에서 에이전트 (Agent)는 이미 정답을 알고 있다고 판단하여 호출을 건너뛰었습니다.

T03 ("배송은 얼마나 걸리나요?") 및 T10 ("멤버십 혜틱은 무엇인가요?"): glm-4-flash는 이 주제들에 대해 내장된 지식 (built-in knowledge)을 가지고 있어, 도구를 사용하라는 지시가 있었음에도 직접 답변했습니다. T04 (두 단계가 필요한 복합 질문) 및 T14 (취소된 주문 환불): 에이전트가 질의하는 대신 추론해 버렸습니다.

해결 방향: 시스템 프롬프트 (System Prompt)에 시나리오별로 더 강력한 제약 조건을 추가하거나, LLM이 결정을 내리기 전에 특정 질문 유형을 처리할 수 있는 규칙 기반 라우팅 레이어 (rule-based routing layer)를 사용합니다.

발견 사항 2: 단계 효율성 (Step Efficiency) 0.73x — 1.0 미만인 이유는 단계가 생략되었기 때문

단계 효율성이 1.0 미만인 것이 (

이 분포는 대부분의 에이전트 (Agent) 시스템의 패턴과 일치합니다: 단순한 직접적 과업은 높은 점수를 기록하지만, 복합적이고 경계에 있는 과업은 더 낮은 점수를 기록합니다. 단순한 사례로만 구성된 테스트 세트는 정확도 수치를 부풀리고 실제 문제를 은폐합니다.

구현 (Implementation)

도구 이름 정확도 (Tool Name Accuracy)

def tool_name_accuracy(actual: list[str], expected: list[str]) -> bool:
    """도구 호출 시퀀스가 정확히 일치하는지 확인합니다."""
    if len(actual) != len(expected):
...

파라미터 정확도 (Parameter Accuracy)

형식 차이로 인한 잘못된 실패를 방지하기 위해 유연한 매칭을 사용합니다:

def param_match_score(actual_calls, expected_args) -> float:
    total, correct = 0, 0
    for actual, expected in zip(actual_calls, expected_args):
...

궤적 품질 (Trajectory Quality) (LLM-as-Judge)

TRAJECTORY_JUDGE = """이 에이전트 (Agent) 궤적 품질을 평가하세요 (1-5):

사용자 질문: {question}
...

테스트 세트 설계 (Test Set Design)

단순히 예상되는 정답뿐만 아니라, 정답 도구 시퀀스 (ground truth tool sequences)를 포함해야 합니다:

TestCase(
    id="T04",
    question="ORD-004 주문에 대한 환불 금액은 얼마인가요?",
...

세 가지 난이도 수준을 포함하세요:

단순 (Simple, 단일 도구):    기본적인 도구 인식, 세트의 약 50%
다단계 (Multi-step):       계획 능력 (planning capability), 세트의 약 30%
엣지 케이스 (Edge cases):   강건성 (robustness) (리소스 누락, 빈 결과), 약 20%

"도구가 필요 없는" 사례를 포함하세요:

인사말이나 가벼운 대화는 에이전트 (Agent)가 도구를 과도하게 호출하는지 테스트합니다. 올바른 에이전트 (Agent)라면 "안녕"이라는 말이 데이터베이스 쿼리를 필요로 하지 않는다는 것을 알아야 합니다.

요약 (Summary)

1. 도구 이름 정확도 (Tool name accuracy) 73%, 파라미터 정확도 (parameter accuracy) 100%: 모든 실패 사례는 "호출해야 할 때 호출하지 않음" — 즉, "잘못된 도구를 호출함"이 아니라 — 도구 트리거링 로직 (tool triggering logic)을 수정 대상으로 직접 지목하고 있습니다.
2. 1.0 미만의 단계 효율성 (Step efficiency)은 컨텍스트가 필요함: 이를 도구 이름 정확도와 결합하여 분석해야 합니다. 단계를 건너뛰어서 발생하는 낮은 효율성은 문제이지만, 실제로 더 짧은 경로를 통해 달성된 낮은 효율성은 특징 (feature)입니다.
3. 테스트 세트에는 반드시 다단계 (multi-step) 및 엣지 케이스 (edge cases)가 포함되어야 함: 단순한 단일 도구 작업은 75%의 점수를 기록하지만, 다단계 및 엣지 케이스는 67%의 점수를 기록합니다. 단순한 작업으로만 구성된 테스트 세트는 85% 이상의 점수를 보고하여 실제 실패 모드 (failure modes)를 숨기게 될 것입니다.

참고 문헌 (References)

• BFCL — Berkeley Function Calling Leaderboard
• 전체 데모 코드: eval-05-agent

실제 기업급 워크플로우에서 검증된 AI 에이전트와 기술을 큐레이션하여 제공하는 마켓플레이스 PrimeSkills를 확인해 보세요. 군더더기 없이 실제로 작동하는 것들만 제공합니다.

저의 홈페이지에서 더 유용한 지식과 흥미로운 제품들을 찾아보세요.