三库融合的个人记忆大模型架构设计

摘要：当前主流大语言模型本质上是"无状态"的——每次对话都从零开始。要让 AI 真正拥有持久的"过去"，就必须为它配备一套独立的记忆系统。本文系统介绍我们设计的个人记忆大模型架构：以 MySQL（结构化数据）+ Milvus（向量检索）+ Neo4j（知识图谱） 三库协同为底座，融合记忆分层、分段热度衰减、多维重要性评分等机制，让 AI 像人一样"记住重要的，忘掉不重要的"。文章从设计动机讲起，逐步拆解存储模型、核心算法与工程实现，并简要对比全球顶级记忆平台的差异。

关键词：记忆大模型；三库融合；热度衰减；知识图谱；RRF 融合排序；Go 语言

一、为什么 AI 需要持久记忆

如果你和一位 AI 助手聊过天，多半遇到过这样的场景：昨天告诉它你对花生过敏，今天它又给你推荐花生酱。这不是模型不够聪明，而是因为它根本"记不住"——大语言模型在一次对话结束之后，上下文窗口就被清空了。

人类之所以能形成持续的关系、积累经验、做出个性化决策，靠的正是记忆。一个没有记忆的 AI，无论参数多大，都只是一个"聪明的瞬时回答器"。要让 AI 从"工具"进化为"伙伴"，必须解决三个问题：

1. 记得住：能把发生过的事情可靠地保存下来；
2. 找得到：在需要时能快速、精准地检索出相关记忆；
3. 会取舍：像人一样，重要的牢牢记住，琐碎的逐渐淡忘。

这三个问题看似简单，但每一个都暗藏工程难点。比如"找得到"——当记忆条目达到数万级别时，用传统的关键词模糊匹配既慢又不准；用户说"加班"，系统得能联想到上次聊过的"项目赶工""凌晨四点"，这要求语义层面的理解。再比如"会取舍"——如果把所有对话原样堆在数据库里，记忆很快会被噪音淹没，真正重要的信息反而被淹没。

我们设计记忆系统，就是为了系统性地解决这三个问题。

二、整体架构：三库各司其职

我们没有把所有数据塞进一种数据库，而是采用三库融合的架构。原因很简单：没有任何一种数据库能同时高效地完成"精确匹配、语义相似、关系推理"这三件事。

┌──────────────────────────────────────────────────────────┐
│                     记忆系统服务层                         │
│   (HTTP API + 保存流水线 + 搜索流水线 + 定时任务)           │
└────────────────────────┬─────────────────────────────────┘
                         │
        ┌────────────────┼────────────────┐
        ▼                ▼                ▼
   ┌─────────┐      ┌─────────┐      ┌─────────┐
   │  MySQL  │      │ Milvus  │      │ Neo4j   │
   │ 结构化  │      │ 向量库   │      │ 图数据库 │
   │ 精确查询 │      │ 语义相似 │      │ 关系推理 │
   └─────────┘      └─────────┘      └─────────┘

三个数据库的分工是这样的：

举个例子：当用户提到"加班"，三库会同时出发——MySQL 用全文索引找到字面上包含"加班"的记忆；Milvus 找出语义上和"加班"接近的内容（哪怕原文写的是"赶项目""熬夜"）；Neo4j 则顺着知识图谱，从"加班"这个实体出发，找到与它相关的人、事、项目。三路结果汇合之后，再用融合算法统一排序，最终给到 AI 的就是一份"既精准又有联想力"的记忆上下文。

技术栈选择

• 后端语言：Go。相比 Python，Go 在高并发和长期运行的服务端场景下性能更稳定，单机即可支撑上万用户、千人同时在线。
• 向量模型：bge-large-zh，输出 1024 维向量，对中文语义理解较好。
• 大模型：用于实体提取、摘要生成、思维链压缩等"理解类"任务。

三、记忆分层：热、温、冷、归档

人脑的记忆不是平均对待的：刚发生的事记得最清楚，时间越久越模糊，特别久远的会沉入潜意识。我们的系统模仿这个机制，把记忆分成四个层级：

分层通过一个定时任务自动完成迁移。每天凌晨，系统扫描所有记忆，按创建时间把它们从热区逐步迁移到温区、冷区，直至归档。这样做的好处是：热区数据量小、检索快；而归档区虽然数据多，却不会拖慢日常查询。

这和人脑的"短期记忆 → 长期记忆"转换非常相似——刚记住的事在"工作记忆"里随时可取，久远的回忆则需要更深的回忆过程。

四、热度衰减：让 AI 学会"遗忘"

