RAGAS·DeepEval로 RAG 환각 측정 — 7가지 메트릭 평가 가이드 2026년 5월

RAG 환각, 평가 프레임워크로 줄이기

RAG 시스템 운영하는 분이라면 ‘이상한 답변 나옴’ ‘출처에 없는 내용 생성’ 같은 환각 사고 한 번씩은 겪으셨죠? 문제는 측정 없이는 그 사고가 얼마나 자주 일어나는지, 어떤 변경이 실제로 도움이 됐는지 아무도 모른다는 점이에요.

평가 프레임워크의 핵심 가치는 ‘감’으로 하던 개선을 숫자로 바꿔준다는 데 있어요. 첫 측정값이 나오면 본인 RAG가 검색에서 무너지는지 생성에서 무너지는지 바로 드러나고, 이후 변경마다 효과를 대조할 기준선이 생깁니다. 이번 글에서는 7가지 메트릭 평가 가이드를 한국어 RAG 환경 기준으로 정리합니다.

메트릭 1 — Faithfulness (충실도)

‘LLM 생성 답변이 검색된 컨텍스트에 부합하는가’. 5월 표준 임계값 0.75+.

from ragas.metrics import faithfulness
from ragas import evaluate

result = evaluate(
    dataset=test_dataset,
    metrics=[faithfulness],
    llm=judge_llm  # judge LLM (사용 중인 최신 모델로 지정)
)
print(result["faithfulness"])

faithfulness 낮은 경우 원인 분석. (1) 검색된 컨텍스트와 답변 사이 일치 부족. (2) LLM이 자신의 지식 사용 (출처 무시). (3) 컨텍스트 자체가 부정확.

한국 RAG에서 가장 흔한 사고가 ‘LLM이 자신의 사전 학습 지식을 답변에 섞어버리는 패턴’이에요. 시스템 프롬프트에 ‘반드시 제공된 컨텍스트 안에 있는 정보로만 답하세요’ 명시 하나만 추가해도 faithfulness가 눈에 띄게 올라가는 경우가 많아요. 한 줄 변경으로 재측정까지 몇 분이면 끝나니까 첫 개선 작업으로 적용해보시기 바랍니다.

메트릭 2 — Answer Relevancy (응답 관련성)

‘답변이 질문과 얼마나 관련 있는가’. 임계값 0.8+.

질문 ‘파이썬 리스트 정렬 방법은?’에 LLM이 ‘딕셔너리는 키 기반 자료구조입니다’ 답변하면 관련성 0점.

from ragas.metrics import answer_relevancy

result = evaluate(
    dataset=test_dataset,
    metrics=[answer_relevancy]
)

한국어 RAG에서 자주 발생하는 사고가 ‘질문 의도 파악 실패 → 동음이의어 답변’. ‘공’ 질문에 ‘구球 공’ 답변 대신 ‘공무원’ 답변하는 식. answer relevancy 측정으로 사전 탐지 가능.

한국어 동음이의어 처리는 ‘질문 재작성 단계’ 추가로 거의 해결 가능해요. RAG 파이프라인 시작 부분에 ‘사용자 질문을 더 명확하게 재작성하는 LLM 호출’ 단계 추가하면 ‘공’ 같은 모호한 질문이 ‘운동에서 사용하는 둥근 공’ 같이 명확해져요. 추가 비용은 호출당 약 100~200 토큰이지만 answer relevancy 0.1~0.15 향상 효과가 누적돼서 본전 회수가 빠른 패턴이에요.

메트릭 3 — Context Precision (검색 정확도)

‘검색된 컨텍스트가 관련 있는 정보만 포함하는가’. 임계값 0.7+.

5월 시점 한국 RAG에서 가장 자주 약점으로 나타나는 메트릭. 이유는 한국어 임베딩 모델이 영어 대비 검색 정확도가 약간 떨어지기 때문.

from ragas.metrics import context_precision

result = evaluate(
    dataset=test_dataset,
    metrics=[context_precision]
)

낮은 context precision 개선 방법. (1) BM25 + 임베딩 하이브리드 검색. (2) Reranker 모델 추가 (Cohere Rerank·Voyage). (3) 청크 크기 최적화 (200~500 토큰 권장).

