RAG 품질을 올리려면 최종 답변 점수 하나만 봐서는 안 된다. 검색이 필요한 문서를 찾았는지, 가져온 문서에 잡음이 얼마나 섞였는지, 답변이 근거를 지켰는지를 분리해 측정해야 한다. 그래야 임베딩·청킹·검색 파라미터 문제를 프롬프트나 모델 문제로 오진하지 않는다.

RAG 평가는 검색과 답변을 따로 봐야 한다

RAG는 질문, 검색, 컨텍스트 조립, 답변 생성의 연쇄 시스템이다. 정답이 틀렸다는 결과만 기록하면 어느 단계가 고장 났는지 알 수 없다. 검색 결과에 정답 문서가 없었다면 생성 모델을 바꿔도 해결되지 않는다. 반대로 정답 문서가 들어왔는데 답변이 근거를 벗어났다면 검색 튜닝보다 프롬프트·모델·출력 검증을 손봐야 한다.

평가 구간	확인할 질문	대표 지표	실패 시 먼저 볼 곳
테스트셋	실제 사용 질문을 반영했는가	유형·난도·언어별 분포	운영 로그와 라벨 기준
검색	필요한 문서를 상위 K개 안에 찾았는가	Recall@K, MRR, nDCG@K	청킹, 임베딩, 필터, 하이브리드 검색
컨텍스트	관련 없는 문서가 답변을 방해하는가	Context Precision, 노이즈 민감도	K값, 재랭커, 문서 중복
답변	질문에 답하고 근거를 지켰는가	근거성, 관련성, 정확성	프롬프트, 모델, 인용·거절 규칙

테스트셋은 정답보다 실패 조건부터 설계한다

처음부터 수천 건을 만들 필요는 없다. 도입 초기는 핵심 업무 질문 50~100건으로 시작하되 질문 유형을 의도적으로 나누는 편이 실용적이다. 단순 사실 조회만 넣으면 실제 서비스의 긴 질문, 모호한 표현, 문서에 답이 없는 질문을 놓친다. 이후 운영 로그에서 실패 사례를 골라 테스트셋을 늘린다.

1. 정답이 한 문서에 있는 질문: 기본 검색 성능을 확인한다.
2. 여러 문서를 조합해야 하는 질문: 다중 근거 회수와 합성을 확인한다.
3. 문서에 답이 없는 질문: 근거 없는 생성 대신 모른다고 답하는지 본다.
4. 날짜·버전이 충돌하는 질문: 최신 문서 우선순위와 메타데이터 필터를 본다.
5. 오탈자·약어·한국어와 영어가 섞인 질문: 실제 입력 변형에 견디는지 본다.
6. 권한 밖 문서를 묻는 질문: 검색 단계에서 접근 제어가 지켜지는지 본다.

각 행에는 질문, 기대 답변, 관련 문서 ID, 반드시 포함할 사실, 허용 가능한 변형, 중요도, 실패 유형을 저장한다. 정답 문서 라벨이 없으면 검색 Recall을 계산할 수 없으므로 최소한 핵심 질문에는 관련 문서 ID를 사람이 붙이는 것이 좋다.

{
  "question": "환불 요청 가능 기간은?",
  "reference_answer": "수령 후 7일 이내",
  "relevant_doc_ids": ["policy-2026-08"],
  "must_include": ["7일"],
  "risk": "high",
  "expected_behavior": "answer_with_citation"
}

검색 품질은 Recall@K 하나로 끝나지 않는다

검색 평가는 관련 문서 라벨이 있을 때 가장 명확하다. Pinecone의 정보검색 평가 설명처럼 Recall@K는 관련 문서를 얼마나 놓치지 않았는지, MRR은 첫 관련 결과가 얼마나 위에 있는지, nDCG는 여러 결과의 관련도와 순서를 함께 본다. 서비스 목적에 따라 우선순위가 달라진다.

