LLM 평가는 모델 벤치마크, 애플리케이션 평가, 프로덕션 모니터링을 구분해야 한다. RAGAS, DeepEval, Promptfoo는 “모델 자체가 똑똑한가”보다 “내 앱이 내 데이터와 내 프롬프트에서 제대로 동작하는가”를 보는 도구다. 문제는 이 도구들이 상당 부분 LLM-as-a-judge에 의존하므로 judge 편향까지 함께 설계해야 한다는 점이다.
세 도구의 역할
| 도구 | 강점 | 적합한 상황 |
|---|---|---|
| RAGAS | faithfulness, context precision/recall 같은 RAG 특화 지표 | 검색 증강 생성 파이프라인 평가 |
| DeepEval | pytest 스타일 테스트, hallucination·bias·toxicity 등 폭넓은 metric | CI/CD에서 품질 게이트를 걸 때 |
| Promptfoo | YAML + CLI 기반 다중 모델 비교, 공격 프롬프트와 red-teaming | 프롬프트 실험과 보안 테스트 |
성숙한 팀은 보통 하나만 고르지 않는다. RAG 앱은 RAGAS로 검색·근거성을 보고, DeepEval로 일반 품질과 회귀를 막으며, Promptfoo로 프롬프트 변형과 공격 케이스를 돌린다. 운영 단계에서는 LangSmith, Braintrust, Arize Phoenix, Langfuse 같은 trace·monitoring 도구가 별도로 필요하다.
평가 범주를 먼저 나눈다
- 모델 벤치마크: MMLU, GSM8K, HumanEval 같은 표준 과제. 모델 선택에는 유용하지만 앱 품질을 직접 보장하지 않는다.
- 애플리케이션 평가: RAG 답변의 groundedness, 챗봇 답변의 정책 준수, 에이전트의 도구 사용 성공 여부를 본다.
- 프로덕션 모니터링: 배포 후 실제 사용자 입력에서 발생하는 drift와 회귀를 추적한다.
RAGAS·DeepEval·Promptfoo는 두 번째 범주에 있고, 세 번째 범주와 함께 써야 운영 품질로 이어진다.
LLM Judge 편향
LLM Judge는 편리하지만 다음 편향을 가진다.
| 편향 | 증상 | 완화 |
|---|---|---|
| 위치 편향 | A/B 비교에서 특정 슬롯의 답을 선호 | 응답 순서를 바꿔 두 번 평가하고 평균 |
| 자기 선호 | judge가 같은 모델 계열 출력을 더 좋게 평가 | 평가 대상과 다른 모델 계열의 judge 사용 |
| 장문 선호 | 길고 장황한 답을 더 높은 품질로 오판 | 루브릭에 간결성·불필요한 정보 감점 명시 |
특히 위치 편향은 같은 두 답변의 순서를 바꿔 비교했을 때 판정이 뒤집히는지 보면 바로 드러난다. 이 검사는 비용이 한 번 더 들지만, pass/fail 경계에 있는 배포 판단에서는 충분히 값어치가 있다.
추천 구조
- 작은 human-labeled set을 만들어 기준선을 잡는다.
- 결정론적으로 검사 가능한 항목은 파서나 테스트 코드로 처리한다.
- 열린 품질 판단에만 G-Eval류 LLM Judge를 쓴다.
- CI에는 DeepEval 또는 Promptfoo를 넣어 회귀를 막는다.
- RAG는 RAGAS로 retrieval과 generation을 분리해 본다.
- 프로덕션 trace를 저장해 judge 점수와 실제 사용자 피드백을 연결한다.
관련 문서
- g-eval — 루브릭 기반 LLM Judge 평가 프레임워크
- rag-evaluation-tips-frameworks — RAGAS·TruLens·DeepEval 선택 기준
- ai-agent-evaluation-tips-roadmap — 에이전트 평가 설계 순서
- llm-observability-tips-tools — LLM 앱 관찰성 도구
참고 자료
- LLM Evaluation Frameworks Compared: RAGAS, DeepEval, Promptfoo — MachineLearningMastery.com (2026-07-14)