If it's an unqualified win, we should modify the VectorScorer to do
it, and then we wouldn't need to expose the quantized values. I do
think we would rather not expose the details of quantization since we
want to be free to innovate without back-compat considerations, and
generally don't want to e
Hi all,
I have a follow-up question on this. Would it make sense to expose the
quantized vector values as well? Currently even if we are quantizing the
vectors, calling vectorValue() will return the full precision vectors while
the quantized vectors are only used for scorer(). Do we consider the
q
Stored fields is a separate format that stores data in a row-wise
fashion: all the stored data for a single document is written
together. Vectors aren't *also* copied into stored fields storage, so
the stored fields API can't be used to retrieve them. If we did allow
that it would result in massiv
Thanks Adrien!
The code has one issue:
if (iterator.advance(leafDocID) == docID)
should have been:
if (iterator.advance(leafDocID) == leafDocID)
After fixing this, it works (for reference, I'm using Lucene 10.1). But I
still wonder why can't we retrieve vectors just as we retrieve any oth
Hi Viliam,
Your logic is mostly correct, here is a version that should be a bit
simpler and correct (but beware, untested):
IndexReader reader; // your multi-reader
int docID; // top-level doc ID
int readerID = ReaderUtil.subIndex(docID, reader.leaves());
LeafReaderContext leafContext = reader.le
Dear all,
when indexing vector fields, Lucene doesn't allow specifying the vector
field as stored (it throws `IllegalStateException: Cannot store value of
type class [F`). When trying to retrieve the value using
`IndexReader.storedFields()`, the vector field isn't stored.
However, Lucene 10 store
