https://github.com/Flow-Research/local-first-AI/pull/3
This week I was doing the Capture / Create Context portion of the Local Context Store. My job was to create_context_item which was a function that accepts context data that is useful, validates it and stores it in a local SQLite database. The aim was simple; to build an AI assistant that can read, search, update and reason with memory, it had to be able to reliably store that memory.
A local-first AI is not a generic text saved somewhere, as it is in the context of a traditional AI.Unlike traditional AI, in a local-first AI, the context is not just random text stored somewhere. Information that could be useful for the assistant to learn about a user, project, device event, learning record, configuration decision or a future conversation. As this information is not stored in any structured way, the memory system can easily become cluttered. From then on, the AI can get the wrong thing, misinterpret old memories or consider weak memories as reliable memories. That is, if we save all of the information in a non-structured way, AI memory is no longer brain-like, but it is more like the Downloads folder.
I used create_context_item for this task, which are the fields context_type, title, content, source, tags and importance. The function can only be passed valid context types like user_note, project_note, device_log, learning_record, config_decision or conversation_context. This is important because, different types of memory need to be treated differently. The distinction between a device log and a project note, as well as between a configuration decision and a conversation context, is that they are distinct. Assigning each item a definite class makes it easier to predict where it can be found in the future when it is needed for reading and/or searching.
In addition, validation for title and content has been added. Memory items with empty titles and empty content are rejected as they should make sense when read at a later time. The title assigns an identity to the item, the content contains the useful information of the item. This function behaves as per the rest of the team, as I have taken the shared db_contract.py helpers to validate, normalize tag, check for importances, check time stamps and connect to the database.
The field which is present on the source is also of importance. It documents the source of the context, like a project discussion, a meeting note, device event or an event in a weekly learning log. This will help the memory to be trusted later. In the future the AI (or developer) will be able to find a stored context item and the source will help to explain why it exists and if it is relevant.
The function also automatically saves the 'created_at' and 'updated_at' attributes. If a context item is created for the first time then both the time stamps will be the same. Subsequent updates of a feature will not affect created_at, so it will indicate the time the memory was captured, and updated_at will indicate when the feature was last updated. This can be helpful to sort, filter, sync and view the history of local data.
Once implemented I performed the script for the local storage test for Week 2. The Fellow 1 tests succeeded: Function can create a context item, return a unique integer ID, can store the correct fields, can save timestamps, reject empty title/content and reject invalid context types. This is to ensure the create step is the entry point for the Local Context Store.
This task demonstrated to me that there is no model to begin with when using AI memory locally. It begins with data that is captured clean. Creating a little function might sound easy, but it will establish the rules for all that follows it. Fellow 2 is able to read up the context here, Fellow 3 can search it and Fellow 4 can update or delete it. The remaining memory system is stable if it is consistent to create.
Dey, A. K., Abowd, G. D., & Salber, D. (2001). A conceptual framework and a toolkit for supporting the rapid prototyping of context-aware applications. Human–Computer Interaction, 16(2–4), 97–166. https://doi.org/10.1207/S15327051HCI16234_02
Kleppmann, M., Wiggins, A., van Hardenberg, P., & McGranaghan, M. (2019). Local-first software: you own your data, in spite of the cloud. Onward! 2019. https://doi.org/10.1145/3359591.3359737
Sikos, L. F., & Philp, D. (2020). Provenance-Aware Knowledge Representation: A Survey of Data Models and Contextualized Knowledge Graphs. Data Science and Engineering, 5, 293–316. https://doi.org/10.1007/s41019-020-00118-0
Wang, R. Y., & Strong, D. M. (1996). Beyond Accuracy: What Data Quality Means to Data Consumers. Journal of Management Information Systems, 12(4), 5–33. https://doi.org/10.1080/07421222.1996.11518099
Top comments (0)