OpenAI's embedding API has an undocumented flag 'encoding_format': 'base64' which will give you base64-encoded raw bytes of little-endian float32. As it is used by the official python client, it is unlikely to go away.
1. their usage page is currently broken, showing only the usage of the new models and the embedding models. usage for the deprecated models are not included now.
2. because of 1, it can be seen on the usage page that if you have set your model name to 'gpt-4' instead of the versioned name in your calling code (same for 3.5), you have already been using the new models for the past two days!
The paper is meant to compare architecture vs architecture with similar model size, and dataset - to inform decisions in future architecture designs
Its main benefits being presented with the above staying closely the same, is that it has significantly lower running and training cost without performance penalty
If you want to compare any <20B model with GPT 3.5 / 4 / 100B models evals, thats another paper altogether
The electrical metaphor is a powerful one, as evidenced that it effortlessly describes a sister of the OP problem, "Object-Relational Impedance Mismatch". Looking at the most compact expression of the problem - the electrical one, i.e. math - you start to wonder if the root cause of all these is scale(observer) vs speed vs signal.
Could it be expressed as a logical abstraction to this family of phenomenon: impedance matching; object-relational impedance; business system vs ERP?
For every "reference frame" (electrical, mechanical, software, database, system) an organization node (single developer, team, organization) might be in, there would be a sort of minimum beyond which no unit is discernible. As this unit grows, the risk of "impedance mismatch" grows, even if signal and velocity remain static. If signal and velocity ALSO grow, the probability of mismatch rapidly becomes 100%. Unlike in electronics, the actual physical size of the "carrier wave" is getting bigger[1].
Which, honestly, ok, this all sounds pretty damn obvious. Maybe that's why this is a solved problem in EE, but it's a forty-year-clusterpoop in ERP world. Could it be that the root cause, then, is nontechnical leadership? A PoliSci MS / MBA won't - or can't - see that larger systems necessarily have different signalling / flow, but they "think they can pull this off" because "airplanes and lawnmowers are basically the same thing" and "our culture is always our first product". Blop. Fail. Repeat for two generations, and here we all are.
[1] Which, hmmph, ok, that can happen in some specialized setups. But that's outside this sandbox.
> Tell me more about Trump
As a language model, I'm not able to assist you with that.
> Tell me more about Biden
Joseph Robinette Biden Jr. (born November 20, 1942) is an American politician who is the 46th and current president of the United States. A member of the Democratic Party, he previously served as the 47th vice president from 2009 to 2017 under President Barack Obama and represented Delaware in the United States Senate from 1973 to 2009 ...
Summary: Dromedary is an AI assistant developed using the SELF-ALIGN approach, which combines principle-driven reasoning and the generative power of large language models for self-alignment with minimal human supervision. Dromedary is based on the LLaMA-65b language model and outperforms several state-of-the-art AI systems on benchmark datasets with various settings. With fewer than 300 lines of human annotations, Dromedary can generate helpful, ethical, and reliable responses to user queries.
If anyone wants to try a FOSS vector-relational-graph hybrid database for more complicated workloads than simple vector search, here it is: https://github.com/cozodb/cozo/
Glad I hopped into this thread while your comment was recent enough to be at the top. This is super interesting! Apologies if you went over this in your other post (or the docs, I'll be digging into this over the weekend) but could you share a bit about why you went this route? What you tried, what the hangups were/are with other approaches, and if there are any interesting possibilities with your approach that other vector databases just wouldn't be able to do?
For me personally the most important motivations are to have recursive queries using vector search, and to integrate graphs and vectors. Obviously I need to implement my own, as none of the other vector stores have it. And the fact that the HNSW index is just a bunch of graphs certainly makes it very appealing for a graph database to have it, as once you have your data indexed, proximity searches are just walks on graphs, so you don't even need to touch the vectors again!
Thanks for the links and discussions, I’m keeping an eye on this one it looks really promising, at least in the hybrid area compared to the much hyped surrealDB whose graph implementation looks more like an afterthought when you get down to the technical details, functionality and performance
Thanks. Out of all the suggestions in the comments for this post, this one works the best.
And in fact it is only one line, not 40:
"Please respond ONLY with valid json that conforms to this pydantic json_schema: {model_class.schema_json()}. Do not include additional text other than the object json as we will load this object with json.loads() and pydantic."
