Workflow:Langchain ai Langchain Vector Store Operations

Knowledge Sources	LangChain LangChain Docs
Domains	Vector_Stores, Embeddings, RAG
Last Updated	2026-02-11 15:00 GMT

Overview

End-to-end process for storing documents as vector embeddings and performing semantic similarity search using LangChain's vector store abstraction.

Description

This workflow covers the complete lifecycle of vector store operations in LangChain: embedding documents into vector representations, storing them in a vector database (Chroma, Qdrant, etc.), and retrieving relevant documents through semantic similarity search. The VectorStore base class provides a unified interface across backends, while the Embeddings interface abstracts the embedding model used to convert text to vectors. The workflow supports three search strategies: basic similarity search, similarity search with relevance scores, and maximal marginal relevance (MMR) search for diversity-aware retrieval.

Usage

Execute this workflow when building a Retrieval-Augmented Generation (RAG) pipeline, a semantic search system, or any application that needs to find documents based on meaning rather than exact keyword matching. This is the foundation for question answering over custom documents, context-aware chatbots, and knowledge base search.

Execution Steps

Step 1: Initialize the Embedding Model

Create an instance of an embedding model that converts text into dense vector representations. LangChain provides embedding implementations for multiple providers: OpenAIEmbeddings (text-embedding-ada-002, text-embedding-3-small/large), HuggingFaceEmbeddings (local models), OllamaEmbeddings (local Ollama), and NomicEmbeddings. The embedding model must be initialized with the provider's API key and desired model name.

Key considerations:

• The same embedding model must be used for both indexing and querying
• OpenAI embeddings handle long texts by splitting into token-safe chunks and averaging
• Local embedding models (HuggingFace, Ollama) avoid API costs but require local compute
• Embedding dimension varies by model (e.g., ada-002 produces 1536-dimensional vectors)

Step 2: Initialize the Vector Store

Create a vector store instance connected to the backend database. For Chroma, specify a collection name and optional persistence directory for local storage, or host/port for a remote server. For Qdrant, provide a QdrantClient and collection name, selecting a retrieval mode (DENSE, SPARSE, or HYBRID). Pass the embedding model from Step 1 to the vector store so it knows how to embed documents and queries.

Key considerations:

• Chroma supports in-memory, local persistence, and client-server modes
• Qdrant supports in-memory, local snapshot, and remote server modes
• The collection is created automatically if it does not exist
• Vector dimension is determined by embedding the first document

Step 3: Load and Prepare Documents

Convert raw content (text files, PDFs, web pages, databases) into LangChain Document objects, each containing a page_content string and a metadata dictionary. Use text splitters from the langchain-text-splitters package to chunk large documents into appropriately sized segments. Each chunk becomes a separate vector in the store.

Key considerations:

• Chunk size should match the embedding model's context window
• Overlap between chunks preserves context at boundaries
• Metadata (source URL, page number, section title) enables filtering at search time
• The text splitter choice affects retrieval quality (recursive character, token-based, semantic)

Step 4: Add Documents to the Vector Store

Embed and store the prepared documents using add_documents() or add_texts(). The vector store calls the embedding model's embed_documents() method to convert each text chunk into a vector, then stores the vector alongside the original text and metadata. Documents are processed in batches for efficiency. Each document receives a unique ID (auto-generated UUID or user-provided).

Key considerations:

• Batch size affects memory usage and API call frequency
• add_documents() calls add_texts() internally after extracting text and metadata
• Chroma uses upsert() to handle duplicate IDs gracefully
• Qdrant supports separate dense and sparse embedding vectors for hybrid search

Step 5: Perform Similarity Search

Query the vector store with a natural language question using similarity_search(). The query text is embedded using embed_query() and compared against stored vectors using the configured distance metric (cosine, dot product, or Euclidean). The top-k most similar documents are returned as a list of Document objects. For scored results, use similarity_search_with_score() or similarity_search_with_relevance_scores() which also return distance or normalized relevance scores.

Key considerations:

• Default k=4 returns the four most similar documents
• Cosine similarity is the most common distance metric
• similarity_search_with_relevance_scores() normalizes scores to [0, 1] range
• Score threshold filtering can exclude low-relevance results
• Qdrant HYBRID mode fuses dense and sparse results using Reciprocal Rank Fusion (RRF)

Step 6: Apply Maximal Marginal Relevance Search (Optional)

For diversity-aware retrieval, use max_marginal_relevance_search() instead of basic similarity search. MMR first fetches a larger candidate set (fetch_k), then iteratively selects documents that balance relevance to the query with diversity from already-selected documents. The lambda_mult parameter controls this tradeoff: 1.0 is pure relevance (equivalent to similarity search), 0.0 is maximum diversity.

Key considerations:

• MMR prevents redundant results when documents contain overlapping content
• fetch_k (default 20) determines the initial candidate pool size
• lambda_mult (default 0.5) balances relevance and diversity
• Qdrant implements MMR natively in the database for better performance
• Chroma implements MMR client-side using a Python algorithm

Step 7: Use Results in a RAG Pipeline

Feed the retrieved documents into a chat model as context for generating grounded responses. The retrieved documents provide factual context that the model uses to answer questions accurately. This typically involves formatting the documents into a prompt template, combining them with the user's question, and passing the result to a chat model for final answer generation.

Key considerations:

• Retrieved documents should be formatted clearly with source attribution
• The number of documents should fit within the model's context window
• Vector stores can be wrapped as Retriever objects for use in LangChain chains
• The as_retriever() method converts any vector store into a standard retriever interface

GitHub URL

Workflow Repository