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

Show HN: Core – open source memory graph for LLMs – shareable, user owned

github.com

Post reply on HN
Print view View original

31–40 of 43 posts

Re: Show HN: Core – open source memory graph for LLMs – shareable, user owned

#31

Post by Manoj58 »

MarkMarine wrote: post #29

I’ve been thinking about how to do this well, how my memory actually works. I think what is happening is I’ve either got the facts now (that is easy to repro w/ a system like this) or I’ve got an idea that I could have the facts after working on retrieval. It’s like I’ve got a feeling or sense that somewhere in cold storage is the info I need so I kick off a background process to get it. Sometimes it works. That seco…

You've identified a fundamental gap - that meta-cognitive "I could retrieve this" intuition that humans have but LLMs lack.

Our graph approach addresses this: - Structure knowledge with visible relationship patterns before loading details

- Retrieval system "senses" related information without fetching everything

- Temporal tracking prioritizes recent/relevant information

- Planning recall frequency tracking for higher weightage on accessed facts

In SOL(personal assistant), we guide LLMs to use memory more effectively by providing structured knowledge boundaries. This creates that "I could know this if I looked" capability.

Re: Show HN: Core – open source memory graph for LLMs – shareable, user owned

#32

Post by visarga »

ianbicking wrote: post #7

I've been building a memory system myself, so I have some thoughts... Why use a knowledge graph/triples? I have not been able to come up with any use for the predicate or reason to make these associations. Simple flat statements seem entirely sufficient and more accurate to the source material. ... OK, looking a little more, I'm guessing it is a way to see when a memory should be updated; you can match on the first t…

I built a graph memory MCP tool as well. I don't use triplets, instead I generate nodes. The node is composed of (id, title, text) and text can contain links inlined, like @45, referencing past nodes. So it can create both a node and its relations in one tool call.

My MCP has two tools - a search tool and a node adding tool. The search tool uses embedding similarity to retrieve K nodes, then expands on links and fetches another P nodes. By controlling K and P the LLM can choose to use the graph as a simple RAG or as a pure linked graph, or anywhere in-between. In practice I use Claude which is able to do deep searches. What it does not find in one call it locates in 4-5 calls.

The LLM will only add new ideas not already in the KB. It does the searching, filtering and writing. I am just directing this process. The KB can grow unbounded because when I need to add new nodes I first search the KB and find relevant nodes to link to without loading every node.

But one problem I see with these memory systems is that they can reduce interest on a topic once we put it in the KB.

Re: Show HN: Core – open source memory graph for LLMs – shareable, user owned

#33

Post by saxenauts »

visarga wrote: post #32
ianbicking wrote: post #7

I've been building a memory system myself, so I have some thoughts... Why use a knowledge graph/triples? I have not been able to come up with any use for the predicate or reason to make these associations. Simple flat statements seem entirely sufficient and more accurate to the source material. ... OK, looking a little more, I'm guessing it is a way to see when a memory should be updated; you can match on the first t…

I built a graph memory MCP tool as well. I don't use triplets, instead I generate nodes. The node is composed of (id, title, text) and text can contain links inlined, like @45, referencing past nodes. So it can create both a node and its relations in one tool call. My MCP has two tools - a search tool and a node adding tool. The search tool uses embedding similarity to retrieve K nodes, then expands on links and fetc…

I am building a graph memory too, and I agree with you. It is almost useless to generate triplets, and instead generate nodes that are usually statement strings. And can extend up to a short paragraph too.

I have strong opinions that memory should be a graph + vector hybrid. The vector store can store and index information as a cognitive fragment( ex. all things related to my house), and can keep editing it as a set of statements, while that node can be associated with other nodes (ex. my renovation plans, budgeting, etc.), because those are separate fragments. I am also using LLM to consolidate and find new patterns across the connected memories

> But one problem I see with these memory systems is that they can reduce interest on a topic once we put it in the KB.

