RAG 시스템을 구축하고 나면 으레 이런 질문이 따라옵니다. “이 답변이 정말 맞는 건가?” “검색된 문서가 적절한 건가?” “다른 설정이었으면 더 나았을까?” 직감으로 판단하던 시절은 이미 지났습니다. 2026년 현재, RAG 시스템의 성능을 정량적으로 측정하고 개선 사이클을 돌리는 것은 프로덕션 품질의 RAG를 운영하기 위한 필수 조건이 되었습니다.

기존에 RAG의 기본 구조, 청킹 전략, 답변 정확도 튜닝 기법을 다루었지만, 정작 “내 RAG가 얼마나 잘 작동하는지”를 체계적으로 측정하는 방법은 아직 이야기하지 않았습니다. 이번 글에서는 RAG 평가의 전체 그림을 그려보겠습니다. 어떤 지표를 봐야 하는지, 어떤 도구를 쓸 수 있는지, 그리고 실제 운영 환경에서 평가 파이프라인을 어떻게 자동화하는지까지 실전 중심으로 안내합니다.

RAG 평가가 특별히 어려운 이유

일반적인 머신러닝 모델은 정답 레이블이 있고, 정확도(accuracy)나 F1 스코어 같은 명확한 지표로 성능을 판단할 수 있습니다. 하지만 RAG 시스템은 검색과 생성이라는 두 단계가 결합되어 있어서 단일 지표로는 전체 품질을 파악하기 어렵습니다.

예를 들어 보겠습니다. 사용자가 “2026년 여름 전력 수요 전망은?”이라고 질문했을 때, RAG는 먼저 관련 문서를 검색하고(Retrieval), 그 문서를 바탕으로 답변을 생성합니다(Generation). 이 과정에서 여러 가지 실패 모드가 존재합니다.

• 검색 실패: 관련 문서가 데이터베이스에 존재하지만 검색되지 않는 경우. 임베딩 모델의 표현력 부족이나 쿼리 변환 미흡이 원인일 수 있습니다.
• 검색 과잉: 무관한 문서가 너무 많이 검색되어 LLM이 핵심 정보를 놓치는 경우. 특히 컨텍스트 윈도우가 제한적일 때 치명적입니다.
• 생성 환각: 검색된 문서에 없는 내용을 LLM이 지어내는 경우. 가장 위험한 실패 모드입니다.
• 생성 누락: 검색된 문서에 답이 있는데 LLM이 이를 반영하지 못하는 경우. 프롬프트 설계 문제일 수 있습니다.
• 통합 불일치: 검색도 잘 되고 생성도 틀리지 않았지만, 사용자의 의도와 어긋난 답변이 나오는 경우.

이처럼 RAG 평가는 파이프라인의 각 단계를 개별적으로 측정하면서 동시에 전체 흐름의 품질도 판단해야 합니다. 한쪽만 보면 문제의 근본 원인을 놓치기 쉽습니다.

검색 단계 평가 지표: 올바른 문서를 찾고 있는가

RAG 시스템의 품질은 검색 단계에서 결정적으로 갈립니다. 아무리 뛰어난 LLM을 사용해도, 엉뚱한 문서가 컨텍스트로 들어가면 좋은 답변을 기대할 수 없습니다. 검색 단계의 핵심 평가 지표를 하나씩 살펴보겠습니다.

Context Precision (컨텍스트 정밀도)

검색된 문서 중에서 실제로 답변에 유용한 문서의 비율을 측정합니다. 5개의 문서를 검색했는데 그중 2개만 관련이 있다면 정밀도는 0.4입니다. 이 지표가 낮다는 것은 불필요한 노이즈가 많다는 뜻이며, LLM이 핵심 정보를 가려내는 데 추가적인 부담을 지게 됩니다.

단순 정밀도 외에도 검색 결과의 순서를 반영하는 가중 정밀도(Weighted Context Precision)가 실전에서 더 유용합니다. 관련 문서가 상위에 위치할수록 높은 점수를 부여하는 방식으로, 검색 결과 1위에 관련 문서가 있는 것과 5위에 있는 것은 실질적으로 큰 차이가 있기 때문입니다.

