[HN Gopher] Show HN: Mem0 - open-source Memory Layer for AI apps
___________________________________________________________________
Show HN: Mem0 - open-source Memory Layer for AI apps
Hey HN! We're Taranjeet and Deshraj, the founders of Mem0
(https://mem0.ai). Mem0 adds a stateful memory layer to AI
applications, allowing them to remember user interactions,
preferences, and context over time. This enables AI apps to deliver
increasingly personalized and intelligent experiences that evolve
with every interaction. There's a demo video at
https://youtu.be/VtRuBCTZL1o and a playground to try out at
https://app.mem0.ai/playground. You'll need to sign up to use the
playground - this helps ensure responses are more tailored to you
by associating interactions with an individual profile. Current
LLMs are stateless--they forget everything between sessions. This
limitation leads to repetitive interactions, a lack of
personalization, and increased computational costs because
developers must repeatedly include extensive context in every
prompt. When we were building Embedchain (an open-source RAG
framework with over 2M downloads), users constantly shared their
frustration with LLMs' inability to remember anything between
sessions. They had to repeatedly input the same context, which was
costly and inefficient. We realized that for AI to deliver more
useful and intelligent responses, it needed memory. That's when we
started building Mem0. Mem0 employs a hybrid datastore
architecture that combines graph, vector, and key-value stores to
store and manage memories effectively. Here is how it works:
Adding memories: When you use mem0 with your AI App, it can take in
any messages or interactions and automatically detects the
important parts to remember. Organizing information: Mem0 sorts
this information into different categories: - Facts and structured
data go into a key-value store for quick access. - Connections
between things (like people, places, or objects) are saved in a
graph store that understands relationships between different
entities. - The overall meaning and context of conversations are
stored in a vector store that allows for finding similar memories
later. Retrieving memories: When given an input query, Mem0
searches for and retrieves related stored information by leveraging
a combination of graph traversal techniques, vector similarity and
key-value lookups. It prioritizes the most important, relevant, and
recent information, making sure the AI always has the right
context, no matter how much memory is stored. Unlike traditional
AI applications that operate without memory, Mem0 introduces a
continuously learning memory layer. This reduces the need to
repeatedly include long blocks of context in every prompt, which
lowers computational costs and speeds up response times. As Mem0
learns and retains information over time, AI applications become
more adaptive and provide more relevant responses without relying
on large context windows in each interaction. We've open-sourced
the core technology that powers Mem0--specifically the memory
management functionality in the vector and graph databases, as well
as the stateful memory layer--under the Apache 2.0 license. This
includes the ability to add, organize, and retrieve memories within
your AI applications. However, certain features that are optimized
for production use, such as low latency inference, and the scalable
graph and vector datastore for real-time memory updates, are part
of our paid platform. These advanced capabilities are not part of
the open-source package but are available for those who need to
scale memory management in production environments. We've made
both our open-source version and platform available for HN users.
You can check out our GitHub repo (https://github.com/mem0ai/mem0)
or explore the platform directly at https://app.mem0.ai/playground.
We'd love to hear what you think! Please feel free to dive into the
playground, check out the code, and share any thoughts or
suggestions with us. Your feedback will help shape where we take
Mem0 from here!
Author : staranjeet
Score : 96 points
Date : 2024-09-04 16:01 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| ksx098 wrote:
| how it is different from Calude prompt caching ?
| choilive wrote:
| Because this doesn't prompt cache? Prompt caching is dumping
| out the calculated values from vRAM onto disk and reloading
| them back into memory as necessary.
| staranjeet wrote:
| Thanks for your question!
|
| Claude Prompt Caching and Mem0's memory system have several key
| differences:
|
| 1. Purpose and duration: Claude's cache is designed for short-
| term memory, clearing every 5 minutes. In contrast, Mem0 is
| built for long-term information storage, retaining data
| indefinitely unless instructed otherwise. 2. Flexibility and
| control: Mem0 offers more flexibility, allowing developers to
| update, delete, or modify stored information as needed.
| Claude's cache is more static - new information creates
| additional entries rather than updating existing ones. 3.
| Content management: Claude has minimum length requirements for
| caching (1024 characters for Sonnet, 2048 for Haiku). Mem0 can
| handle information of any length, from short facts to longer
| contexts. 4. Customization: Developers have greater control
| over Mem0's memory management, including options for
| prioritizing or deprioritizing information based on relevance
| or time. Claude's caching system offers less direct control. 5.
| Information retrieval: Mem0 is designed for more precise and
| targeted information retrieval, while Claude's cache works with
| broader contextual blocks.
|
| These differences reflect the distinct purposes of each system.
| Claude's cache aims to maintain recent context in ongoing
| conversations, while Mem0 is built to serve as a flexible,
| long-term knowledge base for AI applications.
| lagniappe wrote:
| What's up with all the flagged comments?
| Kiro wrote:
| There was even more before. Some has been removed completely.
| dang wrote:
| If you turn on 'showdead' in your profile you can see all
| killed comments. (This is in the FAQ:
| https://news.ycombinator.com/newsfaq.html.)
|
| There's only one level of removal beyond that ("[deleted]")
| but we never do that as moderators. "[deleted]" always means
| either that the author deleted the post themselves or asked
| us to do it for them.
| golergka wrote:
| I'm also confused. They seem positive and constructive. Do mods
| detect that these are some kind of automated bots?
| threecheese wrote:
| I observed at least two brand new accounts posting some
| variety of "kudos", not flagged into oblivion (yet). Gives me
| the ick, i guess it's better to know mem0 is a shady marketer
| (maybe they are also a shady operator).
| jeppebemad wrote:
| If I see this many questions that could have been taken
| straight from an FAQ, all followed up with "great question, we
| do so and so..", my alarm bells go off. Shady marketing indeed.
| dang wrote:
| I flagged some (most? not sure) of them as booster comments,
| presumably by friends trying to help the submitters out. HN
| users aren't supposed to do that and YC founders are given
| strict instructions not to do it (and scoldings when it
| happens), but it's impossible to prevent completely. People's
| friends try to "help" them and don't realize that it's actually
| the opposite of helping.
|
| See the "Comments" section of the Launch HN instructions for YC
| startups (https://news.ycombinator.com/yli.html) for an example
| of how strongly we emphasize this.
| ezhang887 wrote:
| Is there any way to change what "user" I am chatting as in the
| playground? I created some memories in the onboarding process
| under a specific user, but it seems like my chats in the
| playground are using a different user.
| deshraj wrote:
| Hey, Deshraj from Mem0 team. Right now you cannot change the
| "user" you are chatting as yet but we can definitely make it
| happen. Will ship this update later today. :)
| kaybi wrote:
| How does Mem0 handle the potential for outdated or irrelevant
| memories over time? Is there a mechanism for "forgetting" or
| deprioritizing older information that may no longer be
| applicable?
| staranjeet wrote:
| Mem0 currently handles outdated or irrelevant memories by:
|
| 1. Automatically deprioritizing older memories when new,
| contradictory information is added. 2. Adjusting memory
| relevance based on changing contexts.
|
| We're working on improving this system to give developers more
| control. Future plans include:
|
| 1. Time-based decay of unused memories 2. Customizable
| relevance scoring 3. Manual removal options for obsolete
| information
|
| These improvements aim to create a more flexible "forgetting"
| mechanism, allowing AI applications to maintain up-to-date and
| relevant knowledge bases over time.
|
| We're open to user feedback on how to best implement these
| features in practical applications.
| Oras wrote:
| Looks interesting but curious to know how is it different from
| using traditional databases or vector databases? Is that the
| graph element?
| staranjeet wrote:
| Thanks for your question!
|
| Vector databases are typically used for storing embeddings and
| are great for tasks like similarity search. However, they are
| generally read-only and don't natively support the concept of
| time or state transitions. Let's take an example of tracking
| state of a tasks from your todo list in a vector database:
|
| You might store the task's states like:
|
| Task 1 in backlog Task 1 in progress Task 1 in canceled
|
| But there's no concept of "latest state" or memory of how the
| task evolved over time. You'd have to store multiple versions
| and manually track changes.
|
| With a memory-enabled system like Mem0, you could track: Task 1
| (current state: in progress) with a memory of previous states
| (backlog, canceled, etc). This gives your AI app more stateful
| understanding of the world, allowing it to update and reflect
| the current context automatically.
|
| Traditional databases, on the other hand, are designed for
| structured, relational data with fixed schemas, like customer
| information in a table. These are great for handling
| transactional data but aren't optimal for cases where the data
| is unstructured.
|
| As mentioned in the post, we use a hybrid datastore approach
| that handles these cases effectively and that's where the graph
| aspect comes into picture.
| AngelaHoover wrote:
| Over time, I can imagine there's going to be a lot of sensitive
| information being stored. How are you handling privacy?
| deshraj wrote:
| We already support the feature of inclusion and exclusion of
| memories where the developer can control what things to
| remember vs not remember for their AI app/agent. For example,
| you can specify something like this:
|
| - Inclusion prompt: User's travel preferences and food choices
| - Exclusion prompt: Credit card details, passport number, SSN
| etc.
|
| Although we definitely think that there is scope to make it
| better and we are actively working on it. Please let us know if
| you have feedback/suggestions. Thanks!
| weisser wrote:
| Congrats on the launch!
|
| I messed around with the playground onboarding...here's the
| output:
|
| With Memory Mem0.ai I know that you like to collect records from
| New Orleans artists, and you enjoy running.
|
| Relevancy: 9/10
|
| Without Memory I don't have any personal information about you. I
| don't have the ability to know or remember individual users. My
| main function is to provide information and answer questions to
| the best of my knowledge and training. How can I assist you
| today?
|
| Relevancy: 4/10
|
| --
|
| It's interesting that "With Memory" is 9/10 Relevancy even though
| it is 100% duplication of what I had said. It feels like that
| would be 10/10.
|
| It's also interesting that "Without Memory" is 4/10 -- it seems
| to be closer to 0/10?
|
| Curious how you thinking about calculating relevancy.
| soulofmischief wrote:
| This is why in my system I have more specific, falsifiable
| metrics: freshness, confidence, etc. which come together to
| create a fitness score at the surface-level, while still
| exposing individual metrics in the API.
| omarshaya wrote:
| Solves a key need to make AI Agents useful!
| omarshaya wrote:
| I enjoyed our collaboration to integrate with our MultiOn agent
| platform. Try it our if you are building AI Agents for the web.
| yding wrote:
| Congrats Taranjeet and Deshraj!
|
| So after using Mem0 a bit for a hackathon project, I have sort of
| two thoughts: 1. Memory is extremely useful and almost a
| requirement when it comes to building next level agents and Mem0
| is probably the best designed/easiest way to get there. 2. I
| think the interface between structured and unstructured memory
| still needs some thinking.
|
| What I mean by that is when I look at the memory feature of
| OpenAI it's obviously completely unstructured, free form text,
| and that makes sense when it's a general use product.
|
| At the same time, when I'm thinking about more vertical specific
| use cases up until now, there are very specific things generally
| that we want to remember about our customers (for example, for
| advertising, age range, location, etc.) However, as the use of
| LLMs in chatbots increases, we may want to also remember less
| structured details.
|
| So the killer app here would be something that can remember and
| synthesize both structured and unstructured information about the
| user in a way that's natural for a developer.
|
| I think the graph integration is a step in this direction but
| still more on the unstructured side for now. Look forward to
| seeing how it develops.
| mbm wrote:
| This is great feedback. I've felt this too, and am working on
| something that I hope enables this in an intuitive way. I'd
| love to get your thoughts on what you'd find to be the ideal
| UX?
| deshraj wrote:
| Thanks yding! Definitely agree with the feedback here. We have
| seen similar things when talking to developers where they want:
|
| - Control over what to remember/forget - Ability to set how
| detailed memories should be (some want more detailed vs less
| detailed) - Different structure of the memories based on the
| use case
| giovannibonetti wrote:
| Great product, thanks for releasing it for the opensource
| community. Have you considered replacing Neo4j with something
| more cost-effective like Memgraph?
| PaulHoule wrote:
| When I worked as a consultant in the knowledge graph area I ran
| into clients over and over against who had failed with Neo4J,
| which I'd never done because I read the Neo4J manual and
| understood it just wasn't an industrial strength tool.
| deshraj wrote:
| Thanks for the feedback! Yes, we are definitely planning to add
| support for other graph datastores including Memgraph and
| others.
| twoodfin wrote:
| Does the structure of data & query patterns required demand a
| graph store for acceptable performance? Would a Postgres-
| based triplestore & recursive CTE's suck badly?
| deshraj wrote:
| Yes, it won't scale well. I have used postgres exactly the
| way you specified in my past job and it didn't scale well
| after a certain point.
| FooBarWidget wrote:
| Where do you process your data? Do you have a Europe region? Are
| you GDPR compliant?
|
| This is my main concern with most AI providers. They are based in
| the US, with unclear GDPR compliancy, making most of them a non-
| starter for me.
| golergka wrote:
| Congrats on the launch!
|
| The only AI memory solution I work with every day is ChatGPT
| memory feature. How does mem0 compares to it?
| deshraj wrote:
| Thanks for the question. Here's how Mem0 differs from ChatGPT
| memory:
|
| 1. LLM Compatibility: Mem0 works with various AI providers
| (OpenAI, Anthropic, Groq, etc.), while ChatGPT memory is tied
| to OpenAI's models only.
|
| 2. Target Audience: Mem0 is built for developers creating AI
| applications, whereas ChatGPT memory is for ChatGPT users.
|
| 3. Quality and Performance: Our evaluations show Mem0
| outperforms ChatGPT memory in several areas:
| - Consistency: Mem0 updates memories more reliably across
| multiple instances. - Reliability: ChatGPT memory
| can be inconsistent with the same prompts, while Mem0 aims for
| more consistent performance. - Speed: Mem0
| typically creates memories in about 2 seconds, compared to
| ChatGPT's 30-40 seconds to reflect new memories.
|
| 4. Flexibility: Mem0 offers more customization options for
| developers, allowing better integration into various AI
| applications.
|
| These differences make Mem0 a better choice for developers
| building AI apps that need efficient memory capabilities.
| kaybi wrote:
| Congratulations to the Mem0 team on your launch! As LLMs continue
| to advance, with newer models featuring larger context windows
| and better context retention, how does Mem0 distinguish itself
| from the memory capabilities that future LLMs might inherently
| possess?
| handfuloflight wrote:
| Could you speak to more about what the pricing is? With the
| current pricing page, it's hard to model costs against potential
| use cases.
| krawczstef wrote:
| @staranjeet we should get you plugged in as part of persistence
| with https://github.com/dagworks-inc/burr !
| jazzyjackson wrote:
| 10/10 name
|
| makes me nostalgic for ChatScript's fact triples
| jedwhite wrote:
| Congrats on the launch. Adding a memory layer to LLMs is a real
| painpoint. I've been experimenting with mem0 and it solves a real
| problem that I failed to solve myself, and we're going to use it
| in production.
|
| One question that I've heard a few times now: will you support
| the open source version as a first class citizen for the long
| term? A lot of open source projects with a paid version follow a
| similar strategy. They use the open source repo to get traction,
| but then the open source version gets neglected and users are
| eventually pushed to the paid version. How committed are you to
| supporting the open source version long term?
___________________________________________________________________
(page generated 2024-09-04 23:00 UTC)