[
https://issues.apache.org/jira/browse/LUCENE-10559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17541282#comment-17541282
]
Kaival Parikh commented on LUCENE-10559:
----------------------------------------
The graph construction parameters were:
docs = path_to_vec_file, ndoc = 1000000, dim = 100, fanout = 0, maxConn = 150,
beamWidthIndex = 300
All these were the same for search time, with additional:
search = path_to_query_file, niter = 1000, selectivity = (as required, 0.01 ~
0.8), prefilter (as required)
Also you were right about the search vectors, there was an overlap with the
training set. I created a fresh query file excluding trained vectors and re-ran
the utility:
||selectivity||effective topK||post-filter recall||post-filter time||pre-filter
recall||pre-filter time||
|0.8|125|0.965|1.57|0.976|1.61|
|0.6|166|0.959|2.07|0.981|2.00|
|0.4|250|0.962|2.71|0.986|2.65|
|0.2|500|0.958|4.80|0.992|4.51|
|0.1|1000|0.954|8.61|0.994|7.74|
|0.01|10000|0.971|58.78|1.000|9.44|
The recall and time seem to be in the same range as before. The high recall for
selective queries (selectivity = 0.01, prefilter, recall = 1.000) may be due to
performing an exact search when the nodes visited limit is reached
> Add preFilter/postFilter options to KnnGraphTester
> --------------------------------------------------
>
> Key: LUCENE-10559
> URL: https://issues.apache.org/jira/browse/LUCENE-10559
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Michael Sokolov
> Priority: Major
>
> We want to be able to test the efficacy of pre-filtering in KnnVectorQuery:
> if you (say) want the top K nearest neighbors subject to a constraint Q, are
> you better off over-selecting (say 2K) top hits and *then* filtering
> (post-filtering), or incorporating the filtering into the query
> (pre-filtering). How does it depend on the selectivity of the filter?
> I think we can get a reasonable testbed by generating a uniform random filter
> with some selectivity (that is consistent and repeatable). Possibly we'd also
> want to try filters that are correlated with index order, but it seems they'd
> be unlikely to be correlated with vector values in a way that the graph
> structure would notice, so random is a pretty good starting point for this.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