Context Recall (컨텍스트 재현율)

답변에 필요한 정보가 검색된 문서 안에 얼마나 포함되어 있는지를 측정합니다. 정답을 구성하는 핵심 팩트가 5개인데 검색된 문서에서 3개만 커버한다면 재현율은 0.6입니다. 이 지표가 낮으면 검색 범위를 넓히거나, 청킹 전략을 재검토해야 합니다.

재현율 측정에는 레퍼런스 답변(ground truth)이 필요합니다. 레퍼런스 답변을 문장 단위로 분해한 뒤, 각 문장의 내용이 검색된 컨텍스트에서 뒷받침되는지 하나씩 확인하는 방식으로 계산합니다. 이 과정을 자동화하기 위해 LLM을 판정자(judge)로 활용하는 방법이 보편화되어 있습니다.

Hit Rate와 MRR (Mean Reciprocal Rank)

Hit Rate는 가장 직관적인 검색 지표입니다. 상위 K개의 검색 결과 안에 관련 문서가 하나라도 포함되어 있으면 1, 아니면 0으로 계산합니다. 여러 질문에 대해 평균을 내면 전체적인 검색 성공률을 파악할 수 있습니다.

MRR은 한 단계 더 나아가 관련 문서의 위치를 반영합니다. 관련 문서가 1위에 있으면 1.0, 2위에 있으면 0.5, 3위에 있으면 0.33의 점수를 부여합니다. 여러 질문에 대한 평균 역순위가 곧 MRR입니다. 이 지표는 “검색 결과를 몇 개 가져올 것인가(top-K)”를 튜닝할 때 특히 유용합니다.

NDCG (Normalized Discounted Cumulative Gain)

검색 결과에 관련 문서가 여러 개일 때 유용한 지표입니다. 각 문서의 관련도를 이진(0/1)이 아닌 다단계(0, 1, 2, 3 등)로 평가할 수 있어서, 부분적으로 관련 있는 문서와 핵심 문서를 구분할 수 있습니다. 정보 검색 분야에서 오랫동안 사용되어 온 표준 지표로, RAG 환경에서도 검색 품질을 세밀하게 측정하고자 할 때 채택됩니다.

생성 단계 평가 지표: 답변이 정확하고 충실한가

검색된 문서를 바탕으로 LLM이 생성한 답변의 품질을 측정하는 단계입니다. 여기서는 “맞는 말인가”와 “관련 있는 말인가”를 구분하는 것이 핵심입니다.

Faithfulness (충실도)

생성된 답변이 검색된 컨텍스트에 충실한지, 즉 컨텍스트에 없는 내용을 지어내지 않았는지를 측정합니다. RAG 평가에서 가장 중요한 지표라고 해도 과언이 아닙니다. 환각(hallucination) 문제를 직접적으로 탐지하기 때문입니다.

측정 방법은 다음과 같습니다. 먼저 답변을 개별 주장(claim) 단위로 분해합니다. 그런 다음 각 주장이 제공된 컨텍스트에 의해 뒷받침되는지 판정합니다. 뒷받침되는 주장의 비율이 곧 충실도 점수입니다.

예를 들어, 답변에 “서울의 여름 평균 기온은 26도이며 습도가 높다”라는 내용이 있고, 검색된 문서에 평균 기온 정보만 있다면, 기온 부분은 충실하지만 습도 부분은 컨텍스트에서 확인할 수 없는 주장이 됩니다. 이 경우 충실도는 0.5입니다.

Answer Relevancy (답변 관련도)

생성된 답변이 사용자의 원래 질문과 얼마나 관련이 있는지를 측정합니다. 충실도가 높아도 질문과 동떨어진 답변은 쓸모가 없습니다. 검색된 문서가 엉뚱해서 그에 충실한 답변을 만들어낸 경우가 대표적입니다.

