Live data from Hacker News

Show HN: Continual Learning with .md

github.com

1–10 of 39 posts

Show HN: Continual Learning with .md

#1
I have a proposal that addresses long-term memory problems for LLMs when new data arrives continuously (cheaply!). The program involves no code, but two Markdown files.

For retrieval, there is a semantic filesystem that makes it easy for LLMs to search using shell commands.

It is currently a scrappy v1, but it works better than anything I have tried.

Curious for any feedback!

Show HN: Continual Learning with .md
github.com

Re: Show HN: Continual Learning with .md

#3
I've seen a lot of such systems come and go. One of my friends is working on probably the best (VC-funded) memory system right now.

The problem always is that when there are too many memories, the context gets overloaded and the AI starts ignoring the system prompt.

Definitely not a solved problem, and there need to be benchmarks to evaluate these solutions. Benchmarks themselves can be easily gamed and not universally applicable.

Re: Show HN: Continual Learning with .md

#7

I've seen a lot of such systems come and go. One of my friends is working on probably the best (VC-funded) memory system right now. The problem always is that when there are too many memories, the context gets overloaded and the AI starts ignoring the system prompt. Definitely not a solved problem, and there need to be benchmarks to evaluate these solutions. Benchmarks themselves can be easily gamed and not universal…

What is the memory system you are referring to? I've been trying Memori with OpenClaw. Haven't had a ton of time to really kick the tires on it, so the jury's still out.

Re: Show HN: Continual Learning with .md

#8

I've seen a lot of such systems come and go. One of my friends is working on probably the best (VC-funded) memory system right now. The problem always is that when there are too many memories, the context gets overloaded and the AI starts ignoring the system prompt. Definitely not a solved problem, and there need to be benchmarks to evaluate these solutions. Benchmarks themselves can be easily gamed and not universal…

The armchair ML engineer in me says our current context management approach is the issue. With a proper memory management system wired up to it’s own LLM-driven orchestrator, memories should be pulled in and pushed out between prompts, and ideally, in the middle of a “thinking” cycle. You can enhance this to be performant using vector databases and such but the core principle remains the same and is oft repeated by parents across the world: “Clean up your toys before you pull a new one out!”

Also since I thought for another 30 seconds, the “too many memories!” Problem imo is the same problem as context management and compaction and requires the same approach: more AI telling AI what AI should be thinking about. De-rank “memories” in the context manager as irrelevant and don’t pass them to the outer context. If a memory is de-ranked often and not used enough it gets purged.

Re: Show HN: Continual Learning with .md

#9

I've seen a lot of such systems come and go. One of my friends is working on probably the best (VC-funded) memory system right now. The problem always is that when there are too many memories, the context gets overloaded and the AI starts ignoring the system prompt. Definitely not a solved problem, and there need to be benchmarks to evaluate these solutions. Benchmarks themselves can be easily gamed and not universal…

The armchair ML engineer in me says our current context management approach is the issue. With a proper memory management system wired up to it’s own LLM-driven orchestrator, memories should be pulled in and pushed out between prompts, and ideally, in the middle of a “thinking” cycle. You can enhance this to be performant using vector databases and such but the core principle remains the same and is oft repeated by p…

Mid thinking cycle seems dangerous as it will probably kill caching.

Re: Show HN: Continual Learning with .md

#10

Earlier quoted context omitted.

The armchair ML engineer in me says our current context management approach is the issue. With a proper memory management system wired up to it’s own LLM-driven orchestrator, memories should be pulled in and pushed out between prompts, and ideally, in the middle of a “thinking” cycle. You can enhance this to be performant using vector databases and such but the core principle remains the same and is oft repeated by p…

Mid thinking cycle seems dangerous as it will probably kill caching.

The mid thinking cycle would require significant architecture change to current state of art and imo is a key blocker to AGI
Post reply on HN