Skip to content

Commit aefafae

Browse files
authored
Update mem_production.md
1 parent 905d155 commit aefafae

File tree

1 file changed

+68
-21
lines changed

1 file changed

+68
-21
lines changed

content/cn/memos_cloud/introduction/mem_production.md

Lines changed: 68 additions & 21 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
---
22
title: 记忆生产
3-
desc: 记忆生产模块将原始消息或事件转化为可存储、可检索的记忆单元,作为MemOS全流程的起点。
3+
desc: 记忆生产模块将原始消息、事件或知识转化为可存储、可检索的记忆单元,作为MemOS全流程的起点。
44
---
55

66
::warning
@@ -13,40 +13,32 @@ desc: 记忆生产模块将原始消息或事件转化为可存储、可检索
1313

1414
## 1. 能力介绍:为什么要将原始消息加工为记忆
1515

16-
在 MemOS 里,你提交的是 **原始信息**(用户与 AI 的对话、用户在APP上的操作日志 / 行动轨迹等),系统会自动完成“记忆化”的过程。
16+
在 MemOS 里,你提交的是 **原始信息**(用户与 AI 的对话、用户在APP上的操作日志 / 行动轨迹、知识库文档等),系统会自动完成“记忆化”的过程。
1717

1818
::note{icon="ri:triangular-flag-fill"}
1919
**为什么要进行记忆加工?**
2020
::
2121

22-
如果只是简单地把原始对话全部保存,再次使用时直接丢给大模型,会出现几个问题:
22+
如果只是简单地把原始信息全部保存,再次使用时直接丢给大模型,会出现几个问题:
2323

24-
- **上下文过长**原始消息往往冗长、重复,把整段上下文都传给模型既低效,又浪费 Token;
25-
- **检索不精准**没有加工的原始文本难以快速定位关键信息,检索往往会召回大量噪音
26-
- **调用成本高**直接拼接原始消息会显著增加模型输入长度,带来 Token 成本和延迟
24+
- **上下文过长**原始信息通常冗长且包含大量重复与无关内容,整段传入模型会显著拉长上下文窗口,处理效率低且浪费 Token;
25+
- **检索不精准**未经结构化与抽取的原始文本难以突出对话中的关键信息,检索时容易召回大量噪音内容,影响回答质量
26+
- **体验不连续**原始对话是一次性的静态文本,无法感知用户偏好与情感、业务背景与规则的变化,造成连续对话的体验偏差
2727

2828
<br>
2929

3030
::note
31-
**加工后有什么不同**
31+
**MemOS 加工后的记忆是什么**
3232
::
3333

3434
MemOS 会把原始消息转化为结构化记忆单元,自动提炼:
3535

36-
- **关键事实**如“用户在旅行时通常是全家出游(带孩子和父母)”;
37-
- **任务线索**:提炼出用户的目标意图,比如“规划一次家庭旅游”,而不仅仅是“暑假出去玩”。
36+
- **关键事实**
37+
- 提炼用户对话中的事实信息,如“用户计划在2025年暑假期间前往广州旅游。”;
3838
- **用户偏好**
39-
- 不仅是显式表述(“我喜欢全家出游”),还包括隐含的推理范式。
40-
- 例如,如果用户在 让AI给10 篇文章评分过程中,展现出“偏向逻辑清晰的写法”,那么在未来的 20 篇文章评分任务中,MemOS 会保留这种偏好模式,引导模型保持一致性;
41-
42-
<br>
43-
44-
这样一来:
45-
46-
- **检索更快更准**:直接定位到事实 / 偏好 / 任务,而不是一整段原始消息。
47-
- **调用更高效**:拼接给大模型时只需传递精炼记忆,减少 Token 消耗。
48-
- **体验更稳定**:模型能持续保持对用户习惯的理解,不会因上下文丢失而偏离。
49-
39+
- 提炼用户对话中显式的偏好表述,例如“用户提到喜欢全家出游”;
40+
- 提炼用户对话中隐含的推理范式,例如“用户可能偏好性价比高的酒店选择”;
41+
- MemOS 会保留用户的偏好模式,引导模型在后续回答中保持一致性。例如,当用户在使用 AI 辅助写作时,展现出“偏向逻辑清晰的写法”,那么 MemOS 会继续引导模型在其他任务中,保持“逻辑性的写作手法”。
5042

5143
<br>
5244

@@ -68,6 +60,61 @@ Reasoning: 七天酒店通常以经济实惠著称,而用户选择七天酒店
6860

6961
> 对你来说,这意味着:只要存原始对话,不必自己写“关键词提取”或“意图识别”的逻辑,就能得到可被长期调用的用户偏好。
7062
63+
<br>
64+
65+
除了文本对话消息,针对 Agent 任务执行的过程,MemOS 适配了工具记忆、技能:
66+
- **[工具记忆(tool memory)](/memos_cloud/features/advanced/tool_calling)**
67+
- 提炼 Agent 任务执行过程中的工具调用信息为记忆,记录工具类型、使用场景与调用结果特征,用于后续相似任务的工具优先选择。
68+
- **[技能(Skills)](/memos_cloud/features/advanced/skill)**
69+
- 提炼用户对话,生成可复用的执行能力。
70+
- 例如,从多轮关于“生成旅行规划”的对话中,提炼出包含目的地分析、行程拆分、预算约束的可执行“旅行规划技能”,而不仅仅再是“用户喜欢特种兵旅行”这样供模型推理参考的记忆。
71+
72+
此外,MemOS 还支持基于[知识库](/memos_cloud/features/advanced/knowledge_base)[多模态消息](/memos_cloud/features/basic/multimodal)的记忆加工哦!
73+
74+
<br>
75+
76+
::note
77+
**记忆是如何被加工的?**
78+
::
79+
80+
MemOS 始终认为记忆不是静态的记录,而是随时间演化的对象,它需要快速、准确、连续地记住用户。
81+
<br>
82+
为了更好地处理记忆的三角问题:实时性、准确性、一致性,MemOS 把记忆加工的全流程拆分为以下三个阶段:
83+
| 阶段 | 目标 | 特点 |
84+
| ---- | --------- | -------------------------------------------------------------------- |
85+
| Fast | 不丢记忆 | 原文简单处理并快速入库,耗时毫秒级,下一轮对话即可检索到。 |
86+
| Fine | 近程组织 | 回溯当前上下文及历史记忆,如发现冲突,会在原 Memory ID 上生成新版本。 |
87+
| Offline | 全局组织 | 定期长程回溯,修正早期未识别的冲突,保持整体一致性。 |
88+
89+
形成的结果不是两条冲突记忆,而是:**同一个 Memory ID 的 V1 / V2 / V3… 时间演化链**
90+
91+
<br>
92+
93+
**例子**
94+
95+
```json
96+
# 假设是2025年
97+
User: 我是小忆,现在在上海居住,不太能吃辣。
98+
99+
# 假设是2026年
100+
User: 最近我搬去成都了,突然爱上四川火锅,喜欢辣锅!
101+
```
102+
103+
```json
104+
V1版本记忆:用户叫小忆,在上海居住,不能吃辣
105+
V2版本记忆:用户叫小忆,在成都居住,喜欢吃辣,喜欢四川火锅。
106+
```
107+
108+
>这样,同一条记忆能够随时间演化,既能给出“可依赖的当前认知”,同时保留完整的历史轨迹。
109+
110+
<br>
111+
112+
这样一来,我们解决了最初提到的问题:
113+
- **调用更高效**:拼接给大模型时只需传递精炼记忆,减少 Token 消耗。
114+
- **检索更快更准**:直接定位到事实 / 偏好 / 工具 / 技能记忆,而不是一整段原始消息。
115+
- **体验更稳定**:模型能持续保持对用户习惯的理解,不会因上下文丢失而偏离。
116+
117+
<br>
71118

72119
## 2. 进阶:如果你想做深度定制
73120

@@ -78,7 +125,7 @@ Reasoning: 七天酒店通常以经济实惠著称,而用户选择七天酒店
78125
| 抽取与结构化 | 默认会生成 MemoryItem(包含内容、时间戳、来源等) | 可以替换抽取模型或模板,或在 schema 中增加领域字段 |
79126
| 切分与嵌入 | 系统会对长文本切分并送入嵌入模型 | 可以调整切分粒度,或替换为更适合的 embedding 模型(如 bge、e5) |
80127
| 存储后端 | 默认使用向量数据库(如 Qdrant) | 可切换为图数据库,或混合使用两者 |
81-
| 合并与治理 | 系统会自动处理重复与冲突 | 可以编写自定义规则(如时间优先、来源优先),或增加治理逻辑(去重、过滤等) |
128+
| 合并与治理 | 系统会自动处理重复与冲突 | 可以编写自定义规则(如时间优先、来源优先) |
82129

83130

84131
## 3. 下一步行动

0 commit comments

Comments
 (0)