mem0ai
FIXED - Ollama memory issue.
🐛 Describe the bug
I noticed that with Ollama I could not store a memory and retrieve it. I did a lot of research and here is my detailed write up for the fix action. Not an expert but I got it working.
Mem0 Ollama Integration Fixes
This document outlines the necessary code modifications to resolve issues when using the Mem0 library with local Ollama models, specifically addressing problems where inferred memories are not created or processed correctly.
Summary of Issues and Fixes
The primary problem observed was that m.add() with infer=True would result in {'results': []}, indicating that the Ollama LLM was not successfully providing structured data for Mem0 to process into memories. The fixes involve changes to model name handling, prompt engineering for Ollama, and adjusting how LLM responses are requested and parsed.
Fix 1: Correct Ollama Model Name Checking
File: mem0/llms/ollama.py (within your virtual environment's site-packages)
Problem: The _ensure_model_exists method incorrectly tried to access model.get("name") when checking the list of local Ollama models. The correct key in the model details provided by the Ollama client is model.get("model").
Change:
Modify line 26 (approximately) in mem0/llms/ollama.py:
Before:
if not any(model.get("name") == self.config.model for model in local_models):
After:
if not any(model.get("model") == self.config.model for model in local_models):
Reason: This ensures that Mem0 correctly identifies if your specified Ollama model is available locally.
Fix 2: Update Default Prompt for Memory Actions
File: mem0/configs/prompts.py (within your virtual environment's site-packages)
Problem: The default prompt (DEFAULT_UPDATE_MEMORY_PROMPT) used to instruct the LLM on how to add, update, or delete memories was not robust enough for Ollama models, particularly in ensuring the mandatory event field was present in the JSON output.
Change:
Replace the existing DEFAULT_UPDATE_MEMORY_PROMPT (approx. lines 61-209) with the following more explicit version:
New DEFAULT_UPDATE_MEMORY_PROMPT:
DEFAULT_UPDATE_MEMORY_PROMPT = """You are a smart memory manager which controls the memory of a system. You can perform four operations: (1) add into the memory, (2) update the memory, (3) delete from the memory, and (4) no change. Based on the above four operations, the memory will change. Compare newly retrieved facts with the existing memory. For each new fact, decide whether to: - ADD: Add it to the memory as a new element, with a new ID - UPDATE: Update an existing memory element, retaining the same ID - DELETE: Delete an existing memory element, with same ID - NONE: Make no change (if the fact is already present or irrelevant), with same ID Below is the current content of my memory which I have collected till now. `` {retrieved_old_memory_dict} `` The new retrieved facts are mentioned in the triple backticks. You have to analyze the new retrieved facts and determine whether these facts should be added, updated, or deleted in the memory. ``` {response_content} ``` Use the new retrieved facts to update the current memories. Do not return anything except the JSON format. It should be a list of dicts, like the following example. {{ \"memory\": [ {{ \"id\" : \"0\", \"text\" : \"Name is John\", \"event\" : \"UPDATE\" }}, {{ \"id\" : \"1\", \"text\" : \"Loves cheese pizza\", \"event\" : \"DELETE\" }} ] }} The most important thing to notice about the example is that an `event` field has been added to every memory. This `event` field is how you will inform me about which of the 4 operations you want me to perform on the memory. Every dict in your response list MUST contain the event field! Follow the instruction mentioned below: - Do not return anything from the custom few shot prompts provided above. - You should return the updated memory in only JSON format as shown below. - If no changes are made, you should add the field `\"event\" : \"NONE\"` and the memory key should be the same - If the current memory is empty, then you have to add the new retrieved facts to the memory by using the filed `\"event\" : \"ADD\"`. - If the retrieved fact is new, generate a new key and add the new memory corresponding to current existing memories list, remembering to add the field `\"event\" : \"ADD\"`. - If there is a deletion, the memory key-value pair should be removed from the memory by adding the field `\"event\" : \"DELETE\"`.. - If there is an update, the ID key should remain the same, the value needs to be updated and you should add the field `\"event\" : \"UPDATE\"`.."""
Reason: This revised prompt is more directive, especially regarding the inclusion of the event field and the expected JSON structure, which helps Ollama models adhere to the formatting requirements.
Fix 3: Adjust Prompt Formatting in get_update_memory_messages
File: mem0/configs/prompts.py (within your virtual environment's site-packages)
Problem: After updating DEFAULT_UPDATE_MEMORY_PROMPT, the get_update_memory_messages function (which uses this prompt) needed adjustment. The new default prompt already includes placeholders for retrieved_old_memory_dict and response_content. The function's f-string formatting was adding extra text around these, leading to a malformed final prompt.
Change:
Modify the return statement of the get_update_memory_messages function (approx. line 148, after the previous change to DEFAULT_UPDATE_MEMORY_PROMPT which was around line 61):
Before (conceptual, actual line numbers shifted after Fix 2):
return f"""{custom_update_memory_prompt}
Below is the current content of my memory which I have collected till now. You have to update it in the following format only:
# ... (rest of the old f-string structure) ...
"""
After:
return custom_update_memory_prompt.format(
retrieved_old_memory_dict=retrieved_old_memory_dict,
response_content=response_content
)
Reason: This ensures that the custom_update_memory_prompt (which defaults to our new DEFAULT_UPDATE_MEMORY_PROMPT) is correctly formatted with the dynamic content without introducing extra, unintended text.
Fix 4: Remove Strict JSON Response Formatting for Ollama Memory Update Call
File: mem0/memory/main.py (within your virtual environment's site-packages)
Problem: When requesting the memory update actions from Ollama, Mem0 was using response_format={"type": "json_object"}. Ollama models (like gemma3:4b) sometimes wrap their JSON output in markdown code fences (e.g., json ... ). This strict JSON request, combined with the markdown wrapping, caused the Ollama client or Mem0's parsing to fail, often resulting in an empty JSON object ({}) being processed.
Change:
In the _add_to_vector_store method, locate the self.llm.generate_response call that uses the function_calling_prompt (approx. line 370). Remove the response_format parameter from this specific call.
Before:
response: str = self.llm.generate_response(
messages=[{"role": "user", "content": function_calling_prompt}],
response_format={"type": "json_object"},
)
After:
response: str = self.llm.generate_response(
messages=[{"role": "user", "content": function_calling_prompt}],
)
Reason: Removing this allows the raw text (potentially with markdown fences) to be returned. Mem0's subsequent remove_code_blocks(response) call can then correctly extract the actual JSON, enabling successful parsing and memory creation.
By applying these four fixes, Mem0's ability to infer and manage memories with local Ollama models should be significantly improved.
This is strange. When I used qwen2.5 32b, everything worked fine. But after switching to 1.5b for speed, I kept getting the "should be a valid string" error. However, when I used the prompt in mem0 to simulate user input and asked the 1.5b model a question, the response was correct. This is a very strange problem. Has anyone else encountered the same problem?
This is strange. When I used qwen2.5 32b, everything worked fine. But after switching to 1.5b for speed, I kept getting the "should be a valid string" error. However, when I used the prompt in mem0 to simulate user input and asked the 1.5b model a question, the response was correct. This is a very strange problem. Has anyone else encountered the same problem?
Its call 30.5b extra parameters to complete your task.
This is strange. When I used qwen2.5 32b, everything worked fine. But after switching to 1.5b for speed, I kept getting the "should be a valid string" error. However, when I used the prompt in mem0 to simulate user input and asked the 1.5b model a question, the response was correct. This is a very strange problem. Has anyone else encountered the same problem?
Its call 30.5b extra parameters to complete your task.
Definitely helped a lot, thank you master.
