Home
Blog
对 ChatGPT 和克劳德记忆系统的思考：实现按需对话检索所需的条件

对 ChatGPT 和克劳德记忆系统的思考：实现按需对话检索所需的条件

Engineering

January 09, 2026

Min Yin

在高质量的人工智能 Agents 系统中，内存设计远比初见时复杂得多。其核心是必须回答三个基本问题：对话历史应该如何存储？何时检索过去的上下文？到底应该检索什么？

这些选择直接决定了 Agents 的响应延迟、资源使用以及最终的能力上限。

像 ChatGPT 和 Claude 这样的模型，我们用得越多，它们就越有 "记忆意识"。它们能记住偏好，适应长期目标，并在不同会话中保持连续性。从这个意义上说，它们已经具备了小型人工智能 Agents 的功能。然而，在表象之下，它们的记忆系统建立在截然不同的架构假设之上。

最近对ChatGPT和克劳德的记忆机制进行的逆向工程分析显示了一个明显的对比。ChatGPT依靠预先计算的上下文注入和分层缓存来提供轻量级、可预测的连续性。相比之下，Claude采用了 RAG 风格的按需检索和动态内存更新，以平衡内存深度和效率。

这两种方法不仅仅是设计上的偏好，它们是由基础架构能力决定的。Milvus 2.6引入了按需会话内存所需的密集-稀疏混合检索、高效标量过滤和分层存储的组合，使得选择性检索足够快速和经济，可以部署在现实世界的系统中。

在这篇文章中，我们将介绍 ChatGPT 和 Claude 的内存系统究竟是如何工作的，它们在架构上产生分歧的原因，以及 Milvus 等系统的最新进展是如何使按需对话检索大规模实用化的。

ChatGPT 的记忆系统

ChatGPT 的 "记忆 "系统不是查询向量数据库，也不是在推理时动态检索过去的对话，而是通过组装一组固定的上下文组件，并将它们直接注入每个提示中。每个组件都提前准备好，并在提示中占据已知的位置。

这种设计保持了个性化和会话的连续性，同时使延迟、令牌使用和系统行为更具可预测性。换句话说，内存不是模型临时搜索的东西，而是系统每次生成响应时打包并交给模型的东西。

从高层来看，一个完整的 ChatGPT 提示由以下几层组成，顺序从最全局到最直接：

[0] 系统说明

[1] 开发人员说明

[2] 会话元数据（短暂数据）

[3] 用户记忆（长期事实）

[4] 最近对话摘要（过去的聊天记录、标题和片段）

[5] 当前会话消息（本次聊天）

[6] 您的最新信息

其中，[2]至[5]部分构成了系统的有效记忆，各自发挥着不同的作用。

会话元数据

会话元数据代表短暂、非持久的信息，在会话开始时注入一次，会话结束时丢弃。它的作用是帮助模型适应当前的使用环境，而不是长期个性化行为。

这一层捕捉有关用户周围环境和近期使用模式的信号。典型信号包括

设备信息--例如，用户使用的是手机还是台式机
账户属性--如订阅层级（如 ChatGPT Go）、账户年龄和总体使用频率
行为指标--包括过去 1 天、7 天和 30 天的活跃天数、平均对话长度和模型使用分布（例如，49% 的请求由 GPT-5 处理）

用户内存

用户记忆是一个持久的、可编辑的记忆层，可实现跨对话的个性化。它存储相对稳定的信息，如用户的姓名、角色或职业目标、正在进行的项目、过去的成果和学习偏好，并注入到每次新对话中，以保持随着时间推移的连续性。

这种记忆可以通过两种方式进行更新：

显式更新是指用户通过 "记住这个 "或 "从记忆中删除这个 "等指令直接管理记忆。
当系统识别出符合 OpenAI 存储标准的信息（如已确认的姓名或职位）时，就会进行隐式更新，并根据用户的默认同意和内存设置自动保存。

当前会话消息

当前会话消息包含正在进行的会话的完整消息历史记录，并提供了连贯、逐一回复所需的短期上下文。这一层包括用户输入和助手回复，但仅限于会话处于活动状态时。

由于该模型是在一个固定的令牌限制内操作的，因此该历史记录不能无限增长。当达到限制时，系统就会删除最早的信息，为较新的信息腾出空间。这种截断只影响当前会话：用户的长期记忆和最近的对话摘要保持不变。

克劳德的内存系统