이 지표의 측정 방식이 독특합니다. 답변으로부터 역으로 질문을 생성해 봅니다. 생성된 역질문들과 원래 질문 사이의 의미적 유사도를 계산합니다. 유사도가 높다면 답변이 질문의 의도를 잘 반영한 것이고, 낮다면 질문과 동떨어진 내용을 담고 있다는 뜻입니다.

Answer Correctness (답변 정확도)

레퍼런스 답변(정답)이 있을 때 사용할 수 있는 지표입니다. 생성된 답변과 정답 사이의 사실적 일치도를 측정합니다. 단순한 문자열 매칭이 아니라, 의미 단위의 팩트를 비교합니다.

정확도는 두 가지 요소의 가중 조합으로 계산됩니다. 하나는 사실적 정확성(F1 score 기반)이고, 다른 하나는 의미적 유사도(임베딩 기반 코사인 유사도)입니다. 둘을 조합하면 표현은 다르지만 같은 내용을 말하는 경우도 올바르게 평가할 수 있습니다.

Hallucination Rate (환각 비율)

충실도의 반대 관점에서 바라보는 지표입니다. 답변 내 주장 중 컨텍스트로 뒷받침되지 않는 것의 비율을 측정합니다. Faithfulness가 0.8이면 Hallucination Rate는 0.2가 됩니다. 같은 정보를 다른 관점에서 표현한 것이지만, 환각의 심각도를 직관적으로 인식하는 데는 Hallucination Rate가 더 효과적입니다.

주요 평가 프레임워크와 도구 비교

RAG 평가 지표의 개념을 이해했다면, 이를 실제로 측정할 도구를 선택해야 합니다. 2026년 현재 가장 널리 사용되는 프레임워크 네 가지를 비교해 보겠습니다.

RAGAS (Retrieval-Augmented Generation Assessment)

RAG 평가에 특화된 오픈소스 프레임워크로, RAG 평가의 사실상 표준이 되어 가고 있습니다. Faithfulness, Answer Relevancy, Context Precision, Context Recall 등 앞서 소개한 핵심 지표를 모두 지원합니다.

RAGAS의 가장 큰 장점은 레퍼런스 답변 없이도 평가가 가능한 지표를 다수 제공한다는 점입니다. Faithfulness와 Answer Relevancy는 정답 데이터 없이 컨텍스트와 질문만으로 측정할 수 있어서, 초기 평가 데이터셋이 없는 프로젝트에서도 바로 적용할 수 있습니다.

사용법도 간결합니다. 질문, 답변, 검색된 컨텍스트, 그리고 선택적으로 정답을 담은 데이터셋을 준비하면, 몇 줄의 코드로 전체 지표를 한꺼번에 계산할 수 있습니다. LangChain, LlamaIndex 등 주요 RAG 프레임워크와의 통합 모듈도 제공됩니다.

DeepEval

LLM 애플리케이션 전반의 평가를 위한 프레임워크로, RAG 평가 외에도 대화형 AI, 요약, 번역 등 다양한 태스크를 지원합니다. pytest와의 긴밀한 통합이 특징적이며, 기존 테스트 파이프라인에 평가 코드를 자연스럽게 녹여 넣을 수 있습니다.

RAG 관련 지표로는 Faithfulness, Contextual Relevancy, Answer Relevancy, Hallucination 등을 제공합니다. RAGAS와 유사하지만, 각 지표의 내부 구현 방식에 미묘한 차이가 있어서 결과 수치가 완전히 동일하지는 않습니다. 실제 프로젝트에서는 두 프레임워크를 병행 실행하여 교차 검증하는 팀도 있습니다.

DeepEval의 강점은 CI/CD 통합과 임계값 기반 자동 판정입니다. “Faithfulness가 0.8 미만이면 테스트 실패”와 같은 규칙을 설정해 두면, 코드 변경이 RAG 품질을 저하시키는 것을 자동으로 감지할 수 있습니다.

TruLens

