[AI설계] RAG 평가와 운영 - 검색이 틀렸는가, 생성이 틀렸는가

RAG 시스템은 단순한 LLM 호출이 아니라, 여러 단계로 이루어져있다.

1. 사용자 질문
2. 관련 문서 검색
3. 문서를 프롬프트에 넣기
4. LLM 답변 생성
5. 출처와 함께 반환

그래서 RAG 답변이 틀렸을 때 원인도 여러 가지다.

• 검색이 잘못됐을 수 있다.
• 검색은 맞았는데 LLM이 문서를 잘못 읽었을 수 있다.
• 답은 맞았는데 출처가 틀렸을 수 있다.
• 문서 자체가 오래됐을 수 있다.

RAG 평가는 이 원인을 분리해서 보는 작업이다.

예시로 보기

질문이 들어왔다고 하자.

질문:
해외배송 상품을 환불하면 위약금은 얼마인가요?

정답을 만들려면 두 개의 근거가 필요하다.

• 근거 A: 해외배송 상품의 환불 정책
• 근거 B: 환불 정책이 참조하는 위약금 산정 조항

RAG 시스템은 이 두 근거를 찾아서 LLM에게 줘야 한다.

정상적인 흐름은
질문 → 검색 단계에서 A와 B를 찾음 → LLM이 A와 B를 함께 읽음 → 위약금 금액과 조건을 답변 → A와 B를 출처로 표시
이지만, 실제로는 여러 실패가 있을 수 있다.

RAG 실패 유형

검색 실패

검색 단계에서 필요한 근거를 못 찾은 경우.

검색 결과:
A. 해외배송 환불 정책
C. 국내배송 교환 정책
D. 고객센터 운영 시간

필요한 근거 B: 위약금 산정 조항이 빠졌을 경우.
이 때 LLM은 정확한 답을 만들기 어렵다. 없는 근거를 정확히 사용할 수는 없기 때문에.

생성 실패

검색은 필요한 근거를 찾았지만, LLM이 잘못 답한 경우.

검색 결과에는 A와 B가 모두 있음.
그런데 LLM이 B의 위약금 조건을 잘못 해석함.

→ 검색(retrieval)은 성공했지만 생성(generation)이 실패한 경우

출처 실패

답변 내용은 맞지만 출처 표시가 틀린 경우.

답변:
위약금은 10,000원입니다.

실제 근거:
B. 위약금 산정 조항

표시된 출처:
A. 해외배송 환불 정책

답은 맞아도 출처가 틀리면 사용자가 검증할 수 없다. 법령, 정책, 계약서 기반 RAG에서는 출처 정확도가 매우 중요하다.

최신성 실패

검색된 문서가 오래된 경우.

현재 정책:
2026년 6월 개정판

검색된 문서:
2025년 12월 구버전

LLM은 검색된 문서를 기준으로 답변하기 때문에, 문서가 오래되면 답변도 오래된 기준으로 나간다.

RAG 실패 원인

평가를 단계별로 나누는 이유

RAG를 최종 결과(end-to-end)만 보고 평가하면 원인을 알기 어렵다.

만약 최종 답변이 틀렸다고 했을 때, 가능한 원인은

1. 검색 결과에 정답 근거가 없었다.
2. 검색 결과에는 있었지만 LLM이 무시했다.
3. LLM이 맞게 읽었지만 답변 형식이 틀렸다.
4. 출처를 잘못 붙였다.
5. 문서 버전이 오래됐다.

인데, 이 중 어떤 것인지 원인을 모르면 개선도 어렵다.

따라서 평가는 보통 세 단계로 나눈다.

1. 검색(Retrieval) 평가: 필요한 문서를 찾았는가?
2. 생성(Generation) 평가: 찾은 문서를 바탕으로 맞게 답했는가?
3. 최종 결과(End-to-end) 평가: 사용자 입장에서 최종 답변이 좋은가?

Golden Set

