Memory recall gated by keyword matching

Jc-965 commented

2026-09-26 16:48:11 +00:00

Member

Bark only looks up what it remembers about a user when the message contains first-person words like "my" or "prefer". If someone mentioned they're vegetarian last week and now asks "any good spots near Gates?", the answer ignores that, because the message didn't contain a trigger word. Same problem as the tool loading issue in #23.

We want stored facts to be used whenever they'd change the answer, regardless of phrasing, without adding cost for users who have nothing stored.

Bark only looks up what it remembers about a user when the message contains first-person words like "my" or "prefer". If someone mentioned they're vegetarian last week and now asks "any good spots near Gates?", the answer ignores that, because the message didn't contain a trigger word. Same problem as the tool loading issue in #23. We want stored facts to be used whenever they'd change the answer, regardless of phrasing, without adding cost for users who have nothing stored.

krishsax added this to the (deleted) project

2026-09-26 19:06:50 +00:00

krishsax removed this from the (deleted) project

2026-09-26 19:07:10 +00:00

krishsax added this to the Agent project

2026-09-26 19:07:38 +00:00

rijulm commented

2026-10-03 20:56:07 +00:00

Member

We discussed an idea for better storing user context for quicker lookups using something similar to this MCP. At a high level, the intended purpose for this is to take a huge list of files (like in a codebase) and generate a knowledge graph that lets AI models pull info on a specific topic, then instantly see what nodes of knowledge are related and worth reading, and not read unrelated info each time. This greatly cuts token costs since traditional RAG is very expensive as the number of messages/context grows.

Admittedly, this might be a bit much since it's intended for codebases, but having this as a native feature for storing user info across multiple conversations gives the model the ability to only pull relevant info and have cheaper token costs which is always nice. Also, it means that if a user talks to the AI model about being vegan, it could get stored in a subsection of the graph reserved for the user's dining preferences, then this section will only be referenced when the user asks about dining and won't be looked at if the user asks for, say, coding help.

For this specific example, it would prevent a predictable issue in the future where the model gets overwhelmed by having so much unfiltered user info that it starts to hallucinate. This can be dangerous, since a user could mention "I am a vegan" then several messages later ask something like "am I good to get the pizza at Edge?" and the model, having forgotten by now that the user is vegan, might think they're just asking if The Edge has good tasting pizza, and will response "Yes, The Edge would be a great location for you to go and get pizza." The user could then trust this blindly then later find out that The Edge's pizza is not vegan (and even worse, that it tastes horrible) and lose trust in our AI.

TLDR; Graphify would be a cheap method of storing user info for reduced token costs and give more accurate context.

We discussed an idea for better storing user context for quicker lookups using [something similar to this MCP](https://graphify.net/). At a high level, the intended purpose for this is to take a huge list of files (like in a codebase) and generate a knowledge graph that lets AI models pull info on a specific topic, then instantly see what nodes of knowledge are related and worth reading, and not read unrelated info each time. This greatly cuts token costs since traditional RAG is very expensive as the number of messages/context grows. Admittedly, this might be a bit much since it's intended for codebases, but having this as a native feature for storing user info across multiple conversations gives the model the ability to only pull relevant info and have cheaper token costs which is always nice. Also, it means that if a user talks to the AI model about being vegan, it could get stored in a subsection of the graph reserved for the user's dining preferences, then this section will only be referenced when the user asks about dining and won't be looked at if the user asks for, say, coding help. For this specific example, it would prevent a predictable issue in the future where the model gets overwhelmed by having so much unfiltered user info that it starts to hallucinate. This can be dangerous, since a user could mention "I am a vegan" then several messages later ask something like "am I good to get the pizza at Edge?" and the model, having forgotten by now that the user is vegan, might think they're just asking if The Edge has good tasting pizza, and will response "Yes, The Edge would be a great location for you to go and get pizza." The user could then trust this blindly then later find out that The Edge's pizza is not vegan (and even worse, that it tastes horrible) and lose trust in our AI. TLDR; Graphify would be a cheap method of storing user info for reduced token costs and give more accurate context.

arhavthakkar commented

2026-10-03 20:56:19 +00:00

Member

One of the solutions could be having two different modes in the text box itself, ‘incognito’ and ‘personalise’; incognito, would emphasise on giving a general response without any memory stored or used. Whereas, the personalised mode would give a response with respect to the memory stored.
Now there’s two problems within this method as well, one is token usage when using memory on almost every call, and the other is that this may lead to the response being overpersonalised for prompts that don’t need it, making it worse.

For the first problem, there’s a really common way of solving this, we can limit the token usage of each native account while in the personalised mode, which is going to solve majority of the issue of token usage.

But when it comes to overpersonalisation, we can consider using an intermediary agent that runs each prompt through the memory and decides whether it needs to recall the memory for that specific call or not and then run the primary OpenAI API call. But this would burn through tokens quite quick as well. We need to manage this particular issue maybe by tuning the relevance threshold low enough such that it catches implicit meanings, while being high enough to avoid overpersonalisation.

One of the solutions could be having two different modes in the text box itself, ‘incognito’ and ‘personalise’; incognito, would emphasise on giving a general response without any memory stored or used. Whereas, the personalised mode would give a response with respect to the memory stored. Now there’s two problems within this method as well, one is token usage when using memory on almost every call, and the other is that this may lead to the response being overpersonalised for prompts that don’t need it, making it worse. For the first problem, there’s a really common way of solving this, we can limit the token usage of each native account while in the personalised mode, which is going to solve majority of the issue of token usage. But when it comes to overpersonalisation, we can consider using an intermediary agent that runs each prompt through the memory and decides whether it needs to recall the memory for that specific call or not and then run the primary OpenAI API call. But this would burn through tokens quite quick as well. We need to manage this particular issue maybe by tuning the relevance threshold low enough such that it catches implicit meanings, while being high enough to avoid overpersonalisation.

Rows
Columns

Memory recall gated by keyword matching #26