본문으로 건너뛰기
News실전

[분석] 리랭커를 넣었더니 Recall은 그대로고 지연만 늘었다

RAG 파이프라인에 크로스인코더 리랭커(bge-reranker-v2-m3 류)를 끼우는 게 기본기처럼 굳어졌지만, 측정해 보면 효과가 갈린다. 1차 검색이 Recall@50에서 이미 정답을 못 물어온 경우 리랭커는 없는 정답을 만들어내지 못한다. 즉 리랭커는 순위 재배열일 뿐 회수율 자체를 못 올린다. 그런데 크로스인코더는 쿼리·문서 쌍을 매번 동시 인코딩해 50개 후보를 리랭킹하면 dense 검색 대비 100~300ms가 더 붙는다. 실무 결론은 단순하다. 1차 검색 Recall@k를 먼저 끌어올린 뒤, 상위 후보가 충분히 정답을 포함할 때만 리랭커로 NDCG를 다듬는다. top-k를 무작정 키워 리랭커에 떠넘기면 비용만 는다.

실무에선 리랭커를 만능으로 보지 말고, 1차 검색 Recall과 리랭킹 후 NDCG를 분리 측정해야 한다. 회수 단계 병목을 리랭커로 가리면 지연 예산만 까먹는다.

원문 출처

BAAI FlagEmbedding

원문 보기 ↗
NewsRAG중급·

KURE-v2와 bge-m3, 한국어 RAG 임베딩의 실측 격차를 다시 본다

KURE-v2(고려대)와 bge-m3를 한국어 도메인 코퍼스에서 Recall@10으로 붙이면, 일반 위키·뉴스에선 bge-m3가 다국어 강건성으로 앞서지만 법률·의료처럼 한국어 고유 표현이 많은 도메인에선 KURE-v2가 5~9%p 앞서는 패턴이 반복된다. 핵심은 bge-m3의 dense·sparse·ColBERT 3중 출력을 하이브리드로 묶으면 단일 dense 대비 검색 누락이 줄지만, 한국어 형태소 경계가 깨진 토크나이저 위에서 sparse가 오히려 노이즈를 키운다는 점이다. 1024차원 bge-m3는 pgvector HNSW 인덱스 메모리를 적잖이 먹어, 도메인 적합도와 인프라 비용을 같이 저울질해야 한다.

Hugging Face (nlpai-lab/KURE-v2)원문

이 브리핑에 대한 Q&A

이 브리핑에 질문하기

이 브리핑에서 궁금한 점이 있다면 먼저 질문을 남겨보세요.

댓글

첫 댓글을 남겨보세요.

중요한 AI 소식만, 메일로 받아보세요

매일 쏟아지는 소식 중 꼭 봐야 할 것만 골라 실무 가이드와 함께 보냅니다.

핵심 뉴스 5 · 추천 가이드 3 · 인기 Q&A

구독 시 개인정보 수집·이용에 동의하게 됩니다. 자세한 내용은 개인정보처리방침에서 확인할 수 있으며, 언제든 수신 해지할 수 있습니다.