ChatGPT VS Claude ，Agent记忆用对话压缩还是RAG按需检索

发布日期：2025-12-24 18:17:32 浏览次数： 2928

作者：Zilliz

微信搜一搜，关注“Zilliz”

在高质量 AI Agent 系统里，记忆模块的设计远比看起来复杂，它要解决三个关键问题：

怎么存历史对话？什么时候检索？该检索哪些内容？

这些问题直接决定了 Agent 的响应速度、资源占用和能力天花板。

而我们常用的 ChatGPT、Claude 这类大模型，之所以能记住用户的长期偏好，越用越顺手，本质上是因为它们也算一种极简版 AI Agent。但在记忆模块的设计上，两者走了完全不同的路。

最近，一位外网大神Manthan Gupta，对 ChatGPT 以及Claude 的记忆系统做了逆向，结论如下：

GPT记忆主要靠预计算注入 + 分层缓存，主打轻量化连续性；Claude采用RAG式按需检索 + 动态更新，来平衡记忆的深度与效率。

原文如下：

https://manthanguptaa.in/posts/chatgpt_memory/

https://manthanguptaa.in/posts/claude_memory/

那么，两者的记忆模块究竟是怎么运作的？对我们的日常agent搭建有什么启发？本文将深入解答。

01 ChatGPT：四层静态注入架构搭建记忆模块

ChatGPT 未采用传统的向量数据库（RAG）或全量对话存储，而是通过四个分层组件将记忆提前注入每次对话的上下文，在保证个性化的同时控制计算成本。其整体上下文结构为：[0]系统指令 → [1]开发者指令 → [2]会话元数据 → [3]用户长期记忆 → [4]近期对话摘要 → [5]当前会话消息 → [6]用户最新消息，其中后四层为记忆核心。

其中，会话元数据（Session Metadata）指的是短期、非持久化记忆，仅在会话启动时注入一次，会话结束后销毁，主要用于让模型适配当前场景（如移动端简化回复格式），不影响长期记忆。其内容聚焦用户当前使用环境，包括：设备信息；账号属性（订阅等级如 ChatGPT Go、账号年龄、使用频率）；行为数据（近 1/7/30 天活跃天数、平均对话长度、模型调用分布如 49% 用 GPT-5）。

用户长期记忆（User Memory），则是长期、可编辑的核心记忆，用于记录用户稳定属性（，如姓名、职业目标、过往经历、项目成果、学习偏好），每次对话都会强制注入。其更新方式包括显式更新（用户通过 “记住这个”“从记忆中删除” 等指令直接管理）以及隐式更新（模型检测到符合 OpenAI 标准的事实如姓名、职位且用户默认同意时，自动添加。）

近期对话摘要（Recent Conversations Summary）则是一个轻量化跨会话层，用于替代传统 RAG 的全量检索，每次对话均注入。这一层仅总结用户消息（不包含助手回复）；数量有限（约 15 条），仅保留近期兴趣，不存储细节；整个过程无需嵌入计算或相似度搜索，降低延迟和 token 消耗。

当前会话消息（Current Session Messages）则是一个滑动窗口上下文层，用于维持当前会话连贯性的短期缓存，会存储全量对话内容。当超出 token 上限时，自动 “滚除” 最早的消息，但长期记忆和近期对话摘要不受影响；

02 Claude ：工具化按需检索架构做记忆管理

Claude 摒弃了 ChatGPT全量预注入的思路，采用长期记忆 + 按需工具检索的动态架构，仅在需要时调取历史上下文，平衡细节深度与效率。其上下文结构为：[0]系统指令（静态）→ [1]用户记忆 → [2]对话历史 → [3]当前消息。两者的核心差异体现在对话历史的检索方式和用户记忆”的更新逻辑。

首先是用户记忆（User Memories），其定位是智能更新的长期层，与 ChatGPT 长期记忆功能类似，但支持更灵活的动态更新，格式为 XML 标签包裹。其更新机制包括：隐式更新（后台定期基于对话内容自动更新-非实时，删除对话会逐步移除相关记忆）显式更新（通过memory_user_edits工具，用户用 “记住这个”“删除这个” 指令管理）。对比 ChatGPT，Claude 在这一环增加了后台自动优化，无需用户主动干预记忆迭代。

对话历史（Conversation History）方面，Claude 未采用固定摘要注入，而是通过三个互补组件动态调取历史，仅在模型判断需要时触发，避免无效 token 消耗。