정의

RAG 시스템을 평가하기 위해 미리 만들어둔 기준 질문 세트다.

구성요소

• 질문
• 정답
• 필요한 근거 문서 ID
• 허용 가능한 답변 범위
• 주의해야 할 문서 버전

- id: q_001
  question: "해외배송 상품을 환불하면 위약금은 얼마인가요?"
  answer: "해외배송 상품 환불 시 위약금은 10,000원이며, 단순 변심 환불에 적용된다."
  required_contexts:
    - policy_refund_overseas_2026
    - clause_penalty_2026
  must_not_use:
    - policy_refund_overseas_2025
  category: "환불/해외배송"

Golden Set이 없으면 RAG 개선이 감으로 흐른다.

전보다 좋아진 것 같은데?
이 질문은 잘 되는데 다른 질문은?
검색 설정을 바꾸면 전체적으로 좋아진 건가?

Golden Set이 있으면 변경 전후를 비교할 수 있다.

좋은 Golden Set은 쉬운 질문만 모아두지 않는다.
자주 들어오는 질문, 자주 실패하는 질문, 문서 여러 개를 함께 봐야 하는 질문, 최신 버전이 중요한 질문을 섞어야 한다.
그래야 설정을 바꿨을 때 “데모용 질문만 좋아진 것”인지 “운영에서 중요한 질문도 좋아진 것”인지 구분할 수 있다.

Retrieval 평가

검색 단계만 평가.

질문에 대해 필요한 근거 문서가 검색 결과 안에 들어왔는지 본다.

여기서는 LLM 답변이 예쁜지, 문장이 자연스러운지는 보지 않는다.
오직 “답변에 필요한 재료를 검색이 가져왔는가”만 본다.

Hit@k

필요한 문서가 top-k 검색 결과 안에 하나라도 있으면 성공.

질문에 필요한 문서: B
검색 top-5 결과: A, C, B, D, E

B가 top-5 안에 있으므로 Hit@5 = 1

질문에 필요한 문서: B
검색 top-5 결과: A, C, D, E, F

B가 없으므로 Hit@5 = 0

• Hit@k는 단순하고 직관적
• 필요한 문서가 여러 개인 경우에는 부족할 수 있다.

Recall@k

필요한 문서들 중 top-k 안에 들어온 비율.

필요한 문서: A, B, C
검색 top-5 결과: A, D, B, E, F

→ A와 B는 찾았지만 C는 못 찾았다.
→ Recall@5 = 2 / 3 = 0.667

RAG에서는 Recall@k가 매우 중요하다.

왜냐하면 필요한 근거가 검색 결과에 없으면 LLM이 답을 만들 수 없기 때문이다.

Precision@k

top-k 결과 중 실제로 관련 있는 문서의 비율.

검색 top-5 결과: A, B, D, E, F
관련 문서: A, B
→ Precision@5 = 2 / 5 = 0.4

Precision이 낮으면 LLM 프롬프트에 불필요한 문서가 많이 들어가고 불필요한 문서가 많으면 문제가 생긴다.

• LLM이 잘못된 문서를 참고할 수 있음
• 프롬프트 길이 증가
• 비용 증가
• 답변 집중도 하락

MRR

첫 번째 관련 문서가 몇 번째에 나왔는지.

검색 결과:
1위 D
2위 A
3위 B

첫 번째 관련 문서: A, 2위
Reciprocal Rank = 1 / 2 = 0.5

첫 관련 문서가 1위에 나오면 1.0

MRR은 관련 문서가 검색 결과 상단에 나오는지를 평가한다.

nDCG

검색 결과의 순서와 관련도 등급.

관련도를 0/1이 아니라 여러 단계로 줄 수 있다.

• 3점: 반드시 필요한 핵심 근거
• 2점: 도움이 되는 보조 근거
• 1점: 약간 관련 있음
• 0점: 무관

