An embedding is a numerical representation of content -- typically a list of a few hundred to a few thousand floating-point numbers -- where the position of each number is learned so that semantically similar items end up close together in the resulting vector space. The word "embedding" comes from the idea that we are embedding high-dimensional, discrete things (words, sentences, images) into a continuous mathematical space where distance is meaningful.

The Core Intuition

Humans understand that "dog" and "puppy" are related, that "king" relates to "queen" as "man" relates to "woman," and that "I need to cancel my subscription" means the same thing as "How do I stop my recurring billing?" Traditional databases cannot do this -- they match exact strings or indexed tokens. Embeddings solve this by mapping each item to a point in a high-dimensional space where distance encodes meaning.

A 384-dimensional embedding is a list of 384 floats. Each dimension does not have a human-readable label -- the model learns what each axis "means" during training. But collectively, the vector captures semantic properties. Two sentences with similar meaning produce vectors that are close together (small distance, high cosine similarity) even if they share no words in common.

Why This Matters for AI Applications

Embeddings enable a class of operations that are impossible with keyword search:

• Semantic search: Find documents that mean the same thing, even with zero word overlap. "How do I reset my password" retrieves a document titled "Credential recovery procedure."
• Deduplication: Detect near-duplicate content by finding vectors with very high similarity (e.g., cosine > 0.95).
• Clustering: Group thousands of support tickets into thematic clusters using k-means or HDBSCAN on the embedding vectors.
• Recommendation: Find "more like this" by retrieving the nearest neighbors of an item's embedding.
• RAG retrieval: Given a user question, embed it, find the closest document chunks in a vector database, and feed them as context to an LLM.
• Classification with zero labeled data: Compare an item's embedding to prototype embeddings for each class and pick the nearest.

Dense vs. Sparse Representations

Embeddings are dense representations: every dimension has a non-zero value, and meaning is distributed across all dimensions. This contrasts with sparse representations like TF-IDF or BM25, where a document is a vector with mostly zeros and a few non-zero entries corresponding to the words it contains. Sparse representations excel at exact keyword matching and rare-term retrieval. Dense embeddings excel at semantic matching. Modern production search systems often combine both in a hybrid retrieval approach: BM25 for keyword precision plus embeddings for semantic recall, with results merged and re-ranked.

Embedding models have evolved through several major generations. Each generation improved semantic quality, context handling, and the range of inputs they can embed. Understanding this lineage matters because older models are still deployed in production, and the right model depends on your task, budget, and latency constraints.

Word2Vec (2013) -- The Pioneer

Developed at Google by Tomas Mikolov and colleagues, Word2Vec introduced the idea of learning word embeddings from large text corpora using a shallow neural network. Two architectures were proposed: CBOW (Continuous Bag of Words), which predicts a target word from its context, and Skip-gram, which predicts context words from a target word. Training produces a lookup table: each word in the vocabulary maps to a dense vector (typically 100-300 dimensions). Word2Vec is static: "bank" gets the same vector whether it means a river bank or a financial bank. This ambiguity is its fundamental limitation.

Word2Vec's famous demonstration of vector arithmetic -- king - man + woman ≈ queen -- showed that embeddings capture analogical relationships. This was a watershed moment: it proved that neural networks learn structured, interpretable semantic representations without explicit programming.

GloVe (2014) -- Global Co-occurrence

GloVe (Global Vectors for Word Representation), developed at Stanford by Pennington, Socher, and Manning, takes a different training objective. Instead of predicting context words like Word2Vec, GloVe factorizes the global word-word co-occurrence matrix: it learns vectors such that the dot product of two word vectors approximates the logarithm of how often those words co-occur in a corpus. GloVe embeddings are also static (one vector per word) and typically 100-300 dimensions. Pre-trained GloVe vectors trained on Wikipedia + Gigaword (6 billion tokens) are still widely used as baseline embeddings in NLP courses and lightweight applications.

fastText (2016) -- Subword Awareness

Facebook's fastText extended Word2Vec by learning embeddings for character n-grams in addition to whole words. A word's vector is the sum of its subword n-gram vectors. This means fastText can produce embeddings for words it has never seen (out-of-vocabulary words) by composing them from character sequences. It also handles morphology-rich languages better than Word2Vec or GloVe. The tradeoff is larger model size and slower lookup.