지표	무엇을 측정하는가	잘 맞는 상황	주의점
Recall@K	관련 문서 중 상위 K개 안에 찾은 비율	필요한 근거를 놓치면 안 되는 검색	K를 키우면 잡음과 생성 비용도 늘 수 있다
Precision@K	상위 K개 중 관련 문서의 비율	짧고 깨끗한 컨텍스트가 중요한 경우	관련 문서 전체를 놓치는 문제는 따로 봐야 한다
MRR	첫 관련 문서 순위의 역수 평균	정답 문서 하나를 빨리 찾는 FAQ	두 번째 이후 관련 문서 품질을 거의 반영하지 않는다
nDCG@K	관련도 등급과 순위를 함께 반영	부분 관련·핵심 관련을 구분할 수 있는 검색	등급 라벨 비용과 기준 합의가 필요하다
Context Precision	관련 컨텍스트가 앞쪽에 배치됐는지 평가	LLM 심사 기반으로 문맥 잡음을 점검	심사 모델과 프롬프트 변화에 영향을 받는다

실무에서는 Recall@K를 먼저 확보한 뒤 Precision과 지연·토큰 비용을 함께 줄이는 순서가 안전하다. 정답 문서를 못 가져오는 상태에서 컨텍스트를 짧게 만드는 것은 품질 개선이 아니라 근거 삭제가 될 수 있다. 검색 구조 자체를 설계하는 단계라면 GraphRAG와 벡터 검색의 차이도 함께 확인할 수 있다.

답변 평가는 근거성·관련성·정확성을 분리한다

LangSmith 공식 RAG 평가 튜토리얼은 답변과 정답의 정확성, 답변과 질문의 관련성, 답변과 검색 문서의 근거성, 검색 문서와 질문의 관련성을 서로 다른 비교로 정의한다. 이 분리가 중요하다. 근거에는 충실하지만 질문에 답하지 않는 문장도 있고, 그럴듯하고 유용하지만 문서에 없는 사실을 덧붙인 답변도 있기 때문이다.

평가 항목	비교 대상	판정 질문
정확성	생성 답변 ↔ 기준 답변	필수 사실이 맞고 충돌하는 내용이 없는가
답변 관련성	생성 답변 ↔ 사용자 질문	질문을 직접 해결하며 불필요하게 벗어나지 않는가
근거성	생성 답변 ↔ 검색 문서	답변의 주장마다 검색 문서에서 근거를 찾을 수 있는가
검색 관련성	검색 문서 ↔ 사용자 질문	가져온 문서가 질문 해결에 실제로 필요한가
거절 품질	답변 ↔ 문서 부재·정책	근거가 없거나 권한이 없을 때 안전하게 중단하는가

Ragas도 Context Precision·Context Recall·Response Relevancy·Faithfulness 같은 RAG 전용 지표를 제공한다. 다만 도구가 내놓은 0~1 점수를 절대적인 품질로 해석하면 안 된다. OpenAI 평가 가이드도 자동 지표를 사람 판단으로 보정하고, 실제 분포를 반영한 과업별 평가를 만들며, 변경 때마다 지속 평가할 것을 권한다.

최소 운영 절차는 7단계면 충분하다

1. 성공 기준을 먼저 쓴다. 예를 들어 핵심 정책 질문은 관련 문서가 상위 5개 안에 있어야 하고, 답변은 문서에 없는 숫자를 만들면 실패로 정의한다.
2. 실제 질문을 유형별로 모은다. 정상·경계·적대·답 없음 질문을 섞는다.
3. 관련 문서와 기준 답변을 라벨링한다. 위험도가 높은 질문부터 사람이 검수한다.
4. 검색기를 단독 실행한다. 답변 모델을 호출하기 전에 Recall@K·MRR·지연을 저장한다.
5. 생성기를 고정된 검색 결과로 평가한다. 검색 변동과 답변 변동을 분리한다.
6. 자동 심사와 사람 판정을 맞춘다. 불일치 사례를 보고 루브릭과 예시를 보완한다.
7. 모든 변경에서 회귀 테스트한다. 임베딩, 청킹, 프롬프트, 모델, 재랭커 변경 전후를 같은 데이터셋으로 비교한다.

