🧭 Vector Databases and Embeddings

About this simulation

A retrieval-augmented-generation (RAG) system doesn't search raw text — it searches embeddings: dense numeric vectors produced by a neural encoder so that semantically similar passages land near each other in a high-dimensional space. This scene compresses that space to 3D. Each glowing point is a document chunk; its position is determined by its topic, so clusters emerge naturally — cooking recipes near cooking recipes, astronomy near astronomy.

How it works

• A query vector (the bright pulsing marker) is embedded and placed in the same space as the documents.
• A vector database compares the query against every stored embedding using a similarity metric — cosine similarity (angle between vectors) or Euclidean distance (straight-line distance).
• The top-K closest embeddings are retrieved and linked to the query with lines, ranked brightest-to-dimmest by score.
• Pressing Run retrieval streams those retrieved chunks up to the "LLM context" node, simulating the augmentation step where retrieved text is stuffed into the prompt before generation.

Controls

• Query topic — which document cluster the query is drawn from.
• Topic drift — blends the query toward a neighbouring topic, simulating an ambiguous or cross-domain question.
• Top-K retrieved — how many nearest neighbours the vector database returns.
• Similarity metric — cosine similarity (direction only) vs. Euclidean distance (direction + magnitude); switching can change which points are "nearest".
• Embedding spread — how tightly documents cluster by topic, illustrating how embedding quality affects retrieval precision.

Did you know?

Most production embedding models (OpenAI's text-embedding-3, Cohere Embed, BGE, etc.) are trained so that cosine similarity is the intended comparison — vector databases like Pinecone, Weaviate and pgvector default to it, and approximate-nearest-neighbour indexes such as HNSW trade a little accuracy for searches that scale to billions of vectors in milliseconds.