Dense Retrieval, Semantic Search, Vector Indexes and Vector Databases

Similarity functions

Common choices: cosine similarity, dot product, Euclidean distance.

For unit vectors the ranges shrink: the dot product equals the cosine, in \([-1, 1]\), and the distance lies in \([0, 2]\).

Try it: when the three disagree

A query \(q\) and three documents in 2-D (invented). Stretch document A without turning it: its cosine does not change, but its dot product grows and its distance changes. Tick "normalize" to put every vector on the unit circle.

❗ Match the model's training setup. Do not choose a metric arbitrarily: a retrieval model may have been trained for dot product or for cosine similarity, and the search metric should match the representation model's intended use. (all-MiniLM-L6-v2: cosine, so we normalize and use the inner product.)

What is a vector database?

A vector index and a vector database are related, but they are not the same thing.

What goes into a vector database

The vector database stores and searches these vectors; it does not care what they came from. But the embedding model must suit the data: all-MiniLM-L6-v2 reads text only; images need a multimodal model such as CLIP (Radford et al., 2021), which maps images and texts into one shared space, so that a text query can find a picture. Typical dimensions: 384, 768, 1,536.

{
    "id": "chunk_0011",
    "vector": [-0.079, 0.008, 0.002, ...],     # its all-MiniLM-L6-v2 embedding, 384 numbers
    "text": "The master's thesis is worth 30 ECTS credits.",
    "metadata": {
        "document": "programme_rules.pdf",
        "page": 14,
        "section": "Thesis"
    }
}

See it: the vector database workflow, step by step

The twelve chunks of the widget below (invented texts and metadata, real all-MiniLM-L6-v2 vectors) going through the six steps of a vector database. Pick a query, then step through.

Why metadata matters

The query What is the vacation policy? against a collection that mixes HR documents, engineering manuals, legal contracts and student regulations. We may want semantic similarity + a metadata filter such as department = "HR", year = 2026, document_type = "policy":

This is extremely common in practical RAG systems.

Try it: filtered semantic search

Twelve chunks with invented metadata; the scores are real all-MiniLM-L6-v2 cosines. Choose a query and filters; the top \(k = 3\) are returned. Compare the two ways of combining the filter with the vector search.

💡 For How many vacation days do employees get? the outdated 2024 handbook scores 0.803 and the current one 0.804: the embedding cannot tell which year you need, a metadata filter can. With search, then filter (take the top 3, then drop what fails the filter), What is the vacation policy? filtered to the Student office returns nothing, although a matching chunk exists: the filter must be applied during the search, which is what vector databases do.

Vector database vs traditional database

• The line is blurring: many real-world systems combine both (a vector database for semantic search, a relational database for structured data and transactions), and relational systems add vector search themselves (PostgreSQL's pgvector extension). A vector database does not necessarily replace relational storage.
• Vector database vs FAISS: FAISS is a similarity-search library, a vector-index toolkit; a vector database is a persistent data system that may use ANN indexes internally, and adds storage, metadata, filtering, APIs, index lifecycle, replication / sharding.

Semantic search with a vector database

In a RAG system, those nearest chunks are what the language model gets to read.

• ❗ What the vector database does NOT do: create semantic meaning. It does not replace the embedding model; bad embeddings stored in an excellent vector database are still bad embeddings. Keep the layers separate: encoder → representation quality; vector index / database → storage + retrieval efficiency; reranker → final ordering quality.
• Common operations: insert / upsert vectors, search nearest neighbors, filter by metadata, delete stale vectors, update embeddings, persist the index, partition or shard the collection.
• When do we actually need one? For a teaching dataset such as Cranfield, NumPy + FAISS is enough. A vector database becomes useful with persistent collections, frequent updates, metadata filters, multiple users, large-scale serving, operational APIs, distributed storage. Do not introduce one merely because RAG tutorials use one: the underlying retrieval concepts come first.

Three levels of quality

Diagnostic table

The recall–latency–memory trade-off

A retrieval system rarely optimizes one variable in isolation: more probes → higher recall → higher latency; more graph edges → potentially better search → more memory; compressed vectors → lower memory → possible quality loss. FAISS's HNSW on the same Cranfield vectors (32 edges per node, one thread):

hnsw = faiss.IndexHNSWFlat(d, 32, faiss.METRIC_INNER_PRODUCT)   # 32 edges per node
hnsw.add(vectors)                                                  # no training step; 42 ms here
all_queries = model.encode([q.text for q in queries], normalize_embeddings=True).astype("float32")
_, exact_all = flat.search(all_queries, 10)                        # all 225 queries
for ef in [16, 32, 64]:
    hnsw.hnsw.efSearch = ef                # candidates kept during the graph walk
    _, ids = hnsw.search(all_queries, 10)
    print(f"{ef:>2}  {ann_recall_at_k(exact_all, ids):.4f}  {us_per_query(hnsw, all_queries, reps=50):.1f} µs")
# 16  0.9924  10.8 µs          efSearch, ANN recall@10 on 225 queries, time per query
# 32  0.9982  17.9 µs
# 64  0.9996  29.1 µs

The engineering question is not "which index is best?" but "which operating point satisfies our quality and resource requirements?" And vector-index design affects not only latency: it can change which evidence reaches the later RAG stages.