Skip to main content

정확성 메트릭

Faithfulness (충실도)

“응답이 제공된 컨텍스트에 근거하는가?” — RAG 시스템에서 가장 중요한 메트릭입니다.
상황컨텍스트 (검색된 문서)모델 응답판정
성공”2024년 매출은 100억원""2024년 매출은 100억원입니다”Faithful
실패”2024년 매출은 100억원""2024년 매출은 200억원 입니다”Not Faithful (수치 왜곡)
실패”2024년 매출은 100억원""2024년 매출은 100억원이며 전년 대비 20% 성장 했습니다”Not Faithful (근거 없는 추가 정보)

Relevance (관련성)

“응답이 질문에 적절히 답하는가?”
질문모델 응답판정
”제품 가격이 얼마인가요?""Pro Plan은 월 49,Enterprise는월49, Enterprise는 월 199입니다”Relevant
”제품 가격이 얼마인가요?""우리 회사는 2015년에 설립되었습니다”Not Relevant (질문과 무관)
“제품 가격이 얼마인가요?""Pro Plan은 강력한 기능을 제공합니다”Partially Relevant (가격 미포함)

Groundedness (근거성)

“출처에 기반한 응답인가?” — Faithfulness와 유사하지만, 검색된 문서의 어느 부분에서 근거를 찾을 수 있는지까지 추적합니다.

Correctness (정확성)

“응답이 사실적으로 정확한가?” — 정답 레이블이 있을 때 사용합니다.

안전성 메트릭

메트릭설명실패 예시
Toxicity(유해성)욕설, 혐오, 차별 표현”그런 질문은 바보나 하는 거죠”
Bias(편향)성별, 인종, 국적 등에 대한 편향”여성은 리더십에 적합하지 않습니다”
PII Leakage개인정보 노출”김철수님의 전화번호는 010-1234-5678입니다”

검색(Retrieval) 메트릭 — RAG 시스템 전용

RAG 시스템을 평가할 때는 “검색이 잘 되는가?”“생성이 잘 되는가?” 를 반드시 분리하여 측정해야 합니다. 검색 품질이 낮으면 아무리 좋은 LLM도 좋은 답변을 생성할 수 없습니다.

Precision@K (정밀도)

상위 K개 검색 결과 중 실제 관련 문서의 비율 입니다. 검색된 5개 문서 중 3개가 관련 있다면 P@5 = 0.6입니다.

Recall@K (재현율)

전체 관련 문서 중 상위 K개에 포함된 비율 입니다. 관련 문서가 총 10개인데 상위 5개에 5개가 포함되었다면 R@5 = 0.5입니다.

MRR (Mean Reciprocal Rank)

첫 번째 관련 문서의 순위 역수 평균 입니다. 관련 문서가 3번째에 나오면 1/3, 1번째에 나오면 1/1입니다. 여러 질문에 대해 이 값을 평균합니다.

NDCG (Normalized Discounted Cumulative Gain)

상위 결과일수록 높은 가중치를 부여하여 전체 순위 품질을 측정 합니다. 관련 문서가 위에 있을수록 NDCG가 높아집니다. 1에 가까울수록 이상적인 순위입니다.
메트릭측정 대상사용 시기직관적 해석
Precision@K검색 정확도”쓸모없는 결과가 너무 많은가?”높을수록 노이즈 적음
Recall@K검색 완전성”빠뜨린 관련 문서가 있는가?”높을수록 누락 적음
MRR첫 관련 결과 순위”관련 문서가 위에 나오는가?”높을수록 빠른 발견
NDCG전체 순위 품질”전체적으로 순위가 적절한가?“1에 가까울수록 완벽
참고 RAG 디버깅 팁: RAG 시스템에서 Faithfulness 점수가 낮다면, 원인이 ‘검색’인지 ‘생성’인지를 먼저 구분하세요. Retrieval 메트릭이 낮으면 검색 개선(청킹 전략 변경, 임베딩 모델 교체)이 필요하고, Retrieval은 좋은데 생성이 나쁘면 프롬프트 수정이 필요합니다.

운영 메트릭

메트릭설명목표
Latency(지연시간)응답 생성까지 소요 시간< 3초 (대화형), < 30초 (분석형)
Cost(비용)토큰당 비용사용 사례별 예산 내
Throughput(처리량)초당 처리 요청 수동시 사용자 기준
Token Efficiency답변 대비 사용 토큰 수불필요한 장문 응답 감지

Agent 전용 평가 메트릭

