349 karma · joined April 27, 2012
Hit me up on x.com/svonava
Basically think mixture of experts, but each expert is an encoder with it's own input tokenization/feature engineering part and then there is some machinery to parametrize these encoders based on natural language queries and stitch their outputs together to form unified vectors for objects in the index and the queries coming in.
Given that the whole framework is Apache 2.0, you can also check https://github.com/superlinked/superlinked and the docs: https://docs.superlinked.com/ https://docs.superlinked.com/concepts/overview
We have some proprietary tech besides that - mainly embedding models for things like location and then executors for the Superlinked DAG that help you run it on GPU-accelerated Spark and something analogous to that for streaming workloads - those proprietary things are how we make money, we call it Superlinked Cloud.
Also, the company is doing fine, not sure where that last sentence came from ^_^
As you say, AstraDB also offers vector search (you can see it at https://superlinked.com/vector-db-comparison) but we haven't built the integration with them yet. We focus on fewer but higher quality integrations in general. Do you like AstraDB? Any advantages vs competition that you care about?
In terms of the plan you mentioned Astra+Redis - you don't have to do that, you can just use redis for both key-value store and vector search.
Your life reflects this capacity as much as the environment that let it manifest itself:)
We should hang out :-)
With a set of random strings, for alphabet with 64 chars, there are 16M different 4 character prefixes, so the savings from overlapping prefixes for 128char long strings is likely less than 3%.
- storing this at byte per char = 12.8MB
- storing this in a basic trie = 12.8 * 64 = 820MB
- storing this in the TST = 12.8 * 3 = 38MB
1) Keep an array of size equal to the alphabet size, indexed by the characters, holding pointers to successive nodes.
- but this blows the memory to O(N * alphabet_size) where N is the input size
2) Keep a linked list of pairs (character, pointer).
- but this blows the lookup time to O(word_length * alphabet_size)
3) Keep something like an STL map<character, pointer>.
- still suboptimal complexity of O(word_length * log alphabet_size) + it complicates the code + it dramatically increases the constant time per operation
Or you research a bit more and actually learn a way to properly implement a trie, called a Ternary Search Tree: http://en.wikipedia.org/wiki/Ternary_search_tree