Repository navigation
Conversation
…codec Signed-off-by: Pranshu-S <pranshushukla06@gmail.com>
kaivalnp
left a comment
There was a problem hiding this comment.
Thanks @Pranshu-S, this looks great at first glance -- but I'll try to take a deeper look soon!
Curious if you were able to run luceneutil KNN benchmarks for FLOAT16 vectors to test this?
Signed-off-by: Pranshu-S <pranshushukla06@gmail.com>
Signed-off-by: Pranshu-S <pranshushukla06@gmail.com>
85dc225 to
aa5cdcd
Compare
Signed-off-by: Pranshu-S <pranshushukla06@gmail.com>
Signed-off-by: Pranshu-S <pranshushukla06@gmail.com>
|
Sharing the benchmark runs - baseline here is only raw float16 and candidate here is quantized float16 ndoc: 10000, nquery1000 ndoc100000, nquery10000 |
|
Thanks for the benchmarks @Pranshu-S! Could you run them with Could you also change the baseline to scalar quantized FP16 vectors using the "vanilla" (non-dedup) format? Looking to confirm whether recall is comparable b/w the two (which I think it will be, based on the above benchmark). Might be worth checking all quantization levels too (8, 4, 2, 1-bit), for exercising the symmetric / asymmetric path as well. |
|
Sure @kaivalnp, i can run these suites. On the |
Using |
|
I see, so with Looks to be pretty much within the expectations - |
kaivalnp
left a comment
There was a problem hiding this comment.
Looking great, thanks @Pranshu-S!
Can you add a CHANGES.txt entry + update package-info.java too?
Can you also share benchmarks for higher levels of quantization with FLOAT16?
Signed-off-by: Pranshu-S <pranshushukla06@gmail.com>
b9b1348 to
8e19801
Compare
|
Runs against different quantisation levels: |
Signed-off-by: Pranshu-S <pranshushukla06@gmail.com>
|
Hi @kaivalnp, do let me know if any more changes are required in this PR. Thanks! |
kaivalnp
left a comment
There was a problem hiding this comment.
Thanks @Pranshu-S, this PR is looking great!
Left some minor nits + code cleanup comments, LGTM overall.
Signed-off-by: Pranshu-S <pranshushukla06@gmail.com>
Signed-off-by: Pranshu-S <pranshushukla06@gmail.com>
Signed-off-by: Pranshu-S <pranshushukla06@gmail.com>
|
Looks like all recent PRs are failing due to CodeQL, will merge once the fix for it lands in main branch |
Signed-off-by: Pranshu-S <pranshushukla06@gmail.com>
Signed-off-by: Pranshu-S <pranshushukla06@gmail.com>
kaivalnp
left a comment
There was a problem hiding this comment.
LGTM, thanks @Pranshu-S !
Description
Addresses one of improvements tracked in #16595
The sandbox dedup KNN codec stores each distinct vector once and lets every document referencing it point to that single shared copy. Its scalar-quantized variant (DedupScalarQuantizedVectorsFormat) additionally stores a data-blind scalar-quantized copy of each distinct vector, so scoring runs on the compact quantized form while the raw vectors remain for full-fidelity readback and rescoring.
Previously, only FLOAT32 vectors were quantized — FLOAT16 (and BYTE) were stored raw only. This PR adds scalar-quantization support for FLOAT16 vectors, bringing them to parity with FLOAT32.
How
The data-blind scalar quantizer (OptimizedScalarQuantizer) computes centroids and corrective terms in fp32, and the JVM has no fp16 arithmetic type — so it currently has no way to quantize fp16 values natively. As a result, FLOAT16 vectors are inflated short[] → float[] before quantization. This inflation is lossless (every fp16 value is exactly representable in fp32), so an fp16 vector produces the same quantized record its fp32 equivalent would. This mirrors the core Lucene104ScalarQuantizedVectorsWriter.
Quantizing fp16 directly (without inflating) is a follow-up that first requires the data-blind OptimizedScalarQuantizer itself to support fp16 arithmetic; once that lands, this codec can drop the inflation step. That
prerequisite is tracked by #16533