1. 项目概述：当我们在谈论“记忆”时，我们在谈论什么？

最近和几个做AI应用落地的朋友聊天，发现一个挺有意思的现象：大家一提到让大模型“记住”东西，第一反应就是上RAG（检索增强生成）。好像RAG成了解决模型知识局限和幻觉问题的唯一标准答案。但当我问他们，如果想让一个AI助手记住“我习惯在每周三下午三点开项目例会，并且我讨厌冗长的邮件汇报”，该怎么实现时，不少人会愣一下，然后说“那得设计个复杂的用户偏好向量库，用RAG去查”。这其实是一个典型的思维定式。

“Continuity Memory vs RAG: Different Jobs, Different Architectures”这个标题，精准地切中了当前AI应用架构设计中的一个关键认知误区——将两种解决不同问题的技术方案混为一谈。Continuity Memory（连续性记忆，或称持久化记忆）和RAG，它们虽然都关乎“信息”与“模型”，但职责、设计目标和底层架构逻辑有着本质区别。简单粗暴地类比，RAG像是你书房里一个按主题分类、检索效率极高的巨型图书馆，而Continuity Memory则更像是你大脑中关于个人习惯、经历和长期偏好的那部分“肌肉记忆”或“情景记忆”。

理解这种区别，对于任何正在设计对话机器人、智能助手、游戏NPC或者需要长期个性化交互AI应用的开发者来说，是至关重要的。用错了架构，不仅事倍功半，用户体验也会变得古怪。比如，一个本该记住用户咖啡喜好的助手，却每次都要去“检索”一遍用户历史订单，显得既迟钝又缺乏“人情味”。这篇文章，我就结合自己在这两个方向上的踩坑经验，来拆解一下它们各自的“本职工作”、核心架构思路，以及如何根据你的应用场景做出正确的技术选型。

2. 核心概念拆解：记忆与检索的本质差异

在深入架构之前，我们必须先厘清这两个概念要解决的“元问题”是什么。这决定了它们所有的技术实现路径。

2.1 Continuity Memory：为“状态”与“关系”而生

Continuity Memory的核心目标是维持跨会话的、连贯的交互状态和个性化的用户关系。它关注的是“who you are”和“what happened between us”。

  • 它记忆什么？

    • 用户身份与偏好 ：用户的称呼、基础信息（如职业、时区）、长期稳定的偏好（“我不吃香菜”、“报告喜欢用PPT格式”）。
    • 交互历史与上下文 ：不仅仅是上一轮对话，而是跨越多次会话的重要事件和共识（“上周我们决定项目采用A方案”、“你昨天说头疼，今天好点了吗？”）。
    • 会话状态与目标 ：一个多轮复杂任务的当前进度（“正在为你预订机票，已选好航班，下一步请提供乘客信息”）。
    • 情感与关系基调 ：通过历史交互推断出的用户情绪倾向、交流风格（用户喜欢简洁还是详细，是正式还是随意）。

  • 它的核心特征：

    1. 状态性 ：记忆内容是动态的、可更新的状态。例如，用户的“项目进度”从“10%”更新到“50%”。
    2. 关联性 ：记忆之间可能存在联系。知道用户是“设计师”，可能关联到他偏好“视觉化的报告”。
    3. 高频率、低容量访问 ：在单次会话中，这些记忆会被反复、快速地读取和更新（例如，每次生成回复都可能需要调用用户偏好），但总的数据量相对较小（KB到MB级别）。
    4. 强一致性要求 ：对同一事实的记忆必须保持一致，不能出现这次说“用户爱喝美式”，下次又说“用户爱喝拿铁”的矛盾。

注意 ：这里容易混淆的是“对话上下文窗口”和Continuity Memory。上下文窗口（如128K tokens）是短期工作记忆，会话结束就清零。Continuity Memory是长期记忆，需要持久化存储到数据库或文件，供未来会话读取。

2.2 RAG：为“知识”与“事实”服务