BERT (2018) -- Contextual Embeddings

BERT (Bidirectional Encoder Representations from Transformers) was the breakthrough that made embeddings contextual. Instead of one fixed vector per word, BERT produces a different vector for the same word depending on its surrounding sentence. "Bank" in "I sat by the river bank" and "I deposited cash at the bank" get different embeddings. BERT is a Transformer encoder trained with masked language modeling (predicting randomly masked tokens) and next-sentence prediction.

For retrieval, the standard approach with BERT was to use the [CLS] token output (a 768-dimensional vector) as the sentence embedding. However, raw BERT [CLS] embeddings are surprisingly poor for semantic similarity -- the model was trained for token prediction, not sentence-level similarity. This gap motivated the next generation.

Sentence Transformers (2019) -- Purpose-Built for Similarity

Sentence Transformers (also called SBERT) fine-tune BERT and similar encoder models on sentence-pair similarity tasks using contrastive learning. The result is a model whose sentence-level embeddings are directly optimized for semantic similarity -- cosine similarity between two SBERT embeddings meaningfully reflects how similar the sentences are. Popular models include:

• all-MiniLM-L6-v2: 384 dimensions, 80MB, very fast. Excellent default for English semantic search on CPU.
• all-mpnet-base-v2: 768 dimensions, 420MB. Higher quality than MiniLM at moderate cost.
• bge-base-en-v1.5: 768 dimensions from BAAI. Strong on MTEB benchmarks, supports instruction-tuned queries.
• bge-large-en-v1.5: 1024 dimensions. Higher quality, slower, more memory.
• e5-large-v2: 1024 dimensions from Microsoft. Requires "query:" and "passage:" prefixes for best results.
• multilingual-e5-large: 1024 dimensions, supports 90+ languages. Critical for multi-language corpora.

OpenAI Embeddings (2022-Present) -- Proprietary API Models

OpenAI offers embedding models via API: text-embedding-ada-002 (1536 dimensions, now legacy), text-embedding-3-small (1536 dimensions, with support for shortening), and text-embedding-3-large (3072 dimensions, also shortable). These models are not open-weight -- you send text to the API and receive vectors back. They perform well on benchmarks and require no local infrastructure, but introduce a per-token cost, network latency, and a data-privacy dependency. For many enterprise deployments, self-hosted sentence-transformer or BGE models offer comparable quality at lower cost with full data control.

The dimensionality of an embedding is the length of the vector -- how many floating-point numbers represent each item. More dimensions can capture more nuanced semantic distinctions, but at a cost: larger storage, slower similarity computation, more memory, and potentially diminishing returns. The "right" dimensionality is a tradeoff between retrieval quality, latency, and cost.

Common Dimension Tiers

Storage Math at Scale

Dimensionality directly drives storage cost. At float32 precision (4 bytes per float):

Dimensionality Reduction and Shortening

You can reduce dimensions after generation through techniques like PCA (Principal Component Analysis) or Matryoshka Representation Learning (MRL). OpenAI's text-embedding-3 models are trained with MRL, which means you can safely truncate the vector to a shorter length (e.g., take the first 256 or 512 dimensions of a 1536-dim vector) and retain most of the semantic quality. This is a genuine capability of the model, not a hack -- the training objective explicitly optimized for this. Truncation reduces storage and speeds up similarity computation at a modest quality cost.

Float Precision -- float32 vs float16 vs int8

Beyond dimensionality, the precision of each float matters. Most embedding models output float32. Storing as float16 halves storage with negligible quality loss for most similarity tasks. int8 scalar quantization (mapping each dimension to an integer in [-128, 127]) reduces storage 4x and speeds up distance computation significantly -- Qdrant, ChromaDB, and Weaviate all support this natively. Product quantization (PQ) compresses further (16x-32x) at a more noticeable quality cost, and is useful for billion-scale datasets where memory is the binding constraint.

Once you have vectors, you need a way to measure how "close" two vectors are. The choice of distance metric affects retrieval results and must align with how the embedding model was trained. Using the wrong metric is a common and silent retrieval-quality bug.

Cosine Similarity

