diff --git a/docs/core-concepts/memory-evaluation.mdx b/docs/core-concepts/memory-evaluation.mdx index 5f5f8e03c..e265abf61 100644 --- a/docs/core-concepts/memory-evaluation.mdx +++ b/docs/core-concepts/memory-evaluation.mdx @@ -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 | |---|---|---| diff --git a/docs/core-concepts/memory-operations/add.mdx b/docs/core-concepts/memory-operations/add.mdx index bf80553eb..aa92dbeb7 100644 --- a/docs/core-concepts/memory-operations/add.mdx +++ b/docs/core-concepts/memory-operations/add.mdx @@ -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. diff --git a/docs/core-concepts/memory-operations/delete.mdx b/docs/core-concepts/memory-operations/delete.mdx index 1c8830c79..80703a2c5 100644 --- a/docs/core-concepts/memory-operations/delete.mdx +++ b/docs/core-concepts/memory-operations/delete.mdx @@ -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 diff --git a/docs/core-concepts/memory-operations/search.mdx b/docs/core-concepts/memory-operations/search.mdx index 025980047..1d63577c9 100644 --- a/docs/core-concepts/memory-operations/search.mdx +++ b/docs/core-concepts/memory-operations/search.mdx @@ -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 diff --git a/docs/core-concepts/memory-operations/update.mdx b/docs/core-concepts/memory-operations/update.mdx index 9c2da80ed..d8340c26a 100644 --- a/docs/core-concepts/memory-operations/update.mdx +++ b/docs/core-concepts/memory-operations/update.mdx @@ -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 diff --git a/docs/core-concepts/memory-types.mdx b/docs/core-concepts/memory-types.mdx index 5a4486406..7a0277435 100644 --- a/docs/core-concepts/memory-types.mdx +++ b/docs/core-concepts/memory-types.mdx @@ -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 diff --git a/docs/docs.json b/docs/docs.json index baa53d83f..39e8424a8 100644 --- a/docs/docs.json +++ b/docs/docs.json @@ -1222,6 +1222,10 @@ { "source": "/open-source/features/supported-vector-dbs", "destination": "/components/vectordbs/overview" + }, + { + "source": "/open-source/multimodal-support", + "destination": "/open-source/features/multimodal-support" } ] } diff --git a/docs/llms.txt b/docs/llms.txt index 21daabcd9..9adece671 100644 --- a/docs/llms.txt +++ b/docs/llms.txt @@ -238,7 +238,6 @@ If the user is on a pre-current major (Python < 2, TS < 3, or Platform `output_f - [Reranking](https://docs.mem0.ai/open-source/features/reranking) [OSS]: Use when configuring reranking end-to-end in OSS. - [Async Memory](https://docs.mem0.ai/open-source/features/async-memory) [OSS]: Use when the self-hosted app needs `AsyncMemory`. - [OSS Multimodal Support (features)](https://docs.mem0.ai/open-source/features/multimodal-support) [OSS]: Use when handling images and PDFs self-hosted (feature guide). -- [OSS Multimodal Support](https://docs.mem0.ai/open-source/multimodal-support) [OSS]: Use when handling images and PDFs self-hosted (concept overview). - [Custom Instructions (OSS)](https://docs.mem0.ai/open-source/features/custom-instructions) [OSS]: Use when tailoring extraction prompts in OSS. - [REST API Server](https://docs.mem0.ai/open-source/features/rest-api) [OSS]: Use when exposing a self-hosted Mem0 as a FastAPI service. - [OpenAI Compatibility](https://docs.mem0.ai/open-source/features/openai_compatibility) [OSS]: Use when hitting an OpenAI-compatible endpoint with self-hosted. diff --git a/docs/open-source/features/multimodal-support.mdx b/docs/open-source/features/multimodal-support.mdx index 6bc63f20d..8b63892d8 100644 --- a/docs/open-source/features/multimodal-support.mdx +++ b/docs/open-source/features/multimodal-support.mdx @@ -14,7 +14,7 @@ Multimodal support lets Mem0 extract facts from images alongside regular text. A - Images larger than 20 MB are rejected. Compress or resize files before sending them to avoid errors. + Mem0 passes images straight to your configured vision model, so per-image size and resolution limits come from that provider (for example, OpenAI caps images at 20 MB). Compress or resize large files to stay within your provider's limits and keep processing fast. --- @@ -49,6 +49,10 @@ Multimodal support lets Mem0 extract facts from images alongside regular text. A ``` + + `vision_details` maps to the vision model's image `detail` setting and accepts `"auto"` (the default), `"low"`, or `"high"`. Use `"high"` for dense images like receipts or documents; `"low"` is faster and cheaper for simple photos. + + ### Add image messages from URLs @@ -161,7 +165,7 @@ await client.add(messages, { userId: "alice" }); - Keep base64 payloads under 5 MB to speed up uploads and avoid hitting the 20 MB limit. + Smaller images upload and process faster. Compress or resize before encoding to base64, and check your vision provider's per-image size limit for large files. --- @@ -234,7 +238,6 @@ client.add(messages, user_id="user123") ```python Python from mem0 import Memory -from mem0.exceptions import ValidationError client = Memory() @@ -250,10 +253,12 @@ try: client.add(messages, user_id="user123") print("Image processed successfully") -except ValidationError as exc: - print(f"Image validation error: {exc}") +except ValueError as exc: + # Raised when an image_url part is missing its url + print(f"Invalid image message: {exc}") except Exception as exc: - print(f"Unexpected error: {exc}") + # Raised when the image can't be downloaded or the vision model call fails + print(f"Could not process image: {exc}") ``` ```ts TypeScript @@ -273,13 +278,8 @@ try { await client.add(messages, { userId: "user123" }); console.log("Image processed successfully"); } catch (error: any) { - if (error.type === "invalid_image") { - console.log("Invalid image format or corrupted file"); - } else if (error.type === "file_size_exceeded") { - console.log("Image file too large"); - } else { - console.log(`Unexpected error: ${error.message}`); - } + // A missing image_url, a failed download, or a vision model error surfaces here + console.log(`Could not process image: ${error.message}`); } ``` @@ -313,10 +313,10 @@ try { | Issue | Cause | Fix | | --- | --- | --- | -| Upload rejected | File larger than 20 MB | Compress or resize before sending. | +| Upload rejected | Image exceeds your vision provider's size limit | Compress or resize before sending. | | Memory missing image data | Low-quality or blurry image | Retake the photo with better lighting. | | Invalid format error | Unsupported file type | Convert to JPEG or PNG first. | -| Slow processing | High-resolution images | Downscale or compress to under 5 MB. | +| Slow processing | High-resolution images | Downscale or compress to under 5 MB. | | Base64 errors | Incorrect prefix or encoding | Ensure `data:image/;base64,` is present and the string is valid. | --- diff --git a/docs/open-source/features/reranker-search.mdx b/docs/open-source/features/reranker-search.mdx index 91fd71fdf..e1d747a0e 100644 --- a/docs/open-source/features/reranker-search.mdx +++ b/docs/open-source/features/reranker-search.mdx @@ -32,11 +32,11 @@ Reranker-enhanced search adds a second scoring pass after vector retrieval so Me - - **[Cohere](/components/rerankers/models/cohere)** – Multilingual hosted reranker with API-based scoring. - - **[Sentence Transformer](/components/rerankers/models/sentence_transformer)** – Local Hugging Face cross-encoders for GPU or CPU. - - **[Hugging Face](/components/rerankers/models/huggingface)** – Bring any hosted or on-prem reranker model ID. - - **[LLM Reranker](/components/rerankers/models/llm_reranker)** – Use your preferred LLM (OpenAI, etc.) for prompt-driven scoring. - - **[Zero Entropy](/components/rerankers/models/zero_entropy)** – High-quality neural reranking tuned for retrieval tasks. + - **[Cohere](/components/rerankers/models/cohere)**: Multilingual hosted reranker with API-based scoring. + - **[Sentence Transformer](/components/rerankers/models/sentence_transformer)**: Local Hugging Face cross-encoders for GPU or CPU. + - **[Hugging Face](/components/rerankers/models/huggingface)**: Bring any hosted or on-prem reranker model ID. + - **[LLM Reranker](/components/rerankers/models/llm_reranker)**: Use your preferred LLM (OpenAI, etc.) for prompt-driven scoring. + - **[Zero Entropy](/components/rerankers/models/zero_entropy)**: High-quality neural reranking tuned for retrieval tasks. | Provider | Latency | Quality | Cost | Local deploy | diff --git a/docs/open-source/multimodal-support.mdx b/docs/open-source/multimodal-support.mdx deleted file mode 100644 index c9d7f9ee8..000000000 --- a/docs/open-source/multimodal-support.mdx +++ /dev/null @@ -1,269 +0,0 @@ ---- -title: Multimodal Support -description: "Enable multimodal support in Mem0 to process images alongside text and extract visual information into memory." -icon: "image" -iconType: "solid" ---- - -Mem0 extends its capabilities beyond text by supporting multimodal data, including images. You can seamlessly integrate images into your interactions, allowing Mem0 to extract pertinent information from visual content and enrich the memory system. - -## How It Works - -When you provide an image, Mem0 processes it to extract textual information and relevant details, which are then added to your memory. This feature enhances the system's ability to understand and remember details based on visual inputs. - - -To enable multimodal support, you must set `enable_vision = True` in your configuration. The `vision_details` parameter can be set to "auto" (default), "low", or "high" to control the level of detail in image processing. - - - -```python Code -from mem0 import Memory - -config = { - "llm": { - "provider": "openai", - "config": { - "enable_vision": True, - "vision_details": "high" - } - } -} - -client = Memory.from_config(config=config) - -messages = [ - { - "role": "user", - "content": "Hi, my name is Alice." - }, - { - "role": "assistant", - "content": "Nice to meet you, Alice! What do you like to eat?" - }, - { - "role": "user", - "content": { - "type": "image_url", - "image_url": { - "url": "https://www.superhealthykids.com/wp-content/uploads/2021/10/best-veggie-pizza-featured-image-square-2.jpg" - } - } - }, -] - -# Calling the add method to ingest messages into the memory system -client.add(messages, user_id="alice") -``` - -```typescript TypeScript -import { Memory, Message } from "mem0ai/oss"; - -const client = new Memory(); - -const messages: Message[] = [ - { - role: "user", - content: "Hi, my name is Alice." - }, - { - role: "assistant", - content: "Nice to meet you, Alice! What do you like to eat?" - }, - { - role: "user", - content: { - type: "image_url", - image_url: { - url: "https://www.superhealthykids.com/wp-content/uploads/2021/10/best-veggie-pizza-featured-image-square-2.jpg" - } - } - }, -] - -await client.add(messages, { userId: "alice" }) -``` - -```json Output -{ - "results": [ - { - "memory": "Name is Alice", - "event": "ADD", - "id": "7ae113a3-3cb5-46e9-b6f7-486c36391847" - }, - { - "memory": "Likes large pizza with toppings including cherry tomatoes, black olives, green spinach, yellow bell peppers, diced ham, and sliced mushrooms", - "event": "ADD", - "id": "56545065-7dee-4acf-8bf2-a5b2535aabb3" - } - ] -} -``` - - -## Image Integration Methods - -Mem0 allows you to add images to user interactions through two primary methods: by providing an image URL or by using a Base64-encoded image. Below are examples demonstrating each approach. - -### Using an Image URL (Recommended) - -You can include an image by passing its direct URL. This method is simple and efficient for online images. - - -```python -# Define the image URL -image_url = "https://www.superhealthykids.com/wp-content/uploads/2021/10/best-veggie-pizza-featured-image-square-2.jpg" - -# Create the message dictionary with the image URL -image_message = { - "role": "user", - "content": { - "type": "image_url", - "image_url": { - "url": image_url - } - } -} -``` - -```typescript TypeScript -import { Memory, Message } from "mem0ai/oss"; - -const client = new Memory(); - -const imageUrl = "https://www.superhealthykids.com/wp-content/uploads/2021/10/best-veggie-pizza-featured-image-square-2.jpg"; - -const imageMessage: Message = { - role: "user", - content: { - type: "image_url", - image_url: { - url: imageUrl - } - } -} - -await client.add([imageMessage], { userId: "alice" }) -``` - - -### Using Base64 Image Encoding for Local Files - -For local images or scenarios where embedding the image directly is preferable, you can use a Base64-encoded string. - - -```python Python -import base64 - -# Path to the image file -image_path = "path/to/your/image.jpg" - -# Encode the image in Base64 -with open(image_path, "rb") as image_file: - base64_image = base64.b64encode(image_file.read()).decode("utf-8") - -# Create the message dictionary with the Base64-encoded image -image_message = { - "role": "user", - "content": { - "type": "image_url", - "image_url": { - "url": f"data:image/jpeg;base64,{base64_image}" - } - } -} -``` - -```typescript TypeScript -import { Memory, Message } from "mem0ai/oss"; - -const client = new Memory(); - -const imagePath = "path/to/your/image.jpg"; - -const base64Image = fs.readFileSync(imagePath, { encoding: 'base64' }); - -const imageMessage: Message = { - role: "user", - content: { - type: "image_url", - image_url: { - url: `data:image/jpeg;base64,${base64Image}` - } - } -} - -await client.add([imageMessage], { userId: "alice" }) -``` - - -### OpenAI-Compatible Message Format - -You can also use the OpenAI-compatible format to combine text and images in a single message: - - -```python Python -import base64 - -# Path to the image file -image_path = "path/to/your/image.jpg" - -# Encode the image in Base64 -with open(image_path, "rb") as image_file: - base64_image = base64.b64encode(image_file.read()).decode("utf-8") - -# Create the message using OpenAI-compatible format -message = { - "role": "user", - "content": [ - { - "type": "text", - "text": "What is in this image?", - }, - { - "type": "image_url", - "image_url": {"url": f"data:image/jpeg;base64,{base64_image}"}, - }, - ], -} - -# Add the message to memory -client.add([message], user_id="alice") -``` - -```typescript TypeScript -import { Memory, Message } from "mem0ai/oss"; - -const client = new Memory(); - -const imagePath = "path/to/your/image.jpg"; - -const base64Image = fs.readFileSync(imagePath, { encoding: 'base64' }); - -const message: Message = { - role: "user", - content: [ - { - type: "text", - text: "What is in this image?", - }, - { - type: "image_url", - image_url: { - url: `data:image/jpeg;base64,${base64Image}` - } - }, - ], -} - -await client.add([message], { userId: "alice" }) -``` - - -This format allows you to combine text and images in a single message, making it easier to provide context along with visual content. - -By utilizing these methods, you can effectively incorporate images into user interactions, enhancing the multimodal capabilities of your Mem0 instance. - -If you have any questions, please feel free to reach out to us using one of the following methods: - - diff --git a/docs/templates/concept_guide_template.mdx b/docs/templates/concept_guide_template.mdx index 07e396d96..f652a517b 100644 --- a/docs/templates/concept_guide_template.mdx +++ b/docs/templates/concept_guide_template.mdx @@ -43,8 +43,8 @@ icon: "lightbulb" ## Key terms -- **[Term]** – [Short definition] -- **[Term]** – [Short definition] +- **[Term]**: [Short definition] +- **[Term]**: [Short definition] {/* Optional: delete if not needed */} ```mermaid diff --git a/docs/templates/cookbook_template.mdx b/docs/templates/cookbook_template.mdx index 02cd33340..ce84fa87a 100644 --- a/docs/templates/cookbook_template.mdx +++ b/docs/templates/cookbook_template.mdx @@ -89,7 +89,7 @@ Expected output (Python): `[describe inline]` · Expected output (TypeScript): [One sentence on why the result is unacceptable.] -## Fix It – [Solution Name] +## Fix It: [Solution Name] [Explain the fix and why it helps.] @@ -115,7 +115,7 @@ Expected output (Python): `[describe inline]` · Expected output (TypeScript): [Highlight the improvement + remaining gap if any.] -## Build On It – [Second Layer] +## Build On It: [Second Layer] [Add another enhancement, e.g., metadata filters, rerankers, batching.] diff --git a/docs/templates/feature_guide_template.mdx b/docs/templates/feature_guide_template.mdx index 333782404..fc502f88b 100644 --- a/docs/templates/feature_guide_template.mdx +++ b/docs/templates/feature_guide_template.mdx @@ -15,7 +15,7 @@ Use this when you introduce or deepen a single Mem0 capability (Graph Memory, Ad ## Start → Middle → End Pattern -### 1. **Start – Why this feature exists** +### 1. **Start: Why this feature exists** - Frontmatter stays outcome-driven: `title`, `description`, `icon`, optional `badge` (e.g., “Advanced”). - Opening paragraph = two sentences: problem, then payoff. Keep energy high right from the start. - Include an `` block titled “You’ll use this when…” with 3 bullets (user persona, workload, expected benefit). @@ -24,15 +24,15 @@ Use this when you introduce or deepen a single Mem0 capability (Graph Memory, Ad - Optional but encouraged: add a Mermaid diagram right after the intro to show how components connect; delete it if the story is obvious without visuals. - Add a `## Configure access` snippet (even if it’s “Confirm your Mem0 API key is already configured”) so contributors never forget to mention the baseline setup. -### 2. **Middle – How it works** +### 2. **Middle: How it works** - Create three predictable sections: - 1. **Feature anatomy** – Diagram or bullet list of moving parts. Use a table if you need to compare modes (platform vs OSS). - 2. **Configure it** – Step-by-step enabling instructions with `` or JSON/YAML snippets. Follow each code block with a short explanation of why it matters. - 3. **See it in action** – End-to-end example (often reusing operation snippets). Pair code with `` for expected results and `` for optimization hints. + 1. **Feature anatomy**: Diagram or bullet list of moving parts. Use a table if you need to compare modes (platform vs OSS). + 2. **Configure it**: Step-by-step enabling instructions with `` or JSON/YAML snippets. Follow each code block with a short explanation of why it matters. + 3. **See it in action**: End-to-end example (often reusing operation snippets). Pair code with `` for expected results and `` for optimization hints. - Insert `` blocks for cross-links (e.g., “Also available via REST endpoint `/v1/...`”). - Keep the tone instructive but light. No long manifestos. -### 3. **End – Evaluate and go deeper** +### 3. **End: Evaluate and go deeper** - Add an `## Verify the feature is working` section with bullets (metrics, logs, dashboards). - Follow with `## Best practices` or `## Tuning tips` (3–4 bullets max). - Close with the standard two-card CTA pair: left card = related concept or architecture page, right card = cookbook/application. Keep the comment reminder to double-check links.