Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Continual Learning with .md

github.com

Post reply on HN
Print view View original

21–30 of 39 posts

Re: Show HN: Continual Learning with .md

#21

Post by natpalmer1776 »

wenhan_zhou wrote: post #19
natpalmer1776 wrote: post #16

Earlier quoted context omitted.

Ah, I mean bi-directional management of context. Add and remove. Basically just the remove bit since we have adding down.

I see your point. A removal mechanism is not (yet) implemented. But in principle, we could adjust the instructions in Update.md so that it does a minor "refactor" of the filesystem each day, then newer abstractions can form, while irrelevant gets pruned/edited. That's the beauty of the architecture, you define how the update can occur! But if you do have a new memory (possibly contradicting an old one), is it really…

Do you remember the day you learned how to perform long division?

The purpose of memory pruning is not to “forget” useful or even contradictory information, but to condense it so that the useful bits of the memory take less context and be more immediately accessible in situations that need it.

Re: Show HN: Continual Learning with .md

#22

Post by wenhan_zhou »

natpalmer1776 wrote: post #21
wenhan_zhou wrote: post #19

Earlier quoted context omitted.

I see your point. A removal mechanism is not (yet) implemented. But in principle, we could adjust the instructions in Update.md so that it does a minor "refactor" of the filesystem each day, then newer abstractions can form, while irrelevant gets pruned/edited. That's the beauty of the architecture, you define how the update can occur! But if you do have a new memory (possibly contradicting an old one), is it really…

Do you remember the day you learned how to perform long division? The purpose of memory pruning is not to “forget” useful or even contradictory information, but to condense it so that the useful bits of the memory take less context and be more immediately accessible in situations that need it.

I don't remember such details, but as you suggest, it is a healthy kind of compression.

I address it through merging the lower-level memories into more abstracted ones through a temporal hierarchical filesystem. So, days -> months -> quarters -> years. Each time scale focuses on a more "useful" context since uncertain/contradictory information does not survive as it goes up in abstraction.

For example, A day-level memory might be: "The user learned how to divide 314 by 5 with long division on Jan 3rd 2017."

A year-level memory might be: "The user progressed significantly in mathematics during elementary school."

From the perspective of the LLM, it is easier to access the year-level memories because it requires fewer "cd" commands, and it only dives down into lower levels when necessary.

Re: Show HN: Continual Learning with .md

#23

Post by wenhan_zhou »

SyneRyder wrote: post #20
in-silico wrote: post #5

Earlier quoted context omitted.

This assumes that the model's behavior and memories are faithful to their english/human language representation, and don't stray into (even subtle) "neuralese".

Having run a Markdown memory system with Claude for over a year, I don't think I've seen any evidence of neuralese. That's even with Claude being regularly encouraged to write "reflections" on each session, including automated sessions, and weekly summaries of those reflections. The bigger problem is avoiding what I call the Memento Effect. I won't spoil the movie for anyone, but Memento involves a character who cann…

I think what's missing is a benchmark that measures how well the memories contribute to future interactions.

Re: Show HN: Continual Learning with .md

#25

Post by 0xchamin »

is this based on Karapathy's LLM Wiki idea (link: https://gist.github.com/karpathy/442a6bf555914893e9891c11519...)? . I leveraged Karapathy's wiki idea and built MCPTube- it's a CLI and also an MCP server that turns YouTube videos into a compounding knowledge base. Check it out and let me know what you think (link: https://github.com/0xchamin/mcptube)

Re: Show HN: Continual Learning with .md

#27

Post by wenhan_zhou »

jusasiiv wrote: post #26

Seems interesting. Ill give it a try on my agent, memory is definitely an ongoing issue. How long have you been running this in a continuous state? Also have you tried other LLM's and seen a difference on how well they can use it?

Although I have been working on memory before, ReadMe is very fresh. The moment I saw it running, I published it. So, no continuous running nor LLM ablation studies.

Treat it as an MVP, would love to hear how your agent performs!

Re: Show HN: Continual Learning with .md

#29

Post by wenhan_zhou »

0xchamin wrote: post #25

is this based on Karapathy's LLM Wiki idea (link: https://gist.github.com/karpathy/442a6bf555914893e9891c11519... )? . I leveraged Karapathy's wiki idea and built MCPTube- it's a CLI and also an MCP server that turns YouTube videos into a compounding knowledge base. Check it out and let me know what you think (link: https://github.com/0xchamin/mcptube )

I just read LLM Wiki in more detail. I have heard about it second-hand before this project. The "no-code" idea was inspired by Karpathy.

As I have understood it, in LLM Wiki, the human is very much in the loop in what gets written. In ReadMe, the human control is mostly on the policy (prompt) level, and it is done once, the agent then goes full autonomously afterwards.

After a quick skim of your project.

I have tried an embedding-based knowledge base as well, but it is a bit tricky to make the embedding match a user query. For example, "What happened?" is not at all similar to "Batman defeats Joker." You need to reformulate the query using an LLM, which is tricky given that the query is conditioned on the whole chat history. That's partly why I abandoned embedding-based methods.

But given that MCPTube already works on Gemini CLI, I could see it work natively without embeddings. Gemini is capable of reading video files natively. Worth a try?

Post reply on HN