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

Show HN: Yet another memory system for LLMs

github.com

Post reply on HN
Print view View original

41–50 of 51 posts

Re: Show HN: Yet another memory system for LLMs

#41

Post by blackmanta »

threecheese wrote: post #40

Reviewing the prompts, looks like you are using this CAS tool as a global context data manager, supporting primarily a code use case. There are a number of extant MCP-capable code understanding tools (Serena and others), but what I am lacking in my CLI toolchain is non-code memory. You even called this out in another thread, mentioning task management- I find that the type of memory I need is not scoped to a code mod…

While the examples and provided prompt lean toward code (since that's my personal use case), YAMS is fundamentally a generic content-addressed storage system.

I will attempt to run some small agents with custom prompts and report back.

Re: Show HN: Yet another memory system for LLMs

#42

Post by 3abiton »

blackmanta wrote: post #37
retreatguru wrote: post #11

How do you use this in your workflow? Please give some examples because it’s not clear to me what this is for.

I have been using it for task tracking, research, and code search. When using CLI tools, I found that the LLM's were able to find code in less tool calls when I stored my codebase in the tool. I had to wrangle the LLMs to use the tool verse native rgrep or find. I am also trying to stabilize PDF text extraction to improve knowledge retrieval when I want to revisit a paper I read but cannot remember which one it was.…

This is an interesting approach! Why not offload PDF extraction to other frameorks that apply OCR pdf -> .md

Re: Show HN: Yet another memory system for LLMs

#43

Post by blackmanta »

3abiton wrote: post #42
blackmanta wrote: post #37

Earlier quoted context omitted.

I have been using it for task tracking, research, and code search. When using CLI tools, I found that the LLM's were able to find code in less tool calls when I stored my codebase in the tool. I had to wrangle the LLMs to use the tool verse native rgrep or find. I am also trying to stabilize PDF text extraction to improve knowledge retrieval when I want to revisit a paper I read but cannot remember which one it was.…

This is an interesting approach! Why not offload PDF extraction to other frameorks that apply OCR pdf -> .md

I may explore this when I implement the vectordb implementation I started.

Re: Show HN: Yet another memory system for LLMs

#44

Post by SJC_Hacker »

ActorNightly wrote: post #38
SJC_Hacker wrote: post #16

Earlier quoted context omitted.

Blame the committee for refusing to include basic functionality like regular expressions , networking and threads as part of the STL

I feel like there are pretty standard C++ server implementations that are less bloated.

There might be, but as of a few years ago they were not mature and may not have captured the mindshare yet. Company I worked for actually used websocketpp because Boost ASIO implementation had some bug they couldn't work around, but then it was fixed and we dropped websocketpp.

I can say one the the nice thing about Boost network implementation (ASIO) is fairly mature asychronous framework using a variety of techniques. Also if you need HTTP or Websockets you can use Beast which is built on top of ASIO.

And if you're using one thing from Boost, its easy to just use everything else you need and that Boost provides to minimize dependencies.

Re: Show HN: Yet another memory system for LLMs

#45

Post by SJC_Hacker »

ActorNightly wrote: post #39
menaerus wrote: post #17

Earlier quoted context omitted.

The reason for depending on Boost in this repo is just few search characters away - he needs HTTP/WebSocket implementation and Boost.Beast provides it. The actual bloat here in this repo is conan.

My experience with Boost has been template metaprogramming hell.

For its credit though, it follows the C++ "philosophy" fairly faithfully. If you don't like Boost you probably don't like C++ either.

Although that download is a monster, I think its like 1.6 GB even compressed. Its not modular at all, some of the modules depend on others and its impossible to separate them out (they've tried in the past)

But last I check there is ALOT they could have removed, especially support for older compilers like MSVC 200x (!), pre C++ 11/older GNU compilers, etc. without compromising functionality. I'm not if they got around to doing that.

Re: Show HN: Yet another memory system for LLMs

#46

Post by sitkack »

blackmanta wrote: post #31
sitkack wrote: post #10

How would you use the built in functionality to enable graph functionality? Metadata or another document used as the link or collection of links?

The graph functionality is exposed through the retrieval functionality. I may improve this later but the idea was to maximize getting the best results when looking for stored data.

There is no built in graph functionality correct? But one could use existing mechanisms like metadata or storing the link between documents as a document itself?

Re: Show HN: Yet another memory system for LLMs

#50

Post by blackmanta »

sitkack wrote: post #46
blackmanta wrote: post #31

Earlier quoted context omitted.

The graph functionality is exposed through the retrieval functionality. I may improve this later but the idea was to maximize getting the best results when looking for stored data.

There is no built in graph functionality correct? But one could use existing mechanisms like metadata or storing the link between documents as a document itself?

The graph functionality is stubbed but I will expose it in a future update. You can also use metadata and tags for similar things.
Post reply on HN