RAG的核心目标是为模型提供它训练数据之外的最新、专有或海量的参考知识，以增强回答的准确性、时效性并减少幻觉。它关注的是“what is true in the world”。

  • 它检索什么？

    • 领域文档 ：产品手册、法律条文、学术论文、公司内部Wiki。
    • 实时信息 ：新闻、股价、天气、体育比赛结果。
    • 大型知识库 ：百科全书条目、历史事件资料、所有公开的API文档。
    • 非结构化数据 ：图片、音频、视频中提取的文本信息。

  • 它的核心特征：

    1. 静态性 ：被检索的知识库相对稳定，虽然可以更新，但在单次检索过程中被视为静态数据源。
    2. 独立性 ：文档之间通常是独立的，检索的目标是找到最相关的若干片段，而非理解片段间的复杂关系。
    3. 低频率、高容量扫描 ：并非每次用户提问都需要检索（例如闲聊就不需要），但一旦触发，可能需要在海量数据（GB到TB级）中进行搜索。
    4. 相关性优先 ：核心挑战是找到与问题最相关的文档片段，对“一致性”的要求体现在检索结果与问题匹配度上，而非记忆内容本身的逻辑一致。

一个简单的类比 ：假设你要写一篇关于“火星殖民”的论文。

  • RAG 是你的文献检索工具（如Google Scholar）。你输入关键词，它返回相关的学术论文、报告。这些知识是公共的、事实性的。
  • Continuity Memory 是你写作时的“思维状态”。它记住你已决定采用“技术可行性”作为主线，第一章写了哪些论点，你对某个引用来源的信任度，以及你计划明天重点攻克生命保障系统部分。这些状态是私人的、动态的。

3. 架构设计对比：从数据流看根本不同

理解了目标差异，它们的架构设计自然分道扬镳。我们可以从数据存储、索引、读写模式和应用流程四个维度来对比。

3.1 存储与索引层：结构化 vs 向量化

  • Continuity Memory 的存储 ：

    • 首选：结构化/半结构化数据库 。如SQLite、PostgreSQL、Redis甚至一个简单的JSON文件。为什么？因为记忆内容通常是键值对（ {“user_preference”: {“coffee”: “americano”, “report_format”: “ppt”}} ）、列表（ [“completed_tasks”: [“task1”, “task2”]] ）或带有时间戳的事件记录。这些结构便于精确的CRUD（增删改查）操作。
    • 索引方式 ：通常基于明确的键（ user_id , session_id , memory_key ）进行直接查询。高级一点的可能会有基于标签或简单元数据的过滤索引，但核心是 精确查找 ，而非相似性搜索。

  • RAG 的存储 ：

    • 核心：向量数据库 。如Chroma、Pinecone、Weaviate、Milvus，或基于PGVector的PostgreSQL。为什么？因为知识文档被切分成片段后，需要转换为向量嵌入（Embeddings），检索的本质是计算问题向量与所有文档片段向量的 相似度 。
    • 索引方式 ：构建的是高维向量的近似最近邻（ANN）索引，如HNSW、IVF-Flat等。目的是在毫秒级时间内从百万级数据中找到最相似的几个片段。它处理的是 模糊匹配 。

实操心得 ：我曾在一个项目中错误地将用户对话历史片段也存入向量库用于“记忆”检索，结果灾难性的。当用户问“我之前跟你提过我养狗吗？”，系统可能会返回一段用户谈论“工作累成狗”的相似文本片段，完全答非所问。记忆查询需要的是精确召回，比如“SELECT pet FROM user_memory WHERE user_id = xxx”，向量检索在这里是错误工具。

3.2 读写模式与更新策略

  • Continuity Memory 的读写 ：

    • 写操作频繁且细粒度 ：每次交互都可能更新记忆。例如，用户说“叫我Alex”，系统需要立刻执行一个更新操作： UPDATE user_profile SET preferred_name = ‘Alex’ WHERE user_id = … 。用户完成一个任务步骤，状态就需要更新。
    • 更新策略 ：需要处理复杂的合并与冲突解决。例如，从不同渠道（语音、文字）同时更新同一记忆项怎么办？通常需要定义优先级，或采用类似乐观锁的机制。记忆也可能需要“衰减”或“归档”，太久远的琐碎记忆可以压缩或删除。

  • RAG 的读写 ：

    • 写操作低频且粗粒度 ：知识库的更新可能以天、周甚至月为单位。一次更新往往是批量导入新的文档或替换整个文档集合。
    • 更新策略 ：相对简单，主要是重建或增量更新向量索引。挑战在于如何保证更新期间检索服务不中断（热更新），以及如何处理文档版本问题。

