Commit 5f605ba
committed
fix(index): sort vector search top-k results when not truncating
`SearchResult::top_k` only sorted results by score on the truncation path
(candidates > k). When `k >= candidate count`, it returned rows in the
unordered scored-map / insertion order instead of by relevance. Because the
row order was previously discarded downstream (row-range scans re-read in
file order), this went unnoticed — but consumers that honor the row order
(e.g. the DataFusion `vector_search` scan) then get unranked results whenever
`limit >= number of matched rows`. This affects `vector_search`,
`full_text_search`, and `hybrid_search`.
Sort the no-truncation branch by relevance rank too, and update the unit
tests that asserted the old insertion-order behavior.1 parent 27dea79 commit 5f605ba
1 file changed
Lines changed: 12 additions & 11 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
218 | 218 | | |
219 | 219 | | |
220 | 220 | | |
221 | | - | |
222 | | - | |
223 | | - | |
224 | | - | |
225 | | - | |
226 | | - | |
| 221 | + | |
| 222 | + | |
| 223 | + | |
| 224 | + | |
227 | 225 | | |
228 | 226 | | |
229 | 227 | | |
| |||
382 | 380 | | |
383 | 381 | | |
384 | 382 | | |
385 | | - | |
| 383 | + | |
| 384 | + | |
| 385 | + | |
386 | 386 | | |
387 | 387 | | |
388 | 388 | | |
389 | | - | |
390 | | - | |
| 389 | + | |
| 390 | + | |
391 | 391 | | |
392 | 392 | | |
393 | 393 | | |
| |||
409 | 409 | | |
410 | 410 | | |
411 | 411 | | |
412 | | - | |
413 | | - | |
| 412 | + | |
| 413 | + | |
| 414 | + | |
414 | 415 | | |
415 | 416 | | |
416 | 417 | | |
| |||
0 commit comments