[AI W3] RAG 기초 - Retriever(벡터, 키워드, Hybrid)

 

 

[AI] LLM 학습 노트 공개 - Transformer부터 RAG까지, 그리고 운영 가능한 AI 시스템을 향해

 

ㅁ 들어가며

“LLM이 똑똑하면 답변도 좋아지겠지.”

하지만 실제로 RAG를 운영해보면, 품질 문제의 원인은 거의 항상 같은 지점에서 시작된다.

Retriever가 잘못된 문서를 가져온다.

  아무리 좋은 LLM을 써도, 아무리 프롬프트를 다듬어도, 입력 컨텍스트가 틀리면 결과는 틀릴 수밖에 없다.

RAG에서도 결국 이 원칙이 그대로 적용된다.

  Garbage In, Garbage Out

이번 글에서는 RAG 파이프라인의 첫 단계인
  Retriever를 중심으로,

• Dense 검색
• Sparse 검색
• Hybrid 검색

이 세 가지 방식이 왜 등장했고, 실무에서는 왜 Hybrid가 사실상 기본이 되었는지를 정리해본다.

 

 

ㅁ Retriever란 무엇인가

Retriever는 RAG 파이프라인의 첫 번째 단계다.

역할은 단순하다.

질의와 관련된 문서를 빠르게 찾아오는 것

 

하지만 이 “빠르게”와 “관련된”이라는 조건이 Retriever를 가장 어려운 컴포넌트로 만든다.

Retriever는 보통 다음 구조를 가진다.

• 질의와 문서를 각각 인코딩하는 Bi-Encoder 구조
• 대규모 문서 집합에서 Top-K 후보를 빠르게 검색
• 정확도보다 Recall을 우선하는 설계

즉, Retriever의 목표는 정답을 고르는 것이 아니라, 정답을 포함할 후보군을 놓치지 않는 것이다.

 

 

ㅁ Dense Retrieval — 의미를 기준으로 찾는다

Dense Retrieval은 임베딩 벡터 간의 유사도를 기준으로 문서를 검색한다.

작동 흐름은 비교적 단순하다.

1. 질의를 임베딩 모델로 벡터화
2. 사전에 계산된 문서 벡터들과 유사도 계산
3. 가장 가까운 Top-K 문서 반환

이 방식의 핵심은 “같은 의미를 다른 표현으로 말해도 찾을 수 있다”는 점이다.

 

동의어, 유사 표현, 문장 구조가 달라도 의미가 비슷하면 검색된다.

그래서 일반적인 QA나 대화형 검색에서는 Dense Retrieval이 강력하다.

 

하지만 단점도 명확하다.

• 정확한 키워드 매칭에 약함
• 고유명사, 숫자, 코드 토큰에 취약
• 임베딩 모델 품질에 크게 의존

Dense 검색만으로 RAG를 구성하면, “비슷한 말은 찾는데, 정작 정확한 문서는 놓치는” 상황이 자주 발생한다.

 

 

ㅁ Sparse Retrieval — 키워드를 기준으로 찾는다

Sparse Retrieval은 BM25와 같은 키워드 기반 검색 방식이다.

이 방식은 의미를 이해하지 않는다. 대신 단어의 출현 빈도와 희귀성을 이용한다.

 

그래서 다음과 같은 경우에 강하다.

• 정확한 용어가 중요한 검색
• 법률, 계약, 정책 문서
• 코드, 함수명, 설정 키워드

BM25의 장점:

• 동작 방식이 직관적이다
• 결과를 설명하기 쉽다
• 계산이 빠르고 안정적이다

반면 단점도 분명하다.

• 의미적 유사성은 전혀 고려하지 않는다
• 동의어에 약하다
• 오타나 표현 변화에 취약하다

즉, Sparse 검색은 “정확한 단어가 맞을 때는 강하지만, 문맥에는 둔감하다.”

 

 

ㅁ Hybrid Search — 현실적인 타협이 아니라 기본 전제

Dense와 Sparse는 서로의 단점이 너무 명확하다.

  그래서 실무에서는 자연스럽게 Hybrid Search로 수렴한다.

Hybrid Search의 핵심은 단순하다.

• Dense: 의미를 놓치지 않기 위해
• Sparse: 정확한 키워드를 놓치지 않기 위해

두 점수를 결합해 최종 순위를 만든다.

가장 흔한 방식은 선형 결합이다.

Dense 점수에 가중치를 주고, Sparse 점수에 나머지 가중치를 준다.

도메인에 따라 가중치는 달라진다.

• 일반 QA: 의미와 키워드 균형
• 법률/코드: 키워드 비중 증가
• 대화형 QA: 의미 비중 증가

중요한 점은, Hybrid는 “고급 옵션”이 아니라 프로덕션 RAG의 기본 형태라는 것이다.

 

 

ㅁ Retriever와 ANN — 빠른 검색은 근사다

Dense Retrieval이 가능하려면 대규모 벡터를 빠르게 검색할 수 있어야 한다.

여기서 등장하는 개념이 ANN(Approximate Nearest Neighbor)이다.

RAG에서 사용하는 벡터 검색은 정확한 최근접 탐색이 아니다.

대신,

• 빠른 속도
• 충분한 Recall

을 목표로 한 근사 검색이다.

 

실무에서는 HNSW가 사실상 표준처럼 쓰인다.

• 검색 속도와 품질의 균형
• 튜닝 가능한 파라미터
• 다양한 VectorDB에서 지원

Retriever 품질 문제는 결국 HNSW 파라미터 튜닝 문제로 이어지는 경우가 많다.

 

[AI] HNSW - ANN부터 파라미터 튜닝까지, RAG 검색 성능의 진짜 핵심

 

 

ㅁ 마무리 - Retriever는 선택지가 아니라 설계 영역이다

Retriever를 단순히 “검색 모듈 하나”로 보면 RAG는 계속 흔들린다.

Retriever는 다음 요소들이 수렴하는 지점이다.

• Embedding
• Chunking
• Similarity Metric
• ANN 인덱스
• VectorDB 설정

그래서 RAG 품질은 모델보다, 프롬프트보다, Retriever 설계에서 가장 크게 갈린다.

Dense / Sparse / Hybrid 검색을 이해한다는 것은 기능을 고르는 게 아니라,

 

RAG 파이프라인의 첫 단추를 제대로 끼우는 일이다.