Yes, FYI, we found the bug in the kNN query https://github.com/apache/lucene/issues/14180
Basically, threads sharing information back for graph early termination can lead to inconsistency. We should fix this in Lucene. Though I do not know the timeline or the simplicity. Thank you Dr. Andreas Moll for bringing this to our attention! On Thu, Jan 30, 2025 at 1:26 PM Varun Thacker <va...@vthacker.in> wrote: > Benjamin - I think this has to do with Solr 9.7+ using thread executor's > for searching. > > I can take Solr 9.7 or Solr 9.8 and just undo this one line in > SolrIndexSearcher > <https://github.com/apache/solr/blob/7af2ad56753bf75b8391639233dcc8d465767de9/solr/core/src/java/org/apache/solr/search/SolrIndexSearcher.java#L385> > and > the query doesn't fail > > - super(wrapReader(core, r), > core.getCoreContainer().getIndexSearcherExecutor()); > + super(wrapReader(core, r)); > > On Thu, Jan 23, 2025 at 6:49 AM Benjamin Trent <ben.w.tr...@gmail.com> > wrote: > >> From the vector search side of things, nothing immediately pops up as a >> cause. https://lucene.apache.org/core/9_11_0/changes/Changes.html >> >> The given query is just a regular kNN query. So, its rewrite should >> behave similarly as it did in 9.10. >> >> One significant change for kNN search behavior did happen in 9.10: >> https://github.com/apache/lucene/pull/12962 But since this issue doesn't >> happen in 9.10, I am at a loss. >> >> Since `knn` rewrites itself to `KnnScoreDoc` object, It's surprising that >> the result set should change between collecting and scoring. >> >> I wonder if Solr adjusted due to this deprecation or started using >> collector managers and inadvertently tripped over a bug or something? >> >> Or, something was added in Apache Lucene 9.11 where the same knn query >> over the same index could result in a different set of top-k docs. Though, >> I would have thought the main candidate there would be: >> https://github.com/apache/lucene/pull/12962 (in lucene 9.10). >> >> On Thu, Jan 23, 2025 at 3:46 AM Moll, Dr. Andreas <m...@juris.de.invalid> >> wrote: >> >>> Hi, >>> >>> I want to inform you about a behavior change in SolR 9.6 (Lucene 9.10) >>> vs. SolR 9.7 (Lucene 9.11) for vector searches. >>> >>> We heavily rely on vector searches for embeddings in combination with >>> filter queries on the parent documents. >>> >>> Our queries in general looked like this: >>> >>> select?q={ knn f=vector topK=2048}[...] >>> >>> rows=100 >>> >>> fq={ child of='childtype:root'}… >>> start=0 >>> >>> sort=score desc,ID desc >>> >>> With SolR 9.7 and higher, this results in ~10% of the queries producing >>> the following error: >>> >>> java.lang.IllegalArgumentException: Doc id 27227879 doesn't match the >>> query >>> >>> at >>> org.apache.lucene.search.TopFieldCollector.populateScores(TopFieldCollector.java:478) >>> ~[?:?] >>> >>> at >>> org.apache.solr.search.SolrIndexSearcher.populateScoresIfNeeded(SolrIndexSearcher.java:1812) >>> ~[?:?] >>> >>> at >>> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:2001) >>> ~[?:?] >>> >>> at >>> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1775) >>> ~[?:?] >>> >>> at >>> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:772) >>> ~[?:?] >>> >>> at >>> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:767) >>> ~[?:?] >>> >>> After several days of debugging, I confirmed that the number of errors >>> correlates to the topK value: >>> >>> - k = 8 -> 44 errors >>> - k = 2048 -> 17 errors >>> - k = 16384 -> 1 error >>> >>> I found a workaround for the issue by modifying the sort parameter to: >>> >>> sort=score desc >>> >>> With this change, our queries work like a charm again. The initial >>> thought of adding the ID desc sorting was to get more reproducible >>> results, but it is not strictly necessary for us. >>> >>> Could you clarify if this change in SolR/Lucene was intended? If so, >>> perhaps you want to add documentation on vector queries that adding an >>> additional sorting might cause errors. >>> >>> Best regards, >>> Dr. Andreas Moll >>> >>> >>> >>