benwtrent commented on issue #14007:
URL: https://github.com/apache/lucene/issues/14007#issuecomment-2493691474
> I think we still need for indexing and merging as vigyasharma@ comment.
I don't know if its strictly necessary to keep the raw vectors for merging.
Once a certain limit is reached, especially for vectors that play well with
quantization, you can likely throw the vectors away even on the indexing side.
It would just require work, and I wouldn't want it to be the default behavior.
I will answer the wall of questions from @Rassyan. But, most of these would
be discoverable through exploring the quantization methodology for yourself.
> Could you elaborate on the computational costs associated with this?
Its just the inverse of the quantization method. For every vector, you
iterate its components inverting the quantization step.
> So, would int7 be considered a higher fidelity quantization method?
I would think so, unless you had a different one in mind?
> Based on your experience and insights, how would you rate the fidelity of
int7, int4, and binary quantization methods?
For pure score correlations, what we have seen:
- int7 ~ 95-99%% score correlations
- int4 ~ 85-90% score correlations
- bit ~ 70-80+ score correlations
There are vectors that are aggressively AGAINST quantization (e.g. GIST &
Glove) and perform way worse than all other vectors. But modern transformer
architectures perform way better.
> Where do they stand in terms of maintaining accuracy while optimizing
storage efficiency?
Just do the math ;)
> Has the Lucene community already planned or discussed the implementation
of a dedicated KnnVectorsFormat for handling only quantized vectors?
There has been discussions around having the floating point removed for
"search segments" but keeping them for "index segments"
> Are there quick support mechanisms for users who are willing to
compromise on accuracy for significant savings in disk space and do not require
the original vectors?
I don't even know what this means.
--
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
