채널 AI팀은 왜 새로운 ML 모델 벤치마크가 필요했을까?

• 출처: 채널톡 블로그
• 저자: 데이브(서상우), 머신러닝 엔지니어
• 읽은 날짜: 2025-12-24
• 태그: #RAG #벤치마크 #리트리벌 #하이브리드검색 #평가

핵심 내용

왜 자체 벤치마크가 필요한가?

• 공개 벤치마크의 한계: MMLU 등 공개 벤치마크 성능이 좋아도 자사 RAG 기반 시스템(ALF) 성능 개선으로 이어지지 않음
• 도메인 특화 필요성: 고객사 FAQ, 내부 문서 등 도메인 특화된 평가 시스템 필수

벤치마크의 구성 요소

요소	설명
평가 데이터	표준화된 테스트 데이터셋
모델	평가 대상이 되는 시스템
메트릭	성능 측정 지표

리트리벌 벤치마크 제작 프로세스

5단계 구축 방식

1. 쿼리 선택: 실제 사용자 질문 데이터 기반 수집
2. 후보 문서 선정: Vector DB에서 Top-20 청크 검색 → 문서 레벨로 변환
3. 실버 라벨 구축: LLM으로 관련 문장(cue sentence) 자동 추출
4. 수동 레이블링: Label Studio로 검증 및 수정
5. 후처리: 이상 데이터 제거, 재청킹

핵심 설계 결정

청크 대신 문서 레벨로 데이터 구축 → 청킹 전략 변경 시 재레이블링 불필요

이게 중요한 이유: 청킹 전략은 자주 바뀔 수 있는데, 매번 재레이블링하면 비용이 너무 큼

평가 메트릭

메트릭	설명
Hit@k	상위 k개 결과 중 정답 존재 여부 (있으면 1, 없으면 0)
Recall@k	전체 관련 문서 중 상위 k개에서 발견된 비율
nDCG@k	순위 품질 평가 (상위에 정답이 있을수록 높은 점수)

검증 결과 (Top-20 기준)

검색 방식	Hit Rate	Recall	nDCG
Vector Search	30/35	-	-
BM25	26/35	-	-
Hybrid	31/35	0.70	0.59

하이브리드 검색이 더 나은 이유

• Dense Retrieval 한계: 의미론적 유사도만으로는 도메인 특화 용어(회사명, 내부 키워드) 검색 어려움
• BM25의 보완 역할: 키워드 기반 매칭이 이런 한계를 보완

인상 깊은 부분

"공개 벤치마크의 성능 향상이 자사 RAG 기반 ALF 성능 개선으로 이어지지 않을 수 있다"

범용 벤치마크 점수에 현혹되지 말고, 실제 우리 도메인/유스케이스에 맞는 평가 체계를 만들어야 한다는 점이 핵심

실무 적용 포인트

1. 도메인 특화 벤치마크의 중요성
2. 범용 벤치마크 성능 ≠ 실제 서비스 성능

3. 자체 평가 데이터셋 구축이 필수

4. 효율적인 레이블링 전략

5. LLM으로 실버 라벨 먼저 생성 → 사람이 검증/수정

6. 문서 레벨 레이블링으로 재작업 최소화

7. 하이브리드 검색 고려

8. Vector Search만으로 부족할 수 있음

9. BM25 + Dense 조합으로 도메인 특화 용어 커버

10. 평가 메트릭 선택

11. Hit@k: 단순 성공/실패 판단
12. Recall@k: 얼마나 많이 찾았는지
13. nDCG@k: 순서까지 고려한 품질