LangChain 관점에서 벡터스토어(Vector Store) 는
단순히 “벡터를 저장하는 DB”가 아니라, RAG 파이프라인 전체를 연결하는 검색 추상화 계층으로 이해하는 것이 가장 정확합니다.
LangChain은 문서 기반 LLM 애플리케이션을 다음과 같은 표준 파이프라인으로 모델링합니다.
DocumentLoader
→ TextSplitter
→ Embeddings
→ VectorStore
→ Retriever
→ LLM
이 중 VectorStore 는
👉 "임베딩 결과를 보관하고, 의미 기반 검색을 책임지는 핵심 인프라 레이어" 입니다.
LangChain에서 VectorStore는 다음 책임을 가집니다.
“Document + Embedding을 함께 저장하고,
유사도 기반 검색을 추상화된 인터페이스로 제공하는 컴포넌트”
즉, 단순히 List[float] 를 저장하는 것이 아니라:
을 결합된 하나의 검색 단위로 관리합니다.
LangChain의 VectorStore는 벡터만 모르는 구조입니다.
Document(
page_content="...",
metadata={"source": "...", "page": 3}
)
이 Document 가 임베딩되고 → VectorStore에 저장됩니다.
의미적 포인트
이 때문에 LangChain에서는 항상 다음 API 형태를 사용합니다.
vectorstore.add_documents(docs)
vectorstore.add_text(text)
LangChain은 색인 방식의 차이를 숨깁니다.
| VectorStore | 내부 색인 방식 |
|---|---|
| FAISS | Flat / IVF / HNSW |
| Chroma | HNSW |
| Pinecone | Managed ANN |
| Milvus | IVF, HNSW |
| Weaviate | HNSW |
LangChain 입장에서는 전부 동일합니다.
docs = vectorstore.similarity_search(query, k=5)
“검색 알고리즘이 아니라 검색 결과에 집중하게 하라”
LangChain에서 VectorStore는 보통 직접 사용되지 않습니다.
대신 Retriever 로 변환됩니다.
retriever = vectorstore.as_retriever(
search_type="similarity",
search_kwargs={"k": 5}
)
| VectorStore | Retriever |
|---|---|
| 저장/색인 책임 | 검색 전략 책임 |
| low-level | high-level |
| DB 개념 | Query 정책 |
이 구조 덕분에:
를 VectorStore 교체 없이 변경할 수 있습니다.
사용자가 말한 추가 / 삭제 / 확장성은 LangChain에서는 다음 의미를 가집니다.
vectorstore.add_documents(new_docs)
→ 운영 중 RAG 시스템을 전제로 한 설계
vectorstore.delete(
ids=[...]
)
또는
vectorstore.delete(
where={"source": "manual_v1.pdf"}
)
→ 문서 버전 관리, 정책 변경 대응 가능
LangChain 애플리케이션 코드 대부분은 다음을 모릅니다.
이 인터페이스 덕분에:
로 무중단 전환이 가능합니다.
LangChain 관점에서 VectorStore는:
LLM이 “기억”을 갖도록 만드는 외부 장기 기억 장치
LLM 자체는:
VectorStore는:
를 제공합니다.
즉,
LLM = 사고 엔진
VectorStore = 의미 기반 기억
LangChain에서 VectorStore는
“임베딩된 Document를 저장·색인하고,
Retriever를 통해 LLM에게 필요한 ‘의미 있는 기억’을 공급하는
RAG 시스템의 핵심 추상화 계층”이다.