3.3 在应用流程中的位置

这是区分两者最直观的视角。

  • Continuity Memory 的工作流程 ： 用户输入 -> 读取当前会话状态及用户长期记忆 -> 与大模型当前指令共同构成完整Prompt -> 模型生成回复 -> 根据回复和交互结果，更新记忆（状态） 记忆是 输入Prompt的一部分 ，直接影响模型的“人格”和回复的上下文。它通常在流程的最开始被加载，在流程的最后被保存。

  • RAG 的工作流程 ： 用户输入 -> 判断是否需要检索知识（分类或意图识别）-> 如需，将输入转换为查询，检索向量库 -> 将检索到的相关文本作为上下文，与大模型指令共同构成Prompt -> 模型生成回复 检索到的知识是 额外的上下文材料 ，用于补充模型的知识盲区。它是一条条件触发的旁路。

一个结合使用的典型流程 ：

  1. 用户问：“根据我们之前的讨论，帮我总结一下项目A的风险，并参考公司风险管理手册给出建议。”
  2. Continuity Memory 路径 ：系统读取记忆，知道“我们之前的讨论”具体指哪次会议记录（通过记忆中的 discussion_id 关联），并知道用户喜欢的总结格式（记忆中的 preferred_summary_style ）。
  3. RAG 路径 ：系统同时将“公司风险管理手册”作为关键词，去向量知识库中检索相关章节。
  4. 合并 ：将记忆中的讨论内容 + 检索到的手册内容 + 用户格式偏好，共同组装成Prompt，送给大模型生成最终回答。

4. Continuity Memory 的实现模式与陷阱

理解了概念，我们来看看具体怎么实现Continuity Memory。市面上没有银弹，但有几个常见模式。

4.1 实现模式一：显式记忆槽

这是最直接、最可控的方式。你为需要记忆的信息预定义好“槽位”（Schema）。

  • 如何做 ： 
    # 定义记忆Schema
user_memory_schema = {
    "preferences": {
        "format": str, # e.g., "markdown", "ppt"
        "tone": str,   # e.g., "formal", "casual"
    },
    "ongoing_tasks": list, # e.g., [{"task_id": 1, "status": "in_progress"}]
    "facts": dict, # e.g., {"allergy": "peanuts", "pet": "dog"}
}

# 在对话中，通过特定指令让模型提取信息填充记忆槽
prompt = f"""
用户说：{user_input}
请从上述对话中提取需要长期记忆的信息，并按照以下JSON格式输出。如果没有任何新信息，输出空JSON。
{json.dumps(user_memory_schema)}
"""
# 解析模型输出，更新数据库
  • 优点 ：结构清晰，易于查询和管理，一致性高。
  • 缺点 ：不灵活，无法记忆预定义结构之外的信息。需要精心设计提示词来指导模型提取。

4.2 实现模式二：摘要式记忆

将较长的对话历史或重要事件，通过模型压缩成一段简短的摘要，存入记忆。下次会话时，先加载这个摘要作为背景。

  • 如何做 ： 
    # 会话结束时或达到一定长度后触发
summary_prompt = f"""
请将以下对话总结成一段简短的段落，保留关于用户核心意图、关键决定和重要事实的信息。总结将用于未来对话的上下文。
对话历史：
{conversation_history}
"""
# 将生成的summary存入数据库，关联user_id和session_id
  • 优点 ：更自然，能捕捉非结构化的信息。减少了直接存储大量历史文本的开销。
  • 缺点 ：存在信息损失。摘要的“质量”和“偏向性”取决于模型，可能丢失细节。多个摘要之间可能存在信息冗余或冲突。

4.3 实现模式三：自主记忆（Agentic Memory）

