issue: memories injected without relevance selection, and auto-truncated mid-memory

问题场景

用户在 Docker 中运行 Open WebUI v0.12.3，启用记忆功能并长期使用后，user 类型记忆总量超过 2000 字符。此后每次发送聊天消息，发往模型的 system prompt 中 [User Memory] 区块都会在字符上限处被直接切断，后面的记忆完全消失；同时记忆库持续增长（报告中达到 209 条、约 102K 字符），记忆向量检索和后台审查提示词随之变差、变长。

报错原文

issue: memories injected without relevance selection, and auto-truncated mid-memory

该 Issue 没有抛出异常或日志报错，问题表现为注入内容被静默截断，模型中看到的只是被截断的片段，且没有任何“已丢弃记忆”的提示。

原因分析

最可能的原因是 backend/open_webui/utils/memory.py 中的 add_memory_context：它把所有 user 类型记忆拼进同一个 section 字符串，随后用 [:user_limit] 按字符直接切片。因此截断点会落在某条记忆的文本中间，后续记忆整体丢失，既没有按记忆边界丢弃整条记录，也没有告诉用户或模型有内容被省略。另外，代码对 context 类型记忆做了 top-k 语义选择，但 user 类型记忆是每轮全量注入，没有相关性筛选。

存储侧同样没有收敛机制：无衰减、无去重强制、无压缩或清理告警，导致记忆库无界增长，进而拖累语义检索、后台审查提示词（最多列出 80 条已有记忆）以及模型可见的记忆工具。以上基于 Issue 描述与代码位置，属于对根因的推断，尚未有官方修复确认。

环境排查

• 确认 Open WebUI 版本是否为 v0.12.3，以及在当前 dev 分支上是否仍可复现。
• 确认部署方式为 Docker，并核对实际加载的镜像版本。
• 确认记忆功能已启用，并查看 memories.user_char_limit 的当前值（默认 2000 字符）。
• 统计 user 类型记忆的条数与总字符数，判断是否已超过该上限。
• 检查 add_memory_context 所在文件的实现，确认是否仍是对拼接后的字符串执行字符切片。
• Issue 未涉及 Ollama、CUDA、显卡或 PyTorch 版本，无需作为本次排查重点。

解决步骤

1. 复现确认：启用记忆后，创建总长度超过 memories.user_char_limit 的 user 类型记忆（例如 15 条约 200 字符），发送任意聊天消息，检查发往模型的 system prompt（可通过代理抓取），确认 [User Memory] 区块是否在中间被切断、截断点之后的记忆是否缺失。
2. 确认代码路径：定位 backend/open_webui/utils/memory.py 中的 add_memory_context，核对 user 类型记忆是否被整体拼接到一个 section 后以 [:user_limit] 截断，且没有按记忆边界处理。
3. 缓解存储膨胀：手动整理 or 删除旧的 user 类型记忆，把总量压回字符上限以内，避免注入块继续被截断。这只是临时缓解，不能解决注入逻辑本身的问题。
4. 关注关联讨论：跟踪 Issue #30235（按相关性、按整条记忆裁剪注入上下文）和 #30234（为注入记忆设置独立的相关性阈值），判断是否已有可用的修复或合并到 dev 的改动。
5. 若需自行修改，可优先尝试（未在 Issue 中验证）：在拼接前对 user 记忆按相关性排序并逐条累加，超限时丢弃整条记忆，而不是对拼接字符串做字符切片；同时保留向用户或模型提示“部分记忆被省略”的能力。

验证方法

重新发送聊天消息并检查 system prompt：[User Memory] 区块应结束在完整记忆的边界上，不再出现半句话；若发生省略，应能看到明确提示。若同时清理了记忆库，可再统计 user 记忆总量，确认已低于字符上限，并观察记忆检索与后台审查提示词的长度是否恢复正常。

参考来源

open-webui/open-webui #32753

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。