RAG 검색 개선기: 평가지표 선정

질의처리기에서 질의를 다듬고, 하이브리드 검색으로 키워드와 벡터를 합치고, 리랭커로 1등을 끌어올렸다. 이 개선기 내내 검색을 한 겹씩 쌓아 올린 셈이다. 그런데 그 모든 단계에서 "이게 정말 나아졌나"를 판정해준 건, 매번 뒤에서 조용히 돌던 '재는 일'이었다. 개선기를 닫는 이번 글은 그 잣대 자체, 평가지표 이야기다.

 

처음 개괄했던 글에서 지표를 한 번 훑었는데, 여기선 한 발 더 들어간다. nDCG까지 넣어 '계산'과 '진단'을 제대로 정리한다.

 

Precision, Recall, Hit Rate, MRR, nDCG. 이름은 딱딱한데, 계산은 사실 더하기랑 나누기가 전부다. 계산보다 중요한 건 각 지표가 "무슨 문제를 알려주는지"다.

1. 하나의 예시로 다 계산해보기

상황 하나를 끝까지 붙들고 간다. 검색했더니 상위 5개가 이렇게 나왔다. O는 정답, X는 틀림.

순위    1등   2등   3등   4등   5등
결과     O     X     O     X     O

그리고 세상의 전체 정답은 4개다. 이 중 3개(1·3·5등)가 상위 5에 들어왔고, 나머지 1개는 5위 밖에 있다. 이 한 장면으로 지표를 전부 계산한다.

Precision@K, 보여준 것 중 맞는 비율

"내가 보여준 것 중 정답이 몇 %냐"다. 자르는 위치 K마다 값이 달라진다.

Precision@1 = 1등만 봄, 그중 O 1개     → 1 ÷ 1 = 1.00
Precision@3 = 1~3등, 그중 O 2개(1·3등)  → 2 ÷ 3 = 0.67
Precision@5 = 1~5등, 그중 O 3개         → 3 ÷ 5 = 0.60

K를 늘릴수록 뒤쪽에 X가 섞여 대개 떨어진다. "위에서부터 몇 개까지 깨끗한가"를 보는 값이다.

Recall@K, 전체 정답 중 찾은 비율

분모가 다르다. '보여준 개수'가 아니라 '세상의 전체 정답 4개'다.

Recall@1 = top1의 정답 1개 ÷ 전체 4   → 1 ÷ 4 = 0.25
Recall@3 = top3의 정답 2개 ÷ 전체 4   → 2 ÷ 4 = 0.50
Recall@5 = top5의 정답 3개 ÷ 전체 4   → 3 ÷ 4 = 0.75

Precision과 반대로, K를 늘릴수록 정답을 담을 기회가 늘어 대개 오른다. 단 5위 밖의 정답 1개는 K=5까진 영영 못 잡아서, Recall@5도 1.00이 못 된다. "놓치지 않고 얼마나 건졌나"를 본다.

 

Hit Rate@K, 정답이 하나라도 들어왔나

비율이 아니라 이진값(1 또는 0)이다. top-K 안에 정답이 하나라도 있으면 1.

Hit@1 = 1등이 O        → 1
Hit@3 = top3에 O 있음   → 1
Hit@5 = top5에 O 있음   → 1

이 예시는 1등부터 O라 전부 1이다. 만약 첫 O가 4등이었다면 Hit@1=0, Hit@3=0, Hit@5=1로 갈렸을 것이다. Recall과의 관계가 중요하다. 정답이 여러 개면 Recall(3 ÷ 4 = 0.75)과 다르지만, 정답이 질의당 1개면 Hit Rate와 Recall은 같은 값이 된다. 그 하나가 top-K에 있냐 없냐가 곧 '하나라도 있냐'이자 '정답의 몇 %냐'라서다. RAG처럼 질의당 정답 문서를 하나 두면, 같은 걸 두 이름으로 부르는 셈이다.

 

MRR, 첫 정답이 몇 등인가? 

첫 O가 나온 순위의 역수(1 ÷ 순위)다.

첫 O가 1등이면  → 1 ÷ 1 = 1.00   (이 예시)
첫 O가 2등이면  → 1 ÷ 2 = 0.50
첫 O가 3등이면  → 1 ÷ 3 = 0.33

이 예시는 1등이 O라 1.00이다.

 

앞의 M(Mean)은 여러 질의를 평균낼 때 붙는다. 질의 셋의 첫 정답이 각각 1등·3등·2등이었다면 이렇게 평균낸다.

MRR = (1/1 + 1/3 + 1/2) ÷ 3
    = (1.00 + 0.33 + 0.50) ÷ 3
    = 0.61

"원하는 걸 첫 방에 주나"를 보는 값이라, 정답 하나만 빠르게 찾는 검색에 잘 맞는다.

 

nDCG, 순위 전체를 관련도순으로 잘 매겼나를 본다.

이것만 3단계지만, 역시 더하기·나누기뿐이다.

 

1단계, 내 결과 점수(DCG). 각 순위의 정답에 점수를 주되(O=1, X=0) 아래 순위일수록 정해진 값으로 나눠 깎는다.

할인표(주어짐, 외울 필요 없음)     내 결과 계산
  1등 ÷1                         1등 O:  1 ÷ 1   = 1.0
  2등 ÷1.6                       2등 X:  0 ÷ 1.6 = 0
  3등 ÷2                         3등 O:  1 ÷ 2   = 0.5
  4등 ÷2.3                       4등 X:  0 ÷ 2.3 = 0
  5등 ÷2.6                       5등 O:  1 ÷ 2.6 = 0.38
                                 DCG = 다 더하기 = 1.88

2단계, 최선 점수(IDCG). 정답을 전부 위로 몰아넣은 이상적 순서라면 이렇게 된다.

