shatejas commented on PR #13407: URL: https://github.com/apache/lucene/pull/13407#issuecomment-2159001847
> Now the user interface itself when querying assumes "HNSW-esque" things. I am wondering why this wasn't raised in [#12551](https://github.com/apache/lucene/pull/12551) > There has been talk of adding a "flat" codec to Lucene, that simply takes advantage of quantization and stores the vectors not in the HNSW graph. In that instance, what would efSearch mean? Apologies if my question sounds naive as I don't have context on "flat" codec, I am curious how will the user be able to choose that codec vs the current one which uses HNSW? Or will the user not have that option?. Are we planning to have a separate `Query` similar to `KNN{Byte:Float}VectorQuery`? In that case does it make sense to constraint the efsearch parameter to implementation of the query? Overall it seems like the implementation (Abstract class) is trying to prioritize making it generic over using params specific to algorithms. Doesn't this make the implementation rigid? There isn't a way to pass in additional parameters even if other algorithms are later used. For `efSearch` it might be easy enough to have users to have additional logic, assuming it will be for other implementations seems a bit optimistic. Shouldn't there be the flexibility for users to pass in parameters if the users want to while lucene providing defaults? @benwtrent -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