赋予AI智能体（Agent）自主决定“记住什么”、“忘记什么”和“回忆什么”的能力。这通常结合了向量检索（用于记忆的“回忆”阶段）和结构化存储。

  • 如何做 ：
    1. 记忆形成 ：Agent在运行中，将认为重要的观察、思考结果或行动结果，转换成文本描述，并生成向量嵌入，存入一个专有的“记忆向量库”。同时，可能用元数据（时间、重要性分数、关联实体）进行标注。
    2. 记忆回忆 ：当遇到新情境时，Agent将当前情境向量化，去“记忆向量库”中搜索相似的历史记忆，将其作为上下文注入。
    3. 记忆管理 ：定期根据访问频率、时间、重要性分数对记忆进行清理或强化。
  • 优点 ：高度灵活、自动化，最接近人类的记忆方式。
  • 缺点 ：实现复杂，不可控因素多。Agent可能记住无关紧要的东西，或错误地关联记忆，导致行为怪异。计算开销大。

常见陷阱与心得 ：

  • 陷阱1：过度记忆导致隐私与性能问题 。记住每一句对话是危险且低效的。一定要定义记忆的边界，什么该记（偏好、重要决定），什么不该记（闲聊细节、临时信息）。实施数据过期和清理策略。
  • 陷阱2：记忆冲突与一致性 。当多个来源或会话试图修改同一记忆时，需要有解决策略。例如，采用“最后写入优先”或“需要用户确认”。对于关键事实，甚至可以设计一个记忆验证流程。
  • 心得 ：对于大多数实用型AI助手， “显式记忆槽+关键会话摘要”的混合模式 往往是最平衡的。用记忆槽存储硬性偏好和事实，用摘要保存重要的对话脉络。启动成本低，可控性强。
  • 心得 ：记忆的“键”设计至关重要。除了 user_id ，考虑加入 memory_domain （如 preference , fact , project_A ）作为复合键，方便管理和分区查询。

5. RAG 的典型架构与优化点

RAG的架构大家相对熟悉，这里重点讲在对比视角下，它与Memory架构差异带来的不同优化侧重点。

5.1 经典RAG管道及其瓶颈

标准的RAG管道包括：文档加载 -> 文本分割 -> 向量化 -> 索引 -> 检索 -> 重排 -> 上下文注入 -> 生成。

在与Memory架构对比时，RAG的核心瓶颈在于：

  • 检索精度 ：“垃圾进，垃圾出”。如果检索到的文档不相关，再好的模型也无力回天。
  • 上下文长度与噪声 ：检索到的多个片段可能包含冗余或矛盾信息，挤占宝贵的上下文窗口，干扰模型。
  • 无法进行多步推理 ：传统RAG是“一次性检索”，对于需要结合多个离散知识点进行推理的复杂问题效果有限。

5.2 针对性的高级优化模式

为了做好“知识检索”这份本职工作，现代RAG系统已经发展出多种高级模式，这些是纯Memory架构不需要考虑的：

  1. 查询转换与扩展 ：

    • 做法 ：在检索前，先用LLM对原始用户查询进行改写、扩展或生成假设性回答。例如，将“它怎么工作的？”扩展为“[产品名]的工作原理是什么？它的核心机制涉及哪些部件？”
    • 为什么 ：用户的提问方式往往与文档表述方式不一致。查询转换能拉齐这种语义鸿沟，提高召回率。这与Memory中精确的键值查询思维完全不同。

  2. 分层检索与混合搜索 ：

    • 做法 ：不单纯依赖向量搜索。先使用关键词搜索（如BM25）快速筛选出候选文档集，再用向量搜索进行精细排序。或者结合元数据过滤（日期、作者、类型）。
    • 为什么 ：向量搜索善于处理语义相似，但可能忽略关键术语。混合搜索能兼顾两者。Memory查询则很少需要这种“混合”，因为它的键通常是明确的。

  3. 上下文压缩与重排 ：

    • 做法 ：检索到多个片段后，使用一个轻量级模型（如Cross-Encoder）对它们进行相关性重排，或使用LLM对冗余信息进行压缩、总结，再送入最终生成模型。
    • 为什么 ：直接拼接所有检索结果会引入噪声。压缩和重排确保了注入Prompt的知识是精炼、相关的。这在处理Memory时通常不需要，因为记忆项本身是精炼的结构化数据。

  4. 递归检索与Agentic RAG ：

    • 做法 ：将RAG过程任务化。让一个“检索智能体”根据初步结果，自主决定是否进行下一轮更精确的检索，或者拆解问题分步检索。
    • 为什么 ：解决复杂、多跳问题。这有点靠近Memory中“状态管理”的思想，但其目标仍然是知识获取，而非维持交互状态。