한국어 RAG에서 context precision 가장 빠른 개선 패턴이 ‘하이브리드 검색 + Reranker’ 조합이에요. BM25는 키워드 매칭에 강하고 임베딩은 의미 검색에 강해서, 둘을 함께 쓰면 한쪽만 썼을 때 놓치던 문서가 눈에 띄게 줄어요. 거기에 Cohere Rerank 같은 reranker를 한 단계 더 얹으면 상위 결과의 순서가 정리됩니다. 개선 폭은 문서 특성에 따라 다르니 도입 전후 context_precision을 반드시 대조해서 확인하세요.

메트릭 4 — Context Recall (검색 회상률)

‘질문에 답하기 위해 필요한 모든 정보가 검색되었는가’. 임계값 0.8+.

context precision과 context recall은 ‘정밀도·재현율’ trade-off 관계. 5월 표준은 ‘정밀도 우선 + 재현율 보조’ 분기. 의료·법률 RAG는 recall 0.9+ 필수.

의료 RAG에서 recall이 낮으면 ‘약물 부작용 정보가 누락된 답변’ 같이 사용자 건강에 영향 주는 사고가 발생할 수 있어요. 법률 RAG도 마찬가지로 ‘판례 누락 → 잘못된 자문’ 케이스가 위험. 의료·법률 영역 RAG는 출시 전 무조건 recall 0.9+ 임계값 통과 강제하는 정책이 5월 표준이고, 일반 정보 검색은 0.8+ 정도면 충분해요.

메트릭 5 — Factual Correctness (사실 정확도)

5월 신규 RAGAS 메트릭. ‘답변이 실제 세계 사실로 정확한가’. faithfulness와 별도 측정 필요.

한국어 의료·법률·금융 RAG는 factual correctness 임계값 0.95+ 필수. 일반 정보 검색은 faithfulness 0.75+가 표준.

메트릭 6 — Hallucination (환각률)

DeepEval 전용 메트릭. 답변에서 ‘출처 없는 주장’ 비율 측정.

from deepeval.metrics import HallucinationMetric
from deepeval.test_case import LLMTestCase

test_case = LLMTestCase(
    input="질문",
    actual_output="LLM 답변",
    context=["검색된 문서 1", "검색된 문서 2"]
)

metric = HallucinationMetric(threshold=0.1, model=JUDGE_MODEL)
metric.measure(test_case)
print(metric.score)  # 낮을수록 좋음

5월 표준 임계값 0.1 이하. 0.1 = 답변 10개 중 1개꼴로 환각 포함. 의료·법률은 0.05 이하 필수.

환각 측정 임계값을 어떻게 잡을지가 한국 사용자 가장 자주 질문하는 부분이에요. 0.1 임계값을 처음 적용하면 통과율이 낮아서 ‘이거 너무 엄격한 거 아닌가’ 의문 들지만 실제로는 ‘이 임계값 통과 못 한 시스템이 운영되면 사용자 피해’가 더 큽니다. 처음 1~2주는 통과율 30~50%로 시작해도 괜찮고 청킹·검색·프롬프트 개선 사이클 돌리면 4주 후 80~90% 통과율 도달이 일반적이에요.

메트릭 7 — Coherence (일관성)

5월 신규 추가 메트릭. ‘답변 내부 논리 일관성’. 같은 답변 안에서 모순된 주장하는지 측정.

긴 답변일수록 coherence 떨어지는 경향. 한국어 RAG는 영어 대비 coherence 약 0.05~0.1 낮은 편. 보고서·논문 RAG에서 중요.

한국어 긴 답변에서 coherence 사고가 자주 일어나는 이유는 ‘앞부분에서 ~합니다 격식체 → 뒷부분에서 ~예요 구어체’ 같이 톤이 섞이거나 ‘앞에서는 A 주장 → 뒤에서는 A를 반박하는 주장’ 같이 논리 모순이 나타나는 경우예요. 시스템 프롬프트에 ‘답변 전체에서 일관된 톤과 논리 유지’ 명시하면 coherence 0.05~0.1 향상되니까 적용 권장.

