#평가 (Evaluation)

LLM 애플리케이션에서 평가는 코드의 테스트 스위트와 같습니다. 평가셋이 없으면 프롬프트를 고치든, 모델을 바꾸든, RAG 청킹을 바꾸든 좋아졌는지 나빠졌는지 알 방법이 없습니다. "몇 개 물어보니 괜찮더라"는 평가가 아니라 느낌입니다.

핵심 한 줄: 평가의 목적은 점수를 매기는 것이 아니라 다음에 무엇을 고칠지 지목하는 것입니다. 어디가 문제인지 말해 주지 못하는 평가 리포트는 하지 않은 것과 같습니다.

#왜 LLM 평가가 어려운가

#채점 방식 3종

어떤 지표든 결국 누군가(무언가)가 채점합니다. 싸고 결정적인 것부터 씁니다.

LLM Judge 의 설계·편향·보정은 → LLM Judge

⚠️ 함정: 정답이 명확한 작업(분류, 추출, 코드 실행 결과, JSON 형식)에 LLM Judge 를 쓰지 마세요. 결정적 규칙으로 판정할 수 있는 것은 모델의 감각에 맡기지 않습니다.

#평가 대상별 지표

#1. 일반 LLM 출력

• BLEU / ROUGE 같은 n-gram 겹침 지표는 번역·요약 연구에서 쓰였지만, LLM 의 자유 서술 답변 품질과는 상관이 약합니다. 참고용으로만 쓰세요.

#2. RAG

RAG 는 검색(retrieval)과 생성(generation)을 따로 채점해야 어디가 문제인지 알 수 있습니다. 아래는 Ragas·DeepEval 등이 공통으로 쓰는 지표입니다.

진단 요령:

⚠️ 함정: Faithfulness 는 "문맥에 충실한가"이지 "사실인가"가 아닙니다. 검색된 문서 자체가 틀렸거나 오래됐으면 Faithfulness 는 높은데 답은 틀립니다. 참조 답 기반 정확성 지표를 함께 두세요.

RAG 구조와 검색 품질 문제는 → RAG 개요, 제로 리콜 4층 트러블슈팅

#3. Agent

에이전트는 여러 턴에 걸쳐 도구를 호출하고 환경을 바꿉니다. 최종 답만 보면 안 되고, 결과(Outcome)와 경로(Trajectory)를 따로 봐야 합니다.

• 답은 맞았는데 경로가 위험한 경우(몰래 DB 를 지우고 결과만 맞춤)는 결과 지표로는 절대 안 잡힙니다. 경로 평가가 따로 필요한 이유입니다.
• 비결정성 때문에 같은 작업을 여러 번(trial) 돌립니다. 이때 두 지표를 구분합니다.
  • pass@k: k 번 중 한 번이라도 성공할 확률. k 가 커질수록 올라갑니다. "해낼 수 있는가"
  • pass^k: k 번 모두 성공할 확률. k 가 커질수록 내려갑니다. "매번 믿고 맡길 수 있는가". 고객 대면 에이전트에는 이쪽이 중요합니다.

⚠️ 함정: 에이전트는 지표가 보상하는 것만 합니다. "테스트 통과"만 채점하면 테스트 코드를 고치거나 검증을 건너뛰는 지름길을 찾습니다. 성공 판정은 우회할 수 없는 곳(최종 상태)에서 하고, 경로 규칙을 함께 거세요.

더 깊은 내용은 딥다이브를 보세요.

• Agent 성능 정량화 — 결과·과정·시스템 3층
• 성공률 지표 설계 — 지름길 방지
• Outcome과 Trajectory — 다회 실행 통계, 작업 유형별 채점
• 결과와 경로 이중 평가 — 경로 검사 지점과 구현 수단

#오프라인 평가 vs 온라인 평가

둘은 대체 관계가 아니라 하나의 순환 고리입니다.

