
Type: New Feature

Status: Open

Priority: Major

Resolution: Unresolved

Affects Version/s: None

Fix Version/s: None

Component/s: None

Labels:None

Lucene Fields:New
"Semantic" search based on machinelearned vector "embeddings" representing terms, queries and documents is becoming a musthave feature for a modern search engine. SOLR12890 is exploring various approaches to this, including providing vectorbased scoring functions. This is a spinoff issue from that.
The idea here is to explore approximate nearestneighbor search. Researchers have found an approach based on navigating a graph that partially encodes the nearest neighbor relation at multiple scales can provide accuracy > 95% (as compared to exact nearest neighbor calculations) at a reasonable cost. This issue will explore implementing HNSW (hierarchical navigable smallworld) graphs for the purpose of approximate nearest vector search (often referred to as KNN or knearestneighbor search).
At a high level the way this algorithm works is this. First assume you have a graph that has a partial encoding of the nearest neighbor relation, with some short and some longdistance links. If this graph is built in the right way (has the hierarchical navigable small world property), then you can efficiently traverse it to find nearest neighbors (approximately) in log N time where N is the number of nodes in the graph. I believe this idea was pioneered in [1]. The great insight in that paper is that if you use the graph search algorithm to find the K nearest neighbors of a new document while indexing, and then link those neighbors (undirectedly, ie both ways) to the new document, then the graph that emerges will have the desired properties.
The implementation I propose for Lucene is as follows. We need two new data structures to encode the vectors and the graph. We can encode vectors using a light wrapper around BinaryDocValues (we also want to encode the vector dimension and have efficient conversion from bytes to floats). For the graph we can use SortedNumericDocValues where the values we encode are the docids of the related documents. Encoding the interdocument relations using docids directly will make it relatively fast to traverse the graph since we won't need to lookup through an idfield indirection. This choice limits us to building a graphpersegment since it would be impractical to maintain a global graph for the whole index in the face of segment merges. However graphpersegment is a very natural at search time  we can traverse each segments' graph independently and merge results as we do today for termbased search.
At index time, however, merging graphs is somewhat challenging. While indexing we build a graph incrementally, performing searches to construct links among neighbors. When merging segments we must construct a new graph containing elements of all the merged segments. Ideally we would somehow preserve the work done when building the initial graphs, but at least as a start I'd propose we construct a new graph from scratch when merging. The process is going to be limited, at least initially, to graphs that can fit in RAM since we require random access to the entire graph while constructing it: In order to add links bidirectionally we must continually update existing documents.
I think we want to express this API to users as a single joint KnnGraphField abstraction that joins together the vectors and the graph as a single joint field type. Mostly it just looks like a vectorvalued field, but has this graph attached to it.
I'll push a branch with my POC and would love to hear comments. It has many nocommits, basic design is not really set, there is no Query implementation and no integration iwth IndexSearcher, but it does work by some measure using a standalone test class. I've tested with uniform random vectors and on my laptop indexed 10K documents in around 10 seconds and searched them at 95% recall (compared with exact nearestneighbor baseline) at around 250 QPS. I haven't made any attempt to use multithreaded search for this, but it is amenable to persegment concurrency.
UPDATES:
 (1/12/2020) The uptodate branch is: https://github.com/apache/lucenesolr/tree/jira/lucene9004aknn2
 links to