RAGAS + DeepEval 통합 워크플로

5월 시점 표준 통합 패턴.

# rag_eval_pipeline.py
from ragas import evaluate
from ragas.metrics import (
    faithfulness, answer_relevancy,
    context_precision, context_recall,
    factual_correctness
)
from deepeval.metrics import HallucinationMetric
from deepeval.test_case import LLMTestCase

# 1. RAGAS로 핵심 메트릭 측정
ragas_result = evaluate(
    dataset=test_dataset,
    metrics=[
        faithfulness, answer_relevancy,
        context_precision, context_recall,
        factual_correctness
    ],
    llm=judge_llm
)

# 2. DeepEval로 임계값 검증 + CI 통합
test_cases = build_test_cases(test_dataset)
hallucination = HallucinationMetric(threshold=0.1)

for tc in test_cases:
    hallucination.measure(tc)
    assert hallucination.is_successful()

LLM API 비용 80% 절감 8가지 전략에서 평가 비용 최적화 전략을 함께 참고하시면 비용 부담 줄일 수 있어요.

도메인별로 약점이 갈리는 지점

같은 RAG라도 도메인에 따라 먼저 무너지는 메트릭이 달라요. 어디부터 볼지 감을 잡는 용도로 정리했어요.

개선은 ‘평가 프레임워크만 도입’으로 되지 않아요. ‘측정 → 약점 발견 → 청킹·검색·프롬프트 최적화 → 재측정’ 사이클이 실제 작업입니다.

진행 방식은 한 주에 한 가지만 바꾸고 매번 재측정하는 패턴을 권해요. 예를 들어 첫 주는 시스템 프롬프트에 컨텍스트 한정 명시, 둘째 주는 청크 크기 조정, 셋째 주는 Reranker 도입, 넷째 주는 프롬프트 다듬기 순으로요. 한꺼번에 서너 가지를 바꾸면 점수가 올라도 무엇이 효과였는지 알 수 없어서 다음 판단 근거가 남지 않습니다.

법률 도메인은 ‘판례 검색 정확도’가 핵심이라 하이브리드 검색 도입이 특히 크게 작용하는 편이에요. 한국 법률 자료는 한자어 비중이 높아서 임베딩만 사용하면 매칭 안 되는 케이스가 많은데, BM25 키워드 매칭을 보조로 붙이면 이런 누락을 잡아낼 수 있어요.

5월 시점 도입 우선순위 5단계

‘RAGAS = 탐색, DeepEval = CI, Patronus = 프로덕션’ 3단 분기가 5월 시점 한국 RAG 운영 표준이에요. 이 3단 분기의 본전 분기가 명확한 이유는 ‘각 단계에서 다른 가치 제공’이라는 점이에요. RAGAS는 학술적 기준이라 메트릭 정의 신뢰성 높고, DeepEval은 pytest 호환이라 기존 CI/CD에 자연스럽게 들어가고, Patronus는 프로덕션 트래픽에서 실시간 모니터링 가능. 한 가지 도구만 쓰면 ‘탐색·CI·프로덕션’ 중 약점 영역 발생하니까 세 가지 모두 사용이 본전 분기 가장 안정적이에요.

평가 비용 정리

LLM-as-judge 평가 비용은 다음 공식으로 계산돼요.

• 메트릭 개수 × 테스트 케이스 수 = 1회 실행당 judge 호출 건수
• 호출 건수 × judge 모델 단가 = 1회 실행 비용
• 1회 실행 비용 × CI 실행 빈도 = 월 비용

메트릭 5개에 테스트 케이스 100건이면 실행마다 수백 건 호출이 발생하고, 매일 CI에서 돌리면 그만큼 누적됩니다. 단가는 어떤 judge 모델을 쓰느냐로 결정되니 제공사 공식 요금표에서 확인하세요. 비용을 줄이려면 테스트 케이스를 무작정 늘리기보다 ‘실패 사례 중심으로 100건 안팎을 잘 고르는’ 편이 효율적이에요. 환각 감소로 절약되는 ‘고객 컴플레인·재작업 시간’ 가치를 감안하면 회수가 빠른 영역입니다.