Cosine similarity measures the cosine of the angle between two vectors, ignoring their magnitude. It ranges from -1 (opposite) to 1 (identical direction), with 0 meaning orthogonal. For text embeddings, values typically fall in [0.5, 1.0] for related content and approach 1.0 for near-duplicates.

Cosine similarity is the default and most common metric for text embeddings. Most sentence-transformer and OpenAI models are trained with cosine similarity as the objective. It is magnitude-invariant, which means a long document and a short query with the same "direction" (topic) will still be considered similar.

Dot Product (Inner Product)

The dot product is the sum of element-wise multiplications: dot(A, B) = sum(a_i * b_i). It does not normalize by vector length. If both vectors are L2-normalized (scaled to unit length), then dot product equals cosine similarity. Many vector databases support a "dot product" metric that, when combined with normalized vectors, is mathematically equivalent to cosine similarity but faster to compute (no division by norms).

Some models (notably certain OpenAI and Cohere models) are trained with dot product as the objective and their vectors are not normalized. For these, use dot product directly. Check the model documentation.

Euclidean Distance (L2)

Euclidean distance is the straight-line distance between two points in space: L2(A, B) = sqrt(sum((a_i - b_i)^2)). It is sensitive to both direction and magnitude. For L2-normalized vectors, Euclidean distance and cosine similarity are monotonically related: L2_dist = sqrt(2 - 2*cosine_sim). This means ranking by one is equivalent to ranking by the other when vectors are normalized.

Euclidean distance is common in computer vision embeddings (e.g., CLIP image embeddings, face recognition embeddings) and some older models. For text, cosine similarity or dot product is almost always preferred.

A vector database is a specialized data store optimized for inserting, indexing, and querying high-dimensional vectors along with their associated metadata. Traditional databases (PostgreSQL, MySQL, MongoDB) are designed for exact-match lookups, range queries, and relational joins. They use B-tree or hash indexes that are fundamentally unsuited for finding the "nearest" vectors in a 768-dimensional space. Vector databases exist because nearest-neighbor search in high dimensions is a different computational problem that requires different algorithms and data structures.

The Problem: Nearest Neighbor Search in High Dimensions

Given a query vector q and a dataset of N vectors, find the k vectors most similar to q. The brute-force solution is to compute the distance from q to every vector in the dataset, sort, and return the top k. This is O(N * d) per query, where d is dimensionality. For 10 million 768-dim vectors, a single query requires ~7.6 billion floating-point operations. At query time, this is too slow for interactive applications.

Vector databases solve this with Approximate Nearest Neighbor (ANN) algorithms. They pre-build index structures (HNSW, IVF, etc.) that trade a small amount of retrieval accuracy for massive speedups -- often 100x-1000x faster than brute force with 95%+ recall. They also handle the operational concerns: persistence, sharding, replication, metadata filtering, and horizontal scaling.

Vector Database vs. Traditional Database

Core Operations a Vector Database Provides

• Upsert: Insert or update a vector with an ID, the vector itself, and optional metadata (payload).
• Search: Given a query vector, return the top-k nearest neighbors with their scores and metadata.
• Filtered search: Combine vector similarity with metadata filters (e.g., "find similar documents tagged 'finance' from 2025").
• Delete: Remove vectors by ID or by metadata filter.
• Collection management: Create named collections with specific dimensionality, distance metric, and index configuration.
• Quantization: Built-in scalar, product, or binary quantization to reduce memory and speed up search.
• Persistence and replication: Disk-based storage, snapshots, and multi-node replication for durability.

The vector database landscape matured rapidly between 2022 and 2026. The six options below cover the mainstream choices for production RAG systems. Each has distinct strengths, deployment models, and operational profiles.

Qdrant -- Detailed Profile

Written in Rust, Qdrant is a performance-oriented vector search engine with first-class support for filtered search. Its standout feature is payload filtering with its own indexing structures, which lets you pre-filter by metadata (tags, dates, categories) before or during vector search without the performance cliff that some engines hit. Qdrant supports scalar quantization (int8), product quantization, and binary quantization natively. It runs as a single binary, a Docker container, or a managed cloud service. The API is REST-based (JSON over HTTP) with gRPC also available. For RAG systems where filtered search is important (e.g., "search only documents from department X dated after Y"), Qdrant is a top recommendation.

