agent memory
|
+--------------+--------------+
| |
deductive state episodic memory
| |
facts / rules / time fuzzy context
provenance semantic retrieval
retractions source text
I accidentally turned LLM memory into program analysis
101–109 of 109 posts
Re: I accidentally turned LLM memory into program analysis
#102I reached a similar conclusion: LLMs should only really sit at the terminals of request fulfilment. 1. User request understanding: natural language -> a more rigorous representation, in my case Datalog. 2. Result interpretation: facts and derived facts -> natural language. Between those terminals, the work should be mechanical reasoning over some ontology or formal knowledge structure. That connects to another princi…
When i hear “weathering” i think of something slowly eroding away
Weather is fun choice since it’s a contronym. It has opposing definitions: to endure and to erode.
“He weathered the storm” vs “the stone weathered into an arch”.
Re: I accidentally turned LLM memory into program analysis
#103I’ve been playing with this too, the OP is rediscovering the whole field of AI before LLMs. Prolog, temporal logic …
The next one is ontology and semantic web, for which the “trying to stem verbs and nouns” is a crude v0.1 attempt.
Re: I accidentally turned LLM memory into program analysis
#104[flagged]
Re: I accidentally turned LLM memory into program analysis
#105Earlier quoted context omitted.
When i hear “weathering” i think of something slowly eroding away
Weather is fun choice since it’s a contronym. It has opposing definitions: to endure and to erode. “He weathered the storm” vs “the stone weathered into an arch”.
Really (in your example) the timeframe is the only difference.
You can endure as long as you want to, but we're all going to erode eventually.
Re: I accidentally turned LLM memory into program analysis
#106[deleted]
Re: I accidentally turned LLM memory into program analysis
#107This really matches up to my experience on long research projects with Claude. It’s very hard to remove information - Claude has a habit of recording things all over the place and will happily treat things as facts even after they’ve been disproved. What is currently true can get easily contaminated with old “facts”.
One of my rules of thumb is to minimize the amount of "negative knowledge" an LLM sees, as the concept introduced just hangs around in the context way too strong.
The mnemonic I use for that is "do not think of a polar bear".
Re: I accidentally turned LLM memory into program analysis
#108Earlier quoted context omitted.
The various advances in LLM technology tend to rhyme with the advances in computer programming in general. For example, the stunts that involved getting LLMs to create compilers and browsers are really just extremely expensive[0] versions of genetic programming (none of it would have worked without using the test-suite as a fitness-function). The recent news of migrations from one test-framework to another (featuring…
I would not necessarily call it genetic programming. But you can discover the same pattern e.g. for human knowledge. We have a domain language for math and when we go deeper we will have domain language for algebra, discrete math etc.. and we could go even further to breaking it to even for more specific areas simply to compact the information to deliver. The goal is more and precise information with less words, it m…
I am not calling it GP. I am pointing out that AI-coding systems tend to resemble GP systems in terms of both broad architecture, and in terms of how the code/genome is generated. Also, I already mentioned domain specific languages, in the context of GP, and how (effectively) creating one (i.e. selecting only relevant genes/verbs) that was a better match for the problem domain, made the GP find a solution infinitely faster[0]. Clearly these two things are not contradictory, and are clearly related, to the point that they can be combined. I am not sure what about my comment gave you the impression that I thought one was contradictory with the other. Hope this follow-up clears things up.
[0]: Because, in effect, we are decreasing the size of the search-space. Every programming-language project is basically a set of bets, that the design choices will decrease the size of the search space for the users of that language (most Unix commands fit this pattern, as do most well designed APIs). Mathematics is similar, in that the notation is specialized and sparse (even the named constants and variables have symbolic names, instead of meaningful names). Most system dynamics models could have the names of entities replaced with id-numbers, and they would continue to function. The whole point of (for example) a library is to give a tiny parameterized notation/language, that the user can use to express a solution to their problem, in terms of the problem domain itself. This decreasing of the search-space, is an act of compression. I have to say, I am a little confused by your reply, because it has the tone of a disagreement, but it does not really disagree with anything that I have written. Also, I have given various examples to support my analogies, but you have offered zero examples, and I suspect that there would be less confusion (on my part) if you did.
Re: I accidentally turned LLM memory into program analysis
#109This is the fact I’ve been struggling with for quite some time. It’s not because it forgets the facts, it’s because the invalidation doesn’t propagate. My way of handling that is a decision log. For every project since I started doing that it’s working great. My CLAUDE.md instruct the agent to store my every decision to the file with a metadata when I made this decision and what was the context. The agent is using th…
[flagged]