Search your own documents the way a vector database does - by similarity, animated as a layered graph walk.
multi-layer navigable small-world graph; greedy descent layer by layer.
Three stacked layers: sparse entry on top, dense base at the bottom. The glowing marker is your search word dropping layer to layer to the closest document.
Frequently asked questions
Is HNSW how Spotify finds songs that feel like my favorites?
Yes - that 'similar in vibe, not identical' part is exactly it. Spotify's recommendations find tracks close to your favourites in a space of musical features, almost instantly, from millions of songs. HNSW makes this fast: it builds a navigable layered graph of items so a query can hop quickly toward its nearest neighbours without comparing against every track. It is approximate - trading a touch of accuracy for huge speed - which is the right trade for 'find things like this' at scale.
This demo matches shared words - is that how real semantic search works?
No, and that's an important distinction. This offline demo measures LEXICAL similarity: it rewards documents that share the same words or letters as your search. Real HNSW works on EMBEDDINGS - lists of numbers that capture meaning - so it can tell that 'puppy' is close to 'dog' even with no shared letters. We use word-overlap here only so the graph-walk animation runs instantly with no API. The graph mechanic you see (enter at the top, hop down to the closest) is exactly the same; only the distance measure differs.
What does the 'small world' in Hierarchical Navigable Small World mean?
A 'small world' network is one where any two points are linked by a surprisingly short chain - the same idea as 'six degrees of separation' between people. HNSW builds its graph so most links are to near neighbours but a few are long-range shortcuts. Those shortcuts let a search leap across the whole space in a few hops, which is why query time grows only logarithmically as data grows.
Why is HNSW called 'approximate' - does it ever miss the true match?
Yes, occasionally. Because it follows greedy links rather than checking every item, it can settle on a very-close neighbour that isn't the absolute closest. In practice it's tuned (via parameters like efSearch and M) to find the true nearest neighbour the vast majority of the time. For search and recommendation, a 99%-accurate answer in milliseconds beats a perfect answer that takes seconds over millions of vectors.
How does HNSW relate to RAG and AI chatbots?
Retrieval-Augmented Generation turns documents into embedding vectors, stores them in a vector database, and at query time finds the chunks most similar in meaning to the user's question. HNSW is the index that makes that 'find similar' step fast enough to feel instant. When an AI assistant pulls up the most relevant notes before answering, an HNSW (or similar ANN) index is usually doing the retrieval - exactly the document search you just ran, scaled to millions of items.
What are the M and ef parameters everyone tunes?
M is how many neighbour links each node keeps - higher M means a richer graph that's more accurate but uses more memory and builds slower. efConstruction controls how thoroughly the graph is built; efSearch controls how widely each query explores. Raising efSearch improves recall (fewer missed matches) at the cost of speed. Tuning these three is the main lever for trading accuracy against latency.
What data structure is HNSW built on?
At heart it's a GRAPH - the same generic structure you meet anywhere in computer science: a set of nodes (here, one per item/vector) joined by edges (links to 'neighbour' items). It's stored as an adjacency list, meaning each node simply keeps a list of the other nodes it links to, which is memory-efficient when each node connects to only a handful of others. HNSW's twist is that it's a LAYERED graph: the same nodes exist on several stacked levels, sparse at the top and dense at the bottom, so one structure supports both long-range jumps and fine-grained local search. Compare that with a sorted array (binary search) or a hash table (hash search) - each search algorithm is really defined by the data structure underneath it, and a graph is what lets HNSW 'walk' toward an answer instead of indexing straight to it.
When would you choose FAISS or LSH over HNSW?
HNSW is memory-hungry because it stores all those links in RAM. With billions of vectors, FAISS with inverted-file indexing and product quantization compresses and clusters vectors to scale further on limited memory. LSH is simpler and cheaper but usually less accurate at the same speed. HNSW tends to win for millions-scale datasets where recall and latency both matter and RAM is available.