This doesn’t solve the capacity problem of memory. You can cram more into one context window, but then again you need to associate them with input queries. That’s very hard because slight variations in input create hugely different activations. So really, it doesn’t improve caching. This paper might do a thing or two approximating the compression limit for context windows, but there’s a fundamental limit on how much information can go into it. What you really need is contextual search, as in, different events and objects with the same abstractions and semantic lead to same response, so you can cache effectively… on this front the paper does little to improve “memory” in a meaningful way
δ-mem: Efficient Online Memory for Large Language Models
11–20 of 69 posts
Re: δ-mem: Efficient Online Memory for Large Language Models
#12Is it a lowercase to uppercase conversion going on here?
Re: δ-mem: Efficient Online Memory for Large Language Models
#13The obvious energy saving step would be to utilise previous searches by others. Many of the tasks people do are rather similar, it is such an energy waste to start again each time. (Obviously ignoring the huge energy saver, which is to observe if you even need to bother doing the task at all.)
I had this thought and created https://pushrealm.com which is essentially a sort of Stackoverflow written by agents. My theory was that if an agent burns 30 minutes resolving an issue not present in training data, posting the solution would prevent other agents re-treading the same thinking steps.
Re: δ-mem: Efficient Online Memory for Large Language Models
#14Interesting that the headline is showing Δ-Mem while the paper uses δ-mem Is it a lowercase to uppercase conversion going on here?
Re: δ-mem: Efficient Online Memory for Large Language Models
#15The obvious energy saving step would be to utilise previous searches by others. Many of the tasks people do are rather similar, it is such an energy waste to start again each time. (Obviously ignoring the huge energy saver, which is to observe if you even need to bother doing the task at all.)
A lot of what I see people using LLMs for would be more cheaply and reliably done by [scripts]. A search engine style suggestion thing like "Have you tried `sed`?" would be beneficial imo
This has the benefit of it knowing all of the arcane flags, especially for formatting output.
Re: δ-mem: Efficient Online Memory for Large Language Models
#16Re: δ-mem: Efficient Online Memory for Large Language Models
#17Re: δ-mem: Efficient Online Memory for Large Language Models
#18Papers being voted high on Hacker News are usually uncorrelated with their actual importance. It's basically a lottery. There are regularly more interesting papers going semi viral on Twitter.
Re: δ-mem: Efficient Online Memory for Large Language Models
#19Earlier quoted context omitted.
I had this thought and created https://pushrealm.com which is essentially a sort of Stackoverflow written by agents. My theory was that if an agent burns 30 minutes resolving an issue not present in training data, posting the solution would prevent other agents re-treading the same thinking steps.
I see why, but I don't feel this is the solution. Being able to search thru the endless LLM responses is not viable. However having useful memories, similar to human brain is more important. I sense this is why neuromorphic computing is the next step, energy efficient and doesn't remember much of what isn't useful to be stored.
Re: δ-mem: Efficient Online Memory for Large Language Models
#20Earlier quoted context omitted.
How would you conceptualize recall in this case? Is searching through the current version of your code and possibly git history not enough?
You would think git history should be the first thing an agent would look at, as they make so many mistakes before they get to the correct answer. They don't. I haven't measured, but documenting bug fixes and architecture seems to help, along with TDD patterns, including integration tests. I would probably add it to Claude.md to look for all of the above when tackling a new bug.