ChromaDB -- Detailed Profile

ChromaDB is the easiest vector database to start with. It runs embedded in a Python process (no server needed) or as a client-server setup. The Python API is clean and integrates tightly with LangChain and LlamaIndex. Chroma uses HNSW under the hood (via the hnswlib library) and stores metadata alongside vectors. Its weakness is scale and operational maturity: it is not designed for billion-vector datasets or high-throughput multi-tenant production deployments. For a local RAG prototype or a small internal tool, Chroma is excellent. For a production system serving thousands of concurrent users, evaluate Qdrant, Weaviate, or Milvus instead.

Pinecone -- Detailed Profile

Pinecone is a fully managed, proprietary SaaS vector database. You never touch a server, configure an index, or manage replication. Its serverless architecture (introduced 2024) separates storage and compute, so you pay for what you use rather than provisioning fixed-size pods. Pinecone supports metadata filtering, namespaces for multi-tenancy, and sparse-dense hybrid vectors. The tradeoffs are cost at high query volumes, vendor lock-in, no self-hosting option, and data leaving your infrastructure. Pinecone is ideal for teams that want to ship semantic search fast and have no capacity or desire to operate infrastructure.

Weaviate -- Detailed Profile

Weaviate is an open-source vector search engine (BSD-3 license) with a distinctive feature: vectorizer modules that can generate embeddings server-side. You can configure a Weaviate class to use, say, the text2vec-transformers module, and Weaviate will call a local or external model to embed your text on insertion -- you just send text, not vectors. Weaviate also has built-in hybrid search (BM25 + vector) and a GraphQL API. It supports HNSW, scalar quantization, product quantization, and binary quantization. Weaviate is a strong choice when you want the database to handle embedding generation and hybrid search in one system.

Milvus -- Detailed Profile

Milvus (created by Zilliz) is the choice for very large scale. It is a distributed, cloud-native vector database designed for datasets from hundreds of millions to billions of vectors. Milvus supports the most index types of any engine listed here: HNSW, IVF (flat, PQ, SQ8), DiskANN, SCANN, and GPU-accelerated indexes (GPU_CAGRA, GPU_IVF). Its architecture separates storage and compute, supports sharding and replication, and has a mature ecosystem (Attu for management UI, Zilliz Cloud for managed service). The operational complexity is higher than Qdrant or Chroma -- Milvus typically runs as a multi-component distributed system (etcd, MinIO, Pulsar/Kafka, and Milvus nodes). For datasets under 10M vectors, this complexity is usually not justified. For 100M+ vectors with high throughput, Milvus is the leading open-source option.

pgvector -- Detailed Profile

pgvector is a PostgreSQL extension that adds a vector type and two index types: HNSW (recommended, added in pgvector 0.5.0) and IVFFlat. You store vectors in a regular Postgres table alongside any other columns, and you query them with SQL: SELECT * FROM docs ORDER BY embedding <=> '[0.1, 0.2, ...]' LIMIT 10;. The <=> operator is Euclidean distance, <#> is negative inner product, and <~> is cosine distance. pgvector gives you vector search plus the full power of SQL (joins, aggregations, transactions, row-level security) in one database. For datasets up to roughly 1-5 million vectors, pgvector with HNSW is performant and operationally simple. Beyond that, dedicated vector databases offer better memory management, quantization, and distributed scaling.

The index is the data structure that makes similarity search fast. Without an index, every query scans the entire dataset (brute force / flat search). With an index, queries touch a small fraction of vectors and return approximate results with high recall. Understanding index types is essential because they control the speed-recall-memory tradeoff in your vector database.

Brute-Force (Flat) Index

The flat index is no index at all: the query vector is compared against every vector in the dataset, distances are computed for all, and the top-k are returned. This is exact -- 100% recall by definition. The cost is O(N * d) per query. For small datasets (up to ~10,000-100,000 vectors depending on dimensionality and latency budget), brute force is fast enough and guarantees perfect results. Many vector databases offer a "flat" or "exact" search mode for this reason. Beyond that size, you need an approximate index.

Brute force is also the ground truth for benchmarking: you compare ANN index recall against flat search results to measure how many true top-k neighbors the index finds.