nDCG는 높은 관련도의 문서가 상위에 있을수록 높은 점수를 준다.

RAG에서는 문서가 단순히 관련/무관으로 나뉘지 않는 경우가 많기 때문에, nDCG가 유용할 수 있다.

Generation 평가

검색 결과가 좋다고 최종 답변이 항상 좋은 것은 아니다.

LLM이 근거를 잘못 읽거나, 없는 내용을 만들어낼 수 있다.

Generation 평가는 다음을 본다.

• 답변이 정답과 맞는가?
• 근거에 충실한가?
• 출처가 정확한가?
• 불필요한 추측이 없는가?

검색 결과가 좋았는데도 답변이 틀렸다면, 검색 설정을 바꾸는 것보다 프롬프트, 모델, 답변 형식, 검증 로직을 봐야 한다.
이 구분을 하지 않으면 이미 잘 찾고 있는 검색기를 계속 만지게 된다.

Correctness

답변 내용이 정답과 맞는지 보는 지표.

• 정답: 위약금은 10,000원이다.
• 답변: 위약금은 10,000원입니다.
  → correct
• 답변: 위약금은 5,000원입니다.
  → incorrect

Correctness는 최종 사용자가 가장 직접적으로 느끼는 품질이다. 그러나 이것만 보면 근거 사용 여부를 알 수 없다.

Faithfulness / Groundedness

답변이 제공된 근거에 충실한지 보는 개념.

검색 근거: 위약금은 10,000원이다.

답변: 위약금은 10,000원입니다.

→ 근거에 충실

답변: 위약금은 10,000원이며, VIP 고객은 면제됩니다.

→ VIP 면제 내용이 근거에 없으면 불충실

답변이 사실처럼 보이더라도, 근거에 없는 내용이면 RAG 답변으로는 문제가 있다.
RAG의 목표는 LLM의 상식이나 추측이 아니라, 제공된 문서에 근거한 답변이기 때문이다.

Citation Accuracy

Citation Accuracy는 답변의 각 주장에 맞는 출처가 붙었는지 본다.

답변:
위약금은 10,000원입니다. [출처: B]

실제 근거:
B. 위약금 산정 조항

이 경우 citation은 맞다.

답변:
위약금은 10,000원입니다. [출처: A]

A는 해외배송 환불 정책이고,
위약금 금액은 B에 있음.

답변 내용은 맞아도 출처는 틀렸다.

정책/법령/계약서 RAG에서는 citation accuracy가 특히 중요하다.

Answer Completeness

답변이 필요한 조건을 빠짐없이 포함했는지 본다.

질문:
해외배송 상품 환불 시 위약금은 얼마인가요?

완전한 답변:
위약금은 10,000원이며, 단순 변심 환불에 적용됩니다.
상품 하자 환불에는 적용되지 않습니다.

불완전한 답변:
위약금은 10,000원입니다.

금액은 맞지만 적용 조건이 빠졌다.

End-to-End 평가

최종 결과(end-to-end) 평가는 사용자가 보는 최종 결과를 평가한다.

다음을 모두 포함한다.

• 질문 이해
• 검색 품질
• 답변 정확성
• 근거 충실성
• 출처 정확성
• 표현 명확성
• 응답 시간

운영에서는 최종 결과 만족도가 중요하다.

하지만 개선할 때는 반드시 retrieval과 generation을 분리해서 원인을 봐야 한다.

운영 로그 설계

RAG를 운영하려면 로그를 잘 남겨야 한다.
답변만 저장하면 원인 분석이 어렵다.

저장하면 좋은 정보:

• 질문 원문
• 질문 임베딩 모델 버전
• 검색 top-k 문서 ID
• 검색 점수
• metadata 필터 조건
• reranker 결과
• LLM 프롬프트 버전
• LLM 모델 버전
• 최종 답변
• 출처 ID
• 응답 시간
• 사용자 피드백

이 로그가 있어야 나중에 이런 분석이 가능하다.