这套组件中，比较值得研究的是conversation_search，能在模糊表述、多语言查询等场景依然能实现命中，背后应该使用了语义层面的匹配能力（常见实现是 embedding 检索，或“翻译/规范化 + 关键词/混合检索”的组合）。

整体来看，Claude 这套按需检索系统的特点则在于

非自动触发：工具调用由 Claude 自主判断，如用户提 “上次聊的项目” 时，触发conversation_search。

细节保留：检索结果包含助手回复片段（ChatGPT 摘要仅用户消息），适合需要上下文深度的场景；

效率优势：无需每次注入所有历史，减少无关 token 消耗。

缺点则在于，一旦引入按需检索，系统复杂度上升（索引构建、查询、排序、可能的重排），端到端延迟不如预计算注入可控；同时模型还必须学会判断何时该检索，判断失误就会丢上下文。

03 Claude 式按需检索的技术门槛

一旦选择按需检索路线，向量数据库的选型就变得至关重要。因为，对话检索场景对数据库的要求极为苛刻，须同时满足四个约束。

约束一：延迟容忍度极低

对话系统的 P99 延迟必须控制在 20ms 以内，否则用户会感觉卡顿。这意味着向量检索、元数据过滤、结果排序的全流程都要高度优化。任何一个环节出现性能瓶颈，整个对话体验都会劣化。

约束二：混合检索是刚需

用户的查询包含多维度约束：“最近一周关于 RAG 的讨论”同时涉及时间过滤和语义检索。如果数据库只支持向量检索，先返回 1000 个语义相关的结果，再在应用层做时间过滤可能只剩 3 个，中间 997 次计算全部浪费。必须在数据库层面原生支持向量+标量的组合查询。

约束三：资源占用与扩展性的矛盾

对话历史有明显的冷热特征：最近的对话被频繁检索，几个月前的对话很少访问。如果所有向量数据都必须加载到内存，千万级对话会消耗数百 GB 内存，资源开销不可接受。必须支持存储计算分离，热数据在内存、冷数据在对象存储，按需加载。

约束四：查询模式的多样性

有时是纯语义检索（之前讨论的性能优化方案），有时是纯时间检索（上周的所有对话），有时是复杂组合（三个月内关于 Python 且提到 FastAPI 的讨论）。数据库的查询优化器必须针对不同模式自动选择最优执行策略，避免统一的暴力搜索。

这四个技术挑战构成了对话检索的完整约束。任何想要实现 Claude 式按需检索的系统，都必须系统性地解决这些问题。

04 Milvus2.6：为对话检索场景而生的架构演进

Milvus 2.6 版本的设计选择，与按需检索的核心需求形成了适配。以下是几个关键能力的匹配分析。

稠密+稀疏向量的混合检索

Milvus 2.6 原生支持在同一个 collection 中存储稠密向量和稀疏向量，并在查询时自动融合结果。对话检索场景可以这样组合：用稠密向量（如 BGE-M3 生成的 768 维 embedding）捕捉语义相似度，用稀疏向量（BM25 算法生成）捕捉关键词匹配。查询“上周关于 RAG 的讨论”时，系统会同时执行语义检索和关键词检索，然后通过 Rerank 算法融合结果，召回率相比单一方法有显著提升。

存储计算分离+查询优化器

Milvus 2.6 的架构支持两种分层存储模式：热数据放内存、冷数据放对象存储；以及索引放内存、原始向量数据放对象存储。在这种模式下，100 万条对话只需 2GB 内存+8GB 对象存储就能搞定。在合理配置参数情况下，P99 延迟可控制在 20ms 以内。

JSON Shredding 与标量过滤优化

Milvus 2.6 默认启用 JSON Shredding，将 JSON 字段的嵌套结构打平为列式存储，标量过滤性能提升 3-5 倍（基于官方 benchmark，实际提升幅度取决于查询模式）。对话检索常需要过滤用户 ID、会话 ID、时间范围等元数据，这些字段通常存储在 JSON 中。启用 JSON Shredding 后，查询“用户 A 最近一周的对话”时，不再需要解析完整 JSON，而是直接在列式索引上执行过滤。

开源特性带来的技术掌控力

作为开源方案，Milvus 让你可以根据负载调整索引参数、通过数据分层优化资源占用、定制分布式部署策略。这种灵活性在商业黑盒方案中无法实现。更重要的是，中小团队也能构建百万到千万级检索系统，不再依赖巨额基础设施投入。