VectorStore?

Mujung Kim·2025년 12월 17일

LLM + RAG 시스템

목록 보기
7/11

LangChain 관점에서 벡터스토어(Vector Store) 는
단순히 “벡터를 저장하는 DB”가 아니라, RAG 파이프라인 전체를 연결하는 검색 추상화 계층으로 이해하는 것이 가장 정확합니다.


1. LangChain이 바라보는 전체 흐름

LangChain은 문서 기반 LLM 애플리케이션을 다음과 같은 표준 파이프라인으로 모델링합니다.

DocumentLoader
   → TextSplitter
      → Embeddings
         → VectorStore
            → Retriever
               → LLM

이 중 VectorStore 는
👉 "임베딩 결과를 보관하고, 의미 기반 검색을 책임지는 핵심 인프라 레이어" 입니다.


2. VectorStore의 LangChain적 정의

LangChain에서 VectorStore는 다음 책임을 가집니다.

“Document + Embedding을 함께 저장하고,
유사도 기반 검색을 추상화된 인터페이스로 제공하는 컴포넌트”

즉, 단순히 List[float] 를 저장하는 것이 아니라:

  • 임베딩 벡터
  • 원본 문서 내용 (page_content)
  • 메타데이터 (source, page, timestamp, tag 등)

을 결합된 하나의 검색 단위로 관리합니다.


3. “문서 단위” 저장이 핵심인 이유

LangChain의 VectorStore는 벡터만 모르는 구조입니다.

Document(
  page_content="...",
  metadata={"source": "...", "page": 3}
)

이 Document 가 임베딩되고 → VectorStore에 저장됩니다.
의미적 포인트

  • VectorStore는 “벡터 저장소”라기보다
  • “임베딩된 Document 인덱스” 에 가깝습니다.

이 때문에 LangChain에서는 항상 다음 API 형태를 사용합니다.

vectorstore.add_documents(docs)
vectorstore.add_text(text)

4. 색인(Indexing)의 추상화

LangChain은 색인 방식의 차이를 숨깁니다.

VectorStore내부 색인 방식
FAISSFlat / IVF / HNSW
ChromaHNSW
PineconeManaged ANN
MilvusIVF, HNSW
WeaviateHNSW

LangChain 입장에서는 전부 동일합니다.

docs = vectorstore.similarity_search(query, k=5)

LangChain 철학

“검색 알고리즘이 아니라 검색 결과에 집중하게 하라”


5. Retriever와의 분리 (중요)

LangChain에서 VectorStore는 보통 직접 사용되지 않습니다.
대신 Retriever 로 변환됩니다.

retriever = vectorstore.as_retriever(
    search_type="similarity",
    search_kwargs={"k": 5}
)

왜 분리하였는가?

VectorStoreRetriever
저장/색인 책임검색 전략 책임
low-levelhigh-level
DB 개념Query 정책

이 구조 덕분에:

  • similarity search
  • MMR
  • score threshold
  • hybrid search

를 VectorStore 교체 없이 변경할 수 있습니다.


6. 확장성 관점에서의 VectorStore

사용자가 말한 추가 / 삭제 / 확장성은 LangChain에서는 다음 의미를 가집니다.

6.1 Incremental Update

vectorstore.add_documents(new_docs)
  • 문서 재전체 임베딩 ❌
  • 필요한 청크만 추가 ⭕

→ 운영 중 RAG 시스템을 전제로 한 설계

6.2 삭제 (metadata 기반)

vectorstore.delete(
    ids=[...]
)

또는

vectorstore.delete(
    where={"source": "manual_v1.pdf"}
)

→ 문서 버전 관리, 정책 변경 대응 가능

6.3 스토리지 교체의 자유

LangChain 애플리케이션 코드 대부분은 다음을 모릅니다.

  • FAISS인지
  • Chroma인지
  • Pinecone인지

이 인터페이스 덕분에:

  • PoC: FAISS / Chroma
  • Production: Pinecone / Milvus

로 무중단 전환이 가능합니다.


7. RAG 관점에서 VectorStore의 실질적 역할

LangChain 관점에서 VectorStore는:

LLM이 “기억”을 갖도록 만드는 외부 장기 기억 장치

LLM 자체는:

  • 휘발성
  • 컨텍스트 제한
  • 학습 데이터 고정

VectorStore는:

  • 지속성
  • 의미 기반 주소
  • 실시간 업데이트

를 제공합니다.

즉,

LLM = 사고 엔진
VectorStore = 의미 기반 기억

8. 한 문장으로 정리

LangChain에서 VectorStore는

“임베딩된 Document를 저장·색인하고,

Retriever를 통해 LLM에게 필요한 ‘의미 있는 기억’을 공급하는

RAG 시스템의 핵심 추상화 계층”이다.

향후 고민사항

  • VectorStore vs Traditional DB vs Search Engine
  • Chunk 품질이 VectorStore 검색에 미치는 영향
  • Retriever 설계 전략 (MMR, Hybrid)
  • VectorStore를 “교체 가능하게” 설계하는 코드 구조
profile
천천히 고민하면서 걷는 개발자

0개의 댓글