RAG를 개선하기 위해 임베딩 모델을 변경하거나 하이브리드 검색과 Reranker를 도입했다고 가정해 보겠습니다.
변경 전보다 검색 결과가 좋아진 것처럼 보이지만 실제로 성능이 얼마나 개선되었는지는 어떻게 확인할 수 있을까요?
몇 가지 질문을 직접 입력해 보고 결과가 괜찮은지 확인하는 방법도 있습니다. 하지만 이러한 방식은 평가자의 주관에 따라 결과가 달라지고, 검색 시스템을 변경할 때마다 동일한 기준으로 비교하기 어렵습니다.
검색 품질을 객관적으로 비교하려면 다음과 같은 질문에 수치로 답할 수 있어야 합니다.
- 정답 문서가 검색 결과에 포함되었는가?
- 관련 문서를 빠짐없이 검색했는가?
- 검색 결과에 불필요한 문서가 얼마나 포함되었는가?
- 정답 문서가 몇 번째 순위에 나타났는가?
- 관련도가 높은 문서가 상위에 배치되었는가?
정보 검색 분야에서는 이러한 검색 결과를 평가하기 위해 Precision, Recall, MRR, MAP, NDCG와 같은 지표를 사용합니다.
이번 글에서는 각 지표가 무엇을 평가하는지 살펴보고 RAG 검색 시스템에서는 어떤 지표를 함께 봐야 하는지 정리해 보겠습니다.
검색됐다고 모두 성공한 것은 아닙니다
사용자가 다음과 같은 질문을 했다고 가정해 보겠습니다.
2025년 2분기 영업이익은 얼마인가요?
검색 시스템은 질문과 관련 있다고 판단한 문서를 다음과 같은 순서로 반환했습니다.
1위: 2025년 2분기 실적 보고서
2위: 2025년 사업 계획서
3위: 2025년 2분기 매출 분석 자료
4위: 2024년 연간 실적 보고서
5위: 2025년 2분기 손익계산서
정답이 포함된 문서가 1위에 있으므로 이 검색은 성공한 것처럼 보입니다.
하지만 정답 문서가 10위에 있었다면 어떨까요?
검색 결과 전체에는 정답 문서가 포함되어 있으므로 검색에 성공했다고 볼 수도 있습니다. 그러나 RAG가 상위 5개의 문서만 LLM에 전달한다면, 정답 문서는 실제 답변 생성에 사용되지 못합니다.
즉, RAG에서는 정답 문서를 찾았는지만 확인해서는 충분하지 않습니다. 정답 문서가 검색 결과의 어느 위치에 있는지, 필요한 문서를 얼마나 빠짐없이 찾았는지도 함께 확인해야 합니다.
검색 성능을 평가하기 위한 기본 개념
검색 지표를 살펴보기 전에 몇 가지 용어를 먼저 정리하겠습니다.
Query
사용자가 검색 시스템에 입력한 질문입니다.
2025년 2분기 영업이익은 얼마인가요?
Retrieved Documents
검색 시스템이 질문과 관련 있다고 판단하여 반환한 문서입니다.
Relevant Documents
질문의 답을 찾는 데 실제로 도움이 되는 관련 문서입니다.
검색 시스템이 반환했는지와 관계없이, 전체 문서 중 해당 질문과 관련 있는 문서를 의미합니다.
Ground Truth
평가 기준으로 사용하는 정답 데이터입니다.
RAG 검색 평가에서는 일반적으로 질문마다 다음과 같은 정보를 미리 정의합니다.
{
"question": "2025년 2분기 영업이익은 얼마인가요?",
"relevantDocuments": ["A", "C", "E", "G"]
}
여기서 A, C, E, G는 질문과 관련 있는 정답 문서 또는 정답 청크입니다.
Top-K
검색 결과 중 상위 K개를 의미합니다.
예를 들어 Top-5는 검색 결과의 1위부터 5위까지를 의미합니다.
RAG에서는 전체 검색 결과를 모두 LLM에 전달하지 않고, 일반적으로 상위 몇 개의 문서만 선택하여 전달합니다. 따라서 전체 검색 결과보다 Top-K 범위에서의 성능이 중요합니다.
예시 검색 결과
이제 하나의 검색 결과를 기준으로 각 지표를 계산해 보겠습니다.
전체 문서 중 질문과 관련 있는 문서는 다음 네 개라고 가정하겠습니다.
관련 문서: A, C, E, G
검색 시스템이 반환한 상위 5개 결과는 다음과 같습니다.
1위: A - 관련 문서
2위: B - 관련 없음
3위: C - 관련 문서
4위: D - 관련 없음
5위: E - 관련 문서
관련 문서 네 개 중 A, C, E를 찾았고, G는 상위 5개 안에 포함되지 않았습니다. 이 결과를 여러 검색 지표에서는 어떻게 평가하는지 살펴보겠습니다.
Precision: 검색 결과가 얼마나 정확한가
Precision은 검색된 문서 중 실제 관련 문서가 차지하는 비율입니다.
계산식은 다음과 같습니다.
Precision = 검색된 관련 문서 수 / 검색된 전체 문서 수
예시에서는 상위 5개 문서 중 A, C, E가 관련 문서입니다.
Precision = 3 / 5 = 0.6
따라서 Precision은 0.6, 즉 60%입니다.
Precision이 높다는 것은 검색 결과에 불필요한 문서가 적다는 의미입니다.
반대로 Precision이 낮으면 정답과 관련 없는 문서가 검색 결과에 많이 포함되어 있다는 뜻입니다.
RAG에서 불필요한 문서가 너무 많이 검색되면 다음과 같은 문제가 발생할 수 있습니다.
- 관련 없는 문서가 LLM의 컨텍스트를 차지합니다.
- 서로 다른 문서의 내용이 섞여 답변이 부정확해질 수 있습니다.
- 입력 토큰 수가 늘어나 비용과 응답 시간이 증가합니다.
- 중요한 정답 근거가 다른 문서 사이에 묻힐 수 있습니다.
Precision은 검색 결과의 순도를 확인하는 지표라고 볼 수 있습니다. 정보 검색에서 Precision은 검색된 문서 중 관련 문서의 비율로 정의됩니다.
Recall: 관련 문서를 얼마나 빠짐없이 찾았는가
Recall은 전체 관련 문서 중 검색 시스템이 찾아낸 문서의 비율입니다.
계산식은 다음과 같습니다.
Recall = 검색된 관련 문서 수 / 전체 관련 문서 수
전체 관련 문서는 A, C, E, G로 총 네 개입니다. 검색 결과에서는 A, C, E 세 개를 찾았습니다.
Recall = 3 / 4 = 0.75
따라서 Recall은 0.75, 즉 75%입니다.
Precision이 검색된 결과의 정확성을 본다면 Recall은 관련 문서를 얼마나 놓치지 않았는지를 확인합니다. Recall은 전체 관련 문서 가운데 실제로 검색된 문서의 비율로 정의됩니다.
RAG에서는 일반적으로 초기 검색 단계의 Recall이 중요합니다.
정답 문서가 검색 후보에 포함되지 않으면 이후에 아무리 성능이 좋은 Reranker나 LLM을 사용하더라도 올바른 답변을 생성하기 어렵기 때문입니다.
예를 들어 초기 검색 단계에서 100개의 후보 문서를 가져온 뒤 Reranker가 상위 5개를 다시 선택하는 구조라면, 초기 RAG의 역할은 정답 후보를 최대한 놓치지 않는 것입니다.
다만 Recall을 높이기 위해 검색 문서 수를 무작정 늘리면 관련 없는 문서도 함께 증가할 수 있습니다. 따라서 Recall과 Precision 사이에는 균형이 필요합니다.
Precision@K와 Recall@K
실제 검색 시스템에서는 모든 검색 결과를 사용하는 것이 아니라 상위 K개의 결과만 사용하는 경우가 많습니다.
이처럼 상위 K개 결과를 기준으로 계산한 Precision과 Recall을 각각 Precision@K, Recall@K라고 합니다.
Precision@5
상위 5개의 검색 결과 중 관련 문서의 비율입니다.
Precision@5 = 3 / 5 = 0.6
Recall@5
전체 관련 문서 중 상위 5개 안에서 찾아낸 문서의 비율입니다.
Recall@5 = 3 / 4 = 0.75
이번에는 상위 3개까지만 평가해 보겠습니다.
1위: A - 관련 문서
2위: B - 관련 없음
3위: C - 관련 문서
Precision@3
Precision@3 = 2 / 3 ≈ 0.67
Recall@3
Recall@3 = 2 / 4 = 0.5
같은 검색 결과라도 K 값에 따라 평가 결과가 달라집니다.
상위 3개만 보면 불필요한 문서가 적어 Precision은 높지만, 전체 관련 문서 중 절반밖에 찾지 못했기 때문에 Recall은 낮습니다.
상위 5개까지 범위를 넓히면 관련 문서 하나를 추가로 찾을 수 있어 Recall은 높아집니다. 하지만 동시에 관련 없는 문서도 포함되어 Precision은 달라질 수 있습니다.
RAG에서 K는 단순한 평가 기준이 아닙니다.
실제로 LLM에 전달할 문서 수와 연결되기 때문에 다음 항목을 함께 고려해야 합니다.
- 검색 Recall
- 검색 결과의 관련성
- LLM의 컨텍스트 크기
- 입력 토큰 비용
- 응답 시간
- 문서 간 중복 정도
따라서 Recall@5가 높은 시스템이 항상 Recall@20이 높은 시스템보다 좋은 것은 아닙니다. 실제 서비스에서 몇 개의 문서를 사용하는지에 맞춰 K 값을 설정해야 합니다.
Hit Rate@K: 정답 문서가 하나라도 있는가
Hit Rate@K는 상위 K개 검색 결과 안에 관련 문서가 하나라도 포함되어 있는지를 평가합니다.
질문 하나를 기준으로 다음처럼 계산합니다.
관련 문서가 하나라도 있음: 1
관련 문서가 하나도 없음: 0
예시 검색 결과에는 상위 5개 안에 관련 문서 A, C, E가 포함되어 있습니다.
Hit Rate@5 = 1
평가 질문이 100개이고 그중 85개의 질문에서 상위 5개 안에 정답 문서가 하나 이상 검색되었다면 다음과 같습니다.
Hit Rate@5 = 85 / 100 = 0.85
Hit Rate는 검색 시스템이 최소한 하나의 정답 근거를 찾을 수 있는지 빠르게 확인하기 좋은 지표입니다.
다만 다음과 같은 한계가 있습니다.
첫째, 관련 문서가 1위에 있든 5위에 있든 동일한 성공으로 처리합니다.
둘째, 관련 문서가 하나 검색된 경우와 다섯 개 검색된 경우를 구분하지 않습니다.
셋째, 여러 문서의 내용을 종합해야 하는 질문에서는 충분한 정보를 제공하지 못합니다.
따라서 Hit Rate는 직관적인 지표이지만 검색 순위와 관련 문서의 누락 정도까지 평가하려면 다른 지표를 함께 사용해야 합니다.
MRR: 첫 번째 정답 문서가 얼마나 앞에 있는가
Hit Rate는 정답 문서가 포함되어 있는지만 확인합니다. 정답 문서가 어느 순위에 있는지는 구분하지 않습니다.
이를 보완하기 위해 사용할 수 있는 지표가 Reciprocal Rank입니다.
Reciprocal Rank는 첫 번째 관련 문서가 등장한 순위의 역수입니다.
Reciprocal Rank = 1 / 첫 번째 관련 문서의 순위
첫 번째 관련 문서의 순위에 따라 점수는 다음과 같습니다.
| 첫 관련 문서 순위 | Reciprocal Rank |
| 1위 | 1 |
| 2위 | 0.5 |
| 3위 | 약 0.33 |
| 5위 | 0.2 |
| 10위 | 0.1 |
정답 문서가 앞에 있을수록 높은 점수를 받습니다.
예시에서는 첫 번째 관련 문서인 A가 1위에 있습니다.
Reciprocal Rank = 1 / 1 = 1
여러 질문의 Reciprocal Rank를 평균 낸 값이 MRR, 즉 Mean Reciprocal Rank입니다. TREC에서도 Reciprocal Rank를 첫 번째 정답이 반환된 순위의 역수로 정의하고 여러 질문에 대한 평균을 MRR로 사용합니다.
세 개 질문의 첫 관련 문서 순위가 각각 1위, 2위, 5위라고 가정해 보겠습니다.
질문 1: 1 / 1 = 1
질문 2: 1 / 2 = 0.5
질문 3: 1 / 5 = 0.2
MRR은 다음과 같습니다.
MRR = (1 + 0.5 + 0.2) / 3
≈ 0.57
MRR은 첫 번째 정답 문서가 얼마나 빠르게 등장하는지를 평가하기 때문에 다음과 같은 검색에 적합합니다.
- FAQ 검색
- 하나의 대표 문서가 중요한 검색
- 단일 정답을 찾는 질의
- 첫 검색 결과의 품질이 중요한 서비스
다만 MRR은 첫 번째 관련 문서만 평가합니다.
첫 번째 관련 문서 뒤에 다른 관련 문서가 얼마나 잘 배치되어 있는지는 점수에 반영하지 않습니다. TREC 역시 Reciprocal Rank가 여러 정답에 추가 점수를 주지 않는다는 특성을 설명하고 있습니다.
따라서 여러 문서에서 근거를 모아야 하는 RAG에서는 MRR만으로 전체 검색 품질을 판단하기 어렵습니다.
MAP: 여러 관련 문서가 얼마나 앞쪽에 배치되었는가
MRR이 첫 번째 관련 문서만 평가한다면, Average Precision은 모든 관련 문서가 검색 결과의 어느 위치에 등장하는지를 평가합니다.
Average Precision은 관련 문서가 나타나는 각 순위에서 Precision을 계산한 뒤 평균을 구합니다.
예시 검색 결과를 다시 보겠습니다.
1위: A - 관련 문서
2위: B - 관련 없음
3위: C - 관련 문서
4위: D - 관련 없음
5위: E - 관련 문서
관련 문서가 등장한 순위는 1위, 3위, 5위입니다.
각 지점의 Precision은 다음과 같습니다.
1위까지의 Precision = 1 / 1 = 1
3위까지의 Precision = 2 / 3 ≈ 0.67
5위까지의 Precision = 3 / 5 = 0.6
전체 관련 문서는 A, C, E, G로 네 개이므로 Average Precision은 다음과 같이 계산할 수 있습니다.
AP = (1 + 0.67 + 0.6) / 4
≈ 0.57
검색되지 않은 관련 문서 G는 점수를 얻지 못합니다.
여러 질문에서 계산한 Average Precision의 평균이 MAP, 즉 Mean Average Precision입니다.
MAP는 관련 문서가 나타날 때마다 해당 지점의 Precision을 계산하고, 이를 여러 질의에 걸쳐 평균 내는 방식으로 검색 순위 전체를 평가합니다. Stanford의 정보 검색 교재와 TREC에서도 MAP를 순위 검색 결과를 하나의 값으로 요약하는 대표적인 평가 방법으로 설명합니다.
MRR과 MAP의 차이는 다음처럼 정리할 수 있습니다.
MRR: 첫 번째 관련 문서의 순위만 평가
MAP: 모든 관련 문서의 순위를 평가
관련 문서가 하나뿐이라면 MRR과 AP는 같은 값이 될 수 있습니다. 하지만 관련 문서가 여러 개라면 MAP가 검색 결과 전체의 품질을 더 잘 반영합니다.
NDCG: 문서마다 관련도가 다르다면
지금까지 살펴본 지표는 대부분 문서를 관련 또는 무관으로 구분합니다.
관련 있음: 1
관련 없음: 0
하지만 실제 RAG에서는 모든 관련 문서의 가치가 같지 않을 수 있습니다.
예를 들어 다음과 같이 관련도를 구분할 수 있습니다.
3점: 질문의 정답을 직접 포함한 문서
2점: 정답을 이해하는 데 중요한 보조 문서
1점: 질문의 주제와 일부 관련된 문서
0점: 질문과 관련 없는 문서
이처럼 문서 관련도를 여러 단계로 평가할 때 사용할 수 있는 지표가 NDCG입니다.
NDCG는 다음 두 가지를 함께 고려합니다.
- 관련도가 높은 문서인가?
- 검색 결과의 앞쪽에 배치되었는가?
관련도가 높은 문서가 상위에 있을수록 높은 점수를 받고, 뒤쪽에 있을수록 순위에 따른 할인값이 적용됩니다.
먼저 DCG를 계산합니다.
DCG = Σ ((2^관련도 - 1) / log₂(순위 + 1))
이 수식에서는 문서의 관련도가 높을수록 더 큰 점수를 받습니다. 동시에 순위가 뒤로 밀릴수록 로그값으로 점수가 감소합니다.
그다음 현재 검색 결과의 DCG를 이상적인 순서의 DCG로 나눕니다.
NDCG = 현재 검색 결과의 DCG / 이상적인 검색 결과의 DCG
이상적인 검색 결과는 관련도가 높은 문서부터 정확한 순서로 정렬된 결과입니다.
정규화 과정을 거치기 때문에 NDCG는 일반적으로 0과 1 사이의 값을 가집니다.
1에 가까움: 관련도가 높은 문서가 이상적인 순서로 배치됨
0에 가까움: 관련 문서의 순서가 좋지 않거나 관련성이 낮음
DCG는 관련도가 높은 문서가 상위에 위치할수록 높은 값을 갖도록 로그 기반의 순위 할인을 적용하며, NDCG는 이를 이상적인 순서에서 얻을 수 있는 DCG로 나누어 정규화합니다.
NDCG는 다음과 같은 경우에 유용합니다.
- 정답 근거와 보조 근거를 구분하고 싶은 경우
- 여러 관련 문서의 순서를 평가하는 경우
- Reranker 적용 전후를 비교하는 경우
- 문서 관련성을 0과 1만으로 구분하기 어려운 경우
- 검색 결과 상단의 품질을 더 중요하게 평가하는 경우
다만 NDCG를 사용하려면 각 문서의 관련도를 몇 점으로 평가할지 기준을 정의해야 합니다.
사람마다 관련도 판단이 달라질 수 있으므로 다음처럼 구체적인 평가 기준을 만드는 것이 중요합니다.
3점: 답변에 반드시 필요한 직접 근거
2점: 직접적인 정답은 없지만 답변에 실질적으로 기여
1점: 주제는 관련 있지만 답변에는 거의 기여하지 않음
0점: 무관
각 지표는 무엇을 평가할까요?
지금까지 살펴본 지표를 정리하면 다음과 같습니다.
| 지표 | 평가하는 내용 | 주요 한계 |
| Precision@K | 상위 K개 중 관련 문서의 비율 | 전체 관련 문서의 누락은 알기 어려움 |
| Recall@K | 전체 관련 문서 중 상위 K개에서 찾은 비율 | 관련 문서의 세부 순서를 반영하지 못함 |
| Hit Rate@K | 상위 K개 안에 관련 문서가 하나라도 있는지 | 관련 문서의 개수와 순위를 반영하지 못함 |
| MRR | 첫 번째 관련 문서의 순위 | 첫 번째 관련 문서 이후는 평가하지 않음 |
| MAP | 모든 관련 문서의 전체적인 순위 | 관련도를 주로 관련·무관으로 구분 |
| NDCG@K | 문서별 관련도와 검색 순서 | 관련도 등급을 별도로 정의해야 함 |
각 지표가 평가하는 관점은 서로 다릅니다.
따라서 특정 지표 하나만 보고 검색 시스템 전체가 좋아졌다고 판단하기는 어렵습니다.
예를 들어 다음과 같은 검색 결과가 있다고 가정해 보겠습니다.
첫 번째 정답 문서는 항상 1위에 있음
나머지 관련 문서는 대부분 검색되지 않음
이 시스템은 MRR은 높지만 Recall은 낮을 수 있습니다.
반대로 관련 문서를 대부분 검색하지만, 정답 문서가 매번 10위 이후에 나타난다면 Recall은 높고 MRR은 낮을 수 있습니다.
또한 관련 문서를 모두 검색하더라도 관련 없는 문서가 지나치게 많이 포함되면 Precision은 낮아집니다.
RAG에서는 어떤 지표를 봐야 할까요?
RAG 검색 시스템에서는 하나의 지표보다 여러 지표를 조합해서 보는 것이 좋습니다.
그중에서도 다음 세 가지를 우선적으로 확인할 수 있습니다.
Recall@K
필요한 근거 문서를 놓치지 않았는가?
초기 Retriever를 평가할 때 중요합니다.
정답 문서가 후보 검색 결과에 들어오지 않으면 이후의 Reranker와 LLM이 문제를 해결할 수 없기 때문입니다.
MRR
첫 번째 정답 근거가 충분히 높은 순위에 있는가?
하나의 핵심 근거가 중요한 질문이나, 상위 몇 개의 문서만 사용하는 시스템에서 유용합니다.
NDCG@K
관련도가 높은 문서가 적절한 순서로 배치되었는가?
여러 개의 후보 문서를 정렬하는 Reranker의 성능을 비교할 때 유용합니다.
예를 들어 하이브리드 검색과 Reranker를 사용하는 RAG라면 다음처럼 단계별로 평가할 수 있습니다.
후보 검색 단계
→ Recall@20으로 정답 문서가 후보에 포함되는지 평가
Reranking 단계
→ MRR과 NDCG@5로 정답 문서가 상위에 재배치되는지 평가
최종 Context 단계
→ Precision@5로 불필요한 문서가 얼마나 포함되는지 평가
이렇게 평가 단계를 나누면 검색 성능이 낮을 때 어느 부분을 개선해야 하는지도 판단하기 쉬워집니다.
예를 들어 Recall@20이 낮다면 다음 항목을 먼저 살펴봐야 합니다.
- 임베딩 모델
- BM25와 벡터 검색의 결합 방식
- Query Expansion
- 청킹 방식
- 메타데이터 필터
- 색인 누락
반면 Recall@20은 높지만 NDCG@5가 낮다면 후보 문서는 충분히 찾았지만 순서가 좋지 않다는 의미일 수 있습니다.
이 경우에는 다음 항목이 개선 대상이 됩니다.
- Reranker 모델
- 검색 점수 결합 방식
- RRF 설정
- Reranking 후보 개수
- 질문과 문서의 관련도 판단 기준
K는 어떻게 정해야 할까요?
Recall@K나 NDCG@K를 사용할 때는 K 값을 결정해야 합니다.
K에 모든 상황에 적용할 수 있는 정답은 없습니다.
실제 RAG 파이프라인에서 사용하는 문서 개수와 각 검색 단계의 목적을 기준으로 정해야 합니다.
예를 들어 다음과 같은 검색 구조를 사용한다고 가정해 보겠습니다.
벡터 검색과 BM25
→ 후보 문서 50개 검색
→ Reranker로 상위 5개 선택
→ LLM에 5개 문서 전달
이 경우에는 다음처럼 평가할 수 있습니다.
Recall@50
→ 초기 RAG가 정답 후보를 놓치지 않는지 확인
NDCG@5
→ Reranker가 관련도 높은 문서를 상위 5개로 배치하는지 확인
Precision@5
→ LLM에 전달된 문서 중 불필요한 문서의 비율 확인
또한 하나의 K 값만 보기보다 여러 값을 함께 확인하는 것도 좋습니다.
Recall@5
Recall@10
Recall@20
Recall@50
이를 통해 후보 문서 수를 늘렸을 때 Recall이 어느 구간까지 의미 있게 증가하는지 확인할 수 있습니다.
예를 들어 Recall@20과 Recall@50의 차이가 거의 없다면, 후보 문서를 50개까지 검색하면서 추가 비용을 지불할 필요가 없을 수 있습니다.
반대로 Recall@5는 낮지만 Recall@20이 높다면 Retriever는 관련 문서를 찾고 있으나 순위가 좋지 않다는 의미입니다. 이 경우 검색 범위를 무작정 늘리기보다 Reranking을 개선하는 편이 효과적일 수 있습니다.
검색 평가를 위해서는 정답 데이터가 필요합니다
지표를 계산하려면 질문마다 어떤 문서가 관련 있는지 미리 알고 있어야 합니다.
즉, 다음과 같은 평가 데이터가 필요합니다.
{
"question": "2025년 2분기 영업이익은 얼마인가요?",
"relevantDocuments": [
{
"documentId": "financial-report-2025-q2",
"relevance": 3
},
{
"documentId": "income-statement-2025-q2",
"relevance": 3
},
{
"documentId": "sales-analysis-2025-q2",
"relevance": 1
}
]
}
Precision과 Recall처럼 문서를 관련 또는 무관으로만 평가한다면 문서 ID만 있어도 됩니다.
NDCG처럼 관련도의 차이를 반영하려면 문서마다 관련도 점수도 함께 정의해야 합니다.
이때 정답의 단위를 문서로 볼지, 청크로 볼지도 중요합니다.
RAG가 실제로 청크를 검색한다면 문서 단위 평가만으로는 문제를 정확히 찾기 어려울 수 있습니다.
예를 들어 정답 문서 자체는 검색되었지만, 정답이 들어 있는 청크가 아니라 다른 청크가 검색될 수 있기 때문입니다.
따라서 실제 검색 단위가 청크라면 다음 정보를 함께 관리하는 것이 좋습니다.
정답 문서 ID
정답 청크 ID
정답이 포함된 문장
문서 또는 청크의 관련도
마무리
RAG 검색 성능은 정답 문서가 검색되었는지만으로 평가할 수 없습니다.
검색 시스템을 제대로 평가하려면 다음을 구분해서 확인해야 합니다.
Precision@K
→ 검색 결과에 불필요한 문서가 얼마나 적은가
Recall@K
→ 필요한 문서를 얼마나 빠짐없이 찾았는가
Hit Rate@K
→ 정답 문서가 하나라도 포함되어 있는가
MRR
→ 첫 번째 정답 문서가 얼마나 앞에 있는가
MAP
→ 여러 관련 문서가 전체적으로 얼마나 앞에 배치되었는가
NDCG@K
→ 관련도가 높은 문서가 적절한 순서로 배치되었는가
RAG에서는 초기 검색 단계의 Recall과 최종 검색 결과의 순위 품질을 함께 살펴봐야 합니다.
초기 Retriever의 Recall이 낮으면 필요한 문서를 찾지 못한 것이고, Recall은 높지만 MRR이나 NDCG가 낮다면 필요한 문서는 찾았지만 순위를 제대로 정하지 못한 것입니다.
따라서 다음과 같이 평가 목적을 나누는 것이 좋습니다.
Recall@K
→ 정답 후보를 놓치지 않았는지 평가
MRR
→ 첫 번째 정답 근거가 충분히 앞에 있는지 평가
NDCG@K
→ 관련도 높은 근거들이 올바른 순서로 배치되었는지 평가
다만 검색 점수가 낮다는 사실만으로는 어떤 부분을 고쳐야 하는지 알 수 없습니다.
검색 실패는 청킹 과정에서 문맥이 분리되어 발생할 수도 있고, 임베딩 모델이 질문의 의미를 제대로 표현하지 못해서 발생할 수도 있습니다.
정답 문서를 검색했지만 순위가 낮거나, 최종 컨텍스트를 구성하는 과정에서 제외되었을 가능성도 있습니다.
참고
- Christopher D. Manning, Prabhakar Raghavan, Hinrich Schütze, Introduction to Information Retrieval
https://nlp.stanford.edu/IR-book/ - NIST, TREC Evaluation Measures
https://trec.nist.gov/ - Kalervo Järvelin, Jaana Kekäläinen, Cumulated Gain-Based Evaluation of IR Techniques
https://doi.org/10.1145/582415.582418 - scikit-learn, ndcg_score
https://scikit-learn.org/stable/modules/generated/sklearn.metrics.ndcg_score.html
'AI' 카테고리의 다른 글
| [바미] 좋은 RAG 평가는 좋은 문제에서 시작됩니다. (1) | 2026.07.24 |
|---|---|
| [바미] RAG가 틀렸을 때 RAG의 문제일까? LLM의 문제일까? (2) | 2026.07.23 |
| [바미] Claude Sonnet 5가 공개되었습니다. (0) | 2026.07.01 |
| 2026 Build with AI: Hands-on Campus 다녀왔어요! (1) | 2026.05.10 |
| [바미] RAG도 쓸수록 좋아질 수 있을까? (2) | 2026.04.01 |