Stop Scanning, Start Navigating: Why Graph-Based Indexing is Important for Information Retrieval
Vector search is a navigation problem, not a calculation problem.
What is HSNW (Hierarchical Navigable Small World)?
It is a type of graph-based indexing algorithm which builds multi-layer graph that balances speed and search quality even at large sizes. It combines two worlds:
2. Navigable Small Worlds ( for graph connectivity) : Creating Bidirectional Layers for enabling neighbourhood based searches.
Note: The search within the layers is purely graph based, ensuring any point can reach any other point within very few hops (Small World Concept in graph Theory).
The current bottleneck we face in Information Retrieval:
Let's take an analogy to understand the problem
Imagine trying to find the best coffee shop in a massive city.
The most naive way would be to walk every single street, check every cafe, and then decide which one is best (Flat Search/KNN). It would give you the perfect answer, but it would take forever and is completely impractical.
Note: And to keep in mind there's always a tradeoff between performance(with respect to latency) and accuracy.
How HSNW helps in this scenario?
You don’t start by checking every street. Instead, you first look at a city-level map to get into the right neighbourhood. Then you switch to local roads, and finally walk block by block to find the exact spot.
Recommended by LinkedIn
How HSNW works?
In HNSW, data isn't just one flat list; it’s a multi-storey skyscraper of graphs.
2. Greedy Search (The "Next Cafe" Logic):
HNSW doesn't explore the whole city at once; it acts like a coffee lover who only cares about the next best cafe spot.
3. Six Degrees of Separation (The "Highway" Secret)
Why is this faster than checking a list? Because of Shortcuts.
Constructive Outlook:
Can we use Graph Database to utilise the HNSW Concept (Available in most of the Vector Databases)?
While HSNW is a ANN search method it helps to store the Vector Indexes effectively and not represent semantics, i.e. how we find nearest vectors as with a balanced approach between latency and accuracy.
Whereas, Graph Databases helps in capturing the semantical meaning between it's relationships and nodes, i.e. how are X and Y connected?
Recently, graph databases have begun providing vector indexes as an add-on. While these indexes return the top-K nodes for a graph engine to traverse, this approach introduces significant overhead between the two layers. This becomes a critical bottleneck when scaling to billions of nodes and relationships where low latency is crucial.
Additional Reads:
Treating vector search as a first-class graph operator, not a handoff, is the real unlock here. The edge case I’d watch is update pressure. If embeddings and relationships change often, HNSW maintenance and consistency semantics can become the bottleneck. How are you thinking about online index updates and read consistency when vectors live as native properties on nodes and relationships?
The "context-switching latency" framing is interesting but how much are we actually talking about - single digit milliseconds or something worse? At billion scale the bottleneck might be elsewhere entirely.
checkout TuringDB as well.. similar approach there.. coupled with faiss...
This reminds me of cartesian tiers but for graph indices.
YAOUTCHI! That's Huge! Because i was thinking about the switch between #Neao4J and #FalkorDB for the exact same raison.. And Falkor is using matrices natively right?