1등 O:  1 ÷ 1   = 1.0
2등 O:  1 ÷ 1.6 = 0.63
3등 O:  1 ÷ 2   = 0.5
        IDCG = 2.13

3단계, nDCG = 내 점수 ÷ 최선 점수 = 1.88 ÷ 2.13 = 0.88. "내가 낸 순서가 최선 대비 88%다."

 

계산법만 한 장에 모으면 이렇다.

지표           계산                          이 예시 값
Precision@5    맞은 개수 ÷ 보여준 개수         3 ÷ 5     = 0.60
Recall@5       맞은 개수 ÷ 전체 정답           3 ÷ 4     = 0.75
Hit Rate@5     top-K에 정답 하나라도? 1/0      1  (정답 1개면 Recall과 동일)
MRR            1 ÷ 첫 정답 순위               1 ÷ 1     = 1.00
nDCG           순위별 점수 더한 것 ÷ 최선값     1.88 ÷ 2.13 = 0.88

결국 순위로 나누고, 더하고, 최선 대비 나누는 것뿐이다.

2. 그래서 각 지표가 뭘 알려주나

계산식은 실무에선 라이브러리가 해준다. 정작 알아야 하는 건 "이 지표가 나쁘면 어디가 아픈 건가"다.

 

Precision@K, 쓸데없는 걸 얼마나 섞었나.

낮으면 보여준 것 중에 정답 아닌 게 많이 섞인 것이다. 이럴 땐 필터링·랭킹을 조여 관련 없는 걸 걸러낸다.

Recall@K, 놓친 게 얼마나 있나.

낮으면 정답인데 상위에 못 올린 것(누락)이다. 이럴 땐 검색 범위를 넓히거나(동의어·유사어) 색인 품질을 손본다.

Hit Rate@K, 하나라도 건졌나.

Recall의 이진판이다. "몇 %를 찾았냐" 대신 "하나라도 찾았냐"만 본다. 이게 낮으면 순서를 논하기 전에 회수 자체가 실패한 것이라, 더 근본적인 경고등이다.

Precision과 Recall을 같이 보면 어느 쪽으로 치우쳤는지 보인다.

Precision 높고 Recall 낮으면 너무 깐깐한 것(확실한 것만 보여주고 많이 놓침), 반대면 너무 헐렁한 것(많이 보여주는데 쓰레기 섞임). 둘의 균형으로 "조일까 풀까"를 정한다.

MRR, 첫 정답이 위에 있나.

낮으면 정답은 있는데 아래 파묻힌 것이다. "딱 하나 찾는" 검색(정확한 상품명 같은)에 특히 중요하다.

nDCG, 순위 전체를 관련도순으로 잘 매겼나.

낮으면 관련 높은 게 아래, 낮은 게 위로 간 것이다. 상위 여러 개의 순서가 다 중요할 때(커머스 같은) 제일 종합적인 지표다.

 

한 장 요약: 지표가 낮으면 무슨 일이 벌어진 것이고, 그래서 뭘 하나.

Precision@K 낮음  →  보여준 것에 정답 아닌 게 섞임   →  덜 관련된 걸 걸러낸다
Recall@K 낮음     →  정답을 상위에 다 못 올림        →  검색 범위를 넓힌다(동의어 등)
Hit Rate@K 낮음   →  정답이 아예 안 들어옴           →  회수 단계부터 다시 본다
MRR 낮음          →  정답이 아래 파묻힘              →  상위로 끌어올린다(리랭커 등)
nDCG 낮음         →  관련 높은 걸 위로 못 세움        →  순서(랭킹) 로직을 손본다

3. 실무에선 조합해서 진단한다

지표 하나만 보는 게 아니라 여러 개를 같이 놓고 "어디가 아픈지" 진단한다.

Recall 높고 nDCG 낮음   →  정답은 찾는데 순서가 틀림  →  랭킹 로직을 손봄
Precision 낮음          →  엉뚱한 게 섞임             →  필터를 강화
Hit Rate가 낮음         →  후보에 아예 못 넣음        →  회수부터 다시

즉 지표는 성적표가 아니라 "어디가 아픈지 알려주는 진단 도구"다. 지표를 보고, 원인을 짚고, 그 자리를 고친다. 잰다는 것 자체가 목적이 아니라, 다음에 뭘 손볼지를 정하려고 재는 것이다.

마치며

돌아보면 이 개선기 내내 항상 먼저 한 일은 '재는 것'이었다. 지표가 없으면 "좋아진 것 같다"는 느낌에 속고, 지표가 있으면 어디가 아픈지가 눈에 보인다. 그러니 마지막 글이 다룬 이 평가지표는 시리즈의 부록이 아니라, 처음부터 모든 글의 바닥에 깔려 있었다.

 

각 지표가 뭘 알아보기 위함인지만 알면된다. Precision이 낮으면 노이즈, Recall이 낮으면 누락, MRR이 낮으면 첫 정답이 묻힌 것. 계산은 라이브러리가 해주고, 읽고 판단하는 건 사람 몫이다.

 

이 파트가 RAG 검색 개선기의 마지막 파트인데, 전체를 한 문장으로 줄이면 이렇다. 화려한 기법 하나가 검색을 살리는 게 아니라, 잘 재고 제대로 읽어 '다음에 뭘 손볼지'를 정하는 반복이 검색을 조금씩 개선해나가는 수 밖에 없다. 계속해서 개선해나가다보면 결국은 대부분 트레이드오프에 걸린다.

 

이 트레이드 오프를 결정짓는게 지표다. 어쩌면 가장 먼저 짚고 넘어가야할 파트였을지도 모른다. 다음 글은 총정리 글이 되지 않을까 싶다.