Snowflake가 인수한 TruLens는 RAG 파이프라인의 각 단계별 품질을 추적하는 데 특화되어 있습니다. 검색 → 리랭킹 → 생성 등 각 단계의 입출력을 자동으로 로깅하고, 단계별 품질 지표를 대시보드로 시각화합니다.

TruLens만의 독특한 개념은 “피드백 함수(feedback function)”입니다. 사용자가 커스텀 평가 기준을 파이썬 함수 형태로 정의할 수 있어서, 도메인 특화 평가가 필요한 프로젝트에 유연하게 대응합니다. 예를 들어 법률 문서 RAG에서는 “인용된 판례 번호가 실재하는가”를 별도 피드백 함수로 만들어 검증할 수 있습니다.

프로덕션 환경에서의 실시간 모니터링에도 강합니다. 운영 중인 RAG 시스템의 모든 요청에 대해 백그라운드로 평가를 수행하고, 품질 저하가 감지되면 알림을 보내는 구성이 가능합니다.

LangSmith

LangChain 생태계의 평가·관측 도구인 LangSmith는 RAG 전용은 아니지만, LangChain 기반 RAG 파이프라인을 사용한다면 통합의 편리함이 압도적입니다. 각 체인(chain)의 실행 트레이스를 자동으로 수집하고, 평가 데이터셋과 연동하여 반복 실험을 관리합니다.

LangSmith의 주요 가치는 실험 비교입니다. 프롬프트를 바꾸거나, 임베딩 모델을 교체하거나, top-K 값을 조정한 여러 실험의 결과를 나란히 비교하는 UI를 제공합니다. “어떤 설정 변경이 얼마나 개선을 가져왔는가”를 한눈에 파악할 수 있어서, 반복적인 RAG 튜닝 과정에서 체계적인 의사결정을 지원합니다.

실전 평가 데이터셋 구축하기

어떤 평가 도구를 선택하든, 그 출발점은 양질의 평가 데이터셋입니다. 여기서 많은 팀이 막힙니다. “정답을 일일이 만드는 것은 시간이 너무 많이 걸리는데, 꼭 필요한가?” 결론부터 말하면, 레퍼런스 답변이 없어도 시작할 수 있지만, 정말 신뢰할 수 있는 평가를 원한다면 결국 만들어야 합니다.

1단계: 레퍼런스 없이 시작하기

프로젝트 초기에는 Faithfulness와 Answer Relevancy 같은 레퍼런스-프리 지표부터 시작합니다. 필요한 것은 질문 목록과 RAG 시스템의 실제 응답뿐입니다. 이 단계에서는 50개에서 100개 정도의 대표 질문을 수집하면 충분합니다.

질문을 모으는 방법은 여러 가지입니다. 실제 사용자 로그가 있다면 가장 좋고, 없다면 문서 컬렉션을 살펴보며 사용자가 물어볼 법한 질문을 직접 작성합니다. 이때 질문의 다양성이 중요합니다. 사실 확인형 질문(“A의 정의는?”), 비교형 질문(“A와 B의 차이는?”), 추론형 질문(“A 상황에서 어떻게 해야 하는가?”), 그리고 답변이 불가능한 질문(“해당 문서에 없는 내용 질문”)을 골고루 포함해야 합니다.

2단계: 합성 데이터로 확장하기

수작업으로 수백 개의 질문-답변 쌍을 만드는 것은 현실적으로 어렵습니다. 이때 LLM을 활용한 합성 데이터 생성이 효과적입니다. 문서 청크를 LLM에 제공하고, 해당 청크로 답변할 수 있는 질문과 정답을 동시에 생성하게 합니다.

RAGAS 프레임워크는 이를 위한 합성 데이터 생성 기능을 내장하고 있습니다. 문서 컬렉션을 입력하면 단순 질문, 추론 질문, 다중 컨텍스트 질문 등 다양한 유형의 테스트 데이터를 자동으로 만들어 줍니다. 다만 합성 데이터만으로는 실제 사용 패턴을 완전히 반영하기 어려우므로, 합성 데이터와 실제 사용자 질문을 섞어 사용하는 것이 바람직합니다.