HNSW (Hierarchical Navigable Small World)

HNSW is the dominant ANN index in production vector databases as of 2026. It is a graph-based index inspired by the "small world" network concept. Vectors are nodes in a multi-layer graph. The top layers contain few nodes with long-range connections; the bottom layer contains all nodes with short-range connections. A query starts at a top-layer entry point, greedily moves toward the query vector, and descends layer by layer, refining the search at each level. This hierarchical structure gives logarithmic-time search with excellent recall.

Key HNSW parameters:

• M (default 16): The number of bi-directional links created for each new element during construction. Higher M = more memory, better recall, slower construction. Typical range: 12-48.
• ef_construction (default 200): The size of the dynamic candidate list during index construction. Higher = better index quality, slower build. Typical range: 100-500.
• ef_search (default varies): The size of the dynamic candidate list during search. Higher = better recall, slower query. This can be tuned per query in most engines. Typical range: 50-500.

HNSW strengths: excellent recall-speed tradeoff, fast queries (sub-millisecond at moderate scale), no training step required (unlike IVF), incremental insertion is efficient. HNSW weaknesses: high memory usage (the graph adds 1.5x-2x on top of raw vector storage), index does not fit in memory well for billion-scale datasets, and filtered search can be tricky (the graph may not respect filters, leading to post-filtering recall drops).

IVF (Inverted File Index)

IVF works by clustering the dataset into nlist cells using k-means. At query time, the query vector is compared to the cluster centroids, and only vectors in the nearest nprobe clusters are searched (flat search within those clusters). This reduces the search space from N to roughly N * nprobe / nlist.

Key IVF parameters:

• nlist: Number of clusters/centroids. Rule of thumb: sqrt(N) to 4*sqrt(N). For 1M vectors, nlist = 1000-4000.
• nprobe: Number of clusters to search at query time. Higher = better recall, slower. Typical: nlist/100 to nlist/10.

IVF requires a training step (k-means clustering on a representative sample) before insertion. This is a key difference from HNSW, which builds incrementally. IVF variants include IVF-Flat (exact search within probed clusters) and IVF-PQ (vectors within clusters are product-quantized for further compression). IVF-PQ is the most memory-efficient option for very large datasets, at the cost of lower recall.

IVF strengths: lower memory than HNSW (no graph overhead), good for very large datasets, supports quantization variants. IVF weaknesses: requires training, slower queries than HNSW at equal recall on most workloads, insertion after training can degrade cluster quality over time (may require re-training).

Other Notable Index Types

• DiskANN: A disk-based index for datasets too large to fit in RAM. Stores the graph on SSD and loads only the needed portions per query. Milvus and Weaviate support it. Trades query latency for the ability to search billion-scale datasets on machines with limited RAM.
• ScaNN: Google's ANN library, notable for anisotropic quantization. Available in Milvus. Strong performance on certain benchmarks.
• GPU-CAGRA / GPU-IVF: GPU-accelerated indexes in Milvus (via RAPIDS cuVS). For ultra-low-latency, high-throughput search on GPU-equipped infrastructure.

Retrieval-Augmented Generation (RAG) is the dominant architecture for grounding LLMs in external knowledge. The retrieval layer -- powered by embeddings and a vector database -- is what distinguishes RAG from pure prompt engineering. Here is the complete pipeline, broken into its ingestion and query phases.

Phase 1: Ingestion (Done Once, Updated Periodically)

Step 1 -- Document Loading: Read source documents from their original locations: PDFs, HTML pages, Word docs, Confluence pages, databases, Notion pages, GitHub repos. Each document becomes a Document object with text content and metadata (source URL, title, author, date, department, access level).

Step 2 -- Chunking: Split documents into smaller passages (chunks) that fit within the embedding model's context window and the LLM's context budget. Chunking strategy (covered in detail in the next section) heavily affects retrieval quality. Typical chunk sizes: 200-1000 tokens with 10-20% overlap.

Step 3 -- Embedding Generation: Pass each chunk through the embedding model to produce a vector. This is a batch operation -- chunks are sent in batches of 32-256 to the embedding model (local or API) to maximize throughput. Each chunk now has: an ID, the vector, the chunk text, and metadata inherited from the parent document.