흔한 실수 5가지

실수 1 — 평가 없이 RAG 운영 문제를 인지조차 못 한 채 운영하게 됩니다. 사고가 한 번 터지면 수습 비용이 평가 비용과 비교가 안 돼요.

실수 2 — Judge LLM에 약한 모델 사용 세대가 낮은 모델을 judge로 쓰면 한국어 평가 자체가 부정확해서 점수를 믿을 수 없어요. 가용한 최신 모델 사용을 권장합니다.

실수 3 — 임계값 너무 낮게 설정 faithfulness 0.5 임계값으로 시작하면 ‘평가 통과하는데 사용자는 환각 사고’ 발생. 0.75+ 권장.

실수 4 — 한 번 평가 후 끝 RAG 시스템 변경마다 평가 필요. CI 통합 필수.

실수 5 — 모든 메트릭 100% 추구 faithfulness 1.0은 ‘출처 그대로 복붙’ 의미. 적정 임계값 0.85~0.95가 자연스러운 답변과 정확성 균형.

마무리 — 지금 당장 할 수 있는 액션

5월 16일 시점 추천 액션 순서는 이래요.

먼저 RAGAS 설치 + 4가지 핵심 메트릭 측정. pip install ragas 한 줄 + 테스트 데이터 100건 준비 + 30분 작업이면 첫 측정 가능해요. 첫 측정 결과 보면 본인 RAG가 어느 영역 약한지 즉시 파악돼요. 측정 데이터 없이 ‘대충 잘 되겠지’ 운영하는 RAG는 환각 사고 발생 시 복구 비용이 정말 크게 들어요.

다음 가장 약한 메트릭부터 개선. 한국어 RAG에서 가장 흔한 약점이 context_precision. 개선 방법은 BM25 + 임베딩 하이브리드 검색 → Reranker 추가 → 청크 크기 최적화 3단계.

DeepEval로 CI 통합. GitHub Actions에 deepeval test run 명령 추가. PR마다 자동 평가 + 임계값 통과 강제. 5월 시점 한국 스타트업 RAG 운영 표준 패턴이에요. 한 번 CI 통합해두면 ‘새 코드 변경 시 자동 평가 → 임계값 미달 시 빌드 실패’ 패턴이 자동화되니까 사람 손 없이 품질 유지 가능해요.

4주 사이클로 측정·개선·재측정 반복. 목표치는 남의 숫자가 아니라 본인 시스템의 첫 측정값을 기준선으로 잡으세요. 의료·법률·금융 같은 고위험 영역은 일반 서비스보다 훨씬 엄격한 임계값을 걸어야 안전합니다. 1주에 한 가지 변경 + 재측정 패턴이 효과 측정에 가장 정확한 방식이에요.

Patronus 같은 프로덕션 모니터링은 5단계 마지막. RAG 시스템 안정화 후 도입. 한 번에 다 도입하면 ‘어느 도구가 효과 있는지’ 측정 불가하니까 1~2주 간격 단계 도입이 안전해요. 단계마다 효과 측정 명확하게 해두면 후속 의사결정 근거가 쌓여서 본전 분기 명확해져요.

한두 달 동안 평가 사이클을 정착시키면 이후에는 모니터링만으로 안정 운영이 가능해져요. 환각 감소는 한 번 달성하고 끝나는 목표가 아니라 ‘유지·개선 사이클’ 운영 패턴이라, 처음 4~6주 투자가 가장 회수가 빠른 영역이에요.

한국 RAG 운영의 가장 큰 함정이 ‘출시 직후 평가 도입 미루기’ 패턴이에요. 출시 직후 트래픽 적을 때 평가 도입이 가장 쉬운데 ‘일단 더 만들고 나중에’ 미루다가 트래픽 늘어난 후엔 ‘대규모 평가 데이터 만들기 부담’으로 못 들어가는 케이스 많아요. 출시 1주차부터 평가 프레임워크 같이 도입이 본전 분기 가장 빠른 시점이에요. 한 번 운영 패턴이 자리잡으면 자동으로 굴러가니까 초기 투자가 가장 중요한 결정이에요.