RAG 파이프라인 (2) 임베딩 · 벡터스토어 · 검색기 · 리랭커

RAG 품질이 나쁠 때 가장 흔한 오진은 LLM을 바꾸는 것이다. 실제로는 대부분의 실패가 그 앞에서 일어난다. 정답 문서가 검색 결과에 아예 들어오지 않았거나, 들어왔는데 순위가 낮았거나 둘 중 하나다.

이 글은 그 두 실패가 발생하는 구간을 다룬다. 청크를 벡터로 바꾸는 임베딩, 그 벡터를 저장·색인하는 벡터스토어, 질문과 비교해 후보를 꺼내는 검색기, 그리고 꺼낸 후보의 순위를 다시 매기는 리랭커다. 각 단계의 선택지와 튜닝 파라미터, 그리고 무엇이 어떻게 깨지는지를 정리한다. 8단계 전체 지도와 앞 단계(로드·분할)는 1편에 있다.

용어 정리

단계 3 — 임베딩

분할된 청크를 기계가 다룰 수 있는 수치 형태(벡터)로 변환해, 질문과 청크 사이의 유사도 계산을 가능하게 만드는 단계다.

동작 방식

"시장조사기관이 예측한 AI 소프트웨어 시장의 연평균 성장률은 얼마인가"라는 질문이 들어왔다고 하자. 각 단락은 이미 벡터로 표현돼 있다.

1번 단락: [0.1, 0.5, 0.9, ... , 0.1, 0.2]
2번 단락: [0.7, 0.1, 0.3, ... , 0.5, 0.6]
3번 단락: [0.9, 0.4, 0.5, ... , 0.4, 0.3]

질문도 같은 방식으로 벡터화한 뒤 유사도를 계산하면 순위가 나온다.

질문 벡터: [0.1, 0.5, 0.9, ..., 0.2, 0.4]

1번: 80%  -> 선택
2번: 30%
3번: 25%

임베딩 모델 선택

튜닝 포인트

실패 모드

# 단계 3: 임베딩(Embedding) 생성
from langchain_openai import OpenAIEmbeddings

embeddings = OpenAIEmbeddings()

단계 4 — 벡터스토어 저장

생성된 벡터를 효율적으로 저장·색인해, 검색 시 관련 문서를 빠르게 찾아내게 만드는 단계다.

세 번째가 텍스트 DB와의 결정적 차이다. "모바일 디바이스에서 동작하는 인공지능 기술을 소개한 기업"을 물었을 때 문서에 "모바일 디바이스"라는 표현이 그대로 없어도 의미가 맞으면 찾아낸다.

벡터스토어 선택

"어느 벡터스토어가 좋은가"에는 정답이 없다. 이 선택은 성능 비교표가 아니라 기존 운영 스택·데이터 규모·보안 요건의 함수다. 이미 PostgreSQL을 운영 중이라면 pgvector가, 이미 Elasticsearch 클러스터가 있다면 하이브리드를 한 엔진에서 처리하는 쪽이 대체로 총비용에서 앞선다.

다만 "이미 있다"는 전제에는 그 클러스터를 계속 돌리는 비용이 포함된다. 노드 구성·watermark·ILM은 Elasticsearch 운영과 트러블슈팅에서 다룬다.

튜닝 포인트

실패 모드

# 단계 4: DB 생성(Create DB) 및 저장
from langchain_community.vectorstores import FAISS

vectorstore = FAISS.from_documents(documents=split_documents, embedding=embeddings)

단계 5 — 검색기

저장된 벡터 DB에서 질문과 관련된 문서를 신속·정확하게 찾아내는 단계다. RAG 시스템의 전반적 성능과 가장 직결되는 지점이다.

Sparse와 Dense — 무엇이 다른가

TF-IDF는 단어가 문서에 나타나는 빈도와 그 단어가 몇 개의 문서에서 나타나는지를 반영해 중요도를 계산한다. 자주 나타나면서도 문서 집합 전체에서는 드물게 나타나는 단어가 높은 가중치를 받는다.

BM25는 TF-IDF를 개선한 모델로, 문서의 길이를 고려해 검색 정확도를 높인다. 긴 문서와 짧은 문서 간 가중치를 조정해 단어 빈도의 영향을 상대적으로 조절한다.

둘은 우열 관계가 아니다. 서로의 약점을 정확히 메우기 때문에 실무에서는 둘을 앙상블한 하이브리드가 기본값이다. 다만 BM25가 세는 「단어」가 무엇인지는 색인 시점에 분석기가 정한다 — 한국어에서 그 토큰을 만드는 형태소 분석기와 사전 구성은 한글 검색 구현에서 다룬다.

검색기 종류

튜닝 포인트

실패 모드

# Dense Retriever
faiss_retriever = vectorstore.as_retriever()

# Sparse Retriever
from langchain_community.retrievers import BM25Retriever

bm25_retriever = BM25Retriever.from_documents(split_documents)

# 하이브리드: dense + sparse 결합
from langchain.retrievers import EnsembleRetriever

ensemble_retriever = EnsembleRetriever(
    retrievers=[bm25_retriever, faiss_retriever],
    weights=[0.5, 0.5],
)

# MMR + top-k 설정 예시
mmr_retriever = vectorstore.as_retriever(
    search_type="mmr",
    search_kwargs={"k": 4, "fetch_k": 20, "lambda_mult": 0.5},
)

보강 단계 — 리랭커

리랭커는 8단계의 정식 번호에는 없지만, 검색기와 프롬프트 사이에 들어가는 2단계 검색 시스템(Two-Stage Retrieval System)의 핵심 컴포넌트다. 1차 검색은 빠르지만 정확도가 다소 떨어진다. 리랭커는 그 후보들을 더 정교하게 분석해 최종 순위를 재결정한다.

두 단계는 무엇이 다른가

핵심 차이는 인코딩 방식이다. Retrieval은 질문과 문서를 따로 인코딩하고(Bi-Encoder), Reranker는 같이 인코딩한다(Cross-Encoder). 같이 넣기 때문에 문맥을 고려한 심층 의미 분석이 가능하지만, 사전 인덱싱이 불가능해 질의 시점마다 계산해야 한다.

두 방식을 결합하면 빠른 속도와 높은 정확도를 동시에 얻는다. 이것이 2단계 구조를 쓰는 이유 전부다.

기술적 특징

계산 비용은 리랭커 쪽이 높다. BERT 같은 복잡한 모델을 쓰기 때문이다. 그럼에도 전체 시스템 효율이 유지되는 이유는 선별된 소수 문서만 처리하기 때문이다.

튜닝 포인트

실패 모드

# 검색기 뒤에 Cross-Encoder 리랭커를 붙이는 구성
from langchain.retrievers import ContextualCompressionRetriever
from langchain.retrievers.document_compressors import CrossEncoderReranker
from langchain_community.cross_encoders import HuggingFaceCrossEncoder

model = HuggingFaceCrossEncoder(model_name="BAAI/bge-reranker-v2-m3")
compressor = CrossEncoderReranker(model=model, top_n=3)

compression_retriever = ContextualCompressionRetriever(
    base_compressor=compressor,
    base_retriever=vectorstore.as_retriever(search_kwargs={"k": 10}),
)

여기까지가 근거를 확보하는 구간이다. 확보한 근거를 어떻게 프롬프트에 넣고 답변으로 만드는지는 3편 프롬프트·LLM·체인에서 다룬다.