should we develop a new DB for LLM dev? i) context: Recently im building a simple training data extraction platform. Goal of this platform is using smarter gpt4 to obtain high quality samples and then store them. Later, we plan to use these data to train various local LLMs. End goal is potential user will offer similar input and our LLM can deliver good results. A very typical ML system. ii) initial thoughts of how things gonna work: Training data extraction flow: Raw text data (nature language) + system prompts of protobuf messages + tell gpt4 returns json (api supported this) --> gpt4 --> structured training data (json) Local llm training flow: structured training data (json) + Raw text data (nl) --> local llm User inference flow: User input (nature language) --> convert into protobuf messages (json) --> local llm -> output (nl) iii) impl: Like many typical systems involving with data and data sharing between several micro services, i first defined some data schemas (grpc in this case). i defined like a doze of messages with strong typed fields to represent the training data (i.e. the things i wanna gpt4 extracted). and ofc bunch of auto generated python codes. then coding coding coding,,built v0 with nextjs, mongodb, python grpc. iv) issues: Training data extraction flow output is not idea as my protobuf message structures are nested and complex. gpt4 is hell smart but I found it's struggling on this. spent quite some time adjusting both prompts and schemas and results were still not good. Suddenly, a question stroke me: if end user will also type in nature language, do I even need to schema my training data with strong types? Like, what if i represent each training data as a bunch of text/string fields. it's an exciting and scary thought, especially you were used to deal with data with strong types: floats, ints for decade. Storing everything as plain text made me and my system feel vulnerable. so i tried. Message A_old { float xxx; MessageB yyy; .... } Message A_all_nl { string info_of_field_1; string info_of_field_2; ...... } then, i tried. gpt4 works like a magician, again. so smooth i thought it's beyonce's wigs v) thoughts on LLM-specific DB engine: mongodb and any other db can hand the new messages perfectly: we just use string/varchar for all fields. case closed. but, let's say, what if someone (who?) develop a new orm/db-engine just for LLM related development? What functions I personally want to have? - 1) There are only two concepts in write path: object (collection name/db name/table name, whatever you call it) and object's info (a varchar field, a lot of chars) - 2) And for read path, when i give it a strong type schema, it returns schema-compatible data that's it. that's a LLM db i wish exist in 2024. 1) makes interacting with llm effortless; 2) enabled devs to leverage existing analysis tools/framework which are all strong type bounded; and we still need display those data somewhere and we better have strong typed data transfering around for many good purposes If there's a db there can just do above two things, LLM dev efficiency will skyrocket and im def gonna use it. p.s. i prefer it's still named after a fruit. fruits sound friendly.