#Vector Search
Articles about Vector Search — exploring patterns, best practices, and real-world implementations in production systems.
11 posts tagged with vector search. ← All posts
The final decision isn't "which algorithm is best" — it's "which point on the recall-latency-memory triangle does my workload need, and what's the simplest thing that hits it." For a huge number of systems the honest answer is far less exotic than the vector-database marketing suggests, and knowing when you've genuinely outgrown Postgres is worth more than knowing HNSW's internals.
The final decision isn't 'which algorithm is best' — it's 'which point on the recall-latency-memory triangle does my workload need, and what's the simplest thing that hits it.' Often the honest answer is far less exotic than the vector-database marketing suggests.
Real search is never pure vector similarity. Users want "similar documents from this project, updated this year" and they expect an exact product code to match exactly. Combining similarity with metadata filters and keyword search — without wrecking recall — is where academic ANN meets production requirements, and it's harder than it looks.
Real search is never pure vector similarity. Users want 'similar documents from this project, updated this year' and expect an exact product code to match exactly — combining similarity with metadata filters and keyword search without wrecking recall is where ANN meets production.
Vectors are big, and storing millions of them in full precision is where vector search gets expensive. Quantization compresses each vector into a fraction of its size — trading a little recall for large memory savings — and it's the technique that lets both IVF and HNSW scale from millions of vectors to billions without a memory budget that breaks the bank.
Vectors are big, and storing millions in full precision is where vector search gets expensive. Quantization compresses each vector into a fraction of its size — trading a little recall for large memory savings — and it's what lets IVF and HNSW scale to billions.
HNSW is the algorithm behind most modern vector databases, and its idea is borrowed from the "six degrees of separation" that connects any two people through a short chain of acquaintances. Build the right graph of vectors, and you can walk from a random entry point to a query's nearest neighbors in a handful of hops — searching millions of vectors while touching only a few hundred.
HNSW is behind most modern vector databases, and its idea comes from the 'six degrees of separation' that connects any two people through a short chain — build the right graph and you can walk from a random entry to a query's nearest neighbors in a handful of hops.
The simplest way to beat brute force is to avoid searching most of your data — cluster the vectors into regions, and at query time only look inside the few regions nearest the query. That's IVF, and its one tuning knob, how many regions to probe, is a clean, visible dial on the recall-versus-speed trade at the heart of the whole field.
The simplest way to beat brute force is to avoid searching most of your data — cluster the vectors into regions, and at query time only look inside the few nearest the query. That's IVF, and its one knob (nprobe) is a clean dial on the recall-versus-speed trade.
The most underrated vector index is no index at all. Brute-force search — compare the query to every vector — is the one method with perfect recall, zero build time, and no tuning, and for a surprising number of real systems it's not just adequate but optimal. Knowing when you don't need an ANN index is as valuable as knowing how they work.
The most underrated vector index is no index at all. Brute-force search has perfect recall, zero build time, and no tuning, and for a surprising number of real systems it's optimal — knowing when you don't need ANN is as valuable as knowing how it works.
"Nearest" is meaningless until you define "distance," and the metric you choose — cosine, dot product, or Euclidean — must match how your embedding model was trained or your search is quietly wrong. And in high dimensions, distance itself behaves so strangely that the naive intuitions you'd bring from 2D geometry actively mislead you.
'Nearest' is meaningless until you define 'distance,' and the metric you choose must match how your embedding model was trained or your search is quietly wrong — and in high dimensions, distance itself behaves so strangely that 2D intuitions mislead you.
Every RAG system, recommendation engine, and semantic search box rests on one deceptively simple operation: given a query vector, find the closest vectors among millions. Doing it exactly is easy and doesn't scale; doing it fast enough to be useful means giving up exactness on purpose — and understanding that trade is the foundation of vector search.
Every RAG system and semantic search box rests on one operation: given a query vector, find the closest among millions. Doing it exactly is easy and doesn't scale; doing it fast means giving up exactness on purpose — and that trade is the foundation of vector search.
Wire the embedding client, vector store, and chat client from the last five posts into one working RAG pipeline in Go — ingest and chunk documents, retrieve the top matches for a question, inject them as grounded context, and generate a cited answer, all from scratch.
Assemble embeddings and vector search into a working RAG pipeline in Go: chunk documents, embed and store them, retrieve the top-k for a query, augment the prompt with grounded context (and cite sources), then generate — a baseline end-to-end Answer() built from scratch.
Build a working in-memory vector store and exact k-nearest-neighbor search in Go by hand — no vector database — then understand precisely what HNSW, FAISS, and pgvector optimize when brute force finally runs out of road.
Build an in-memory vector store and exact k-NN search in Go by hand: a VectorStore with Add and Search, top-k selection with container/heap, normalize-on-insert, an honest look at when brute force is right, and when ANN (HNSW, FAISS, pgvector) earns its keep.
Turn text into a `[]float32` that places meaning in space — what an embedding is, cosine similarity implemented by hand in Go, calling an OpenAI-compatible /embeddings endpoint with net/http, and a worked pairwise-similarity example that scores related sentences higher.
Turn text into a []float32 that places meaning in space — what an embedding is, cosine similarity implemented by hand in Go, calling an OpenAI-compatible /embeddings endpoint with net/http, and a worked pairwise-similarity example that scores related sentences higher.
All posts on this site are written by Pratik Dhanave, an Agentic AI Architect with 7+ years building production distributed systems, multi-agent AI platforms, and cloud-native infrastructure. About the author → Each article includes working code, architecture diagrams, and references to the specific frameworks and standards discussed. Browse all posts or explore related topics using the tag cloud above.