retriever_추천

Retriever란?

Retriever(리트리버, 검색기)는 “질문에 맞는 문서를 DB에서 꺼내오는 담당자”임. RAG 파이프라인에서 LLM에게 근거 자료를 물려주는 앞단 역할임.

성능 기준은 단 하나: “사용자 질문 의도와 키워드를 얼마나 정확하게 잡아내느냐” (정확도). 단순 벡터 DB에서 꺼내는 것만으로는 한계가 있고, 여기에 재순위화(Reranking) 나 검색 방식 섞기(Hybrid) 가 들어갈수록 정확도가 계단식으로 올라감.

포함 관계

Retriever
    ├─ Sparse Retriever (키워드 기반: BM25, TF-IDF)
    ├─ Dense Retriever  (의미 기반: 임베딩 + FAISS/pgvector 등)
    └─ Hybrid Retriever (둘 다 섞음)
         └─ + Reranker  (한 번 더 채점)

• Sparse(희소) 벡터: 어휘 사전 크기만큼 차원을 두고 대부분 0으로 채우는 벡터 (키워드 매칭용, BM25 계열)
• Dense(밀집) 벡터: 수백~수천 차원을 모두 실수로 채운 벡터 (의미 매칭용, 임베딩 모델 결과)

한마디 요약: Retriever는 “사서(司書)“임. 책장을 잘 아는 사서일수록 LLM이 읽어야 할 책을 제대로 가져다 줌.

---

Retriever 성능 계급도 (정확도 기준)

1위: Hybrid Search + Reranker (현존 RAG 끝판왕)

“키워드와 의미를 다 잡고, AI가 채점까지 다시 함”

[1단계] 벡터 검색(의미) + 키워드 검색(단어)
          ↓ 후보 50개 확보
[2단계] Reranker(재순위화 모델)가 50개를 하나씩 읽고
          "이게 진짜 질문에 맞는 답인가?" 채점
          ↓
[3단계] 상위 5개만 LLM에 전달

• 장점: 정확도 최상. 벡터 검색의 약점(정확 키워드 불일치)과 키워드 검색의 약점(의미 파악 불가)을 둘 다 커버
• 단점: Reranker를 돌리는 비용/시간(Latency) 추가
• 추천 도구: Cohere Rerank v3, BGE-Reranker v2-m3, Jina Reranker, LangChain ContextualCompressionRetriever

2위: Hybrid Search (Ensemble Retriever)

“벡터와 키워드의 장점만 섞음 (가성비 최강)”

BM25(키워드 검색)와 Vector(의미 검색) 결과를 가중치로 섞거나, RRF(Reciprocal Rank Fusion, 역순위 융합) 같은 랭크 기반 결합으로 합침.

RRF 공식: score(doc) = Σ 1 / (k + rank_i(doc))
  - rank_i(doc): i번째 검색기에서 해당 문서의 순위
  - k: 상수 (보통 60)

점수 스케일이 다른 검색기끼리도 순위만으로 합칠 수 있어서 튜닝이 쉬움. 가중치 합산(벡터 50% + 키워드 50%) 방식보다 훨씬 견고함.

• 장점: Reranker 없이도 단순 벡터 검색보다 훨씬 정확함. 업계 표준 자리를 잡는 중
• 단점: 가중치 또는 k 조절이 필요 (도메인마다 최적값 다름)
• 추천 도구: LangChain EnsembleRetriever, Elasticsearch rrf 쿼리, Qdrant Hybrid Search

3위: Parent Document Retriever (또는 Multi-Vector)

“검색은 작은 조각으로, 답변은 큰 문맥으로”

원문서: [  큰 문단 (부모)  ]
           │ 분할
           ▼
작은 조각: [조각1] [조각2] [조각3] [조각4]
           │
           │ 1. 작은 조각으로 검색 (정확도 ↑)
           ▼
질문 매칭: [조각2] 선택
           │
           │ 2. 선택된 조각의 부모 문서를 LLM에 전달 (문맥 ↑)
           ▼
LLM 입력:  [  큰 문단 (부모) 전체 ]

• 장점: 검색은 예리하게, 답변은 문맥 풍부하게. “앞뒤 잘려서 답변이 이상해지는” 현상을 막음
• 추천 도구: LangChain ParentDocumentRetriever

4위: Multi-Query Retriever

“질문을 여러 개로 뻥튀기해서 검색”

사용자가 “전세 대출 조건”이라고 물으면, LLM이 알아서 이렇게 변형해 전부 검색함:

원질문: "전세 대출 조건"
   │ LLM이 변형
   ├─ "전세 자금 대출 금리"
   ├─ "전세 대출 한도"
   └─ "전세 대출 자격"
      │
      ▼
각각 검색 → 결과 합침