Agent 평가는 단순 LLM Q&A 평가와 근본적으로 다릅니다. 일반적인 LLM 평가가 “입력 → 출력” 의 단일 단계를 측정한다면, Agent 평가는 “입력 → 추론 → 도구 선택 → 실행 → 관찰 → 재추론 → … → 최종 출력” 이라는 다단계 의사결정 전체 경로 를 측정해야 합니다.
참고 왜 Agent 평가가 더 어려운가? 같은 질문에 대해 Agent가 선택할 수 있는 경로가 여러 개 존재합니다. “서울 날씨 알려줘”라는 질문에 weather_api() → 응답 생성 경로와 web_search("서울 날씨") → 파싱 → 응답 생성 경로 모두 정답일 수 있습니다. 따라서 최종 결과 뿐 아니라 경로의 효율성과 합리성 도 함께 평가해야 합니다.

핵심 Agent 메트릭

메트릭측정 대상설명계산 방법
Tool Selection Accuracy올바른 도구 선택 비율Agent가 질문에 적합한 도구를 선택했는가정답 도구 선택 수 / 전체 도구 호출 수
Task Completion Rate작업 완료 비율Agent가 사용자 요청을 끝까지 완수했는가성공적으로 완료된 Task / 전체 요청
Step Efficiency단계 효율성최소 몇 단계로 완료할 수 있었는가 vs 실제 사용한 단계최적 단계 수 / 실제 단계 수
Error Recovery Rate오류 복구율도구 호출 실패 후 대안을 찾아 성공했는가복구 성공 수 / 전체 오류 수
Trajectory Quality추론 경로 품질Agent의 Thought→Action→Observation 경로가 합리적이었는가LLM-as-Judge로 경로 평가 (1-5점)
Multi-turn Consistency다턴 일관성여러 턴에 걸친 응답이 일관적인가모순 발생 비율
주의 Tool Selection Accuracy가 가장 중요한 이유: Agent가 잘못된 도구를 선택하면, 이후 모든 단계가 잘못된 방향으로 진행됩니다. 예를 들어 “지난 달 매출”을 묻는데 search_documents() 대신 search_products()를 호출하면, 아무리 후속 처리가 정확해도 최종 답변은 틀립니다. Agent 품질 개선의 첫 번째 단계는 항상 Tool Selection 정확도를 높이는 것 입니다.

Agent 평가 방법론

Agent를 평가하는 세 가지 대표적인 접근법이 있습니다. 각각 장단점이 뚜렷하므로, 실무에서는 보통 Component 평가로 병목을 찾고Trajectory 기반 평가로 원인을 분석 하는 조합을 사용합니다.

1. Trajectory 기반 평가 (가장 상세)

Agent의 전체 추론 경로를 기록 하고, 각 단계가 합리적인지 개별 평가합니다. MLflow Tracing을 사용하면 Thought → Action → Observation 전체 경로가 자동으로 기록됩니다.
Trajectory 기반 평가 예시:

  질문: "지난 달 매출 Top 5 제품은?"

  Step 1: Thought "매출 데이터를 조회해야 한다"
          → ✅ 합리적 추론

  Step 2: Action  search_products()
          → ❌ 잘못된 도구 선택 (query_sales가 맞음)

  Step 3: Observation "제품 목록 반환됨"
          → Agent가 오류를 인식하지 못함 ❌

  Step 4: Action  format_response()
          → 잘못된 데이터 기반으로 응답 생성

  평가 결과:
  - Tool Selection Accuracy: 0/1 = 0%
  - 근본 원인: search_products와 query_sales의 도구 설명이 모호
  - 개선 방향: 도구 Description을 더 구체적으로 작성
참고 MLflow Tracing 연동: Databricks에서 Agent를 배포하면 MLflow Tracing이 자동으로 모든 Trace를 기록합니다. 이 Trace 데이터를 평가 데이터셋으로 직접 활용할 수 있어, 별도의 로깅 파이프라인 없이도 Trajectory 기반 평가를 바로 시작할 수 있습니다.

2. End-to-end 평가 (가장 빠름)

최종 결과만 평가 합니다 (입력 → 최종 출력). 내부 과정은 블랙박스로 취급합니다.
  • 장점: 평가 데이터셋 구성이 간단하고, 실행 속도가 빠름
  • 단점: “왜 틀렸는지” 파악이 어렵고, 개선 방향을 잡기 힘듦
  • 사용 시기: 빠른 회귀 테스트, A/B 테스트, 프로덕션 모니터링

3. Component 평가 (가장 실용적)

Tool Selection, Retrieval, Generation을 분리하여 각각 독립적으로 평가 합니다.
  • 장점: “어디가 병목인가”를 정확히 식별 가능
  • 단점: 컴포넌트 간 상호작용 효과를 놓칠 수 있음
  • 사용 시기: 성능 저하 원인 분석, 특정 컴포넌트 개선 후 효과 측정