3단계: 골든 데이터셋 구축과 관리

프로젝트가 성숙해지면 도메인 전문가가 검증한 골든 데이터셋(golden dataset)을 구축합니다. 이것은 RAG 시스템의 회귀 테스트 기준선이 됩니다. 100개에서 200개 정도의 질문-답변-관련문서 세트를 확보하면, 시스템의 어떤 변경이든 품질 영향을 즉시 측정할 수 있습니다.

골든 데이터셋을 만들 때 주의할 점이 있습니다. 먼저, 답변은 단일 정답이 아니라 핵심 팩트 목록으로 정리하는 것이 유연합니다. 자연어 답변은 표현 방식이 다양해서, 똑같은 내용이라도 문자열 비교로는 매칭되지 않기 때문입니다. 둘째, 데이터셋을 버전 관리합니다. 문서가 업데이트되면 관련 정답도 갱신해야 하므로, Git으로 변경 이력을 추적하는 것이 좋습니다. 셋째, 정기적으로 데이터셋의 유효성을 재검증합니다. 원본 문서가 바뀌었는데 정답이 예전 내용을 참조하고 있으면 평가 결과가 왜곡됩니다.

LLM-as-Judge: 자동 평가의 핵심 엔진

앞서 소개한 대부분의 평가 지표는 내부적으로 LLM을 판정자(judge)로 사용합니다. 사람이 수백 건의 답변을 일일이 읽고 점수를 매기는 대신, LLM이 설정된 기준에 따라 자동으로 판정하는 방식입니다. 이 접근법의 원리와 한계를 정확히 이해하는 것이 중요합니다.

작동 원리

LLM-as-Judge는 평가 대상(질문, 컨텍스트, 답변)을 구조화된 프롬프트와 함께 LLM에 전달하여 점수를 산출합니다. 예를 들어 Faithfulness 평가에서는 “아래 답변의 각 주장이 제공된 컨텍스트에 의해 뒷받침되는지 하나씩 판정하시오. 뒷받침되면 1, 아니면 0으로 표시하시오”와 같은 프롬프트를 사용합니다.

판정 LLM으로는 성능이 검증된 상위 모델을 사용하는 것이 일반적입니다. RAG 시스템 자체에 사용하는 모델보다 한 단계 높은 모델을 판정자로 쓰면, 마치 선배가 후배의 과제를 채점하는 것처럼 신뢰도가 올라갑니다. 단, 같은 수준의 모델이라도 적절한 프롬프트 엔지니어링으로 충분한 판정 품질을 확보할 수 있다는 연구 결과도 있습니다.

신뢰도 확보 전략

LLM-as-Judge의 가장 큰 우려는 “AI가 AI를 평가하는 게 믿을 만한가”입니다. 이를 보완하기 위한 실전 전략을 소개합니다.

• 인간 판정과의 상관관계 검증: 초기에 50건에서 100건 정도를 인간이 직접 평가하고, 같은 데이터에 대한 LLM 판정 결과와 비교합니다. 상관관계가 0.8 이상이면 해당 지표에 대해 LLM-as-Judge를 신뢰할 수 있습니다.
• 다중 판정: 같은 항목을 여러 번(3회 이상) 판정하여 일관성을 확인합니다. 판정이 갈릴 때는 다수결을 채택하거나 인간 검토로 넘깁니다.
• 체인 오브 소트(Chain of Thought) 활용: 판정 결과만 요구하지 말고, 판정 근거를 함께 출력하게 합니다. 이유가 합당한지 샘플 검토하면 판정의 신뢰도를 간접적으로 확인할 수 있습니다.
• 편향 감시: LLM은 길고 유창한 답변에 높은 점수를 주는 경향이 있습니다. 의도적으로 짧지만 정확한 답변과 길지만 부정확한 답변을 섞어 넣어 편향 여부를 테스트합니다.

비용 관리

