benwtrent commented on PR #14085:
URL: https://github.com/apache/lucene/pull/14085#issuecomment-2595943039
@benchaplin I updated my branch further and simplified the logic:
- we consider at max 2x scored candidates
- We will explore at max 3x filtered candidates
This seemed to be a sweat spot and simplified the math (which had numerous
numerical errors).
I think its getting close to being "done", there are some failing tests, but
I think they can be easily fixed.
One thing I am worried about is that this change will pretty substantially
change recall at various filter levels. Filtered kNN search is likely the most
common kNN search there is. So, we should some how allow users to keep the old
behavior and opt in as this might be considered a breaking change due to the
significant change in behavior. Maybe its not a breaking change, maybe its just
ok 🤷
Here are some other augmentations to the current change I tried. Neither
seems justified IMO.
A. Adding just the first `maxConn` filtered docs to the result set & entry
point list on the bottom layer. This didn't seem to do anything useful and hurt
the recall/latency & vector ops measurements
B. Adding additional 'nearest entry points' from layer 1. So, gather the
nearest and then gather `N` more (up to some limit related to maxConn) and use
those when exploring the base layer. This seemed to have better behavior for
highly filtered scenarios than option A. But, it still didn't add much. So, I
opted for simplicity.
--
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
