大模型需要什么样的记忆？短期记忆与长期记忆在图数据库中怎么存

同一个用户第三次问起同一件事，系统的反应和第一次完全一样——不是答错，是根本没有察觉这个问题被问过。这是当下企业级 AI 应用最普遍的体验缺陷：模型能力在涨，记忆能力没跟上。多数团队把记忆理解成把历史对话多塞一点进上下文窗口，结果是上下文越塞越长、成本越滚越高，而真正该记住的那件事——这个客户上季度已经明确否决过分期方案——依然找不回来。大模型需要的不是更长的上下文，而是有结构的记忆：短期记忆管当前任务的连贯，长期记忆管跨会话的事实沉淀，而两者要共存于同一个体系，承载它们的存储形态就很关键，这正是图数据库的用武之地。本文拆解两类记忆的分界线、记忆的图建模方式、衰减与冲突的处理规则，以及落地路径。

一、上下文窗口不是记忆：三种常见做法的失效点

第一个问题先要厘清：为什么把历史对话塞进上下文不算记忆。上下文是模型的临时工作区，会话一结束就清空，而记忆的本质是跨会话留存并能在需要时被准确取回。两者的要求完全不同，用前者替代后者的团队，通常落到三种做法上，也各自撞上三堵墙。

第一种，全量塞入上下文。把历史对话按时间顺序全部拼进提示词。看起来不用改造任何系统，实际有两个死结：上下文长度有硬上限，且模型对长上下文中段内容的注意力会明显衰减——关键事实夹在一百轮对话中间，等于半丢失状态。成本还会随轮次线性上涨。

第二种，把对话切片存进向量库。按语义相似度召回旧对话。它找回的是措辞相似的片段，不是关于某个对象的完整记忆。同一件事分散在七八次对话里，向量检索不会主动把它们串成一条线索，更不会告诉你哪一条是最新的。

第三种，写进业务系统的字段。记在工单备注、CRM 客户卡片里。人可读、可审计，但没有一项是机器能直接拿去推理的——模型无法在一次问答里自然地做一次跨表关联，把散落在三个模块里的记忆拼起来。

二、短期记忆与长期记忆的分界线在哪

两类记忆经常被混为一谈，实际它们服务的对象完全不同。短期记忆服务的是这一轮任务：用户刚说的条件、刚刚查到的中间结果、本轮会话的主题指向。它的生命周期就是会话本身，会话结束即释放。长期记忆服务的是这个对象的历史：客户的风险偏好、曾经否决过的方案、组织架构的变更、上一次谈判的底线。它必须跨会话存活，而且要能在几个月后被准确取回。

判断一条信息该进哪一类，只需要问一个问题：下一次会话里它还有用吗？有用进长期，没用留在短期。这个标准足够简单，也足够可靠——它把主观判断转成了一个可自动执行的规则。

用同一套数据模型承载两类记忆，是这套设计里最值得强调的一点。如果短期记忆存在会话缓存、长期记忆存在另一个系统，那么从短期升级为长期就需要一次跨系统的数据搬运，而这次搬运往往会丢掉上下文与来源。放在同一张图里，升级只是一次属性变更。

三、记忆怎么写成图：从一条对话到一组边

记忆不是把对话原文存下来，而是把它拆成结构化的事实，锚定到对象上。具体有三个建模要点。

其一，记忆挂在实体上，不挂在对话上。检索的起点决定了建模方式。用户问的是这个客户、这个项目、这份合同，那么记忆的锚点就应该是这些实体节点，而不是第几轮对话这个序列位置。把用户、企业、项目、合同建成节点，记忆作为独立节点或关系边挂上去，召回时先定位实体，再取其全部记忆——这和按对话切片的检索是两条完全不同的路径。

其二，时间、来源与置信度必须成为属性。每条记忆至少要带四个字段：发生时间、写入时间、来源类型（用户陈述／系统推断／文档提取）、置信度。这四项不是锦上添花，它们是后面判断冲突与执行衰减的唯一依据。缺了来源，系统就分不清用户亲口说的话和模型自己推断出来的结论，两者在冲突时该听谁也就无从判断。