LLM-as-Judge의 실용적인 고민 중 하나는 비용입니다. 평가 지표 하나당 1회에서 3회의 LLM 호출이 필요하고, 지표가 5개면 질문 하나에 최대 15회 호출이 발생합니다. 100개 질문이면 1,500회입니다.

비용을 관리하는 방법은 몇 가지가 있습니다. 먼저, 일상적인 모니터링에는 핵심 지표 2개에서 3개만 사용하고, 전체 지표 평가는 주간 또는 릴리스 시점에만 실행합니다. 둘째, 판정 모델로 경량 모델을 사용해 볼 수 있습니다. Faithfulness처럼 상대적으로 판정이 단순한 지표는 소형 모델로도 충분한 정확도를 보이는 경우가 있습니다. 셋째, 합성 데이터 생성과 평가를 한 번에 수행하는 배치 처리로 API 호출 오버헤드를 줄입니다.

운영 환경에서의 지속적 평가 전략

평가 데이터셋과 도구를 갖추었다면, 이를 운영 환경에 통합하는 전략을 수립해야 합니다. 일회성 평가가 아닌 지속적인 품질 모니터링 체계를 만드는 것이 목표입니다.

오프라인 평가: 변경 전 검증

RAG 시스템의 설정이나 구성 요소를 변경하기 전에 수행하는 평가입니다. 골든 데이터셋을 사용하여 현재 설정과 새 설정의 품질을 비교합니다. 구체적인 시나리오는 다음과 같습니다.

• 임베딩 모델 교체: 새 임베딩 모델로 전환하기 전, 동일한 질문 세트에 대해 검색 지표(Hit Rate, MRR, Context Precision)를 비교합니다.
• 청킹 전략 변경: 청크 크기나 오버랩을 조정했을 때 Context Recall이 개선되는지, 동시에 Context Precision이 떨어지지 않는지 확인합니다.
• 프롬프트 수정: 시스템 프롬프트를 수정했을 때 Faithfulness와 Answer Relevancy가 유지되는지 검증합니다.
• top-K 조정: 검색 결과 수를 늘리거나 줄였을 때의 트레이드오프를 수치로 확인합니다. 일반적으로 K를 늘리면 Recall은 오르지만 Precision은 떨어집니다.

이 과정을 CI/CD 파이프라인에 통합하면, RAG 관련 코드 변경이 일어날 때마다 자동으로 회귀 테스트가 실행됩니다. DeepEval은 pytest 기반이므로 기존 테스트 스위트에 자연스럽게 추가할 수 있습니다.

온라인 평가: 운영 중 모니터링

프로덕션 트래픽에 대한 실시간 품질 모니터링입니다. 모든 요청을 평가하면 비용과 지연이 과도해지므로, 샘플링 전략이 필요합니다.

효과적인 샘플링 방법은 세 가지 계층으로 나뉩니다. 첫째, 전수 로깅은 비용 없이 모든 요청의 입출력을 저장합니다. 질문, 검색된 컨텍스트, 생성된 답변을 기록합니다. 둘째, 경량 지표 전수 적용으로, 임베딩 기반의 단순 유사도 점수처럼 LLM 호출이 필요 없는 지표는 모든 요청에 실시간으로 계산합니다. 셋째, LLM 기반 지표 샘플링으로, Faithfulness 같은 LLM 호출이 필요한 지표는 전체 트래픽의 5퍼센트에서 10퍼센트만 샘플링하여 비동기로 평가합니다.

온라인 평가에서 특히 주목해야 할 패턴은 품질 저하 알림입니다. 이동 평균 기반으로 지표를 추적하다가, 특정 임계값 아래로 떨어지면 알림을 발송합니다. 예를 들어, 지난 24시간의 평균 Faithfulness가 0.75 아래로 내려가면 슬랙이나 이메일로 경고합니다. 이런 저하는 보통 원본 문서의 업데이트, 모델 버전 변경, 또는 새로운 유형의 사용자 질문 유입이 원인입니다.

사용자 피드백 통합