평가 방법평가 범위디버깅 용이성데이터셋 복잡도추천 사용 시기
Trajectory전체 경로매우 높음높음개발 단계, 심층 분석
End-to-end최종 결과만낮음낮음CI/CD, 회귀 테스트
Component개별 모듈높음중간병목 식별, 최적화

Agent 평가 데이터셋 설계

단순 Q&A 평가셋과 달리, Agent 평가셋은 기대하는 도구 호출 순서, 최대 허용 단계 수, 범위 밖 질문에 대한 기대 동작 까지 정의해야 합니다.

평가셋 구조 예시

eval_data = [
    {
        "input": "지난 달 매출 Top 5 제품",
        "expected_tools": ["query_sql"],            # 기대하는 도구
        "expected_sql_contains": ["ORDER BY", "LIMIT 5"],  # SQL 검증
        "expected_response_contains": ["제품명", "매출"],    # 응답 검증
        "max_steps": 3,                              # 최대 허용 단계
    },
    {
        "input": "오늘 날씨 알려줘",                    # 범위 밖 질문
        "expected_tools": [],                         # 도구 호출하면 안 됨
        "expected_response_contains": ["지원하지 않"],   # Guardrail 응답 검증
    },
    {
        "input": "지난 분기 대비 이번 분기 매출 증감률",
        "expected_tools": ["query_sql", "query_sql"],  # 2번 호출 기대
        "expected_response_contains": ["증감률", "%"],
        "max_steps": 5,
    },
]
주의 범위 밖(Out-of-scope) 질문 필수 포함: 평가셋에 “Agent가 답하면 안 되는 질문”을 반드시 포함하세요. Agent가 모든 질문에 무리하게 답변을 시도하면, 잘못된 도구를 호출하거나 Hallucination이 발생합니다. expected_tools: []로 설정하여 도구 호출 자체가 없어야 하는 케이스를 검증하세요.

평가셋 설계 시 고려할 카테고리

카테고리설명예시 질문비율 권장
Happy Path정상적인 단일 도구 호출”지난 달 매출은?“40%
Multi-tool여러 도구 조합이 필요”매출 추이 그래프 그려줘”20%
Out-of-scope범위 밖 질문”오늘 날씨는?“15%
Ambiguous모호한 질문 (확인 질문 기대)“매출 알려줘” (기간 미지정)15%
Error Recovery도구 오류 시나리오DB 타임아웃 후 재시도10%

MLflow에서 Agent 평가 구현

Databricks의 MLflow는 Agent 평가를 위한 Custom Scorer 를 지원합니다. 아래는 Tool Selection Accuracy를 측정하는 커스텀 스코어러 예시입니다.
from mlflow.genai.scorers import scorer

@scorer
def tool_selection_accuracy(inputs, outputs, expectations):
    """Agent가 올바른 도구를 선택했는지 평가"""
    expected_tools = expectations.get("expected_tools", [])
    actual_tools = [
        step["tool"] for step in outputs.get("steps", [])
        if "tool" in step
    ]

    if not expected_tools:
        # 도구 호출이 없어야 하는 경우
        score = 1.0 if len(actual_tools) == 0 else 0.0
        justification = (
            "도구 호출 없음 (정상)" if score == 1.0
            else f"불필요한 도구 호출 발생: {actual_tools}"
        )
    else:
        matches = sum(1 for t in expected_tools if t in actual_tools)
        score = matches / len(expected_tools)
        justification = f"Expected: {expected_tools}, Got: {actual_tools}"

    return {
        "score": score,
        "justification": justification
    }


@scorer
def step_efficiency(inputs, outputs, expectations):
    """Agent가 최적 단계 수 대비 얼마나 효율적인지 평가"""
    max_steps = expectations.get("max_steps", 5)
    actual_steps = len(outputs.get("steps", []))

    if actual_steps == 0:
        return {"score": 0.0, "justification": "단계 정보 없음"}

    score = min(max_steps / actual_steps, 1.0)
    return {
        "score": score,
        "justification": f"최대 허용 {max_steps}단계, 실제 {actual_steps}단계 사용"
    }
위 스코어러를 사용하여 Agent를 평가하는 전체 흐름은 다음과 같습니다.
import mlflow

# 평가 실행
results = mlflow.genai.evaluate(
    data=eval_data,
    predict_fn=agent.predict,
    scorers=[
        tool_selection_accuracy,
        step_efficiency,
        "faithfulness",     # 내장 스코어러
        "relevance",        # 내장 스코어러
    ],
)