实操心得 ：RAG系统的性能， 文本分割策略 的影响被严重低估了。按固定长度（如512字符）分割会切断完整的语义单元。推荐尝试按语义分割（使用嵌入相似度突变检测）或按自然结构分割（按标题、段落）。好的分割能直接提升检索精度30%以上。这与Memory存储“完整事件记录”或“键值对”的思路又是截然不同的。

6. 如何为你的项目选择正确的架构？

现在我们来回答最实际的问题：我的项目该用哪个？或者如何组合使用？

6.1 决策树：你需要记忆还是知识？

回答以下几个问题：

  1. 你的应用是否需要记住与特定用户的交互历史，以提供连贯的个性化体验？

    • 是 -> 你需要 Continuity Memory 。
    • 否 -> 跳到问题2。

  2. 你的应用是否需要回答关于一个特定、可能模型未训练过的知识库（如公司文档、最新新闻）的问题？

    • 是 -> 你需要 RAG 。
    • 否 -> 你可能只需要一个基础的聊天上下文窗口。

  3. 如果以上两个都是“是”，那么哪个是核心功能？

    • 个性化体验为核心 （如AI伴侣、私人教练、游戏NPC）：以 Continuity Memory 为架构中心 ，RAG作为补充知识源（例如，NPC可以检索游戏世界百科来回答玩家关于背景故事的问题）。
    • 知识问答为核心 （如客服机器人、企业知识库助手、研究分析工具）：以 RAG 为架构中心 ，Continuity Memory用于记住用户的查询习惯、上次看到的文档位置等辅助信息。

6.2 组合使用模式示例

  • 模式A：记忆为主，检索为辅（智能个人助手）

    • 记忆系统 ：存储用户的日程、联系人、个人习惯、项目进度。
    • RAG系统 ：连接邮件库、文档库。当用户问“我上周和Alice邮件里说的那个预算数字是多少？”，系统先通过记忆知道“Alice”是联系人，“上周”是时间范围，然后利用这些信息作为元数据，去RAG系统检索相关邮件。
    • 架构提示 ：记忆数据库和向量数据库可以是独立的。记忆系统提供检索的“过滤条件”。

  • 模式B：检索为主，记忆为辅（专家级客服机器人）

    • RAG系统 ：索引所有产品手册、故障解决指南、技术白皮书。
    • 记忆系统 ：记住当前用户的产品型号、已尝试的解决步骤、服务等级协议。当用户描述新问题时，系统先读取记忆中的产品型号，将其作为关键词增强查询，再检索知识库。同时，将本次对话中确认的解决步骤更新到记忆，避免重复询问。
    • 架构提示 ：记忆在这里作为会话相关的“动态元数据”，用于优化每一次检索的查询。

6.3 技术选型清单

  • 当你主要需要 Continuity Memory 时 ：

    • 存储 ：SQLite（轻量）、PostgreSQL（功能全）、Redis（高速缓存频繁访问的记忆）。
    • 框架/模式 ：LangChain的 EntityMemory 、 ConversationSummaryMemory ；自主实现基于Schema的记忆管理器。
    • 关键考量 ：数据结构设计、读写延迟、冲突解决策略。

  • 当你主要需要 RAG 时 ：

    • 向量数据库 ：Chroma（简单易用）、Pinecone（全托管、性能好）、Weaviate（功能丰富、支持混合搜索）。
    • 框架 ：LlamaIndex（专精RAG管道）、LangChain（更通用的链编排，包含RAG模块）。
    • 关键考量 ：嵌入模型选择（如 text-embedding-3-small ）、文本分割策略、检索精度优化（重排、混合搜索）。

7. 常见问题与实战排坑指南

在实际开发中，混合使用两者时，会遇到一些特有的问题。

问题1：记忆污染了检索，或检索干扰了记忆。

  • 场景 ：在组合Prompt时，不小心将用户的个人偏好记忆（如“喜欢简短回答”）和检索到的技术文档片段混在一起，导致模型困惑，可能生成一个既简短又试图包含大量技术细节的矛盾回答。
  • 解决 ：在Prompt模板中严格区分上下文区域。使用清晰的标记，例如： 
    # 用户长期偏好与当前会话状态（记忆）：
{memory_context}

