A state vector can represent a point in the state space of floating-point representation, a point in the state space of a hash function, or any other discrete space. Vectors didn't go anywhere. The article is discussing which function to use to interpret a vector. Is there a special meaning of 'vector' here that I am missing? Is it so synonymous in the ML context with 'multidimensional floating point state space desc…
Vectors are over, hashes are the future
31–40 of 43 posts
Re: Vectors are over, hashes are the future
#32This is a rehash (pardon me) of this post from 2021: https://www.search.io/blog/vectors-versus-hashes The demand for vector embedding models (like those released by OpenAI, Cohere, HuggingFace, etc) and vector databases (like https://pinecone.io -- disclosure: I work there) has only grown since then. The market has decided that vectors are not, in fact, over.
PineCone seems interesting. Is the storage backend open source? I've been working on a persistent hashmap database that's somewhat similar (albeit not done) that should have less RAM requirements than bitcask (ie. larger than RAM keysets)
Re: Vectors are over, hashes are the future
#33Hashes are fine, but to say that "vectors are over" is just plain nonsense. We continue to see vectors as a core part of production systems for entity representation and recommendation (example: https://slack.engineering/recommend-api ) and within models themselves (example: multimodal and diffusion models). For folks into metrics, we're building a vector database specifically for storing, indexing, and searching acr…
Re: Vectors are over, hashes are the future
#34> The analogy here would be the choice between a 1 second flight to somewhere random in the suburb of your choosing in any city in the world versus a 10 hour trip putting you at the exact house you wanted in the city of your choice. Wouldn't the first part of the analogy actually be: A 1 second flight that will probably land at your exact destination, but could potentially land you anywhere on earth?
Re: Vectors are over, hashes are the future
#35A state vector can represent a point in the state space of floating-point representation, a point in the state space of a hash function, or any other discrete space. Vectors didn't go anywhere. The article is discussing which function to use to interpret a vector. Is there a special meaning of 'vector' here that I am missing? Is it so synonymous in the ML context with 'multidimensional floating point state space desc…
Keep in mind that this is the same field which uses multidimensional arrays that fail to obey tensor transformation laws (because ML requires the kind of nonlinear structure introduced by functions such as ReLU that requires a preferred basis and cannot be transformed between bases) but insists on calling them tensors.
Re: Vectors are over, hashes are the future
#36Are they re-inventing autoencoders?
Re: Vectors are over, hashes are the future
#37Re: Vectors are over, hashes are the future
#38Re: Vectors are over, hashes are the future
#39> The analogy here would be the choice between a 1 second flight to somewhere random in the suburb of your choosing in any city in the world versus a 10 hour trip putting you at the exact house you wanted in the city of your choice. Wouldn't the first part of the analogy actually be: A 1 second flight that will probably land at your exact destination, but could potentially land you anywhere on earth?
To be fair, that sounds like an extraordinarily fun prospect.
Re: Vectors are over, hashes are the future
#40This is a rehash (pardon me) of this post from 2021: https://www.search.io/blog/vectors-versus-hashes The demand for vector embedding models (like those released by OpenAI, Cohere, HuggingFace, etc) and vector databases (like https://pinecone.io -- disclosure: I work there) has only grown since then. The market has decided that vectors are not, in fact, over.
PineCone seems interesting. Is the storage backend open source? I've been working on a persistent hashmap database that's somewhat similar (albeit not done) that should have less RAM requirements than bitcask (ie. larger than RAM keysets)