| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
- APM
- CKA
- SRE
- Spring
- 정보처리기사 실기 기출문제
- AI
- 기록으로 실력을 쌓자
- 오블완
- golang
- 코틀린 코루틴의 정석
- CloudWatch
- CKA 기출문제
- Kubernetes
- Java
- minikube
- MySQL
- Pinpoint
- LLM
- 티스토리챌린지
- aws
- PETERICA
- Linux
- tucker의 go 언어 프로그래밍
- go
- Rag
- kotlin coroutine
- AWS EKS
- 공부
- kotlin
- 바이브코딩
- Today
- Total
피터의 개발이야기
[AI W3] RAG 기초 - Ranker의 필요성 본문

[AI] LLM 학습 노트 공개 - Transformer부터 RAG까지, 그리고 운영 가능한 AI 시스템을 향해
ㅁ 들어가며 - Retriever 다음에 반드시 필요한 이유
앞선 글에서 Retriever를 정리하였다. Retriever는 빠르지만, 정확하지는 않다.
VectorDB 검색이든 BM25든, Retriever의 역할은 어디까지나 “후보군을 넓게 가져오는 것”이다.
보통 구조는 다음과 같다.
- Retriever: 관련 있어 보이는 문서 Top-50 ~ 100
- Ranker: 그중에서 정말 중요한 문서 Top-5 ~ 10
이 두 단계를 분리하지 않으면 속도와 정확도를 동시에 만족시키기 어렵다.
이번 글에서는
왜 Ranker가 필요한지,
그리고 Cross-Encoder 기반 Reranking이 왜 사실상 표준이 되었는지를 정리해본다.
ㅁ 왜 Ranker가 필요한가
Retriever 단계의 특징을 정리하면 명확하다.
- 속도 우선
- 대규모 문서 풀에서도 빠르게 검색
- 대신 순위 품질은 “대략적”
이 구조에서 자주 발생하는 문제는 이것이다.
정답 문서는 Top-100 안에는 있는데,
상위에 오지 않는다
LLM은 보통 상위 몇 개 문서만 사용한다.
즉, 정답이 있어도 아래에 깔려 있으면 없는 것과 같다.
그래서 중간에 한 단계가 더 필요해진다.
- Retriever: “관련 있을 법한 문서 모으기”
- Ranker: “이 중에서 진짜 중요한 순서 다시 매기기”
이 분리가 바로 RAG 검색 품질을 한 단계 끌어올리는 핵심이다.
ㅁ Bi-Encoder vs Cross-Encoder
이 차이를 이해하면 왜 Ranker가 느리지만 정확한지 바로 납득된다.
ㅇ Bi-Encoder (Retriever)
- 질의와 문서를 각각 따로 인코딩
- 벡터 간 유사도로 비교
- 빠르고 확장성 높음
- 대신 세밀한 문맥 비교는 어려움
ㅇ Cross-Encoder (Ranker)
- 질의와 문서를 한 번에 입력
- 토큰 단위 Attention으로 직접 비교
- 느리지만 훨씬 정확함
직관적으로 말하면,
- Bi-Encoder는
“이 질문이랑 이 문서가 비슷해 보이네?” - Cross-Encoder는
“질문의 이 부분이 문서의 이 문장과 정확히 연결되네”
라는 차이다.
그래서 구조는 자연스럽게 이렇게 나뉜다.
- Bi-Encoder → 대량 후보 추출
- Cross-Encoder → 소수 후보 정밀 정렬
ㅁ Cross-Encoder 기반 Reranking 흐름
RAG 파이프라인에서 Ranker는 보통 이런 식으로 동작한다.
- Retriever로 Top-K 문서 검색 (예: 100개)
- 질의-문서 쌍을 Cross-Encoder에 입력
- 관련도 점수 계산
- 점수 기준으로 재정렬
- 상위 N개만 LLM에 전달
핵심은 단순하다.
Ranker는 검색 결과를 “줄이는” 단계가 아니라
“순서를 바로잡는” 단계다.
ㅁ 주요 Reranker 모델 정리
실무에서 자주 쓰이는 모델만 정리해보면 다음과 같다.
- ms-marco-MiniLM 계열
- 가볍고 빠름
- 영어 중심
- POC나 응답 속도가 중요한 환경에 적합
- bge-reranker-v2-m3
- 다국어 지원
- 정확도 높음
- 온프레미스/자체 서빙에 적합
- Cohere / Jina Rerank
- API 기반
- 운영 편의성 높음
- 비용 고려 필요
선택 기준은 결국 이 두 가지다.
- 문서 수와 언어
- 허용 가능한 지연 시간
ㅁ 성능 튜닝 관점에서의 Ranker
Ranker는 무조건 많이 쓰는 게 답이 아니다.
실무에서 자주 쓰는 기준은 다음 정도다.
- Retriever: Top-50 ~ 100
- Ranker 결과: Top-5 ~ 10
- Ranker 지연 시간: 100~200ms 내
그리고 반드시 지켜야 할 원칙이 하나 있다.
**Ranker는 전체 검색 품질을 바꾸지
ㅁ 마무리
Ranker는 Retriever가 가져온 후보 문서를 정밀하게 재정렬하는 단계이다.
Cross-Encoder는 질의와 문서를 함께 인코딩해 높은 정확도를 제공
프로덕션 RAG는 Retriever(속도) + Ranker(정확도) 구조가 기본이 된다.
'AI > AI이론 | 공부' 카테고리의 다른 글
| [AI] LLM 학습 노트 공개 - Transformer부터 RAG까지, 그리고 운영 가능한 AI 시스템을 향해 (0) | 2026.02.10 |
|---|---|
| [AI W3] Reader(LLM) 프롬프트 설계와 Hallucination을 다루는 방법 (0) | 2026.02.10 |
| [AI W3] RAG 기초 - Retriever(벡터, 키워드, Hybrid) (0) | 2026.02.09 |
| [AI] RAG 파이프라인 전체 구조 (0) | 2026.02.09 |
| [AI] RAG용 VectorDB 튜닝 (0) | 2026.02.08 |