docs: navigation (#5900)
This commit is contained in:
Kartik
@@ -0,0 +1,100 @@
|
||||
---
|
||||
title: "How Mem0 Works"
|
||||
description: "What happens when you add, store, and search memories with Mem0."
|
||||
icon: "diagram-project"
|
||||
---
|
||||
|
||||
Mem0 sits between your application and your model. You send conversation turns to `add`, then call `search` before the next model request to fetch relevant context. Your app decides which returned memories to include in the prompt.
|
||||
|
||||
Use Mem0 when you want agents to remember useful facts across turns, sessions, or users without replaying the full transcript every time.
|
||||
|
||||
<Frame caption="Memory extraction: Mem0 turns messages into stored facts with metadata, embeddings, and optional entity relationships.">
|
||||
<img src="/images/memory-extraction.png" alt="Mem0 memory extraction pipeline: store new memories after the response, context lookup to find related memories, extract memories (ADD only) from input and context, deduplicate and embed, entity linking, written to a SQL database (facts and metadata), vector database (embeddings and similarity), and entity store (entities and relationships)." />
|
||||
</Frame>
|
||||
|
||||
## The mental model
|
||||
|
||||
| Without a memory layer | With Mem0 |
|
||||
|---|---|
|
||||
| Keep appending chat history to the prompt | Store facts once, then retrieve them by query |
|
||||
| Make the model re-read old turns | Give the model only the relevant memories |
|
||||
| Lose context when a session ends | Scope memory by `user_id`, `agent_id`, `run_id`, and metadata |
|
||||
|
||||
## Messages vs memories
|
||||
|
||||
You send Mem0 messages. By default, Mem0 stores extracted memories, not a verbatim transcript.
|
||||
|
||||
| Input | Stored memory |
|
||||
|---|---|
|
||||
| `"I prefer aisle seats"` | `User prefers aisle seats` |
|
||||
| `"Let's use Postgres for this project"` | `Project decision: use Postgres` |
|
||||
| Message metadata | Filterable fields such as category, app, user, or run |
|
||||
|
||||
Use `infer=False` when you need to store raw content exactly as provided. Otherwise, keep inference enabled so retrieval works on clean, deduplicated facts.
|
||||
|
||||
## Two phases: extraction and retrieval
|
||||
|
||||
Most applications use Mem0 in two places:
|
||||
|
||||
1. **After a useful interaction**, call `add` to store what should be remembered.
|
||||
2. **Before a model call**, call `search` and pass the best results into your prompt.
|
||||
|
||||
### 1. Extraction (writing memory)
|
||||
|
||||
When new messages arrive, Mem0 extracts durable facts and stores them with the identifiers and metadata you provide.
|
||||
|
||||
1. **Context lookup.** Mem0 checks related existing memories so it can avoid storing the same fact again.
|
||||
2. **Fact extraction.** An LLM extracts preferences, decisions, plans, and other details your agent can reuse.
|
||||
3. **Deduplication and embedding.** Redundant facts are removed, then each memory is embedded for semantic search.
|
||||
4. **Entity linking.** When configured, Mem0 links people, places, organizations, and concepts across memories.
|
||||
|
||||
The automatic extraction path is additive. If a user says, "I moved from Austin to Seattle," Mem0 can store the new fact without silently rewriting the old one. Use explicit `update` or `delete` operations when your application needs to correct or remove a memory.
|
||||
|
||||
### 2. Retrieval (reading memory)
|
||||
|
||||
When you call `search`, Mem0 ranks stored memories against your query and filters.
|
||||
|
||||
| Signal | What it does | Best for |
|
||||
|---|---|---|
|
||||
| **Semantic** | Vector similarity over embeddings | Conceptual questions |
|
||||
| **Keyword** | Term matching for exact words and phrases | Names, IDs, and factual lookups |
|
||||
| **Entity** | Boosts memories linked to entities in the query | Questions about a person, project, or account |
|
||||
|
||||
Platform retrieval uses multiple signals in the managed service. OSS retrieval depends on your configured vector store, optional reranker, and graph store.
|
||||
|
||||
<Note>
|
||||
Always scope searches with filters such as `user_id`, `agent_id`, or `run_id`. This keeps memories from different users, agents, or sessions from mixing.
|
||||
</Note>
|
||||
|
||||
## Where memories live
|
||||
|
||||
Mem0 stores different parts of a memory in stores built for different lookup patterns:
|
||||
|
||||
| Store | Holds | Purpose |
|
||||
|---|---|---|
|
||||
| **SQL database** | Facts and metadata | The source of truth for each memory |
|
||||
| **Vector database** | Embeddings | Semantic similarity search |
|
||||
| **Entity or graph store** | Entities and relationships | Relationship-aware retrieval when graph memory is enabled |
|
||||
|
||||
On Mem0 Platform, these stores are managed for you. In OSS, you choose and operate the backing stores through your configuration.
|
||||
|
||||
## Build against this flow
|
||||
|
||||
- Call `add` only for information worth reusing later: preferences, decisions, account facts, goals, and durable feedback.
|
||||
- Call `search` before the model response, then include only the returned memories that help answer the current request.
|
||||
- Use metadata for filters your product already cares about, such as workspace, feature area, tenant, or data source.
|
||||
- Avoid storing secrets, raw credentials, or unredacted sensitive data. Mem0 is designed to retrieve stored context.
|
||||
|
||||
## Next steps
|
||||
|
||||
<CardGroup cols={3}>
|
||||
<Card title="Memory types" icon="brain" href="/core-concepts/memory-types">
|
||||
Choose the right scope for user, agent, run, and session memory.
|
||||
</Card>
|
||||
<Card title="Memory operations" icon="database" href="/core-concepts/memory-operations/add">
|
||||
Add, search, update, and delete memories from your app.
|
||||
</Card>
|
||||
<Card title="See the benchmarks" icon="chart-line" href="/core-concepts/memory-evaluation">
|
||||
Review the evaluation setup and benchmark results.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
@@ -9,13 +9,6 @@ iconType: "solid"
|
||||
|
||||
Adding memory is how Mem0 captures useful details from a conversation so your agents can reuse them later. Think of it as saving the important sentences from a chat transcript into a structured notebook your agent can search.
|
||||
|
||||
<Info>
|
||||
**Why it matters**
|
||||
- Preserves user preferences, goals, and feedback across sessions.
|
||||
- Powers personalization and decision-making in downstream conversations.
|
||||
- Keeps context consistent between managed Platform and OSS deployments.
|
||||
</Info>
|
||||
|
||||
## Key terms
|
||||
|
||||
- **Messages** – The ordered list of user/assistant turns you send to `add`.
|
||||
@@ -157,7 +150,6 @@ Add memory whenever your agent learns something useful:
|
||||
|
||||
Storing this context allows the agent to reason better in future interactions.
|
||||
|
||||
|
||||
### More Details
|
||||
|
||||
For full list of supported fields, required formats, and advanced options, see the
|
||||
|
||||
@@ -216,7 +216,7 @@ memory.delete_all(user_id="alice")
|
||||
## Put it into practice
|
||||
|
||||
- Review the <Link href="/api-reference/memory/delete-memory">Delete Memory API reference</Link>, plus <Link href="/api-reference/memory/batch-delete">Batch Delete</Link> and <Link href="/api-reference/memory/delete-memories">Filtered Delete</Link>.
|
||||
- Pair deletes with <Link href="/platform/features/platform-overview">Expiration Policies</Link> to automate retention.
|
||||
- Pair deletes with the <Link href="/api-reference/memory/update-memory">expiration date field</Link> to automate retention.
|
||||
|
||||
## See it live
|
||||
|
||||
@@ -233,9 +233,9 @@ memory.delete_all(user_id="alice")
|
||||
href="/core-concepts/memory-operations/add"
|
||||
/>
|
||||
<Card
|
||||
title="Enable Expiration Policies"
|
||||
description="Automate retention with the platform’s expiration feature."
|
||||
title="Set an Expiration Date"
|
||||
description="Automate retention with the expiration date field on update."
|
||||
icon="clock"
|
||||
href="/platform/features/platform-overview"
|
||||
href="/api-reference/memory/update-memory"
|
||||
/>
|
||||
</CardGroup>
|
||||
|
||||
@@ -9,13 +9,6 @@ iconType: "solid"
|
||||
|
||||
Mem0's search operation lets agents ask natural-language questions and get back the memories that matter most. Like a smart librarian, it finds exactly what you need from everything you've stored.
|
||||
|
||||
<Info>
|
||||
**Why it matters**
|
||||
- Retrieves the right facts without rebuilding prompts from scratch.
|
||||
- Supports both managed Platform and OSS so you can test locally and deploy at scale.
|
||||
- Keeps results relevant with filters, rerankers, and thresholds.
|
||||
</Info>
|
||||
|
||||
## Key terms
|
||||
|
||||
- **Query** – Natural-language question or statement you pass to `search`.
|
||||
|
||||
@@ -9,13 +9,6 @@ iconType: "solid"
|
||||
|
||||
Mem0’s update operation lets you fix or enrich an existing memory without deleting it. When a user changes their preference or clarifies a fact, use update to keep the knowledge base fresh.
|
||||
|
||||
<Info>
|
||||
**Why it matters**
|
||||
- Corrects outdated or incorrect memories immediately.
|
||||
- Adds new metadata so filters and rerankers stay sharp.
|
||||
- Works for both one-off edits and large batches (up to 1000 memories).
|
||||
</Info>
|
||||
|
||||
## Key terms
|
||||
|
||||
- **memory_id** – Unique identifier returned by `add` or `search` results.
|
||||
|
||||
@@ -9,13 +9,6 @@ iconType: "solid"
|
||||
|
||||
Mem0 separates memory into layers so agents remember the right detail at the right time. Think of it like a notebook: a sticky note for the current task, a daily journal for the session, and an archive for everything a user has shared.
|
||||
|
||||
<Info>
|
||||
**Why it matters**
|
||||
- Keeps conversations coherent without repeating instructions.
|
||||
- Lets agents personalize responses based on long-term preferences.
|
||||
- Avoids over-fetching data by scoping memory to the correct layer.
|
||||
</Info>
|
||||
|
||||
## Key terms
|
||||
|
||||
- **Conversation memory** – In-flight messages inside a single turn (what was just said).
|
||||
|
||||
Reference in New Issue
Block a user