Embeddings and Vector Stores in LangChain

You already know the mathematics of embeddings from your earlier course — text turned into vectors, similar meanings landing close together in that vector space. This module skips that theory entirely and focuses on the concrete, practical question: how does this actually look in LangChain code?

Example 1: embedding a single query

from langchain_openai import OpenAIEmbeddings

embeddings = OpenAIEmbeddings(model="text-embedding-3-small")
vector = embeddings.embed_query("What is your return policy?")

print(f"Vector length: {len(vector)}")
print(vector[:5])

embed_query turns one piece of text into one real vector — a list of floating-point numbers. The exact length depends on the specific embedding model; text-embedding-3-small produces a genuinely long vector, each number contributing to representing this text’s position in a real, high-dimensional meaning-space.

Example 2: embedding several documents at once

from langchain_openai import OpenAIEmbeddings

embeddings = OpenAIEmbeddings(model="text-embedding-3-small")

texts = [
    "Our return policy allows returns within 30 days.",
    "Shipping takes 3-5 business days.",
    "Gift cards do not expire.",
]

vectors = embeddings.embed_documents(texts)
print(f"Embedded {len(vectors)} documents, each with {len(vectors[0])} dimensions.")

embed_documents is the batch version — genuinely more efficient than calling embed_query in a loop, echoing the same real efficiency lesson from Module 11’s .batch().

Example 3: storing and searching with a vector store

from langchain_core.documents import Document
from langchain_openai import OpenAIEmbeddings
from langchain_core.vectorstores import InMemoryVectorStore

docs = [
    Document(page_content="Our return policy allows returns within 30 days of purchase."),
    Document(page_content="Shipping typically takes 3-5 business days."),
    Document(page_content="Gift cards do not expire and cannot be redeemed for cash."),
]

vector_store = InMemoryVectorStore(OpenAIEmbeddings(model="text-embedding-3-small"))
vector_store.add_documents(docs)

results = vector_store.similarity_search("How long until my order arrives?", k=1)
for doc in results:
    print(doc.page_content)

add_documents embeds every document and stores both the text and its vector together. similarity_search embeds your query the exact same way, then finds the stored documents whose vectors are genuinely closest to it — correctly returning the shipping document, despite the query sharing almost no exact words with it.

Example 4: getting similarity scores, not just results

results_with_scores = vector_store.similarity_search_with_score("How long until my order arrives?", k=2)

for doc, score in results_with_scores:
    print(f"{score:.4f} — {doc.page_content}")

Seeing the actual numeric score is genuinely useful for debugging — a very low score on your top result is a real, concrete signal that nothing in your knowledge base is actually relevant to the query, worth knowing before your application confidently hands the model a mediocre-fit document anyway.

Example 5: a real, persistent vector store

InMemoryVectorStore disappears the moment your program stops — genuinely fine for learning, not for production, echoing the exact same lesson as Module 19’s InMemorySaver. Real applications use a persistent vector database.

from langchain_chroma import Chroma
from langchain_openai import OpenAIEmbeddings

vector_store = Chroma(
    collection_name="company_docs",
    embedding_function=OpenAIEmbeddings(model="text-embedding-3-small"),
    persist_directory="./chroma_db",
)

vector_store.add_documents(docs)
results = vector_store.similarity_search("What's the return policy?", k=1)
print(results[0].page_content)

Chroma, a real, widely used open-source vector database, writes its data to persist_directory on disk — your embedded documents genuinely survive a program restart, unlike InMemoryVectorStore. LangChain supports many real, production vector databases this same way — Pinecone, Weaviate, and others — each imported from its own dedicated package, exactly the provider-specific pattern from Module 5.

Common mistakes worth avoiding

Re-embedding the same documents every time an application starts. Embedding real text costs real money and real time, echoing this course’s recurring Cost per Token concerns. Recall Example 5’s persistent Chroma store — embedding once and persisting to disk means a restarted application reuses existing embeddings, rather than paying to recompute them from scratch every time.

Comparing similarity scores across different embedding models as if they were the same scale. Recall Example 4 — a “good” score from one embedding model isn’t necessarily comparable to a “good” score from a different one. Establish a genuine, tested threshold for your specific embedding model, rather than assuming a number that worked well elsewhere transfers directly.

Using InMemoryVectorStore and being surprised data disappeared. Recall this module’s own honest warning before Example 5 — this is a real, recurring pattern throughout this course (the same lesson as InMemorySaver in Module 19), worth internalizing once rather than relearning it separately each time.

What you should take away from this module

• embed_query and embed_documents are LangChain’s direct interface to turning text into vectors — one for a single query, one for a batch.
• A vector store holds documents and their vectors together, and similarity_search finds the closest matches by genuine semantic meaning.
• similarity_search_with_score reveals the actual closeness score — worth checking, since a low score on your best match is a real signal your knowledge base may not have relevant content.
• InMemoryVectorStore is for learning and testing; real applications need a persistent vector database like Chroma.

Where this goes next

The next module goes deeper on Retrievers — the actual interface your application code calls, covering configuration options beyond the basics, and a genuinely important distinction: a retriever used as a fixed step in a RAG pipeline versus a retriever exposed to an agent as a tool it can choose to call.