Most active commenters
  • CuriouslyC(4)

←back to thread

147 points fzliu | 11 comments | | HN request time: 0.523s | source | bottom
Show context
gdiamos ◴[] No.45069705[source]
Their idea is that capacity of even 4096-wide vectors limits their performance.

Sparse models like BM25 have a huge dimension and thus don’t suffer from this limit, but they don’t capture semantics and can’t follow instructions.

It seems like the holy grail is a sparse semantic model. I wonder how splade would do?

replies(3): >>45070552 #>>45070624 #>>45088848 #
1. CuriouslyC ◴[] No.45070552[source]
We already have "sparse" embeddings. Google's Matryoshka embedding schema can scale embeddings from ~150 dimensions to >3k, and it's the same embedding with layers of representational meaning. Imagine decomposing an embedding along principle components, then streaming the embedding vectors in order of their eigenvalue, kind of the idea.
replies(3): >>45070777 #>>45071166 #>>45075319 #
2. jxmorris12 ◴[] No.45070777[source]
Matryoshka embeddings are not sparse. And SPLADE can scale to tens or hundreds of thousands of dimensions.
replies(2): >>45070869 #>>45088885 #
3. CuriouslyC ◴[] No.45070869[source]
If you consider the actual latent space the full higher dimensional representation, and you take the first principle component, the other vectors are zero. Pretty sparse. No it's not a linked list sparse matrix. Don't be a pedant.
replies(2): >>45072427 #>>45072485 #
4. 3abiton ◴[] No.45071166[source]
Doesn't PCA compress the embeddings in this case, ie reduce the accuracy? It's similar to quantization.
replies(1): >>45071547 #
5. CuriouslyC ◴[] No.45071547[source]
Component analysis doesn't fundamentally reduce information, it just rotates it into a more informative basis. People usually drop vectors using the eigenvalues to do dimensionality reduction, but you don't have to do that.
6. zwaps ◴[] No.45072427{3}[source]
No one means Matryoshka embeddings when they talk about sparse embeddings. This is not pedantic.
replies(2): >>45072445 #>>45074730 #
7. CuriouslyC ◴[] No.45072445{4}[source]
No one means wolves when they talk about dogs, obviously wolves and dogs are TOTALLY different things.
8. yorwba ◴[] No.45072485{3}[source]
When you truncate Matryoshka embeddings, you get the storage benefits of low-dimensional vectors with the limited expressiveness of low-dimensional vectors. Usually, what people look for in sparse vectors is to combine the storage benefits of low-dimensional vectors with the expressiveness of high-dimensional vectors. For that, you need the non-zero dimensions to be different for different vectors.
9. cap11235 ◴[] No.45074730{4}[source]
Why?
10. miven ◴[] No.45075319[source]
Correct me if I'm misinterpreting something in your argument but as I see it Matryoshka embeddings just sort the vector bases of the output space roughly by order of their importance for the task, PCA-style, so when you truncate your 4096-dimensionnal embedding down to a set of let's say 256 dimensions, those are the exact same 256 vector bases doing the core job of encoding important information for each sample, so you're back to dense retrieval on 256-dimensional vectors, just that all the minor miscellaneous slack useful for a very low fraction of queries has been trimmed away.

True sparsity would imply keeping different important vector bases for different documents, but MRL doesn't magically shuffle vector bases around depending on what's your document contains, were that the case cosine similarity between the resulting documents embeddings would simply make no sense as a similarity measure.

11. faxipay349 ◴[] No.45088885[source]
Yeah, the standard SPLADE model trained from BERT typically already has a vocabulary/vector size of 30,552. If the SPLADE model is based on a multilingual version of BERT, such as mBERT or XLM-R, the vocabulary size could inherently expand to approximately 100,000, as does the vector size.