Can you elaborate please?

Re: Show HN: Core – open source memory graph for LLMs – shareable, user owned

#34

Post by cpard »

khaledh wrote: post #30
cpard wrote: post #26

Earlier quoted context omitted.

The problem with semantic web was deeper, people had to agree on the semantics that would be formalized as triples and getting people to agree on an ongoing basis is not an easy task. My question is, what’s the value of explicitly storing semantics as triples when the LLM can infer the semantics on runtime?

Not much tbh. I'm using markdown files as a memory bank[1] for my projects and it works well without the need to structure them in a schema/graph. But I guess one benefit of this particular memory graph implementation is its temporal aspect: searchable facts can evolve over time; i.e. what is true now and how it got here. [1] https://docs.cline.bot/prompting/cline-memory-bank

That’s interesting! I’ll take a deeper look. Thanks for sharing

Re: Show HN: Core – open source memory graph for LLMs – shareable, user owned

#35

Post by Manoj58 »

cpard wrote: post #26
khaledh wrote: post #10

I love how we have come full circle. Anybody remembers the "semantic web" (RDF-based knowledge graph)? It didn't take off because building and maintaining such a graph requires extensive knowledge engineering work and tools. Fast forward a couple of decades and we have LLMs, which is basically auto-complete on steroids based on general knowledge, with the downside that it doesn't "remember" any facts unless you spoon…

The problem with semantic web was deeper, people had to agree on the semantics that would be formalized as triples and getting people to agree on an ongoing basis is not an easy task. My question is, what’s the value of explicitly storing semantics as triples when the LLM can infer the semantics on runtime?

This is something we brainstorm a lot on. While LLMs can infer semantics at runtime, we got biased to explicit triples for these reasons:

Efficient, precise retrieval through graph traversal patterns that flat text simply can't match ("find all X related to Y through relationship Z")

Algorithmic contradiction detection by matching subject-predicate pairs across time, which LLMs struggle with across distant contexts

Our goal is also to make assistant more proactive, where triplets make pattern recognition more easy and effective

what do you think about these?

Re: Show HN: Core – open source memory graph for LLMs – shareable, user owned

#36

Post by dvrp »

adamkochanowicz wrote: post #4

For those asking how this is different from a simple text based memory archive, I think that is answered here: --- Unlike most memory systems—which act like basic sticky notes, only showing what’s true right now. C.O.R.E is built as a dynamic, living temporal knowledge graph: Every fact is a first-class “Statement” with full history, not just a static edge between entities. Each statement includes what was said, who…

I built this with simple text-based memory archive too. What you said is simply adding git to the equation. I tried many approaches and, to my surprise, Markdown + Git + plain-old UNIX tooling is powerful.

I've noticed that anchoring the tool on well thought out standards correlates with good performance.

Concretely: using Markdown, JSON, RFC 822 MESSAGE ID for identifying emails, or using self-contained binaries (or simply executable files with UNIX shebangs) are all instances of where I've converged after many attempts at using more complex techniques. Examples of those techniques are PostgreSQL, XML, trying to recreate what's essentially Git (for the time component), and even embeddings in some cases.

I think this is an instance of worse-is-better.

Re: Show HN: Core – open source memory graph for LLMs – shareable, user owned

#40

Post by hanszarkov »

Manoj58 wrote: post #38
hanszarkov wrote: post #37

Does this work with Claude?

We support MCP server which you can use to connect to claude https://github.com/RedPlanetHQ/core/blob/main/README.md You can check in our readme on how to use mcp server

Tried this, no joy. I created a CORE API key from my workspace->API page, configured MCP with Claude Desktop, I get this: "You didn't provide an API key...You can obtain an API key from https://platform.openai.com/account/api-keys"

Other memory MCP servers do not require access to OpenAI - and not even sure why I would want any of my data going there when I use a paid Claude subscription.

I like the idea here, but doesn't seem very usable.

Post reply on HN