평가 결과를 실행 단위 trace와 연결하면 원인 분석이 빨라진다. 검색 결과, 프롬프트 버전, 모델, 토큰, 지연, 평가 점수를 함께 남기는 방법은 AI 에이전트 관측 도구 비교와 AI 에이전트 비용 추적 가이드에서 이어서 볼 수 있다.

점수 조합으로 실패 원인을 좁힌다

관찰된 패턴	가능성이 큰 원인	다음 실험
Recall은 낮고 근거성은 높다	가져온 문서에는 충실하지만 정답 문서를 놓침	청킹·필터·하이브리드 검색·재랭커 비교
Recall은 높고 Context Precision이 낮다	K가 크거나 중복·주변 문서가 많음	K 축소, 중복 제거, 재랭킹
검색은 좋고 근거성이 낮다	프롬프트 또는 생성 모델이 문서 밖 사실을 추가	인용 강제, 주장 단위 검증, 거절 규칙
근거성은 높고 관련성이 낮다	문서를 요약했지만 질문에 직접 답하지 않음	답변 형식과 필수 항목 루브릭 보강
오프라인은 좋고 운영 불만이 많다	테스트셋이 실제 사용자 분포를 반영하지 못함	운영 로그 샘플링과 실패 사례 추가

비용과 보안도 평가 설계에 포함한다

LLM 심사기를 모든 운영 요청에 붙이면 품질 점검 비용과 지연이 커진다. 배포 전에는 전체 회귀 세트를 돌리고, 운영 중에는 위험도 기반 표본 추출과 실패 감지 후 재평가를 섞는 방식이 현실적이다. 규칙으로 판정 가능한 인용 유무·JSON 스키마·금칙어·문서 ID 일치 여부는 코드 평가기로 처리하고, 의미 판단이 필요한 항목만 LLM 심사기에 맡긴다.

외부 평가 서비스나 심사 모델로 질문·검색 문서·답변을 보내면 개인정보와 사내 문서가 함께 반출될 수 있다. 운영 전 데이터 보존 정책, 학습 사용 여부, 리전, 암호화, 접근 제어를 확인해야 한다. 테스트셋에는 고객 식별자를 가명 처리하고, 권한 필터가 적용된 문서만 평가 파이프라인에 전달한다.

FAQ

정답 데이터가 없어도 RAG 평가를 시작할 수 있나?

가능하다. 질문과 답변의 관련성, 답변과 검색 문서의 근거성, 질문과 검색 문서의 관련성은 기준 답변 없이도 LLM 심사나 사람 검토로 볼 수 있다. 다만 검색 Recall과 최종 정확성을 신뢰성 있게 측정하려면 핵심 질문부터 관련 문서와 기준 답변을 붙여야 한다.

Ragas와 LangSmith 중 무엇을 써야 하나?

Ragas는 코드 중심으로 RAG 지표를 조합하고 자체 파이프라인에 넣을 때 편하다. LangSmith는 데이터셋, 실험 비교, trace와 평가를 관리형 워크플로로 묶고 싶을 때 유리하다. 도구보다 먼저 평가 데이터 스키마와 합격 기준을 정해야 나중에 교체하기 쉽다.

RAG 품질의 합격 점수는 몇 점으로 잡아야 하나?

모든 서비스에 통하는 단일 점수는 없다. 현재 시스템의 기준선을 같은 테스트셋에서 측정하고, 핵심 질문의 실패 허용치와 안전 관련 실패 0건 같은 운영 기준을 먼저 둔다. 평균점수 상승보다 기존 정상 사례를 깨뜨리지 않았는지와 고위험 질문 실패가 줄었는지를 우선한다.

참고자료

• Ragas 공식 문서: RAG 평가 지표 목록
• Ragas 공식 문서: Context Precision
• Ragas 공식 문서: Faithfulness
• LangSmith 공식 문서: Evaluate a RAG application
• OpenAI 공식 문서: Evaluation best practices
• Pinecone: Evaluation Measures in Information Retrieval

자료와 문서 경로는 2026년 8월 19일 확인했다.