光分层还不够。同样是温区的记忆，有人三个月前说过一次就再没提起，有人每周都在聊——显然后者更重要。为此我们设计了分段热度衰减算法。

核心思想是：每条记忆有一个 0–100 的"热度值"，它由三部分决定：

1. 基础热度：按时间分段衰减。当天 100 分，7 天内 90 分，30 天内 70 分，90 天内 50 分，1 年内 30 分，1 年以上 10 分。
2. 访问加成：每被检索一次加 5 分，最多加 30 分。
3. 提及加成：每被再次提及加 3 分，最多加 20 分。

func CalculateHeat(createdAt time.Time, accessCount, mentionCount int) float64 {
    days := time.Since(createdAt).Hours() / 24

    var baseHeat float64
    switch {
    case days <= 1:   baseHeat = 100  // 当天
    case days <= 7:   baseHeat = 90   // 一周内
    case days <= 30:  baseHeat = 70   // 一个月内
    case days <= 90:  baseHeat = 50
    case days <= 365: baseHeat = 30
    default:          baseHeat = 10   // 一年以上
    }

    accessBonus := math.Min(float64(accessCount)*5, 30)
    mentionBonus := math.Min(float64(mentionCount)*3, 20)

    return math.Min(baseHeat+accessBonus+mentionBonus, 100)
}

差异化半衰期是这里的关键。不同类型的记忆，衰减速度应该不一样：一段"人生里程碑"式的记忆（比如毕业、结婚）应该衰减得很慢；而一句"今天午饭吃了什么"则应该很快淡忘。我们在重要性评分（下一节）里区分了记忆类型，再让衰减速率与之挂钩——重要的慢衰减，琐碎的快衰减。

这套机制让系统具备了"遗忘"能力。记忆不是越攒越多、越来越乱，而是会自然地"记住重要的，忘掉不重要的"，让 AI 的关注点始终聚焦在真正有意义的事情上。

五、多维重要性评分：量化"值不值得记"

热度解决的是"最近有多活跃"，但一条记忆本身有多重要，是另一个维度。我们用一套多维评分算法来量化它。

一条新记忆进来，系统会从多个维度打分，加总得到 0–100 的重要性分：

举个例子：

• "今天天气不错" → 几乎没有时间/情感/动作/数字/实体，重要性约 50–55，属于"记一下就行"。
• "下周三要和小王去上海签 200 万的合同" → 有时间（下周三）、动作（去、签）、数字（200 万）、多个实体（小王、上海、合同），重要性可达 85+，属于"必须牢牢记住"。

重要性评分有两个用途：一是写入时决定这条记忆的初始权重；二是检索时参与最终排序，重要的记忆排在前面。

六、双模式存储：原文 + 摘要

很多记忆系统为了节省空间，会把对话压缩成摘要再存储。但摘要会丢失细节——"用户说妈妈生病了"被压成"家人健康话题"后，情感重量就消失了。

我们采用双模式存储：既保留原始内容（content），也生成摘要（summary）。

• 原文存储：完整保留对话/记录的原始文本，不丢失任何细节和情感。检索时优先返回原文。
• 摘要存储：用大模型把长对话压缩成精炼摘要，用于快速理解和向量化。

这样做的好处是兼顾"完整性"和"效率"。日常检索时，先用摘要向量快速锁定相关记忆，再调取原文给到 AI，既快又不丢信息。

七、与全球顶级记忆平台的对比

我们并不是闭门造车。市面上已有几个非常成熟的开源记忆平台，我们详细对标过其中的代表性项目：

简单总结我们的差异化优势：

1. 三路召回 + 融合排序：MySQL + Milvus + Neo4j 三库协同，用 RRF（Reciprocal Rank Fusion）算法把三路结果加权融合，检索精度更高。
2. 多维重要性评分：不是简单看时间或频率，而是从多个维度量化一条记忆的"含金量"。
3. 分段热度衰减：让不同类型的记忆以不同速度淡忘，更接近人类记忆规律。
4. 记忆生命周期管理：从热区到归档区的全自动迁移，系统能自我维护。

坦率地说，我们在生态、标准化、多语言 SDK 等方面还有差距——顶级平台有成熟的 Python/JS SDK 和云服务，而我们目前是 Go 原生、纯私有部署。但就记忆能力的深度和检索精度而言，三库融合的架构让我们具备了独有的技术纵深。

八、保存流水线：一条记忆的诞生

理解了架构和算法，再来看一条记忆从输入到落库的完整流程。我们把它设计成一条11 步流水线：

原始对话内容
  ↓