Claude 采用了一种不同的内存管理方法。克劳德没有像 ChatGPT 那样，在每个提示符中注入一大捆固定的内存组件，而是将持久用户内存与按需工具和选择性检索结合起来。只有当模型判断历史上下文相关时，才会对其进行检索，这样系统就能在上下文深度与计算成本之间进行权衡。

克劳德的提示上下文结构如下：

[0] 系统提示（静态指令）

[1] 用户记忆

[2] 对话历史

[3] 当前信息

Claude 和 ChatGPT 的主要区别在于如何检索对话历史以及如何更新和维护用户记忆。

用户记忆

在 Claude 中，用户记忆构成了一个长期上下文层，其目的与 ChatGPT 的用户记忆类似，但更强调后台驱动的自动更新。这些记忆以结构化格式存储（用 XML 样式的标签封装），旨在随着时间的推移逐渐发展，只需最少的用户干预。

Claude 支持两种更新路径：

隐式更新- 系统会定期分析对话内容，并在后台更新内存。这些更新不会实时应用，与已删除对话相关的内存会作为持续优化的一部分被逐步剪除。
显式更新--用户可以通过专门的memory_user_edits 工具执行 "记住此内容 "或 "删除此内容 "等命令，直接管理内存。

与 ChatGPT 相比，Claude 将完善、更新和修剪长期记忆的责任更多地交给了系统本身。这就减少了用户主动整理存储内容的需要。

对话历史

在对话历史方面，Claude 并不依赖于每次提示都会注入的固定摘要。相反，只有当模型认为有必要时，它才会使用三种不同的机制检索过去的上下文。这就避免了将无关的历史向前推进，并使令牌的使用处于可控范围内。

组件	目的	如何使用
滚动窗口（当前对话）	存储当前会话的完整消息历史记录（而非摘要），类似于 ChatGPT 的会话上下文。	自动注入。令牌限制为 ~190K；一旦达到限制，旧消息将被删除
`conversation_search` 工具	按主题或关键词搜索过去的会话，返回会话链接、标题和用户/助手信息摘录	当模型确定需要历史细节时触发。参数包括`query` （搜索条件）和`max_results` （1-10）
`recent_chats` 工具	检索指定时间范围内（例如 "过去 3 天"）的最近会话，结果格式与以下工具相同`conversation_search`	当最近的时间范围上下文相关时触发。参数包括`n` （结果数量）、`sort_order` 和时间范围。

在这些组件中，conversation_search 尤其值得一提。它甚至可以为措辞松散或多语言查询提供相关结果，这表明它是在语义层面操作，而不是依赖简单的关键词匹配。这很可能涉及基于 Embeddings 的检索，或者是一种混合方法，首先将查询翻译或规范化为规范形式，然后应用关键词或混合检索。

总的来说，克劳德的按需检索方法有几个显著的优点：

检索不是自动的：工具调用是由模型自身的判断触发的。例如，当用户提到"我们上次讨论过的项目 "时，Claude 可能会决定调用conversation_search 来检索相关上下文。
在需要时提供更丰富的上下文：检索结果可以包括助手的回复摘录，而 ChatGPT 的摘要只能捕捉用户信息。这使得 Claude 更适合需要更深入或更精确对话上下文的用例。
默认情况下效率更高：由于除非需要，否则不会注入历史语境，因此系统可以避免携带大量无关的历史记录，从而减少不必要的令牌消耗。

权衡利弊同样明显。按需检索会增加系统的复杂性：必须建立和维护索引，执行查询，对结果进行排序，有时还要重新排序。端到端延迟的可预测性也比预先计算、始终注入上下文的延迟要低。此外，模型还必须学会判断何时需要检索。如果判断失误，可能根本不会获取相关上下文。

克劳德式按需检索背后的制约因素

采用按需检索模型使向量数据库成为架构的关键部分。对话检索对存储和查询执行都提出了异常高的要求，系统必须同时满足四个限制条件。

1.低延迟容忍度

在对话系统中，P99 延迟通常需要保持在 ~20 毫秒以下。超过 20 毫秒的延迟会立即被用户察觉。这就为低效率留下了很小的空间：向量搜索、元数据过滤和结果排序都必须仔细优化。任何一点出现瓶颈都会降低整个会话体验。

2.混合搜索要求

用户查询往往跨越多个维度。像"过去一周关于 RAG 的讨论 "这样的请求就结合了语义相关性和基于时间的过滤。如果数据库只支持向量搜索，那么它可能会返回 1000 个语义相似的结果，而应用层过滤只能将其减少到少数几个，从而浪费了大部分计算量。为了实用起见，数据库必须原生支持向量和标量组合查询。

3.存储与计算分离

