The Theoretical Limitations of Embedding-Based Retrieval
1–10 of 42 posts
Re: The Theoretical Limitations of Embedding-Based Retrieval
#2Sparse 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?
Re: The Theoretical Limitations of Embedding-Based Retrieval
#3Re: The Theoretical Limitations of Embedding-Based Retrieval
#4Their 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?
Re: The Theoretical Limitations of Embedding-Based Retrieval
#5Their 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?
euclidean embedding
hyperbolic embedding
sparse BM25 / SPLADE lexical search
optional multi-vector signatures
↓ merge & deduplicate candidates
followed by weight scoring, expansion (graph) & rerank (LLM)?Re: The Theoretical Limitations of Embedding-Based Retrieval
#6we used multi-vector models at Morphik, and I can confirm the real-world effectiveness, especially when compared with dense-vector retrieval.
Re: The Theoretical Limitations of Embedding-Based Retrieval
#7Their 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?
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.
Re: The Theoretical Limitations of Embedding-Based Retrieval
#8Earlier quoted context omitted.
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.
Matryoshka embeddings are not sparse. And SPLADE can scale to tens or hundreds of thousands of dimensions.
Re: The Theoretical Limitations of Embedding-Based Retrieval
#9In fact, I think we can do it in d=2k dimensions, if we're willing to have arbitrarily precise query vectors.
Embed our points as (sin(theta), cos(theta), sin(2 x theta), cos(2 x theta)..., sin(k x theta), cos(k x theta)), with theta uniformly spaced around the circle, and we should be able to select any k of them.
Using a few more dimensions we can then ease the precision requirements on the query.
Re: The Theoretical Limitations of Embedding-Based Retrieval
#10Their 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?
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.