Step 4 -- Vector Database Insertion: Upsert each (ID, vector, payload) tuple into the vector database. The payload includes the chunk text, source document metadata, and any precomputed filter fields. The vector database builds or updates its HNSW index as vectors arrive.

Step 5 -- Index Optimization: After a bulk load, optionally tune index parameters (HNSW M, ef_construction, quantization settings) based on the dataset size and target latency. For incremental updates, this is done periodically rather than per-insert.

Phase 2: Query (Done Per User Request)

Step 1 -- Query Embedding: The user's question is passed through the same embedding model used during ingestion. Using a different model for queries than for ingestion is a fatal retrieval bug -- the vectors live in different spaces and similarity is meaningless. The output is a single query vector.

Step 2 -- Metadata Filter Construction (Optional): If the user's query implies a scope (e.g., "What did our finance team say about Q4 earnings?"), construct a metadata filter: {"department": "finance", "date": {"$gte": "2025-10-01"}}. This narrows the search space before vector similarity is computed.

Step 3 -- Vector Search: Send the query vector to the vector database with parameters: top-k (e.g., 10-20), the similarity metric, optional filter, and search-time index parameters (ef_search for HNSW, nprobe for IVF). The database returns the k most similar chunks with their scores and payloads.

Step 4 -- Re-ranking (Optional but Recommended): Retrieve a larger top-k (e.g., 50-100) from the vector database, then re-rank them with a cross-encoder model (e.g., bge-reranker-large, Cohere Rerank). Cross-encoders score query-document pairs jointly (not via embeddings) and are more accurate than pure vector similarity. Re-ranking the top 50-100 down to the final 5-10 significantly improves end-to-end RAG quality.

Step 5 -- Context Assembly: Take the final top-k chunks (after re-ranking), concatenate their text with source citations, and insert them into the LLM prompt under a "Context" or "Retrieved Documents" section. The prompt also includes the user's question and instructions to answer based on the context.

Step 6 -- LLM Generation: The LLM reads the context and question, generates an answer grounded in the retrieved chunks, and (if instructed) cites the sources. The answer is returned to the user along with the source citations for verification.

Chunking is how you split documents into the passages that get embedded and stored. It is one of the most impactful and most neglected levers in RAG system quality. Bad chunking destroys retrieval even with a perfect embedding model: a chunk that spans two unrelated topics will not match either query well, and a chunk that cuts a sentence in half loses meaning. Good chunking preserves semantic coherence within each chunk.

Fixed-Size Chunking (Token or Character Based)

The simplest strategy: split text into chunks of N tokens (or N characters) with an optional overlap. Common settings: 512 tokens with 64-token overlap. Fixed-size chunking is easy to implement and predictable. Its weakness is that it ignores semantic boundaries -- a chunk may start or end mid-sentence, fragmenting the meaning. Overlap (10-20% of chunk size) mitigates but does not solve this. Fixed-size chunking is a reasonable default for homogeneous text (articles, manuals) and is the baseline most frameworks use.

Sentence-Based Chunking

Split text at sentence boundaries, then group sentences into chunks up to a target size. This preserves sentence-level semantics -- no chunk cuts a sentence in half. Use a sentence tokenizer (NLTK, spaCy, or the simpler regex-based splitter in LangChain) to identify boundaries first. Sentence chunking is better than fixed-size for prose but can still group unrelated sentences if a paragraph shifts topics mid-way.

Paragraph-Based Chunking

Split at paragraph boundaries. Paragraphs are natural semantic units -- an author typically groups related sentences into a paragraph. For well-structured documents (reports, articles, documentation), paragraph chunking often produces the most coherent chunks. The challenge is variable chunk size: some paragraphs are one sentence, others are 500 words. You can merge small adjacent paragraphs or split large ones with sentence-level fallback to stay within a target size range.

Recursive / Structural Chunking

LangChain's RecursiveCharacterTextSplitter is the most widely used approach in practice. It splits on a hierarchy of separators (e.g., ["\n\n", "\n", ". ", " ", ""]) -- first by paragraphs, then by lines, then by sentences, then by characters -- until chunks fit the target size. This respects document structure as much as possible while guaranteeing a size bound. It is the recommended default for most RAG ingestion pipelines.