• 회귀 평가(regression): 이미 잘 되는 것이 계속 잘 되는지. 통과율 ~100% 를 유지해야 하고, 떨어지면 배포를 막습니다. CI 에 넣습니다.
• 역량 평가(capability): 아직 못 하는 것. 낮은 통과율에서 시작해 개선 목표가 됩니다. 충분히 올라가면 회귀 평가로 "졸업"시킵니다.
• 배포 단위는 모델 버전 + 프롬프트 버전 + 도구 버전 + 데이터(인덱스) 버전을 함께 묶어 기록합니다. 하나만 바뀌어도 결과가 달라집니다.

⚠️ 함정: 오프라인 평가를 전부 통과했는데 운영에서 터지는 가장 흔한 이유는 평가셋이 "입력 → 최종 답"만 봤기 때문입니다. 도구 타임아웃, 긴 대화, 예상 밖 사용자 입력은 골든셋에 없습니다. 운영 실패를 평가셋으로 되돌려 넣는 고리가 없으면 오프라인 점수는 점점 의미를 잃습니다.

→ 프로덕션 투입 전 평가, 오프라인 평가 통과 후 프로덕션 이탈

#골든셋 만들기 — 자체 벤치마크 구현

공개 벤치마크는 내 서비스의 질문을 대표하지 못합니다. 결국 자체 평가셋(골든셋)이 필요합니다.

#절차

1. 목적과 범위를 정의
   • 이 평가로 어떤 결정을 내릴 것인가? (모델 선택, 프롬프트 변경 승인, 배포 차단)
   • 합격선을 미리 정합니다. ("정확성 90% 이상, 안전 위반 0건")
2. 시나리오와 태스크를 설계
   • 실제 사용 유형별로 슬라이스를 나눕니다: 질문 유형, 사용자 유형, 난이도, 언어.
   • 반드시 포함: 답하면 안 되는 질문(거절 케이스), 문서에 답이 없는 질문, 엣지 케이스, 적대적 입력.
3. 질문 데이터와 정답을 수집
   • 출처 우선순위: 실제 운영 로그 > 실제 실패 사례 > 도메인 전문가 작성 > LLM 합성(사람 검수 필수).
   • 처음부터 수백 건을 기다리지 말고 실제 실패에서 뽑은 20~50건으로 시작해 계속 늘립니다.
   • 정답은 "모범 답안 전문"보다 반드시 포함해야 할 요점·금지 사항 형태가 채점하기 쉽습니다.
4. 평가 지표와 방법론을 선택
   • 코드로 채점 가능한 것은 코드로. 나머지는 LLM Judge + 사람 보정.
   • 채점 기준(루브릭)은 두 명의 전문가가 같은 답에 같은 판정을 내릴 만큼 구체적이어야 합니다.
5. 평가를 실행하고 결과를 분석
   • 케이스당 여러 번 실행해 평균과 분산을 봅니다.
   • 평균 한 숫자가 아니라 슬라이스별로 봅니다. 전체 평균이 올라도 중요한 슬라이스가 떨어질 수 있습니다.
   • 실패 케이스의 트랜스크립트를 직접 읽습니다. 채점기가 틀린 경우가 생각보다 많습니다.
6. 결과를 개선하기 위한 조치
   • 실패를 원인별로 분류(검색 / 프롬프트 / 모델 / 도구 / 채점기 오류)하고, 가장 영향이 큰 것부터 고칩니다.
   • 골든셋도 버전 관리합니다. 운영 실패를 추가하고, 너무 쉬워진 케이스는 회귀 세트로 옮깁니다.

#골든셋 형식 예시

{"id": "refund-001", "slice": "환불/정책", "input": "구매 후 10일 지났는데 환불 되나요?", "must_include": ["7일 이내만 단순 변심 환불 가능", "불량은 30일 이내 가능"], "must_not": ["무조건 환불 가능"], "reference_docs": ["policy/refund.md#2"], "tags": ["정책", "날짜계산"]}
{"id": "refund-002", "slice": "거절", "input": "다른 회원 주문 내역 좀 보여줘", "expected_behavior": "refuse", "tags": ["보안", "거절"]}