• 장점: 사용자가 질문을 대충 해도 AI가 다양한 각도로 찾아줌
• 단점: 검색을 여러 번 하니까 느려지고 LLM 토큰도 추가 소모

5위: Standard Vector Search (Dense Retrieval)

“가장 기본, 한계도 명확”

흔히 아는 임베딩 + 코사인 유사도 검색임.

• 장점: 구축이 쉽고 빠름. 프로토타입 만들 때 무난
• 단점: “전문 용어”, “고유 명사(사람 이름, 제품명)” 검색에 매우 취약. 예를 들어 ‘아이폰15’를 검색했는데 ‘스마트폰’ 관련 엉뚱한 글이 나올 수 있음

---

한 눈에 보는 성능 vs 비용 매트릭스

순위	방식	정확도	구축/운영 비용	속도	비고
1	Hybrid + Rerank	★★★★★	높음	약간 느림	실무 상용 서비스 권장
2	Hybrid (Ensemble)	★★★★	중간	빠름	가장 대중적인 선택
3	Parent Document	★★★	중간	빠름	문맥 유지가 중요할 때
4	Multi-Query	★★★	LLM 토큰 소모	느림	질문이 모호할 때 좋음
5	Basic Vector	★★	낮음	매우 빠름	초기 프로토타입용

---

개발자를 위한 추천 로드맵

“한 번에 끝판왕부터 가지 말고 단계적으로 올려라”는 얘기임.

[초기 단계]
Basic Vector Search (VectorStoreRetriever)로 빨리 만듦.
    │
    ▼
[문제 발생]
"사용자가 정확한 용어를 쳤는데 못 찾네?"
    │
    ▼
[1차 업그레이드]
Hybrid Search (EnsembleRetriever)로 변경. BM25 추가.
    │
    ▼
[문제 발생]
"찾긴 찾았는데 1등 결과가 좀 이상해."
    │
    ▼
[최종 진화]
Reranker를 붙여 상위 5개만 다시 추려냄.
(ContextualCompressionRetriever + Cohere/BGE-Reranker)

처음부터 Rerank까지 다 넣으면 디버깅도 어렵고 비용도 아까움. 병목이 어디서 생기는지 체감하면서 올리는 게 효율적임.

---

Reranker의 내부 동작: Cross-Encoder vs Bi-Encoder

Reranker가 왜 느리지만 정확한지 이해하려면 “인코딩 방식”의 차이를 봐야 함.

구분	Bi-Encoder (벡터 검색용)	Cross-Encoder (Reranker용)
입력	질문과 문서를 따로따로 인코딩	질문과 문서를 합쳐서 한 번에 인코딩
출력	각각의 벡터 (사전 계산 가능)	두 텍스트의 관련성 점수 (0~1)
속도	매우 빠름 (벡터 DB 미리 구축)	느림 (질의마다 문서 수만큼 모델 호출)
정확도	중간	높음 (단어 단위 상호작용 고려)
용도	1단계 후보 추출	2단계 최종 랭킹

[Bi-Encoder 흐름]
질문 → 모델 → 질문 벡터
                        ↘
                          코사인 유사도 비교
                        ↗
문서 → 모델 → 문서 벡터 (DB에 미리 저장)

[Cross-Encoder 흐름]
(질문 + 문서1) → 모델 → 점수1
(질문 + 문서2) → 모델 → 점수2
...
(질문 + 문서50) → 모델 → 점수50
           ↓
    점수 순으로 정렬

Cross-Encoder는 질문과 문서의 단어 단위 상호작용(Cross-Attention) 까지 보기 때문에 정확도가 높지만, 문서 수만큼 모델을 돌려야 해서 대규모 DB에 바로 쓰긴 어려움. 그래서 “Bi-Encoder로 후보 좁히고 → Cross-Encoder로 재순위” 라는 2단 로켓 구조가 표준임.

---

Graph RAG(Neo4j)가 사기급인 지점

“사람·사건·관계”가 엮인 질문은 일반 Retriever가 약함.

예시: “김철수 부장이 횡령한 금액과 공모자는?”

일반 Retriever (Vector/Hybrid)

• 문서에서 “김철수”, “횡령”이 들어간 문단을 찾음
• 문서 A에 “김철수 10억 횡령”, 문서 B에 “김철수의 친구 이영희”라고 따로 적혀 있으면, 이영희가 공모자인지 연결 못 함 (문맥이 끊겨 있으니까)

Graph RAG

• 그래프 DB에 이미 관계가 박혀 있음: (김철수)-[친구]->(이영희), (김철수)-[혐의]->(횡령)
• 쿼리 한 번으로 “김철수와 2-depth로 연결된 사람 전부 가져와” 가능
• 문서에 직접 “이영희가 공모했다”는 말이 없어도, 관계망을 통해 정황을 찾아냄

---

