原来ChatGPT的记忆是这么做的

大家好，许久未见，心中充满了思念。在这个不断变化的牛马世界中，每一天都有新的故事上演，繁忙而又充满激情。感谢大家的理解和支持。

最近看到一篇关于ChatGPT记忆系统逆向工程的技术分析，笔者觉得其中的架构设计思路对做对话系统和知识库问答的同学很有参考价值，今天就来深入聊聊这个话题。

码字不易，觉得有价值的话记得点赞、关注。

问题背景与技术动机

我们在讨论什么问题？

当你问ChatGPT"你记得关于我的什么"时，它可能会列出几十条关于你的信息——从名字、职业目标到健身习惯。这引发了一个技术问题：它是如何存储和检索这些信息的？

很多人的第一反应是：肯定用了向量数据库，肯定做了RAG。

但实际逆向分析的结论却出乎意料：没有向量数据库，没有对历史对话的RAG检索。整个记忆系统的架构比想象中简单得多。

这篇文章的核心发现来自对ChatGPT行为的大量实验和对话分析，OpenAI并未公开这些实现细节。

ChatGPT的上下文架构

六层结构模型

通过逆向分析，ChatGPT每次接收消息时的上下文结构大致如下：

[0] System Instructions   // 系统指令
[1] Developer Instructions  // 开发者指令
[2] Session Metadata     // 会话元数据（临时）
[3] User Memory       // 用户记忆（长期事实）
[4] Recent Conversations   // 近期对话摘要
[5] Current Session Messages // 当前会话消息
[6] Your Latest Message   // 用户最新输入

前两层定义高层行为和安全规则，技术上没有太多可讨论的。真正有意思的是从第三层开始。

第一层：Session Metadata（会话元数据）

技术定义

会话元数据在每个session开始时注入一次，不会被永久存储，session结束后即丢弃。

包含的信息类型：

• • 设备类型（desktop/mobile）
• • 浏览器和User Agent
• • 大致地理位置/时区
• • 订阅级别
• • 使用模式和活跃频率
• • 近期模型使用分布
• • 屏幕尺寸、深色模式状态等

实际数据示例

Session Metadata:
- User subscription: ChatGPT Plus
- Device: Desktop browser
- Browser user-agent: Chrome on macOS
- Approximate location: China (may be VPN)
- Local time: ~16:00
- Account age: ~157 weeks
- Recent activity:
  - Active 1 day in the last 1
  - Active 5 days in the last 7
  - Active 18 days in the last 30
- Conversation patterns:
  - Average conversation depth: ~14.8 messages
  - Average user message length: ~4057 characters
- Device environment:
  - Dark mode enabled
  - Screen size: 900×1440

技术意义

这层信息的作用是让模型能够适配用户的使用环境，但不形成长期记忆。比如检测到移动端可能会生成更简洁的回复，检测到深色模式可能在代码展示时考虑配色。

第二层：User Memory（用户长期记忆）

存储机制

ChatGPT有一个专门的工具用于存储和删除关于用户的稳定、长期事实。这些信息会在数周、数月内累积，形成持久化的用户画像。

触发存储的条件：

1. 1. 用户显式要求："记住这个"或"把这个存到记忆里"
2. 2. 模型检测到符合OpenAI标准的事实（如名字、职位、偏好），且用户在对话中隐式同意

存储内容示例

- 用户名字是张三
- 之前在某科技公司和某创业公司工作过
- 偏好通过视频、论文和动手实践相结合的方式学习
- 正在研究现代信息检索系统（LDA、BM25、混合检索、稠密向量、FAISS等）
- 健身习惯：每周跑步3次

关键技术特点

这些记忆被注入到每一次后续的prompt中，作为独立的上下文块存在。这意味着：

• • 存储成本是线性增长的（事实数量 × 平均token数）
• • 检索成本几乎为零（直接注入，无需检索）
• • 更新机制是显式的（用户主动触发）

第三层：Recent Conversations Summary（近期对话摘要）

这是最出乎意料的发现

笔者原本预期ChatGPT会使用某种RAG机制来检索历史对话。但实际上，它用的是轻量级摘要。

ChatGPT维护一个近期对话摘要列表，格式如下：

1. <时间戳>: <对话标题>
|||| 用户消息片段 ||||
|||| 用户消息片段 ||||

关键观察

1. 1.只摘要用户消息，不摘要助手回复
2. 2. 大约保留15条左右的对话摘要
3. 3. 作为用户近期兴趣的粗粒度地图，而非详细上下文

与传统RAG的对比分析

维度	传统RAG方案	ChatGPT摘要方案
存储	向量化每条历史消息	预计算轻量摘要
检索	每次query执行相似度搜索	直接注入，无检索
延迟	较高（取决于向量库规模）	几乎为零
Token消耗	可能拉入完整消息上下文	固定的摘要长度
上下文精度	高（原始内容）	低（仅保留片段）

这是一个典型的precision-latency trade-off：用上下文精度换取响应速度和计算效率。

第四层：Current Session Messages（当前会话消息）

标准滑动窗口机制

当前对话的完整历史（非摘要）会被传递给模型，这是维持会话连贯性的基础。

技术细节

• • 上限基于token数量而非消息条数
• • 超出限制后，当前session中较早的消息会被滚动移除
• • 但User Memory和对话摘要始终保留

这意味着在一个长对话中，你可能会发现模型"忘记"了对话开头的内容，但它仍然记得你是谁、你的偏好是什么。

整体架构的技术分析

工作流程梳理

当你发送一条消息时，系统的处理流程是：

1. 1.Session初始化：注入会话元数据，让模型了解当前使用环境
2. 2.长期记忆加载：用户记忆事实始终被包含在prompt中
3. 3.跨对话感知：近期对话摘要提供历史兴趣的粗粒度信息
4. 4.当前上下文：滑动窗口维护本次对话的连贯性
5. 5.Token预算管理：当session增长时，旧消息滚动移除，但记忆和摘要保留

架构设计的核心洞察

这个架构的关键思路是：不是所有信息都需要以"记忆"的形式存在。

• • Session Metadata → 实时适配环境
• • User Memory → 跨session持久化
• • Conversation Summary → 提供连续性但不追求细节
• • Current Messages → 维持即时连贯性

四个组件各司其职，动态组合。

工程上的务实选择

传统思路可能会想：为什么不直接对所有历史对话做RAG？

答案是成本和延迟的现实约束：

1. 1. ChatGPT的用户量级巨大，对每个query做向量检索的成本不可接受
2. 2. 用户对响应速度的预期很高，额外的检索延迟会显著影响体验
3. 3. 大多数对话场景下，粗粒度的摘要已经够用

这是一个工程妥协，而非技术局限。

对我们的启发

记忆系统设计的方法论

1. 1.分层思考：不同类型的信息适合不同的存储和检索策略
2. 2.显式优于隐式：重要的长期事实通过显式机制存储，而非自动推断
3. 3.预计算换取实时性能：摘要这种预计算策略在特定场景下很有效
4. 4.接受合理的信息损失：完美的历史还原不一定是最优解

适用场景的边界

这套架构适合：

• • 高并发、对延迟敏感的场景
• • 用户画像相对稳定的场景
• • 对话历史的详细内容不是核心价值的场景

不适合：

• • 需要精确检索历史对话细节的场景
• • 知识库问答等需要高recall的场景
• • 用户期望"完美记忆"的场景