-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support Elasticsearch Approximate Nearest Neighbors #5557
Comments
Hello, @AndreasR90! Related: #2810 @bogdankostic do you have any insights to share on this point? |
I haven't tried approximate knn with Elasticsearch 8 yet, but I agree with @AndreasR90 that we should allow to set the I had a quick look at the Elasticsearch documentation and it seems that Elasticsearch is creating always an index of type HNSW, so indexing time wouldn't even increase for users deciding to use aproximate knn instead of exact knn with Elasticsearch 8. To perform an approximate knn search, we would just need to set the |
I had a closer look into this yesterday and have a first implementation of this feature. I can create a draft PR this afternoon. What do you think @bogdankostic ? |
@AndreasR90 Yes, creating a draft PR would be awesome. ⭐ |
Hi @bogdankostic, |
Closing as won't fix, Haystack 2.x supports HNSW. |
Elasticsearch>8.0 has an implementation for an aNN (approximate Nearest Neighbor) Algorithm based on HSNW. The corresponding blogpost https://www.elastic.co/blog/introducing-approximate-nearest-neighbor-search-in-elasticsearch-8-0 indicates that this gives a significant speedup for the query times in comparison to the currently used the exact kNN match. The obvious downside is, that not all actual nearest neighbors are found. In my opinion the decision which algorithm to use should be given to the user of haystack.
It would be ideal to have an additional argument for the ElasticsearchDocumentstore (>=8) where the user can choose which query is used.
The text was updated successfully, but these errors were encountered: