像是上下文压缩
milvus & mysql & redis
感觉就是套了一层大模型的壳
记忆
知识库检索：RAG
使用哈希去重
为什么需要记忆
解决大模型"健忘"的根本问题
没有记忆的缺点
-
上下文稀释
- 重要信息被淹没在冗余中
-
注意力退化
- 模型难以聚集关键点
-
性能问题
- 上下文越长，速度越慢，成本越高
记忆如何存储
储存：文本 vs 张量
文本记忆 (工程化方法)
- 人类可读、可审计、可编辑
- 高度的可移植性
- 为 GPT-4 构建的记忆库可被 Claude 使用
- 系统具有可观测性
- 易于调试和编辑
- 数据所有权清晰
张量记忆 (模型内化方法)
- 高维、压缩的数学表示
- 对人类来说是不透明的表示
- 难以直接编辑
- 深度绑定于特定模型架构
- 理论上具有更高效率
- 与模型原生表示兼容
实现路径
-
模型内化记忆
- 从根本上改造Transformer 架构，使其本身具备可读写的、持久化的内部状态。
-
应用层工程化
- 将LLM 视为无状态的“处理单元”，在其外部构建完整的记忆系统。开发者通过各种工程技术来管理和编排输入到模型上下文窗口中的信息。
业界方案
类RAG 记忆框架：这三种方案都在"怎么记得更结构化"上下功夫。Mem0靠Embedding，Zep靠图谱，LangGraph让模型自己画知识图。这其实都还是数据数据库层的记忆
Agent Memory:让模型'主动记‘
这些方案的想法都很有趣：Letta让模型自己写日记，SuperMemory靠提示更新记忆，而MemOS则是在构建一个AI的"记忆管理系统"，让模型能像人一样分类保存信息
问题分析
试图让LLM 自主决定——"什么是重要的？" "什么可以被遗忘？" "何时该更新记忆？"
模型主观性问题 • 模型对"重要性"的判断主观且不可解释。
• 记忆更新逻辑若交由模型，可能强化偏见或误删关键信 息。
对问题复杂度的忽视 • 试图用封闭域解决开放域问题 • 现实世界的记忆管理需规则、权限与共识
📌有没有一种说法，大模型就像是接口，而记忆就是数据库。
想要大规模应用在生产，即使企业级的服务，那么就得部署多台。
从工程上来说，得是无状态的，如果你跟我的混淆了，那就是数据泄露问题。
所以现在的卡点，或者说方向就是，怎么做好记忆，怎么检索记忆。
而效果方面，则有py的人来实现。
都在用封闭域的解决方案试图解决开放域的问题
封闭域解决方案的特点
预设固定的规则和模式
适用于边界清晰、规则明确的场景
模型可以基于有限的选择做决策
开放域问题的复杂性
用户需求千变万化，无法预设所有情况
不同用户对 “重要性” 的定义完全不同
上下文依赖性强，需要动态判断
现有方案的局限
- Mem0、Zep 等试图用固定算法判断信息重要性
- 忽视了记忆管理本质上是个性化、主观的过程
- 缺乏用户参与和控制机制
为什么这种方法行不通
- 记忆的价值判断需要人类的价值观和目标导向
- 不同应用场景需要不同的记忆策略
- 一刀切的解决方案无法满足多样化需求
dify之把选择权交给用户
Memory Orchestration 解决方案：
提供一种产品化的记忆调度方式，让模型能自主遗忘不重要的信息、只保留重要且相关的知识，同时让"什么是重要的"这类判断权交还给用户与系统设计者
开发者设定规则，模型自动执行 • 模型根据策略自动删改记忆 • 用户定义"重要性标准""更新频率""保留策略
记忆类型
- Disabled：不支持记忆，单轮对话
- Liner：传统的线性记忆，滑动窗口呗，最长上下文论数
- Memory Block：记忆以文本的形式被存储在会话变量中，这个变量会随着聊天而被自动更新，仅保留用户话题聊天主题相关的内容，最重要的是，用户可以决定模型应该记住什么，忘记什么
详细介绍
- 侧栏实时预览Memory 状态，可成为会话"产出物"（如行程草案）
- 支持用户修改并版本回退/切换（携带版本概念）
- Every N turns：每经过N 轮，系统会更新一次Memory
哈啰技术方案
*两阶段事务模板*
先执行mysql操作，再执行milvus
milvus失败时回滚MySQL
📌核心：先把数据库的数据进行一个备份，然后再
