DeepEval, promptfoo, Evidently AI, W&B Weave, LangSmith, Ragas 등 실무 평가 도구를 비교합니다. 학술 vs 실무 평가의 차이점과 프레임워크 선택 의사결정 트리를 제시합니다.
앞선 3-5장에서 살펴본 lm-evaluation-harness, HELM, Inspect AI는 학술 연구에 뿌리를 둔 프레임워크입니다. 이들은 "이 모델의 일반적 능력이 어떤 수준인가"라는 질문에 답합니다. 하지만 프로덕션 환경에서 엔지니어가 묻는 질문은 다릅니다.
"어제 배포한 프롬프트 변경이 품질을 떨어뜨리지 않았는가?"
"RAG 파이프라인이 올바른 문서를 검색하고 있는가?"
"모델 응답이 회사의 톤앤매너 가이드라인을 준수하는가?"
이러한 질문에 답하기 위해서는 학술 벤치마크와는 다른 도구가 필요합니다.
| 관점 | 학술 평가 | 실무 평가 |
|---|---|---|
| 목적 | 모델의 일반 능력 측정 | 특정 유즈케이스의 품질 보장 |
| 데이터 | 공개 벤치마크 데이터셋 | 자사 데이터, 실제 사용자 쿼리 |
| 빈도 | 모델 출시 시 1회 | 배포마다 반복, CI/CD 통합 |
| 메트릭 | 표준화된 학술 메트릭 | 비즈니스 KPI에 맞춘 커스텀 메트릭 |
| 규모 | 수천-수만 건 | 수십-수백 건 (골든 데이터셋) |
| 소요 시간 | 수 시간-수일 | 수 분-수십 분 |
DeepEval은 "LLM 출력에 대한 pytest"를 표방하는 오픈소스 프레임워크입니다. 소프트웨어 개발에서 단위 테스트가 코드의 정확성을 보장하듯, DeepEval은 LLM 출력의 품질을 테스트 코드로 검증합니다.
import pytest
from deepeval import assert_test
from deepeval.test_case import LLMTestCase
from deepeval.metrics import (
AnswerRelevancyMetric,
FaithfulnessMetric,
GEval,
)
def test_customer_support_response():
"""고객 지원 챗봇의 응답 품질을 테스트합니다."""
test_case = LLMTestCase(
input="주문한 상품이 아직 도착하지 않았어요.",
actual_output="주문 상태를 확인해보겠습니다. 주문번호를 알려주시면 정확한 배송 현황을 안내해드리겠습니다.",
expected_output="배송 상태 확인을 위한 주문번호 요청",
retrieval_context=[
"배송 문의 시 주문번호를 확인하여 택배사 추적 정보를 제공합니다.",
],
)
# 여러 메트릭으로 동시에 평가
relevancy = AnswerRelevancyMetric(threshold=0.7)
faithfulness = FaithfulnessMetric(threshold=0.8)
tone = GEval(
name="톤앤매너",
criteria="응답이 친절하고 전문적인 톤을 유지하는지 평가합니다.",
threshold=0.8,
)
assert_test(test_case, [relevancy, faithfulness, tone])# pytest로 직접 실행
deepeval test run test_chatbot.py
# 결과를 Confident AI 대시보드로 전송
deepeval test run test_chatbot.py --confident| 메트릭 | 설명 | RAG 관련 |
|---|---|---|
| Answer Relevancy | 응답이 질문에 관련되는 정도 | 아니오 |
| Faithfulness | 응답이 컨텍스트에 충실한 정도 | 예 |
| Contextual Precision | 검색된 문서의 정밀도 | 예 |
| Contextual Recall | 검색된 문서의 재현율 | 예 |
| Hallucination | 환각(Hallucination) 정도 | 예 |
| GEval | 커스텀 기준 기반 평가 | 선택적 |
DeepEval의 GEval 메트릭은 자연어로 평가 기준을 정의하면 LLM이 이를 기반으로 채점합니다. "응답이 200자 이내인가", "한국어로 작성되었는가" 등 비즈니스 규칙을 코드 없이 메트릭으로 정의할 수 있어 매우 유연합니다.
promptfoo는 프롬프트 엔지니어링과 CI/CD 통합에 특화된 도구입니다. 프롬프트의 변경이 품질에 미치는 영향을 자동으로 검증하고, 레드팀 테스트를 통해 안전성을 점검합니다.
# 프롬프트 정의
prompts:
- file://prompts/customer_support_v1.txt
- file://prompts/customer_support_v2.txt
# 테스트할 모델
providers:
- id: openai:gpt-4o
config:
temperature: 0
- id: anthropic:claude-3-5-sonnet
config:
temperature: 0
# 테스트 케이스
tests:
- vars:
query: "환불 절차가 어떻게 되나요?"
assert:
- type: contains
value: "환불"
- type: llm-rubric
value: "응답이 환불 절차를 단계별로 안내하고 있는가"
- type: cost
threshold: 0.01 # 요청당 최대 비용 $0.01
- type: latency
threshold: 2000 # 최대 지연시간 2000ms
- vars:
query: "경쟁사 제품을 추천해주세요."
assert:
- type: not-contains
value: "추천"
- type: llm-rubric
value: "자사 제품의 장점을 설명하면서 정중하게 안내하는가"# 평가 실행
promptfoo eval
# 결과 웹 UI로 확인
promptfoo view
# CI/CD에서 사용 (비대화형 모드)
promptfoo eval --no-cache --output results.json# 자동 레드팀 테스트 생성 및 실행
promptfoo redteam init
promptfoo redteam runpromptfoo의 레드팀 기능은 자동으로 공격적인 프롬프트를 생성하여 모델의 안전성 취약점을 탐색합니다. 탈옥(Jailbreak) 시도, 유해 콘텐츠 유도, 개인정보 추출 시도 등 다양한 공격 벡터를 자동으로 테스트합니다.
Evidently AI는 프로덕션 환경에서의 모델 모니터링과 드리프트(Drift) 감지에 초점을 맞춥니다. 모델이 배포된 이후에도 품질이 유지되는지 지속적으로 검증합니다.
from evidently import ColumnMapping
from evidently.report import Report
from evidently.metric_preset import TextEvals
from evidently.descriptors import TextLength, Sentiment, LLMEval
# 텍스트 품질 리포트 생성
report = Report(metrics=[
TextEvals(
column_name="response",
descriptors=[
TextLength(),
Sentiment(),
LLMEval(
subcolumn="faithfulness",
provider="openai",
model="gpt-4o-mini",
template="Is the response faithful to the given context? "
"Context: {context}. Response: {response}. "
"Answer with a score from 0 to 1.",
),
],
),
])
report.run(
reference_data=golden_dataset, # 기준 데이터
current_data=production_logs, # 현재 프로덕션 데이터
column_mapping=ColumnMapping(
text_features=["response"],
),
)
# HTML 리포트 저장
report.save_html("drift_report.html")Evidently AI의 핵심 가치는 시간에 따른 변화 감지입니다. 모델 자체가 변하지 않더라도, 입력 데이터의 분포가 변하면(데이터 드리프트) 출력 품질이 저하될 수 있습니다. Evidently는 이러한 변화를 자동으로 감지하여 알림을 보냅니다.
W&B Weave는 Weights & Biases의 LLM 평가 도구입니다. 실험 추적 플랫폼과의 깊은 통합이 강점입니다.
LangSmith는 LangChain 생태계와 긴밀히 통합된 평가 플랫폼입니다.
Ragas(RAG Assessment)는 RAG 파이프라인 평가에 특화된 프레임워크입니다.
from ragas import evaluate
from ragas.metrics import (
answer_relevancy,
context_precision,
context_recall,
faithfulness,
)
from datasets import Dataset
# RAG 파이프라인의 출력을 준비
eval_dataset = Dataset.from_dict({
"question": ["한국의 수도는 어디인가요?"],
"answer": ["한국의 수도는 서울입니다. 서울은 한강을 중심으로 발전한 도시입니다."],
"contexts": [["서울은 대한민국의 수도이며 최대 도시입니다.", "한강은 서울을 관통하는 강입니다."]],
"ground_truth": ["서울"],
})
result = evaluate(
eval_dataset,
metrics=[
answer_relevancy,
context_precision,
context_recall,
faithfulness,
],
)
print(result)프로젝트의 요구사항에 따라 적합한 도구가 다릅니다. 다음 의사결정 흐름을 참고하세요.
실전에서는 하나의 도구만 사용하는 경우가 드뭅니다. 다음은 일반적인 조합 패턴입니다.
모델 후보 비교: lm-evaluation-harness
최종 후보 심층 분석: HELM
프로덕션 배포 후: Evidently AI + promptfoo
RAG 파이프라인 평가: Ragas
프롬프트 변경 테스트: promptfoo
CI/CD 통합 회귀 테스트: DeepEval
에이전트 벤치마크: Inspect AI
안전성 검증: promptfoo (레드팀)
프로덕션 모니터링: LangSmith + Evidently AI
도구를 선택할 때 가장 중요한 기준은 팀의 기존 워크플로우와의 통합성입니다. 아무리 좋은 도구라도 팀이 실제로 사용하지 않으면 무의미합니다. 기존에 pytest를 사용하는 팀이라면 DeepEval이, GitHub Actions를 적극 활용하는 팀이라면 promptfoo가 자연스러운 선택입니다.
| 도구 | 유형 | 오픈소스 | CI/CD 통합 | RAG 평가 | 에이전트 평가 | 주요 강점 |
|---|---|---|---|---|---|---|
| lm-eval-harness | 학술 | O | 제한적 | X | X | 벤치마크 커버리지 |
| HELM | 학술 | O | X | X | X | 다차원 종합 평가 |
| Inspect AI | 학술/실무 | O | 가능 | X | O | 에이전트 평가 |
| DeepEval | 실무 | O | O | O | X | 단위 테스트 스타일 |
| promptfoo | 실무 | O | O | 제한적 | X | CI/CD + 레드팀 |
| Evidently AI | 실무 | O | O | X | X | 드리프트 모니터링 |
| W&B Weave | 플랫폼 | 부분 | O | O | X | 실험 추적 통합 |
| LangSmith | 플랫폼 | X | O | O | X | LangChain 통합 |
| Ragas | 실무 | O | O | O | X | RAG 전문 |
7장에서는 기존 프레임워크에 의존하지 않고 커스텀 평가 하네스를 직접 설계하고 구축하는 방법을 다룹니다. 도메인 특화 평가 태스크 설계, 메트릭 정의, LLM-as-Judge 구현, 인간 평가 통합, Python으로 처음부터 평가 하네스를 구축하는 실습까지 진행합니다.
이 글이 도움이 되셨나요?
관련 주제 더 보기
도메인 특화 평가 하네스를 처음부터 설계하고 구축합니다. 평가 태스크 설계, 메트릭 정의, LLM-as-Judge 구현, 인간 평가 통합, Golden Dataset 관리를 코드와 함께 실습합니다.
UK AISI의 Inspect AI를 분석합니다. 에이전트 벤치마크 GAIA, SWE-Bench, Cybench의 실행, 샌드박싱 환경, 태스크/솔버/스코러 아키텍처, 멀티에이전트 평가까지 다룹니다.
벤치마크 오염 문제, 좋은 벤치마크의 조건, 다차원 평가 설계, 도메인별 벤치마크 구축, 데이터셋 버전 관리, 통계적 유의성 검증까지 벤치마크 스위트 설계의 전체를 다룹니다.