# 결과 확인
print(results.tables["eval_results"])
참고 실무 팁: Agent 평가를 CI/CD 파이프라인에 통합하세요. 도구 설명(Description)이나 시스템 프롬프트를 수정할 때마다 자동으로 평가가 실행되어야 합니다. Tool Selection Accuracy가 기존 대비 5% 이상 하락하면 배포를 차단하는 게이트를 설정하는 것을 권장합니다.

추가 핵심 메트릭 — 실무에서 자주 간과되는 것들

Context Relevance (컨텍스트 관련성)

“검색된 문서가 질문에 관련이 있는가?” — Faithfulness와 혼동하기 쉽지만 완전히 다른 메트릭입니다.
메트릭비교 대상질문핵심
Faithfulness답변 vs 검색 문서”답변이 문서 내용에 충실한가?”생성 단계 품질
Context Relevance질문 vs 검색 문서”검색된 문서가 질문에 관련이 있는가?”검색 단계 품질
구체적 예시:
질문검색된 문서Context Relevance설명
”2024년 매출 실적은?“2024년 재무보고서높음질문과 직접 관련된 문서
”2024년 매출 실적은?“2023년 재무보고서낮음연도가 다른 문서. 모델이 이 문서를 참조하면 잘못된 수치를 답변할 위험
”2024년 매출 실적은?”회사 연혁 소개 페이지매우 낮음매출과 전혀 무관한 문서
주의 실무 함정: Context Relevance가 낮으면 Faithfulness가 높아도 의미가 없습니다. 엉뚱한 문서를 충실히 인용하면 “충실하지만 틀린 답변”이 됩니다. 예를 들어 2023년 재무보고서를 충실히 인용해서 “2024년 매출은 500억입니다”라고 답하면 Faithful하지만 Correct하지는 않습니다.

Answer Completeness (답변 완전성)

“질문의 모든 부분에 답변했는가?” — 복합 질문에서 특히 중요합니다.
질문답변Completeness누락 부분
”A, B, C 제품의 가격과 배송기간을 비교해줘""A는 10만원(3일), B는 15만원(2일), C는 20만원(5일)입니다”완전없음
”A, B, C 제품의 가격과 배송기간을 비교해줘""A는 10만원, B는 15만원, C는 20만원입니다”불완전배송기간 누락
”A, B, C 제품의 가격과 배송기간을 비교해줘""A는 10만원(3일), B는 15만원(2일)입니다”불완전C 제품 정보 누락
Answer Completeness가 중요한 이유: 사용자는 불완전한 답변을 받으면 후속 질문을 해야 합니다. 이는 사용자 경험을 악화시키고, 멀티턴 대화 비용을 증가시킵니다. 특히 보고서 생성, 비교 분석 등의 사용 사례에서는 불완전한 답변이 잘못된 의사결정으로 이어질 수 있습니다.

Latency vs Quality 트레이드오프

응답 품질과 속도는 거의 항상 트레이드오프 관계에 있습니다. 모델이 더 많이 “생각”할수록 품질은 높아지지만 속도는 느려집니다.
사용 사례적정 Latency품질 기대치트레이드오프 전략
대화형 챗봇3초 이내중간 (간결한 답변)작은 모델 + 스트리밍 출력. 사용자가 기다리지 않도록 첫 토큰 빠르게
분석/보고서30초 이내높음 (정확한 수치, 포괄적 분석)큰 모델 + 체인 오브 씽킹. 로딩 UI로 사용자 기대치 관리
리서치/탐색수분 허용매우 높음 (깊이 있는 분석)멀티 에이전트 + 반복 검증. 진행 상황 표시 필수
실시간 추천500ms 이내낮음~중간 (빠른 제안)캐싱 + 사전 계산. 모델 호출 최소화
참고 측정 팁: Latency는 단순 평균이 아닌 P50, P95, P99 백분위수 로 측정하세요. 평균 2초여도 P99가 15초면 100명 중 1명은 15초를 기다리는 것입니다. 사용자 불만은 항상 꼬리(tail) 지연에서 발생합니다.

흔한 오해 (Common Misconceptions)

평가 메트릭을 선택할 때 흔히 빠지는 오해들입니다.
오해사실
”BLEU/ROUGE 점수가 높으면 좋은 답변이다”이 메트릭들은 단어 겹침만 측정합니다. 의미적으로 동일하지만 다른 표현을 사용하면 낮게 나옵니다. LLM-as-Judge가 더 적합합니다.
”모든 메트릭을 다 측정해야 한다”사용 사례에 맞는 핵심 메트릭 3~5개에 집중하세요. RAG라면 Faithfulness와 Relevance가 최우선입니다.