对话历史记录表现出明显的冷热访问模式。最近的对话会被频繁查询，而较早的对话则很少被触及。如果所有向量都必须保留在内存中，那么存储数千万条会话将消耗数百 GB 的 RAM--这在规模上是不切实际的。为了保证可行性，系统必须支持存储-计算分离，将热数据保存在内存中，冷数据保存在对象存储中，并按需加载向量。

4.多样的查询模式

对话检索并不遵循单一的访问模式。有些查询是纯粹的语义查询（例如，"我们讨论的性能优化"），其他查询是纯粹的时间查询（"上周的所有对话"），还有很多查询结合了多个约束条件（"过去三个月中提到 FastAPI 的 Python 相关讨论"）。数据库查询规划器必须根据不同的查询类型调整执行策略，而不是依靠一刀切的强制搜索。

这四项挑战共同构成了会话检索的核心约束条件。任何试图实现克劳德式按需检索的系统都必须以协调的方式解决所有这些问题。

Milvus 2.6 为何能很好地用于对话检索

Milvus 2.6的设计选择与按需对话检索的核心要求密切相关。以下是关键功能的细分，以及它们如何与实际会话检索需求相匹配。

密集向量和稀疏向量混合检索

Milvus 2.6 本机支持在同一个 Collections 中存储密集向量和稀疏向量，并在查询时自动融合它们的结果。密集向量（例如由 BGE-M3 等模型生成的 768 维嵌入向量）捕捉语义相似性，而稀疏向量（通常由 BM25 生成）则保留精确的关键词信号。

对于"上周有关 Rerankers 的讨论 "这样的查询，Milvus 会并行执行语义检索和关键词检索，然后通过重新排序合并结果。与单独使用其中一种方法相比，这种混合策略在实际对话场景中的召回率要高得多。

存储-计算分离和查询优化

Milvus 2.6 支持两种方式的分层存储：

热数据在内存中，冷数据在对象存储中
索引在内存中，原始向量数据在对象存储中

采用这种设计，大约只需 2 GB 内存和 8 GB 对象存储空间就能存储 100 万个对话条目。通过适当调整，即使启用存储-计算分离，P99 延迟也能保持在 20 毫秒以下。

JSON 粉碎和快速标量过滤

Milvus 2.6 默认启用 JSON 粉碎功能，将嵌套的 JSON 字段扁平化为列式存储。根据官方基准测试，这可将标量过滤性能提高 3-5倍（实际提高因查询模式而异）。

对话检索通常需要通过用户 ID、会话 ID 或时间范围等元数据进行过滤。有了 JSON Shredding，像"过去一周用户 A 的所有对话 "这样的查询可以直接在列式索引上执行，而无需重复解析完整的 JSON blob。

开源控制和操作符灵活性

作为一个开源系统，Milvus 提供了封闭式黑盒解决方案所不具备的架构和操作符控制能力。团队可以调整索引参数，应用数据分层策略，并定制分布式部署以匹配其工作负载。

这种灵活性降低了入门门槛：中小型团队无需依赖过高的基础设施预算，即可构建百万到千万级规模的对话检索系统。

为什么 ChatGPT 和 Claude 走不同的道路

从根本上说，ChatGPT 和 Claude 记忆系统的区别在于各自如何处理遗忘。ChatGPT 倾向于主动遗忘：一旦内存超过固定限制，旧的上下文就会被丢弃。这就以完整性换取了简单性和可预测的系统行为。克劳德倾向于延迟遗忘。从理论上讲，对话历史可以无限制地增长，并委托按需检索系统进行回忆。

那么，为什么这两个系统会选择不同的路径呢？有了上文所述的技术限制，答案就显而易见了：只有在底层基础设施能够支持的情况下，每种架构才是可行的。

如果在 2020 年尝试克劳德的方法，很可能是不切实际的。当时，向量数据库经常会产生数百毫秒的延迟，混合查询的支持也很差，而且随着数据的增长，资源使用量的扩展也令人望而却步。在这种情况下，按需检索会被认为是过度设计。

到 2025 年，情况已经发生了变化。在Milvus 2.6等系统的推动下，基础设施取得了进步，使存储与计算分离、查询优化、密集-稀疏混合检索和 JSON 切碎在生产中变得可行。这些进步降低了延迟、控制了成本，并使大规模选择性检索成为现实。因此，按需工具和基于检索的内存不仅变得可行，而且越来越有吸引力，尤其是作为 Agents 类型系统的基础。

归根结底，架构的选择取决于基础设施是否可行。