VECTOR SEARCH / STRUCTURAL MAP

Vector Search Notes

Visual notes on embeddings, ANN indexes, vector databases, hybrid search, and production RAG retrieval systems.

Learn how vector search works, how embeddings represent meaning as coordinates, how HNSW and product quantization make retrieval scalable, how vector databases fit into RAG systems, and how to estimate memory with the RAM calculator.

01 / FOUNDATIONS

Vector Search Limitations

Cosine similarity limits
Embedding failure modes
RAG retrieval risk

Why vector proximity is a ranking signal, not proof of understanding, factual truth, or user intent.

Read vector search limitations

02 / ALGORITHMS

HNSW Graph Search

Approximate nearest neighbor
M and efSearch
Graph memory

How HNSW uses layered proximity graphs to make ANN search fast enough for vector databases and RAG systems.

Open HNSW graph search

03 / COMPRESSION

Product Quantization

Vector compression
Codebooks
Recall tradeoffs

How PQ compresses embeddings into compact codes, lowers RAM pressure, and adds controlled approximation error.

Study product quantization

04 / ARCHITECTURE

Production RAG Retrieval Architecture

Hybrid BM25 + vector
Metadata filters
Reranking pipelines

How production vector search combines embeddings, metadata, hybrid retrieval, reranking, sharding, and monitoring.

Open production architecture

05 / TOOLS

Vector Database Memory Calculator

Embedding storage
Index overhead
Quantization planning

Estimate RAM and storage from vector count, dimensions, precision, index overhead, and compression assumptions.

Estimate vector RAM

PRODUCTION SCALE

Why Vector Search Matters in Production

Vector search moves AI systems from stateless text generation into stateful enterprise memory. The model can answer from what the system can retrieve. The retrieval layer becomes part of the product contract.

Serving 10,000 vectors is easy. Serving 1 billion vectors is a different machine. RAM, CPU cache behavior, recall, latency, sharding, filtering, and reranking all start competing for the same budget. The hard part is not calling a similarity API. The hard part is deciding what memory the system is allowed to touch for every query.

SEARCH INTENT GUIDES

Next Technical Topics.

Shorter guides for comparison queries and production RAG problems that engineers search for directly.

01 Vector Search vs Keyword Search 02 Semantic Search vs Vector Search 03 HNSW vs IVF 04 FAISS vs Pinecone vs Qdrant 05 Cosine Similarity Explained for Vector Search 06 RAG Chunking Strategies 07 RAG Retrieval Failure Modes 08 Vector Database Interview Questions

VENDOR-AGNOSTIC CONSTRAINTS

Agnostic Architectural Truths.

The first-principles here apply across dedicated vector databases, local search libraries, and traditional databases that added vector support. Milvus, Qdrant, Pinecone, Weaviate, FAISS, USearch, PostgreSQL with pgvector, and Elasticsearch/Lucene do not share one internal architecture.

They do face similar constraints: memory footprint, distance metrics, candidate generation, recall versus latency, compression error, filtering, reranking, and sharding. Different systems expose different controls. The physics do not disappear.

Dedicated vector databases Milvus, Qdrant, Pinecone, Weaviate
Local search libraries FAISS, USearch
Traditional search and SQL systems PostgreSQL/pgvector, Elasticsearch/Lucene