# 本次查询的相关知识参考（检索结果）：
{retrieved_knowledge}

# 指令：
请综合以上信息，特别注意用户的回答风格偏好，回答以下问题：{query}
    明确告诉模型不同部分的性质和用途。

问题2：该用记忆查询时，误触发RAG检索，导致响应慢且不准确。

  • 场景 ：用户问“我上次说的那个想法你觉得怎么样？”。系统错误地将其识别为需要知识检索，去向量库搜了一圈，结果当然找不到。
  • 解决 ：实现一个轻量级的 意图分类器 。在流程入口处，先判断用户输入是：
    • 需要访问长期记忆 （如查询状态、更新偏好、提及历史事件）
    • 需要检索外部知识 （如询问事实、文档内容）
    • 仅需普通对话 （闲聊、简单指令） 这个分类器可以是一个微调的小模型，或者一组精心设计的规则/提示词。

问题3：记忆的更新时机不当，导致状态不一致。

  • 场景 ：用户说“把会议改到明天下午”。模型基于此生成了回复“好的，已为您改期”。但此时，如果网络问题导致更新记忆的数据库操作失败，系统记忆里会议时间还是旧的。下次用户再问，就会给出错误信息。
  • 解决 ：将 记忆更新作为关键事务 来处理。可以考虑两种模式：
    1. 在模型生成回复前更新 ：先执行记忆更新操作，如果成功，再将“已更新”的状态作为上下文的一部分送给模型生成回复。这保证了回复与记忆的强一致性，但可能因为更新失败导致无回复。
    2. 采用补偿事务 ：模型生成包含“确认动作”的回复（如“已为您改期”），同时异步触发记忆更新。如果更新失败，记录日志并尝试重试或通知用户。这种方式更鲁棒，但存在短暂的不一致窗口。

问题4：如何处理模糊或冲突的记忆查询？

  • 场景 ：用户问“我们之前谈过的那本书叫什么来着？”。记忆里可能有多条关于“书”的记录。
  • 解决 ：实现一个简单的 记忆检索与排序 机制。当记忆查询不精确时（如没有提供具体键），可以：
    • 搜索所有包含相关关键词的记忆项。
    • 根据记忆的 新鲜度 （最近访问或创建）、 强度 （被反复确认的次数）、 关联性 （与当前会话主题的匹配度）进行排序。
    • 将排名前几的记忆项，连同其不确定性一起交给模型，让模型在回复中澄清或确认。例如：“您是指上周提到的《设计模式》，还是昨天聊到的《人类简史》？”

最后的个人体会 ：设计和实现一个健壮的AI记忆系统，其复杂性常常被低估。它不仅仅是存数据、取数据那么简单，而是涉及到状态管理、冲突解决、隐私边界和用户体验设计的综合工程。RAG更像是一个“标准件”，有相对成熟的管道和优化套路。而Continuity Memory则更贴近业务逻辑，需要你深入思考你的AI角色到底需要“记住”什么，以及这些记忆如何塑造它的行为和与用户的关系。从零开始搭建时，建议从最简单的显式记忆槽开始，随着需求明朗再逐步引入更复杂的摘要或自主记忆机制。永远记住，最优雅的架构永远是那个能清晰区分“知识”和“记忆”，并让它们各司其职的架构。

# RAG
Logo
AI Agent技术社区

Agent 垂直技术社区，欢迎活跃、内容共建。

更多推荐

cover

Dify 接入蓝耘 MaaS：基于智能客服分流模板搭建一个客服助手

avatar AI Agent技术社区
cover

ComAct：工业 Agent 为什么要把专业软件变成可执行动作

avatar AI Agent技术社区

写代码为什么越来越多人开始用 ChatGPT 和 Codex？

摘要： ChatGPT-Codex正被越来越多开发者用于日常编程，主要因为它们能高效处理重复性工作而非替代程序员。ChatGPT擅长思路分析和代码解释，如报错排查、框架学习；Codex则直接参与代码生成、重构及功能补充。两者结合可节省查文档、改Bug等琐碎时间，让开发者专注核心逻辑。适用人群包括开发者、新手、运营等，但需注意代码检查、数据安全。AI辅助编程是效率工具，合理使用能加速学习与开发流程。

avatar AI Agent技术社区