docs: remove duplicate multimodal page and normalize em/en-dashes (#6112)
This commit is contained in:
@@ -28,7 +28,7 @@ When new conversations arrive, the extraction pipeline processes them through si
|
||||
3. **Distill Memories**: Single-pass LLM extraction produces ADD-only facts from input + context
|
||||
4. **Deduplicate + Embed**: Hash-based deduplication, then vectorize new memories
|
||||
5. **Graph Memory (Entity Linking)**: Identify entities (proper nouns, quoted text, compound noun phrases) and link them across memories into a graph
|
||||
6. **Temporal Reasoning**: A separate temporal reasoning pass reads each new memory alongside the source conversation and its date, extracting temporal metadata — when the event occurred, whether it is ongoing or completed, how precise the timing is, and the memory type (event, state, plan, preference, relationship, absence). It is independent of extraction and can run asynchronously so writes stay fast; this metadata is stored with the memory and used later at retrieval.
|
||||
6. **Temporal Reasoning**: A separate temporal reasoning pass reads each new memory alongside the source conversation and its date, extracting temporal metadata: when the event occurred, whether it is ongoing or completed, how precise the timing is, and the memory type (event, state, plan, preference, relationship, absence). It is independent of extraction and can run asynchronously so writes stay fast; this metadata is stored with the memory and used later at retrieval.
|
||||
|
||||
Memories are distributed across three storage layers, each tuned for a specific retrieval pattern:
|
||||
|
||||
@@ -51,7 +51,7 @@ When a query arrives, the retrieval pipeline scores candidates across multiple s
|
||||
3. **Entity Search**: Entity matching boosts memories linked to query entities
|
||||
4. **Temporal Reasoning**: The query's temporal intent is classified (with no extra LLM call), then each candidate is scored by how well the temporal metadata extracted at write time matches that intent.
|
||||
|
||||
These signals are fused via rank scoring into the final top-K set. The temporal score is additive and semantic relevance always dominates — it nudges ranking toward the correct dated instance without filtering candidates out or overriding a strong semantic match, so relevant memories are never dropped. Different query types lean on different signals:
|
||||
These signals are fused via rank scoring into the final top-K set. The temporal score is additive and semantic relevance always dominates; it nudges ranking toward the correct dated instance without filtering candidates out or overriding a strong semantic match, so relevant memories are never dropped. Different query types lean on different signals:
|
||||
|
||||
| Query Type | Primary Signal | Example |
|
||||
|---|---|---|
|
||||
@@ -124,7 +124,7 @@ Temporal reasoning is the standout at a top_200 budget, reaching **97.0** on the
|
||||
|
||||
### Performance Summary
|
||||
|
||||
All results use a single-pass retrieval setup — one retrieval call, one answer, no agentic loops — at a top_200 retrieval budget.
|
||||
All results use a single-pass retrieval setup (one retrieval call, one answer, no agentic loops) at a top_200 retrieval budget.
|
||||
|
||||
| Benchmark | Score | Average tokens / query |
|
||||
|---|---|---|
|
||||
|
||||
@@ -11,17 +11,17 @@ Adding memory is how Mem0 captures useful details from a conversation so your ag
|
||||
|
||||
## Key terms
|
||||
|
||||
- **Messages** – The ordered list of user/assistant turns you send to `add`.
|
||||
- **Infer** – Controls whether Mem0 extracts structured memories (`infer=True`, default) or stores raw messages.
|
||||
- **Metadata** – Optional filters (e.g., `{"category": "movie_recommendations"}`) that improve retrieval later.
|
||||
- **User / Session identifiers** – `user_id`, `agent_id`, `app_id`, or `run_id` that scope the memory for future searches.
|
||||
- **Messages**: The ordered list of user/assistant turns you send to `add`.
|
||||
- **Infer**: Controls whether Mem0 extracts structured memories (`infer=True`, default) or stores raw messages.
|
||||
- **Metadata**: Optional filters (e.g., `{"category": "movie_recommendations"}`) that improve retrieval later.
|
||||
- **User / Session identifiers**: `user_id`, `agent_id`, `app_id`, or `run_id` that scope the memory for future searches.
|
||||
|
||||
## How does it work?
|
||||
|
||||
Mem0 offers two flows:
|
||||
|
||||
- **Mem0 Platform** – Fully managed API with dashboard and scaling.
|
||||
- **Mem0 Open Source** – Local SDK that you run in your own environment.
|
||||
- **Mem0 Platform**: Fully managed API with dashboard and scaling.
|
||||
- **Mem0 Open Source**: Local SDK that you run in your own environment.
|
||||
|
||||
Both flows take the same payload and add memories through an additive pipeline.
|
||||
|
||||
|
||||
@@ -18,10 +18,10 @@ Deleting memories is how you honor compliance requests, undo bad data, or clean
|
||||
|
||||
## Key terms
|
||||
|
||||
- **memory_id** – Unique ID returned by `add`/`search` identifying the record to delete.
|
||||
- **batch_delete** – API call that removes up to 1000 memories in one request.
|
||||
- **delete_all** – Filter-based deletion by user, agent, run, or metadata.
|
||||
- **immutable** – Flagged memories that cannot be updated; delete + re-add instead.
|
||||
- **memory_id**: Unique ID returned by `add`/`search` identifying the record to delete.
|
||||
- **batch_delete**: API call that removes up to 1000 memories in one request.
|
||||
- **delete_all**: Filter-based deletion by user, agent, run, or metadata.
|
||||
- **immutable**: Flagged memories that cannot be updated; delete + re-add instead.
|
||||
|
||||
## How the delete flow works
|
||||
|
||||
|
||||
@@ -11,10 +11,10 @@ Mem0's search operation lets agents ask natural-language questions and get back
|
||||
|
||||
## Key terms
|
||||
|
||||
- **Query** – Natural-language question or statement you pass to `search`.
|
||||
- **Filters** – JSON logic (AND/OR, comparison operators) that narrows results by user, categories, dates, etc.
|
||||
- **top_k / threshold** – Controls how many memories return and the minimum similarity score.
|
||||
- **Rerank** – Optional second pass that boosts precision when a reranker is configured.
|
||||
- **Query**: Natural-language question or statement you pass to `search`.
|
||||
- **Filters**: JSON logic (AND/OR, comparison operators) that narrows results by user, categories, dates, etc.
|
||||
- **top_k / threshold**: Controls how many memories return and the minimum similarity score.
|
||||
- **Rerank**: Optional second pass that boosts precision when a reranker is configured.
|
||||
|
||||
## Architecture
|
||||
|
||||
|
||||
@@ -11,12 +11,12 @@ Mem0’s update operation lets you fix or enrich an existing memory without dele
|
||||
|
||||
## Key terms
|
||||
|
||||
- **memory_id** – Unique identifier returned by `add` or `search` results.
|
||||
- **text** / **data** – New content that replaces the stored memory value.
|
||||
- **metadata** – Optional key-value pairs you update alongside the text.
|
||||
- **timestamp** – Unix epoch (int/float) or ISO 8601 string to override the memory's timestamp.
|
||||
- **batch_update** – Platform API that edits multiple memories in a single request.
|
||||
- **immutable** – Flagged memories that must be deleted and re-added instead of updated.
|
||||
- **memory_id**: Unique identifier returned by `add` or `search` results.
|
||||
- **text** / **data**: New content that replaces the stored memory value.
|
||||
- **metadata**: Optional key-value pairs you update alongside the text.
|
||||
- **timestamp**: Unix epoch (int/float) or ISO 8601 string to override the memory's timestamp.
|
||||
- **batch_update**: Platform API that edits multiple memories in a single request.
|
||||
- **immutable**: Flagged memories that must be deleted and re-added instead of updated.
|
||||
|
||||
## How the update flow works
|
||||
|
||||
|
||||
@@ -11,10 +11,10 @@ Mem0 separates memory into layers so agents remember the right detail at the rig
|
||||
|
||||
## Key terms
|
||||
|
||||
- **Conversation memory** – In-flight messages inside a single turn (what was just said).
|
||||
- **Session memory** – Short-lived facts that apply for the current task or channel.
|
||||
- **User memory** – Long-lived knowledge tied to a person, account, or workspace.
|
||||
- **Organizational memory** – Shared context available to multiple agents or teams.
|
||||
- **Conversation memory**: In-flight messages inside a single turn (what was just said).
|
||||
- **Session memory**: Short-lived facts that apply for the current task or channel.
|
||||
- **User memory**: Long-lived knowledge tied to a person, account, or workspace.
|
||||
- **Organizational memory**: Shared context available to multiple agents or teams.
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
@@ -28,15 +28,15 @@ graph LR
|
||||
|
||||
Short-term memory keeps the current conversation coherent. It includes:
|
||||
|
||||
- **Conversation history** – recent turns in order so the agent remembers what was just said.
|
||||
- **Working memory** – temporary state such as tool outputs or intermediate calculations.
|
||||
- **Attention context** – the immediate focus of the assistant, similar to what a person holds in mind mid-sentence.
|
||||
- **Conversation history**: recent turns in order so the agent remembers what was just said.
|
||||
- **Working memory**: temporary state such as tool outputs or intermediate calculations.
|
||||
- **Attention context**: the immediate focus of the assistant, similar to what a person holds in mind mid-sentence.
|
||||
|
||||
Long-term memory preserves knowledge across sessions. It captures:
|
||||
|
||||
- **Factual memory** – user preferences, account details, and domain facts.
|
||||
- **Episodic memory** – summaries of past interactions or completed tasks.
|
||||
- **Semantic memory** – relationships between concepts so agents can reason about them later.
|
||||
- **Factual memory**: user preferences, account details, and domain facts.
|
||||
- **Episodic memory**: summaries of past interactions or completed tasks.
|
||||
- **Semantic memory**: relationships between concepts so agents can reason about them later.
|
||||
|
||||
Mem0 maps these classic categories onto its layered storage so you can decide what should fade quickly versus what should last for months.
|
||||
|
||||
@@ -44,9 +44,9 @@ Mem0 maps these classic categories onto its layered storage so you can decide wh
|
||||
|
||||
Mem0 stores each layer separately and merges them when you query:
|
||||
|
||||
1. **Capture** – Messages enter the conversation layer while the turn is active.
|
||||
2. **Promote** – Relevant details persist to session or user memory based on your `user_id`, `run_id`, and metadata.
|
||||
3. **Retrieve** – The search pipeline pulls from all layers, ranking user memories first, then session notes, then raw history.
|
||||
1. **Capture**: Messages enter the conversation layer while the turn is active.
|
||||
2. **Promote**: Relevant details persist to session or user memory based on your `user_id`, `run_id`, and metadata.
|
||||
3. **Retrieve**: The search pipeline pulls from all layers, ranking user memories first, then session notes, then raw history.
|
||||
|
||||
```python
|
||||
import os
|
||||
@@ -75,10 +75,10 @@ results = memory.search(
|
||||
|
||||
## When should you use each layer?
|
||||
|
||||
- **Conversation memory** – Tool calls or chain-of-thought that only matter within the current turn.
|
||||
- **Session memory** – Multi-step tasks (onboarding flows, debugging sessions) that should reset once complete.
|
||||
- **User memory** – Personal preferences, account state, or compliance details that must persist across interactions.
|
||||
- **Organizational memory** – Shared FAQs, product catalogs, or policies that every agent should recall.
|
||||
- **Conversation memory**: Tool calls or chain-of-thought that only matter within the current turn.
|
||||
- **Session memory**: Multi-step tasks (onboarding flows, debugging sessions) that should reset once complete.
|
||||
- **User memory**: Personal preferences, account state, or compliance details that must persist across interactions.
|
||||
- **Organizational memory**: Shared FAQs, product catalogs, or policies that every agent should recall.
|
||||
|
||||
## How it compares
|
||||
|
||||
|
||||
Reference in New Issue
Block a user