LLM 평가 아키텍처 가이드¶
LLM 기반 시스템의 품질을 체계적으로 측정하고 모니터링하기 위한 아키텍처 패턴
개요¶
LLM을 프로덕션에 배포할 때 가장 어려운 문제 중 하나는 "이 모델이 잘 작동하는가?"를 정량적으로 답하는 것이다. 기존 ML 모델과 달리 LLM의 출력은 자유형 텍스트이므로, 정확도 하나로 평가할 수 없다. 이 문서에서는 오프라인 벤치마크부터 온라인 모니터링까지, 프로덕션 LLM 평가를 위한 아키텍처 패턴을 정리한다.
평가의 3계층¶
| 계층 | 목적 | 시점 | 도구 |
|---|---|---|---|
| 오프라인 벤치마크 | 모델 선택, 버전 비교 | 배포 전 | MMLU, GPQA, HumanEval |
| 스테이징 평가 | 프롬프트/파이프라인 검증 | CI/CD | DeepEval, Ragas, custom suite |
| 온라인 모니터링 | 실시간 품질 추적 | 배포 후 | Langfuse, Arize, custom metrics |
오프라인 벤치마크 아키텍처¶
표준 벤치마크 매트릭스¶
| 벤치마크 | 평가 대상 | 난이도 | 포화 여부 |
|---|---|---|---|
| MMLU | 지식 (57개 분야) | 중 | 거의 포화 |
| MMLU-Pro | 지식 (심화) | 상 | 아직 유효 |
| GPQA Diamond | 전문가 수준 추론 | 최상 | 유효 |
| HumanEval+ | 코드 생성 | 중 | 부분 포화 |
| SWE-bench Verified | 실제 소프트웨어 수정 | 상 | 유효 |
| MATH-500 | 수학 추론 | 상 | 유효 |
| IFEval | 지시 따르기 | 중 | 유효 |
| Arena-Hard | 종합 선호도 | 상 | 유효 |
벤치마크 파이프라인 설계¶
테스트 데이터셋 (버전 관리)
|
v
[평가 실행기] ---> 모델 A, B, C (병렬)
|
v
[채점기] ---> 자동 채점 (정규식, 코드 실행)
| LLM-as-Judge (GPT-4o 등)
v
[결과 저장소] ---> 시계열 DB
|
v
[대시보드] ---> 모델별 비교, 트렌드
설계 원칙¶
- 테스트셋 버전 관리: Git으로 관리, 주기적 로테이션 (오염 방지)
- 재현성 보장: 시드, 온도, 프롬프트 템플릿 모두 고정
- 다차원 평가: 단일 점수가 아닌 능력별 레이더 차트
- 비용 추적: 평가 1회당 토큰 소비량, 비용 기록
스테이징 평가 아키텍처¶
LLM-as-Judge 패턴¶
프로덕션 배포 전, 자동화된 품질 게이트로 활용:
PR/커밋
|
v
[CI 파이프라인]
|
v
[테스트 케이스 로드] (JSON/YAML)
|
v
[대상 LLM 호출] ---> 응답 수집
|
v
[Judge LLM 호출] ---> 채점 (1-5점)
| 기준: 정확성, 관련성, 안전성, 형식
v
[품질 게이트] ---> Pass/Fail 판정
| (임계값: 평균 4.0 이상)
v
[배포 승인/거부]
평가 메트릭 분류¶
자동 메트릭 (코드 기반):
| 메트릭 | 용도 | 계산 방식 |
|---|---|---|
| Exact Match | 팩트 체크 | 정답과 문자열 비교 |
| BLEU/ROUGE | 요약 품질 | n-gram 오버랩 |
| Pass@k | 코드 생성 | k번 시도 중 통과 비율 |
| Latency P50/P95 | 성능 | 응답 시간 분포 |
LLM-as-Judge 메트릭:
| 메트릭 | 평가 기준 | Judge 프롬프트 |
|---|---|---|
| Faithfulness | 환각 없이 소스에 충실한가 | RAG 컨텍스트와 대조 |
| Relevance | 질문에 적절히 답하는가 | 질문-응답 쌍 평가 |
| Coherence | 논리적으로 일관된가 | 문단 구조 분석 |
| Safety | 유해 콘텐츠 포함 여부 | 안전 가이드라인 대조 |
RAG 전용 평가¶
RAG 시스템은 추가 메트릭이 필요:
| 메트릭 | 설명 |
|---|---|
| Context Precision | 검색된 문서 중 관련 문서 비율 |
| Context Recall | 필요한 정보가 모두 검색되었는가 |
| Answer Faithfulness | 답변이 검색 결과에 근거하는가 |
| Answer Relevance | 답변이 질문에 적절한가 |
온라인 모니터링 아키텍처¶
실시간 관측성 스택¶
[사용자 요청]
|
v
[API Gateway] ---> 요청 로깅
|
v
[LLM 서비스] ---> 응답 로깅 (Inference Table)
|
v
[비동기 평가 워커]
|--- 안전성 체크 (가드레일)
|--- 품질 스코어링 (샘플링)
|--- 비용 집계
v
[관측성 플랫폼]
|--- 대시보드 (Grafana)
|--- 알림 (PagerDuty/Slack)
|--- 드리프트 감지
핵심 운영 메트릭¶
| 카테고리 | 메트릭 | 임계값 예시 |
|---|---|---|
| 성능 | TTFT (Time to First Token) | < 500ms |
| 성능 | TPS (Tokens Per Second) | > 30 |
| 성능 | P95 Latency | < 3s |
| 품질 | 환각률 (Hallucination Rate) | < 5% |
| 품질 | 사용자 피드백 (좋아요 비율) | > 80% |
| 비용 | 요청당 비용 | < $0.05 |
| 안전 | 가드레일 트리거율 | 모니터링용 |
드리프트 감지¶
LLM 출력 품질은 시간에 따라 변할 수 있다:
- 입력 드리프트: 사용자 질문 패턴 변화 (임베딩 분포 모니터링)
- 출력 드리프트: 응답 길이, 톤, 구조 변화
- 성능 드리프트: 지연시간, 오류율 증가
- 모델 업데이트 드리프트: 제공사의 모델 변경 (API 모델)
프레임워크 비교¶
오픈소스 평가 프레임워크¶
| 프레임워크 | 강점 | 약점 | 적합 대상 |
|---|---|---|---|
| DeepEval | 14+ 메트릭, 자체 설명 | 초기 설정 복잡 | RAG + 파인튜닝 평가 |
| Ragas | RAG 특화, 직관적 API | RAG 외 평가 제한적 | RAG 시스템 전용 |
| LangSmith | LangChain 통합, 트레이싱 | LangChain 종속 | LangChain 사용자 |
| promptfoo | CLI 기반, CI/CD 친화 | 대시보드 제한적 | DevOps 팀 |
| Eleuther Harness | 학술 벤치마크 포괄 | 커스텀 메트릭 추가 어려움 | 모델 연구 |
상용 플랫폼¶
| 플랫폼 | 특징 | 가격대 |
|---|---|---|
| Langfuse | 오픈소스, 셀프호스팅 가능, 트레이싱 | 무료/유료 |
| Arize Phoenix | 관측성 특화, 임베딩 분석 | 무료/엔터프라이즈 |
| Weights & Biases | 실험 추적 통합 | 팀당 과금 |
| Databricks | 추론 테이블 + 레이크하우스 모니터링 | 클러스터 기반 |
상황별 아키텍처 선택¶
1. RAG 챗봇 평가¶
추천 조합:
- 오프라인: Ragas (Context Precision/Recall)
- 스테이징: DeepEval (Faithfulness + Relevance)
- 온라인: Langfuse (트레이싱) + Grafana (메트릭)
핵심: 검색 품질과 생성 품질을 분리하여 평가
2. 코드 생성 평가¶
추천 조합:
- 오프라인: HumanEval+, SWE-bench
- 스테이징: 단위 테스트 Pass@k + 코드 리뷰 LLM-as-Judge
- 온라인: 사용자 채택률 + 에러 로그
핵심: 실행 가능성(Pass@k)과 코드 품질을 분리
3. 에이전트 시스템 평가¶
핵심: 단계별 정확도뿐 아니라 전체 태스크 성공 여부
4. 멀티모달 (VLM) 평가¶
평가 파이프라인 구축 실전¶
CI/CD 통합 예시 (GitHub Actions)¶
# .github/workflows/llm-eval.yml
name: LLM Evaluation
on:
pull_request:
paths: ['prompts/**', 'config/**']
jobs:
evaluate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run evaluation
run: |
pip install deepeval
deepeval test run tests/eval_suite.py
- name: Check quality gate
run: |
python scripts/check_scores.py \
--min-faithfulness 0.85 \
--min-relevance 0.80 \
--max-hallucination 0.05
비용 효율적 평가¶
| 전략 | 설명 | 절감 효과 |
|---|---|---|
| 샘플링 평가 | 전체 트래픽의 5-10%만 Judge 평가 | 90% 비용 절감 |
| 캐시 활용 | 동일 입력-출력 쌍 재평가 방지 | 30-50% 절감 |
| 소형 Judge | GPT-4o-mini를 Judge로 활용 | 80% 절감 |
| 로컬 Judge | Llama 3 8B를 로컬 Judge로 | API 비용 0 |
체크리스트¶
배포 전 평가 체크리스트:
- [ ] 도메인 특화 테스트셋 100개 이상 확보
- [ ] 자동 평가 파이프라인 CI/CD 연동
- [ ] LLM-as-Judge 프롬프트 최적화 및 검증
- [ ] 온라인 모니터링 대시보드 구축
- [ ] 알림 임계값 설정 (환각률, 지연시간)
- [ ] 테스트셋 버전 관리 및 로테이션 계획
- [ ] 비용 추적 및 예산 알림 설정
- [ ] A/B 테스트 프레임워크 준비
참고¶
- LLM Evaluation: Frameworks, Metrics, and Best Practices (2026 Edition)
- DeepEval - Open-source LLM Evaluation
- Ragas - RAG Assessment
- Langfuse - LLM Engineering Platform
- LLM Benchmarks 2026
최종 업데이트: 2026-03-18