Semantic Chunking

A more advanced strategy: embed each sentence, then split at points where the cosine similarity between adjacent sentences drops below a threshold (often the 95th percentile of similarity drops). This produces chunks that are semantically coherent -- each chunk covers one "topic" as detected by embedding similarity drift. Semantic chunking requires an extra embedding pass during ingestion (embed every sentence first, then chunk), which adds cost. Research and practitioner reports suggest it can outperform fixed-size chunking on complex documents, but the gain is modest on simple text and the cost is non-trivial.

Document-Specific Chunking

• Markdown / HTML: Split on headers (H1, H2, H3) to preserve structural sections. A chunk under an "Installation" heading is semantically about installation.
• Code: Split on function/class boundaries. Each function is a natural chunk. Use language-aware splitters (tree-sitter based).
• PDFs: Use layout-aware extractors (unstructured, PyMuPDF) that respect columns, tables, and figure captions. Naive text extraction from PDFs often interleaves columns and produces garbage chunks.
• Tables: Embed the table as text (CSV or markdown) or use a table-specific embedding approach. Do not split a table across chunks.

1. Generating Embeddings with curl (OpenAI API)

The OpenAI embeddings API is the fastest way to get a working embedding pipeline. Send text, receive a vector.

2. Generating Embeddings with Python (Self-Hosted sentence-transformers)

3. Storing Vectors in Qdrant (Python)

4. Similarity Search in Qdrant (with Metadata Filtering)

5. Full RAG Pipeline in Python (Qdrant + OpenAI LLM)

6. pgvector Example (PostgreSQL + SQL)

Batch Size for Embedding Generation

Always batch your embedding requests. Embedding one text at a time is 10x-50x slower than batching, because the model's forward pass amortizes overhead across the batch. For self-hosted sentence-transformers on GPU, batch sizes of 64-256 are typical. For CPU-only inference, 32-64 is more appropriate (larger batches do not help much on CPU and consume more memory). For OpenAI's API, batch up to 2048 texts per request (the API limit) -- this also reduces per-request overhead and network round-trips.

Dimension Reduction Strategies

If storage or memory is a constraint, reduce dimensions in this order of preference:

1. Use a smaller model: Switch from a 1536-dim OpenAI model to a 384-dim MiniLM or 768-dim BGE model. This is the cleanest reduction -- you embed at lower dimensions from the start.
2. Matryoshka truncation (MRL models only): For OpenAI text-embedding-3-* or MRL-trained open models, set the dimensions parameter to 512 or 256. Safe, model-supported, minimal quality loss.
3. Scalar quantization (int8): Keep all dimensions but store each float as an 8-bit integer. 4x storage reduction, negligible recall loss. Supported natively by Qdrant, Weaviate, Milvus.
4. Product quantization (PQ): Compress vectors into subvectors encoded by codebooks. 16x-32x reduction, more noticeable recall loss. Use for billion-scale where memory is the binding constraint.
5. PCA (post-hoc): Fit PCA on your dataset and reduce 768-dim to 256-dim. Works on any model but requires fitting on your data and adds a transform step. Less clean than model-native shortening.

Metadata Filtering -- The Hidden Performance Lever

Metadata filtering is one of the most impactful yet underused techniques in production vector search. Instead of searching across all vectors, you pre-filter by metadata (date range, category, user ID, access level) and search only the filtered subset. This improves both relevance (the user only sees results from their scope) and performance (fewer vectors to search).

The challenge is that HNSW graphs are built without knowledge of filters. A naive approach (retrieve top-k by similarity, then drop results that fail the filter) can return zero results if none of the top-k match the filter. This is called the post-filtering recall problem. Vector databases handle this differently:

• Qdrant: Uses payload indexing with filterable HNSW. Can do pre-filtering (search only within filtered subset) efficiently. This is Qdrant's signature strength.
• Weaviate: Supports inverted index on properties combined with HNSW, enabling efficient filtered search.
• Pinecone: Supports metadata filtering with its own optimized approach; very fast for selective filters.
• pgvector: Filtering is just a SQL WHERE clause. PostgreSQL's planner handles it naturally. For highly selective filters, Postgres may choose to skip the HNSW index and do a filtered scan instead.