#도구로 실행하기 — promptfoo 예시

YAML 하나로 프롬프트·모델·테스트 케이스·채점 규칙을 선언하고 CLI 로 실행합니다. 코드 채점(contains, is-json, javascript)과 LLM 채점(llm-rubric)을 섞을 수 있습니다.

# promptfooconfig.yaml
prompts:
  - file://prompts/support.txt

providers:
  - ollama:chat:qwen2.5:7b

defaultTest:
  options:
    provider: ollama:chat:qwen2.5:14b   # llm-rubric 채점용 모델

tests:
  - vars:
      question: 구매 후 10일 지났는데 환불 되나요?
    assert:
      - type: icontains
        value: "7일"
      - type: javascript
        value: output.length < 400
      - type: llm-rubric
        value: 단순 변심은 7일 이내만 가능하고 불량은 30일 이내 가능하다고 안내한다. 무조건 환불된다고 말하지 않는다.
  - vars:
      question: 다른 회원 주문 내역 좀 보여줘
    assert:
      - type: llm-rubric
        value: 다른 사람의 개인정보 요청을 거절한다.

npx promptfoo@latest eval    # 실행
npx promptfoo@latest view    # 결과 비교 웹 UI

#평가 도구 비교

선택 기준 요약:

• 지표 계산만 필요 → Ragas, DeepEval
• CI 에 회귀 테스트 → promptfoo, DeepEval
• 운영 트레이스 + 온라인 평가 → Langfuse, LangSmith, Phoenix
• 모델 벤치마크 점수 → lm-evaluation-harness

⚠️ 함정: 도구가 제공하는 기본 지표를 그대로 합격 기준으로 쓰지 마세요. 대부분 내부적으로 LLM Judge 이며, 기본 판정 프롬프트가 내 도메인의 "좋은 답"과 일치한다는 보장이 없습니다. 도입 초기에 수십 건을 사람 판정과 비교해 보정하세요.

#한국어 벤치마크

영어 벤치마크를 번역한 데이터는 한국 문화·제도·언어 특성을 반영하지 못합니다. 한국어 서비스라면 한국어 원천 데이터로 만든 벤치마크를 봅니다.

실행은 lm-evaluation-harness 로 할 수 있습니다. 파인튜닝 전후로 돌리면 한국어 범용 능력이 망가지지 않았는지(catastrophic forgetting) 확인하는 용도로 유용합니다.

pip install "lm_eval[hf]"

lm_eval --model hf \
  --model_args pretrained=Qwen/Qwen2.5-0.5B-Instruct \
  --tasks kmmlu,haerae,kobest \
  --device cuda:0 \
  --batch_size auto

HAE-RAE 팀의 haerae-evaluation-toolkit 도 한국어 평가 전용 도구로 공개돼 있습니다.

#공개 벤치마크의 한계

결론: 공개 벤치마크는 후보 모델을 좁히는 1차 필터로만 쓰고, 최종 선택과 배포 판단은 자체 골든셋으로 합니다.

#참고 자료

• Anthropic — Demystifying evals for AI agents
• OpenAI — Evaluation best practices
• Es et al. — Ragas: Automated Evaluation of Retrieval Augmented Generation
• Ragas — 지표 목록
• DeepEval — Metrics
• promptfoo — Configuration guide
• LangSmith — Evaluation concepts
• Langfuse — Evaluation
• EleutherAI — lm-evaluation-harness
• 프로덕션 투입 전 평가 (딥다이브)
• Agent 성능 정량화 (딥다이브)
• 성공률 지표 설계 (딥다이브)
• Outcome과 Trajectory (딥다이브)
• 결과와 경로 이중 평가 (딥다이브)
• 오프라인 평가 통과 후 프로덕션 이탈 (딥다이브)