I agree to your point, in our current system we are not treating each memory as same. Based on the importance, category and recall frequency we decide a decay rate which would not be same for all the memories. A architectural decision will have a higher importance and although if it's not recalled frequently enough, it will still have a slower decay rate.
The final artifact will look like a flat scored memory graph, in which each node will be a memory having threshold between 0-1 which will be derived through various parameters such as recall, importance etc. Edges will connect semantically similar memories
So based on the importance that it gives the reports individual will decide that which report will survive in the system. You can manually also identify and set the importance or can let llm be the deciding factor here to assign weightage.
Based on the feedback, have made few new enhancement.
1. Activity aware decay, now instead of a wall clock we run decay based on active days in which the user has been using the system.
2. Spatial/ Working directory memory, now while storing an memory we will associate the filePath or active directory and at time of retrieval boast memory associated to the working directory
3. Session wrap up boast, now at the end of a session we will count how many times a memory is being recalled n a session and will apply a recency boost.
4. Memory consolidation, periodically merge near duplicate memories into one combined memory instead of accumulating near identical facts.
5. Suppression link, now when update memory is called we will have a supresed by pointer from the old memory to the new one. This is to keep a track.
6. Smart recall throtelling, added an optional flag of recall cooldown so recall is not triggered in every singal turn. Useful when agents doing multi step task where context is already injected.
All the changes are avaliable in the latest version
Wall clock decay punishing vacation is a issue. The current state of a clock decay is for simplicity but I do see how a session based decay might be helpful.
For failures and strategies it still might work as env drift on calendar anyhow (new version upgrade etc.). But for user preferences it does not.
I agree spatial memory tracking folder visits and session context as retrieval signal would be stronger I agree to that will try to incorporate !
Hi Builder here, biological is here doing the rhetorical work. The actual mechanism here is exponential decay with category specific half lives, recall based reinforcement and pruning context which falls below threshold.
The main difference between a cache and this framework is that it prunes data not only based on recency but also based on importance and category failures fades fast, strategies persists longer, facts stays longer and assumptions fades faster so on.
The 84% is against storing everything forever. The parameter where it beats RAG is handling contradictions and maintaining the memory size near constant with active pruning of data.
Have also benchmarked it against LongMemEval-S dataset the results are in the repo
Comingling unrelated projects is a fair argument for this. But the goal is here not to cater to specific project patterns but general standards you want to use across project.
Using MD files for this is fine till a point. If you keep on adding information in your md file it will bloat up and will have a huge amount of data to go through it might also have some noise which will be picked each and every time that md file is read into the memory.
Decay of unwanted data is very important factor to build up a good context for our agents. Maintaining a md file is also an overhead as either you will ask the agent to auto update it or have to do it manually.
The file will also not able to handle the context which changes over time for example initially I was working in MongoDB and now have moved to Postgres. This info either you have to modify in md manually or both the statements will appear before the llm.
MD file will keep all data points equally weighted which is not correct and it will also be unable to fetch the related data from the data point being fetched !
Hi all builder here, quick update. Benchmarked it against LongMemEval dataset and got the result 84.8% for recall top 5 and 86.8% for nDCG any@5. All the methodology and results are mentioned in the repo !