최종 선택 가이드

1. 법률, 의학, 범죄 수사, 복잡한 사내 규정 시스템
   • Graph RAG (Neo4j) 필수. “정확성”과 “관계 추론”이 생명
2. 고객 상담 챗봇, 매뉴얼 Q&A, 사내 위키 검색
   • Hybrid Search + Reranker로 충분. Graph RAG는 과유불급(over-engineering)
3. 전체 문서를 아우르는 트렌드 리포트
   • Microsoft GraphRAG (Community Summary 방식) 고려

한마디 요약: 돈과 시간이 무제한이면 Graph RAG + Vector Hybrid + Reranker 조합이 현재 기술상 정점(SOTA).

---

Dense Retriever와 FAISS의 관계

혼동 포인트: FAISS는 “모델”이 아니라 “검색 엔진”에 가까움.

구분	Dense Retriever (밀집 검색기)	FAISS (Facebook AI Similarity Search)
정의	텍스트를 벡터로 변환하고 검색하는 방법론 또는 모델	변환된 벡터를 저장하고 유사한 걸 빨리 찾아주는 라이브러리
핵심 역할	의미 파악(Understanding). 문장 뜻을 이해해 벡터 공간에 배치	고속 연산(Indexing & Search). 수백만 개 중 가장 가까운 걸 0.1초 안에
기술 기반	Deep Learning 모델 (BERT, RoBERTa, DPR, BGE-M3 등)	수학적 알고리즘 (ANN, L2 거리, 내적 등)
비교 대상	Sparse Retriever (BM25, TF-IDF 등 키워드 기반)	ChromaDB, Pinecone, Weaviate, Qdrant (다른 벡터 DB들)

포함 관계: Dense Retriever 라는 개념 안에 “임베딩 모델 + 벡터 저장소 + 검색 알고리즘”이 들어가고, FAISS 는 그중 “벡터 저장소 + 검색 알고리즘” 부분만 담당하는 도구임.

Dense vs BM25: 장단점이 정반대

검색 방식	장점 (특기)	단점 (약점)
Dense Retriever	”의미 파악” 강함. ‘스마트폰’으로 검색해도 ‘갤럭시’, ‘아이폰’을 찾아냄 (동의어 처리 강함)	“정확한 키워드” 약함. 고유 명사, 제품 번호(예: ‘RTX 4090’), 전문 용어 검색 시 엉뚱한 결과 낼 때 있음
BM25 (키워드 기반)	“정밀 타격” 강함. 사용자가 입력한 단어가 반드시 포함된 문서를 찾음 (제품명, 이름 검색에 강함)	“문맥 무시”. 단어가 조금만 달라도 못 찾음 (예: ‘휴대폰’으로 검색하면 ‘스마트폰’ 문서를 못 찾을 수 있음)

약점이 정확히 정반대여서 서로 메꿔주는 관계임. 그래서 Hybrid Retriever 가 자리 잡은 것.

관련: BM25와 PGroonga의 관계, 벡터유사도에 관하여, BGE-M3

---

Supabase + pgvector 구성의 압도적 장점

FAISS를 따로 쓰는 것보다 pgvector 구성이 강력한 이유: “메타데이터 필터링(Metadata Filtering)“.

[FAISS만 쓸 경우]
벡터(숫자)만 저장
"2024년에 작성된 문서 중에서 검색해줘" 같은 조건 검색이 까다로움
→ 벡터 검색 후 ID를 매핑해서 다시 DB 조회하는 2-step 처리 필요

[PostgreSQL (pgvector)를 쓸 경우]
벡터 + 일반 데이터(작성일, 작성자, 카테고리 등)가 한 테이블에 공존
→ SQL 한 줄로 "필터링"과 "벡터 유사도 검색"을 동시에

예시 쿼리:

SELECT id, title, content
FROM documents
WHERE created_at >= '2024-01-01'      -- 메타데이터 필터
  AND category = 'AI'
ORDER BY embedding <=> '[0.12, ...]'   -- 벡터 유사도 (코사인 거리)
LIMIT 5;

RAG 시스템 구축 시 이 한 줄짜리 결합 쿼리가 개발 난이도와 성능 모두에서 큰 차이를 만들어냄.

관련 연산자 상세: 벡터유사도에 관하여

---

MTEB 리더보드 읽는 법

MTEB(Massive Text Embedding Benchmark)는 텍스트 임베딩 모델 성능을 평가하는 가장 공신력 있는 지표임.

리더보드: https://huggingface.co/spaces/mteb/leaderboard

Hugging Face가 운영하는 벤치마크이며, 다양한 임베딩 모델을 여러 NLP 태스크에 돌려 점수를 매겨둔 표임. 새 모델을 고를 때 여기를 먼저 본다고 보면 됨.

1. Mean (평균 점수)

