AI 에이전트 평가(evaluation)에 대해 배우기 시작했을 때, 저는 평가(evals)가 주로 최종 답변을 확인하는 것이라고 생각했습니다.

하지만 에이전트는 단순히 최종 답변만을 내놓는 기계가 아닙니다.

에이전트는 다음과 같은 더 작은 부분들로 구성된 시스템입니다:

1. 라우터 (router)
2. 도구 (tools)
3. 기술 (skills)
4. 메모리 (memory)
5. 검색 (retrieval)
6. 최종 응답 (final response)

각 부분은 서로 다르게 실패할 수 있습니다.

따라서 더 나은 질문은 단지 이것만이 아닙니다:
에이전트가 올바르게 답변했는가?

다음과 같은 질문도 포함되어야 합니다:
에이전트의 어느 부분을 평가해야 하며, 그 부분에는 어떤 유형의 평가(eval)가 적절한가?

모든 평가에 LLM 판사가 필요한 것은 아니다

이것은 제가 배운 중요한 사실 중 하나였습니다.
LLM 시스템을 평가하고 있다면, 모든 것을 판단하기 위해 또 다른 LLM을 사용해야 한다고 생각하기 쉽습니다.

하지만 그것이 항상 최선의 선택은 아닙니다.
어떤 확인 작업은 단순하고 결정론적(deterministic)입니다.
어떤 확인 작업은 주관적입니다.
어떤 확인 작업은 인간의 판단을 필요로 합니다.

좋은 평가(eval) 설정은 적절한 문제에 적절한 방법을 사용합니다.

세 가지 일반적인 평가 방법

LLM 시스템과 에이전트를 평가하는 세 가지 일반적인 방법이 있습니다:
1) 코드 기반 평가 (Code-based evals)
2) LLM 판사 방식 평가 (LLM-as-a-judge evals)
3) 인간 평가 (Human evaluation)

이를 간단히 나누어 살펴보겠습니다.

1. 코드 기반 평가 (Code-based evals)

코드 기반 평가는 기대되는 동작이 명확할 때 유용합니다.
예를 들어:

• 출력이 유효한 JSON을 반환했는가?
• 답변에 필수 키워드가 포함되었는가?
• 정규 표현식(regex)과 일치하는가?
• 에이전트가 올바른 도구(tool)를 호출했는가?
• 올바른 파라미터(parameter)를 추출했는가?
• SQL이 읽기 전용(read-only) 상태를 유지했는가?
• 생성된 코드가 성공적으로 실행되었는가?

이러한 규칙은 명확하기 때문에 자동화하기가 더 쉽습니다.

예시:

기대값 (Expected):
tool = order_status_check
order_number = 1234

실제값 (Actual):
tool = order_status_check
order_number = 1234

결과 (Result):
pass

이것은 LLM 판사가 필요하지 않습니다.
코드로 확인할 수 있습니다.

2. LLM 판사 방식 평가 (LLM-as-a-judge evals)

LLM-as-a-judge는 출력 품질을 단순한 규칙으로 확인하기 어려울 때 유용합니다.

예를 들어:

• 요약이 유용한가?
• 답변이 소스(source)에 근거(grounded)하고 있는가?
• 응답이 사용자의 실제 질문에 답변했는가?
• 어조(tone)가 적절한가?
• 에이전트가 환각(hallucination)을 일으켰는가?
• 추론(reasoning)이 일관적인가?

이것들은 정성적인(qualitative) 점검 사항입니다.
명확한 루브릭(rubric)을 사용하여 다른 LLM에게 출력을 판단하도록 요청할 수 있습니다.
하지만 이 방법이 완벽한 것은 아닙니다.

LLM judge 또한 실수를 할 수 있습니다.

따라서 다음과 같이 명확한 레이블(label)을 사용하는 것이 도움이 됩니다:
정답(correct) / 오답(incorrect)
근거 있음(grounded) / 근거 없음(not grounded)
안전함(safe) / 안전하지 않음(unsafe)
유용함(useful) / 유용하지 않음(not useful)

다음과 같이 모호한 점수는 피하십시오:
87% 유용함
73% 근거 있음
이산적(discrete) 레이블이 일반적으로 해석하고 비교하기 더 쉽습니다.

3. 인간 평가 (Human evaluation)

인간 평가(Human evaluation)는 여전히 중요합니다.

특히 작업이 다음과 같을 때 중요합니다:

• 중대한 결과가 초래되는 경우 (high-stakes)
• 주관적인 경우 (subjective)
• 특정 도메인에 특화된 경우 (domain-specific)
• 안전에 민감한 경우 (safety-sensitive)
• 사용자 신뢰와 직결되는 경우

예를 들어, 의료, 법률, 금융, 교육 또는 기업 워크플로우(enterprise workflows)에서는 결과가 실제로 수용 가능한지 인간이 검토해야 할 수도 있습니다.

인간은 나중에 테스트 데이터셋의 일부가 될 레이블을 제공할 수도 있습니다.