자동 평가와 함께 사용자의 직접적인 피드백을 수집하는 것도 중요합니다. 답변 하단에 “도움이 되었나요?”와 같은 간단한 평가 버튼을 제공하면, 자동 지표로는 포착하기 어려운 실제 만족도를 파악할 수 있습니다.

사용자 피드백은 두 가지 역할을 합니다. 하나는 자동 평가 지표의 보정 기준입니다. 자동 지표에서는 높은 점수를 받았지만 사용자가 부정적 피드백을 준 사례를 분석하면, 자동 평가가 놓치는 사각지대를 발견할 수 있습니다. 다른 하나는 골든 데이터셋의 갱신 소스입니다. 사용자가 좋은 평가를 준 답변은 정답 후보로, 나쁜 평가를 준 질문은 개선 대상으로 데이터셋에 반영합니다.

평가 결과를 개선으로 연결하는 진단 체크리스트

평가 지표를 측정하는 것 자체가 목적이 아닙니다. 지표의 패턴을 읽고 어디를 개선해야 하는지 진단하는 것이 핵심입니다. 아래는 지표 조합별 진단 가이드입니다.

• Context Precision 낮고 + Faithfulness 높다면: 검색이 불필요한 문서를 많이 가져오지만, LLM이 이를 잘 걸러내고 있습니다. 임베딩 모델 교체나 리랭커(re-ranker) 도입으로 검색 정밀도를 높이면, 불필요한 컨텍스트 토큰 소비를 줄이고 지연 시간도 개선됩니다.
• Context Recall 낮다면: 관련 문서가 검색 범위에서 빠지고 있습니다. 청킹 크기를 재조정하거나, 하이브리드 검색(벡터 + 키워드)을 도입하거나, 쿼리 확장(query expansion) 기법을 적용합니다.
• Faithfulness 낮다면: LLM이 컨텍스트에 없는 내용을 지어내고 있습니다. 시스템 프롬프트에 “제공된 문서에 없는 내용은 답변하지 마시오”를 강화하고, 인용 표시를 요구하며, temperature를 낮춥니다.
• Answer Relevancy 낮다면: 질문 의도를 제대로 파악하지 못하고 있습니다. 쿼리 재작성(query rewriting) 단계를 추가하거나, 대화 히스토리 관리를 개선합니다.
• 모든 지표가 특정 질문 유형에서만 낮다면: 해당 유형의 문서가 부족하거나, 특정 도메인 용어의 임베딩 품질이 낮을 수 있습니다. 도메인 특화 임베딩 파인튜닝을 고려합니다.

이 진단 과정을 주기적으로 반복하면, RAG 시스템의 품질이 점진적이고 체계적으로 향상됩니다. 감으로 튜닝하던 때와는 비교할 수 없는 효율입니다.

마무리: 측정하지 않으면 개선할 수 없다

RAG 시스템의 성능 평가는 “있으면 좋은 것”이 아니라, 프로덕션 품질을 보장하기 위한 필수 과정입니다. 이번 글에서 다룬 내용을 정리하면 다음과 같습니다.

• RAG 평가는 검색 단계와 생성 단계를 분리하여 각각의 지표로 측정합니다.
• Context Precision, Context Recall로 검색 품질을, Faithfulness와 Answer Relevancy로 생성 품질을 파악합니다.
• RAGAS, DeepEval, TruLens, LangSmith 등 도구를 활용하면 평가를 자동화할 수 있습니다.
• 골든 데이터셋과 LLM-as-Judge를 결합하여 확장 가능한 평가 체계를 구축합니다.
• 오프라인 회귀 테스트와 온라인 모니터링을 함께 운영하여 지속적인 품질 관리를 실현합니다.

처음부터 완벽한 평가 체계를 갖추려 하지 않아도 됩니다. 레퍼런스 없이 Faithfulness 하나만 측정하는 것에서 시작하세요. 그 하나의 숫자만으로도, 여러분의 RAG 시스템이 어디로 가고 있는지 훨씬 명확하게 보일 것입니다.

이미지는 Leonardo AI 로 생성되었습니다.

이미지는 Claude AI 로 생성되었습니다.