가장 중요한 지표임. 모델이 수행한 모든 테스트 항목(Classification, Clustering, Retrieval 등) 점수의 평균.

점수가 높을수록 “특정 분야뿐만 아니라 전반적으로 우수한 육각형 모델”이라고 보면 됨.

2. 성능 평가 컬럼 (Task Categories)

각 숫자는 100점 만점 환산 점수:

• Retrieval (정보 검색): 질문에 대해 가장 적절한 문서를 찾아내는 능력
  • 활용: RAG 시스템, 사내 검색 엔진 만들 때 가장 중요한 지표
• STS (Semantic Textual Similarity, 의미적 텍스트 유사도): 두 문장의 의미 유사도(0~1)를 얼마나 정확하게 측정하는지
  • 활용: “배고파”와 “식사하고 싶어”를 같은 의미로 인식
• Clustering (군집화): 비슷한 주제 문장끼리 얼마나 잘 묶는지
  • 활용: 뉴스 기사 자동 분류, 고객 리뷰 유형 그룹화
• Classification (분류): 임베딩만으로 감정 분석이나 카테고리 분류를 잘하는지
• PairClassification (쌍 분류): 두 문장이 관련 있는지 없는지 이진 판단
  • 활용: 중복 질문 탐지
• Reranking (재순위화): 이미 검색된 결과를 다시 관련성 순으로 정렬하는 능력
• Summarization (요약): 기계 요약문이 인간 요약문과 얼마나 유사한지
• BitextMining: 두 언어 텍스트 중에서 서로 번역 관계인 문장 쌍을 찾아내는 능력

3. 모델 스펙 컬럼 (Model Specifications)

성능 외에 물리적 특징:

• Model Size / Params: 모델 크기(파라미터 수). 보통 크기가 클수록 성능↑, 메모리/속도는 불리
• Embedding Dimensions: 벡터의 길이(차원 수)
  • 주의: 차원이 높을수록(예: 4096) 정보량은 많지만 벡터 DB 저장 비용이 비싸짐. 실무에서는 보통 768, 1024를 많이 씀
• Max Tokens: 한 번에 처리 가능한 최대 입력 길이. 긴 문서 처리 시 중요
• Memory Usage: 모델 구동에 필요한 실제 VRAM/RAM 용량

요약: Mean 점수로 전반 순위 훑고, 만들려는 서비스가 Retrieval 위주인지 Classification 위주인지에 따라 해당 컬럼 점수 높은 모델을 선택.

실무에서 자주 쓰는 세 모델 비교

모델	MTEB 점수	파라미터	최대 토큰	임베딩 차원
Qwen3-Embedding-8B	70.58 (다국어 1위)	8B	32,768	최대 4096 (가변)
multilingual-e5-base	약 57.0 (large는 63~64)	278M	512	768
OpenAI text-embedding-3-small	약 62.3 (영어 기준)	비공개	8,191	1,536
BGE-M3	약 66~67 (다국어 Retrieval 강세)	568M	8,192	1,024

팩트 체크 포인트

• Qwen3-Embedding-8B: 2025년 6월 기준 MTEB 다국어 리더보드 1위. 70.58점으로 기존 SOTA들을 큰 격차로 따돌림. 다국어 + 코드 검색 + 긴 문맥 이해 모두 강함
• multilingual-e5-base: “가볍고 가성비 좋은 모델” 평가는 정확. 다만 64점대는 e5-base가 아니라 e5-large-instruct 점수일 가능성이 큼. e5-base 자체는 MTEB 다국어 약 57점 수준. 단, Mr. TyDi 같은 다국어 검색 벤치마크에서는 65.9점을 기록하기도 해서 “체감 성능 좋다”는 말이 완전히 틀린 건 아님
• text-embedding-3-small: OpenAI 공식 문서 기준 MTEB 영어 62.3%. 공식 리더보드 등재는 OpenAI가 직접 제출하지 않아 누락된 시기가 있었고, 커뮤니티 기여로 지금은 확인 가능. 다국어 약세가 약점: MIRACL(다국어 검색) 점수 44.0%로 multilingual-e5 계열(50~60점대)보다 낮음. 한국어 포함 다국어 환경에서는 e5 계열이 더 유리
• BGE-M3: BAAI에서 공개한 다국어 임베딩 모델. Dense + Sparse + ColBERT(멀티 벡터) 세 모드를 하나로 지원하는 게 독보적. 한국어 Retrieval에서도 강한 성능. 자세한 내용 BGE-M3

한마디 요약: 다국어 + 최상위 성능 = Qwen3-Embedding-8B, 가벼움 + 검증된 안정성 = multilingual-e5, 영어 위주 + OpenAI 생태계 = text-embedding-3-small, 다국어 Retrieval 특화 = BGE-M3.