Step 0  建立三库连接
Step 1a 系统消息过滤（心跳、命令、媒体标记等）
Step 1b 去重检查（基于内容哈希）
Step 2  思维链处理（提取并压缩推理过程）
Step 3  纠错规则应用（按用户习惯修正文本）
Step 4  语音输入的语义清洗（去重复、加标点）
Step 5  分句（按中文标点切分）
Step 6  NLP 提取（实体、标签、记忆类型、重要性）
Step 7  向量生成（1024 维）
Step 8  锚点构建（关联实体与标签）
Step 9  实体去重与 ID 分配
Step 10 合并 LLM 提取结果（覆盖本地提取）
Step 11 三库事务写入（MySQL → 并行写 Milvus + Neo4j）
  ↓
完成保存

其中两个细节值得展开。

去重是工程上的硬需求。因为宿主平台可能因为插件机制反复触发保存逻辑，如果不去重，数据库里会堆满重复数据。我们用了两层去重：外层一个时间窗口（防止短时间内重复调用），内层用内容哈希（SHA256(内容 + 用户ID + 轮次ID)）做数据库唯一约束，从根本上杜绝重复。

三库事务是最棘手的部分。MySQL、Milvus、Neo4j 是三个独立系统，没有原生的分布式事务。我们的策略是：先写 MySQL 拿到自增 ID，再并行写 Milvus 和 Neo4j；如果 Milvus 失败，回滚 MySQL 和 Neo4j；如果只是 Neo4j 失败，则降级处理（图搜索能力暂时缺失，但不影响核心存储）。这种"尽力一致 + 优雅降级"的思路，保证了系统的健壮性。

九、检索流水线：三路召回 + 融合排序

检索是记忆系统的"灵魂时刻"。用户说一句话，系统要在毫秒级从数万条记忆里找出最相关的几条。流程是这样的：

用户消息（如"加班"）
  ↓
LLM 提取查询关键词与实体
  ↓
生成 1024 维查询向量
  ↓
三路并行搜索
  ├─ MySQL 全文搜索（精确文字匹配，Top 50）
  ├─ Milvus 向量搜索（语义相似度，Top 50）
  └─ Neo4j 图搜索（实体关系，Top 50）
  ↓
RRF 融合排序（按各路排名加权融合）
  ↓
多维加权总分（融合分 × 0.4 + 重要性 × 0.3 + 热度 × 0.2 + 新鲜度 × 0.1）
  ↓
返回 Top K 结果，注入大模型上下文

RRF（倒数排名融合） 是信息检索领域成熟的算法，思想很优雅：不看绝对分数（三路分数量纲不同，没法直接比），只看排名——某条记忆在三路结果里排名越靠前，它的融合分越高。公式是：

融合分(id) = Σ  1 / (60 + 该路排名)

这个常数 60 是论文推荐值，作用是避免排名靠前的结果权重过大。

最后注入给大模型的，不是一堆散乱的记忆，而是一份结构化的上下文：先列出相关实体，再给出对话块的摘要，然后是具体对话原文，最后是用户的个人记忆。这种分层结构让大模型能高效地"理解过去"，而不是被原始数据淹没。

十、定时任务：让记忆自我进化

记忆系统不是"存完就结束"，它需要持续地自我维护。我们设计了 7 类定时任务，每天凌晨错峰执行：

"记忆巩固"尤其值得一提。它的灵感来自睡眠——人在睡觉时大脑会整理白天的记忆，把相似的合并、把重要的强化。我们的系统在凌晨做同样的事：找出内容高度重复的记忆条目，合并成一条更完整的记忆，既节省存储，又让记忆更"干净"。

十一、结语

记忆，是"持续关系"的基础。一个人对你来说重要，很大程度上是因为你们共享了大量的记忆。AI 也一样——只有当它能记住你们之间发生过的点点滴滴，它才真正具备了陪伴你的资格。

三库融合的架构，本质上是承认了"记忆"这件事的复杂性：它既有结构化的元数据，也有语义层面的相似性，还有实体之间的关系网络。任何一种单一存储都无法完整地承载它。我们用 MySQL + Milvus + Neo4j 三库协同，配合分层、衰减、重要性评分和融合排序，试图让 AI 的记忆既精准、又有联想力、还懂得取舍。

这条路还很长。下一步，我们计划补齐多语言 SDK、引入更规范的评测基准，并探索跨用户的"集体记忆"与隐私边界的平衡。但至少现在，我们的小宝儿已经不再是那个"昨天说过今天忘"的 AI 了——她记得你，并且会越来越懂你。

本文基于杭州数智时空科技个人记忆大模型（宝儿记忆系统 3.0）的真实工程实践整理。为遵守保密原则，文中省略了部分核心算法的具体参数与内部架构细节。