예를 들어:
사용자 피드백: 좋음(thumbs up) / 싫음(thumbs down)
인간 레이블: 정답(correct) / 오답(incorrect)
검토자 노트: 답변이 핵심 문맥(context)을 놓침
이러한 피드백은 향후 평가(evals)를 개선하는 데 도움이 될 수 있습니다.

적절한 평가(eval)를 선택하는 방법

단순한 규칙:

기준이 결정론적(deterministic)이라면, 코드 기반 평가(code-based evals)를 사용하세요.
기준이 정성적(qualitative)이라면, LLM-as-a-judge를 사용하세요.
기준에 도메인 판단이 필요하다면, 인간 평가(human evaluation)를 사용하세요.

다음은 간단한 멘탈 모델(mental model)입니다:

명확한 규칙 → 코드 기반 평가 (code-based eval)
품질 판단 → LLM-as-a-judge
도메인 또는 안전 판단 → 인간 평가 (human evaluation)

목표는 가장 진보된 평가를 사용하는 것이 아닙니다.
목표는 가장 명확한 신호(signal)를 주는 평가를 사용하는 것입니다.

라우터(router) 평가하기

라우터(router)는 에이전트가 다음에 무엇을 해야 할지 결정합니다.

라우터는 다음과 같은 사항을 결정할 수 있습니다:
어떤 도구(tool)를 호출할지
어떤 워크플로우(workflow)를 실행할지
어떤 파라미터(parameter)를 추출할지
직접 답변할지 여부
더 많은 문맥(context)이 필요한지 여부

라우터 평가(Router evals)는 보통 두 가지를 확인합니다:
라우터가 올바른 함수/도구(function/tool)를 선택했는가?
라우터가 올바른 파라미터(parameter)를 추출했는가?

예시:
사용자:
“주문 번호 #1234의 상태를 확인해 줄래?”

올바른 라우터 결정:
tool = order_status_check
order_number = 1234

잘못된 라우터 결정:
tool = shipping_status_check
shipping_tracking_id = 1234

잘못된 결정은 사소해 보일 수 있지만, 전체 경로를 바꿔버립니다.
라우터가 실패하면 에이전트의 나머지 부분도 실패할 수 있습니다.

이것이 라우터 평가(router evals)가 중요한 이유입니다.

기술(Skills) 평가

기술(skill)은 에이전트가 수행할 수 있는 작업입니다.
예를 들어:

• 데이터베이스 조회 (database lookup)
• 데이터 분석 (data analysis)
• 데이터 시각화 (data visualization)
• 검색 (retrieval)
• 요약 (summarization)
• 코드 생성 (code generation)

각 기술은 고유의 평가(eval)가 필요할 수 있습니다.
데이터베이스 조회 기술의 경우, 다음을 평가할 수 있습니다:

올바른 SQL을 생성했는가?
올바른 테이블을 쿼리했는가?
안전하지 않은 작업을 피했는가?
올바른 데이터를 반환했는가?

데이터 분석 기술의 경우, 다음을 평가할 수 있습니다:

계산이 정확했는가?
올바른 엔티티(entity)를 식별했는가?
설명이 명확했는가?

시각화 기술의 경우, 다음을 평가할 수 있습니다:

생성된 코드가 실행되었는가?
차트가 사용자의 요청과 일치하는가?
올바른 데이터를 사용했는가?

기술마다 서로 다른 점검이 필요합니다.

실수: 에이전트를 하나의 블랙박스(black box)로 평가하는 것
최종 답변만 평가한다면, 우리는 약한 피드백을 받게 됩니다.

우리는 단지 다음과 같은 사실만 알 수 있습니다:
에이전트가 실패했다.

하지만 왜 실패했는지는 알 수 없습니다.

더 나은 평가(eval) 설정은 우리에게 다음과 같은 정보를 알려줍니다:
라우터가 잘못된 도구를 선택함
파라미터 추출(parameter extraction)에 실패함
검색(retrieval) 단계에서 취약한 문맥(context)이 반환됨
SQL이 유효하지 않음
요약(summary)에서 환각(hallucination)이 발생함
최종 답변이 유용하지 않음

이것은 개선을 더 쉽게 만듭니다.

실패한 특정 부분을 수정할 수 있기 때문입니다.

마지막 생각

에이전트를 여러 부분으로 나눌 때 에이전트 평가(agent evals)는 더욱 유용해집니다.

라우터를 평가하세요.
도구(tools)를 평가하세요.
기술(skills)을 평가하세요.
최종 응답(final response)을 평가하세요.
경로(path)를 평가하세요.

이것이 바로 평가(evals)가 모호한 점수 매기기에서 실질적인 디버깅(debugging)으로 넘어가는 방식입니다.

목표는 단순히 다음과 같이 말하는 것이 아닙:
이 에이전트는 좋다 또는 나쁘다.

목표는 다음을 이해하는 것입니다:
무엇이 실패했는지, 어디에서 실패했는지, 그리고 어떻게 개선할 수 있는지.