其三，短期与长期共用一套模型，差异只在生命周期。新写入的记忆默认带短期标记与过期时间，会话结束或超期即清理；被反复引用、被用户确认、或命中关键实体属性的记忆，升级为长期并取消过期。这套机制写在图里，就是属性与边的增删改，不需要在两套系统之间做同步。

还有一个容易被跳过、但直接决定召回质量的动作：把散落的记忆组织成簇。单个客户可能累积几十条记忆，逐条召回会漏，全量返回又太长。借助社区发现、PPR 与邻居发现这类图算法，可以把围绕同一主题反复共现的记忆自动聚成一个语义簇——比如这个客户的全部风控相关记忆、全部价格敏感型反馈——召回时先命中簇，再展开簇内明细，既保证覆盖又控制长度。这类聚类在向量库里做不了，因为聚的是关系的密集程度，不是文本的相似程度。

四、记忆的衰减与冲突：该忘什么、听谁的

记忆系统真正难的不是写，是维护。写入容易，难的是让图谱不随时间腐化。

衰减不是定时删除，而是按权重排序。一条记忆的综合权重由三部分构成：时间新鲜度（越旧越低，可按半衰期折算）、引用次数（被后续对话佐证或多次召回的加分）、来源等级（用户确认高于用户陈述，用户陈述高于系统推断，系统推断高于文档提取）。权重低于阈值的记忆退出默认召回集合，但节点与边本身保留，需要时仍可回溯——审计场景下，忘掉和删除是两回事。

这套权重机制自然导出三条运维策略。一是时效清理：带强时效性的记忆（比如本季度的预算口径）过了有效期就退出召回，避免拿旧口径回答新问题。二是引用加固：被反复召回、被后续对话反复佐证的记忆权重持续上升，越用越牢固。三是确认升级：用户明确确认或修正过的记忆直接置为最高等级并转为长期，一次确认胜过十次推断。

冲突则必须有一套事先定好的规则。记忆写多了必然出现矛盾：上个月说预算五十万，这个月说三十万；文档里写的口径与用户口述不一致。系统不能靠模型临场裁决，那等于把错误随机化。

最后一条最容易被忽略，却是记忆系统与存储系统的分水岭：记忆最怕的不是忘，而是记错。遗忘的代价是重问一次，记错的代价是污染后续所有推理，而且很难被发现。因此当两条同级记忆互相矛盾、又没有更高优先级的证据时，正确做法是标记为待确认并向用户追问，而不是让模型自己挑一个看起来顺眼的。

五、悦数 AI 应用平台与图数据库的支撑

AI Memory 是悦数 AI 应用平台生成式 AI 套件中的记忆模块，与图建模、图检索增强提取器、图谱构建器、社区增强、探索链、Text2GQL、图洞察智能体等能力同属一套产品体系，短期记忆与长期记忆统一由图数据库承载。底座层面，悦数图数据库支持千亿点万亿边的存储规模，百亿点千亿边量级下点与边精确查询小于 1 秒、5 度关系查询小于 5 秒（结果集千万级），原生融合图、向量与全文索引，采用 Shared-Nothing 与存算分离架构，并提供面向智能体的 MCP、CLI 与 Skill 接口。对记忆系统而言，这意味着写入、衰减与按实体召回都发生在同一个引擎内，不需要跨系统做记忆同步。

常见问题（FAQ）

Q1：悦数图数据库是一款什么样的产品？

A：悦数图数据库是杭州悦数科技自主研发的企业级原生分布式 GQL 图数据库，100% 国产自研、自主可控，原生支持 ISO-GQL 国际标准，融合图、向量与全文索引能力，可支撑千亿点万亿边规模。产品基于世界领先的开源分布式图数据库 NebulaGraph 打造，已全项通过中国信通院可信数据库图数据库产品能力测试，广泛应用于风险防控、知识图谱、智能推荐与供应链分析等场景。

Q2：AI Memory 与悦数图数据库是什么关系？

A：AI Memory 是悦数 AI 应用平台生成式 AI 套件中的记忆模块，短期记忆与长期记忆统一由悦数图数据库承载，与图建模、图谱构建器、社区增强、探索链等能力同属一套产品体系。底座可支撑千亿点万亿边规模，5 度关系查询小于 5 秒，并提供面向智能体的 MCP、CLI 与 Skill 接口。