Latency Budgets and Sizing

Monitoring and Benchmarking

In production, track these metrics continuously:

• Query latency (p50, p95, p99): Set alerts on p99 latency. If it drifts upward, your index may need tuning or your dataset has outgrown your index parameters.
• Recall@k: Periodically run a set of known queries with known-good results and measure what fraction the vector search returns. A recall drop signals index degradation or a model change.
• Index build time: Track how long bulk loads take. If it grows non-linearly with dataset size, you may be hitting a configuration issue.
• Memory usage: HNSW is memory-resident. Monitor RAM and swap. If you start swapping, latency will spike dramatically.
• Filter selectivity: Log what fraction of your queries use filters and how selective they are. This informs whether you need payload indexing or collection partitioning.

Source Attribution

Source: Avondale.AI Technical Documentation Library
Category: Core AI Concepts
Type: Technical Reference Guide
License: CC BY 4.0

Foundational Papers

• Mikolov et al. (2013). "Efficient Estimation of Word Representations in Vector Space." arXiv:1301.3781 -- The Word2Vec paper.
• Pennington, Socher, Manning (2014). "GloVe: Global Vectors for Word Representation." EMNLP 2014 -- The GloVe paper.
• Devlin et al. (2019). "BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding." arXiv:1810.04805 -- The BERT paper.
• Reimers & Gurevych (2019). "Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks." arXiv:1908.10084 -- The Sentence Transformers paper.
• Malkov & Yashunin (2018). "Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs." arXiv:1603.09320 -- The HNSW paper.
• Jegou, Douze, Schmid (2011). "Product Quantization for Nearest Neighbor Search." IEEE TPAMI -- The PQ paper.
• Lewis et al. (2020). "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks." arXiv:2005.11401 -- The original RAG paper.
• Karpukhin et al. (2020). "Dense Passage Retrieval for Open-Domain Question Answering." arXiv:2004.04906 -- DPR, dual-encoder retrieval.
• Kusupati et al. (2022). "Matryoshka Representation Learning." arXiv:2205.13147 -- MRL, dimension shortening.
• Jayaram Subramanya et al. (2019). "DiskANN: Fast Accurate Billion-point Nearest Neighbor Search on a Single Node." NeurIPS -- Disk-based ANN.

Vector Databases & Tools

• Qdrant: qdrant.tech -- Open-source vector search engine (Rust)
• ChromaDB: trychroma.com -- Open-source, Python-native vector database
• Pinecone: pinecone.io -- Managed serverless vector database
• Weaviate: weaviate.io -- Open-source vector search with modules
• Milvus: milvus.io -- Distributed vector database for billion-scale
• pgvector: github.com/pgvector/pgvector -- PostgreSQL vector extension
• Sentence Transformers: sbert.net -- Sentence embedding models and docs
• HuggingFace MTEB Leaderboard: huggingface.co/spaces/mteb/leaderboard -- Embedding model benchmarks
• OpenAI Embeddings Guide: platform.openai.com/docs/guides/embeddings
• LangChain Text Splitters: python.langchain.com/docs/how_to/#text-splitters
• LlamaIndex: llamaindex.ai -- RAG framework with chunking and retrieval primitives
• Faiss: github.com/facebookresearch/faiss -- Facebook's vector similarity search library

Further Reading

• Massive Text Embedding Benchmark (MTEB): arXiv:2210.07316 -- Comprehensive embedding evaluation across 56 tasks.
• Anthropic Contextual Retrieval: anthropic.com/news/contextual-retrieval -- Adding context to chunks before embedding.
• OpenAI Cookbook - Embeddings: cookbook.openai.com/articles/embeddings
• BGE Reranker Models: huggingface.co/BAAI/bge-reranker-large -- Cross-encoder re-ranking for RAG.
• Qdrant Documentation - Filtering: qdrant.tech/documentation/concepts/filtering/
• Pinecone - Hybrid Search: pinecone.io/learn/hybrid-search-intro/

Suggested Citation:
Embeddings and Vector Databases Explained: The Semantic Layer That Powers Modern AI Search and RAG. Avondale.AI Technical Documentation Library. Accessed June 2026. https://avondale.ai/technical/embeddings-vector-databases.html