• 검색이 문서를 못 찾았나?
• 찾았는데 LLM이 무시했나?
• 특정 문서 버전에서만 문제가 생기나?
• top-k가 너무 작나?
• 필터가 너무 강한가?

실패 분석 예시

해외배송 상품을 환불하면 위약금은 얼마인가요?

케이스 1: 검색 결과에 B가 없음

• 검색 결과:
  
  • A. 해외배송 환불 정책
  • C. 국내배송 환불 정책
  • D. 고객센터 안내
• 원인: 검색 실패
• 개선:
  • chunking 재검토
  • hybrid search 추가
  • GraphRAG로 참조 조항 확장
  • top-k 증가
  • reranker 적용

케이스 2: 검색 결과에 A/B가 모두 있음, 답변이 틀림

• 검색 결과:
  
  • A. 해외배송 환불 정책
  • B. 위약금 산정 조항
• 답변: 위약금은 5,000원입니다.
• 원인: 생성 실패
• 개선:
  • 프롬프트에 근거 인용 규칙 강화
  • 답변 형식 구조화
  • 계산/금액 추출 검증 로직 추가
  • 더 강한 모델 사용

케이스 3: 답은 맞지만 출처가 틀림

• 답변: 위약금은 10,000원입니다. [A]
• 실제 금액 근거: B
• 원인: citation 실패
• 개선:
  • 문장별 citation 요구
  • 출처-주장 매칭 검증
  • LLM 후처리 검증

개선 루프

RAG 운영은 한 번 만들고 끝이 아니라, 반복적으로 개선해야 한다.

1. 사용자 질문 수집
2. 실패 사례 라벨링
3. 실패 원인 분류
4. 검색/생성/문서 중 원인 파악
5. 설정 변경
6. Golden Set으로 회귀 테스트
7. 배포
8. 모니터링

중요한 점은 변경 후 반드시 기존 질문들이 나빠지지 않았는지 확인하는 것이다.

새 질문은 좋아졌는데 기존 핵심 질문이 망가질 수 있다.

그래서 regression test가 필요하다.

변경할 수 있는 요소

RAG 품질을 개선할 때 바꿀 수 있는 것은 많다.

• Retrieval 
  • chunk 크기
  • chunk overlap
  • embedding 모델
  • 벡터 검색 metric
  • top-k
  • 메타데이터 필터
  • hybrid search 가중치
  • reranker 사용 여부
    GraphRAG 확장 범위
• Generation 
  • LLM 모델
  • 프롬프트
  • temperature
  • 답변 형식
  • citation 규칙
  • 모르는 경우 답변 정책
• Data 쪽
  • 문서 최신화
  • 중복 문서 제거
  • 문서 버전 관리
  • 문서 구조 정리
  • 표/이미지 텍스트화
  • 메타데이터 보강

개선할 수 있는 지점이 많기 때문에, 로그와 평가 세트 없이 감으로 고치면 위험하다.

모니터링 지표

• 검색 결과 없음 비율
• 평균 검색 점수
• top-k score 분포
• 응답 latency p50/p95/p99
• LLM 오류율
• 사용자 재질문율
• 사용자 thumbs down 비율
• citation 누락률
• 구버전 문서 사용률
• fallback 발생률

특히 RAG에서는 문서 변경이 성능에 큰 영향을 준다.
문서가 업데이트되었는데 재색인이 안 되면 최신성 문제가 생기기 때문.

배포 전략

RAG 설정을 바꿀 때는 바로 전체 배포하지 않는 것이 좋다.

가능한 방식:

• 오프라인 Golden Set 평가
• 소수 트래픽 A/B 테스트
• 내부 사용자 대상 베타
• 점진적 rollout
• 문제 발생 시 rollback

RAG는 검색 인덱스, 문서, 프롬프트, 모델이 모두 얽혀 있어, 작은 변경도 예상보다 큰 영향을 줄 수 있다.