今年 4 月，OpenAI 对 ChatGPT 的记忆系统进行了重磅升级：它可以参考用户的全部过往对话来提供更个性化的响应。ChatGPT 不再是那个每次都从零开始、记忆如风的“临时陪聊者”，而正在变成一个真正能“记住你是谁、理解你喜好、回忆你曾说过什么”的“长期陪伴者”。
软件工程师 Eric Hayes 对此进行了逆向拆解——不仅厘清了 ChatGPT 的双重记忆架构，还推测出其背后的实现机制，并给出了完整的技术复刻路径。
本文一共分为三部分：
拆解 ChatGPT 记忆系统是如何运作的
推测背后可能采用的技术实现方式
探索记忆机制如何重塑用户体验
一是「保存记忆（Saved Memory）」 二是「聊天历史（Chat History）」。
当前会话历史（Current session history） 对话历史（Conversation history） 用户洞察（User insights）
用户在 Rust 编程方面有丰富经验，尤其擅长异步操作、线程处理与流式计算；
用户曾多次就 Rust 的异步机制、Trait 对象、Serde 序列化实现、自定义错误处理等话题提出深入问题，时间横跨 2024 年末至 2025 年初；
置信度：高。
{ "type": "function", "function": { "name": "bio", "description": "persist information across conversations", "parameters": { "type": "object", "properties": { "messagage": { "type": "string", "description": "A user message containing information to save" } }, "required": [ "message" ], "additionalProperties": False }, "strict": True }}const BIO_PROMPT: &'static str = r#"You are a tool that transforms user messges into useful user facts. Your job is tofirst transform a user message into a list of distinct facts. Populate the facts arraywith these facts.Next transformt these facts into elliptical descriptive clauses prefaced with apredicate. Populate the clauses array with these.Finally check these clauses against each other and against the clauses in your inputfor contradictions and similarity. If any clauses are overly similar or contradict doNOT populate the output array. Otherwise populate the output array with the checkedclauses."#;async fn bio_transform(existing_facts: &[String], user_message: String)-> Result<Vec<String>>;async fn update_user_bio(user: T, db: D, facts: Vec<String>) -> Result<()>;
bio 工具允许你在不同对话之间“持久化”信息。只需要将你的信息发送至=bio，模型就会“记住”你希望它记住的内容。在之后的对话中，这些信息会出现在模型的上下文设定中。但它也明确设下了几条“记忆边界”：不要用 bio 工具存储敏感信息。敏感信息包括但不限于：用户的种族、民族、宗教信仰、性取向、政治立场、性生活、犯罪记录、医疗诊断、处方药物，以及工会会员身份等。
不要存储短期信息。短期信息指的是用户一时的兴趣、正在进行的项目、当下的愿望或意图等内容。
接下来，用户的事实信息会在每次发送消息时被注入到系统提示词（system prompt）中。为了实现与 ChatGPT 相同的功能，还可以构建一个简单的用户界面，用于查看和删除这些记忆条目。
引用聊天历史
当前会话历史
这一部分的实现非常直接：只需在数据库中筛选用户发送的消息记录（如 ChatMessage 表），按时间排序，并设置消息数量上限即可。
Conversation History
配置两个向量空间：第一个以消息内容（message-content）为索引，第二个则以对话摘要（conversation-summary）为索引。
{embedding: message-content | conversation-summarymetadata: {message_content: string,conversation_title: string,date: Date }}将消息按发送顺序插入到以“消息内容”为索引的向量空间中。一旦某段对话进入足够长时间的非活跃状态（或当用户跳转到其他会话时），则将该对话中的用户消息添加到“对话摘要”索引空间中。
配置第三个向量空间，以“摘要”作为索引，内容为各类摘要信息。
{embedding: conversation-summary,metadata {message_summaries: string[]conversation_title: string,date: Date }}在会话创建后的两周内，将对话摘要和消息插入该向量空间。
每当用户发送一条消息时，对其进行嵌入，并同时查询两个向量空间以检索相似项，检索时限定时间范围为两周内，并对返回结果进行合理上限控制。将检索结果注入到系统提示中（system prompt）。
每当用户发送一条消息时，还需查询摘要空间中过去两周之前的数据，以避免重复引用。将相关结果同样注入到系统提示中。
用户洞察（User Insights）
用户洞察的实现方式有很多种，哪种方式最优还需要进一步讨论与实验，当前尚不明确。
用户洞察很可能是基于前文所述的 Chat History RAG 实现中使用的一个或多个向量空间生成的。用户洞察不要求实时生成，因此通常通过批处理（batching）与某种定期调度任务（cron job）结合使用，周期性地发起更新请求。
用户洞察最棘手的部分在于：如何在不重复或产生矛盾的前提下，持续保持与用户行为模式的同步更新。一种简单但计算代价较高的方式是：每周重新生成所有活跃用户的用户洞察。这种做法可以在保持系统对变化的响应能力的同时，使得洞察可以涵盖超过定期调度周期的更长时间跨度。
配置一个每周运行一次的 Lambda 函数；
查询 ChatMessage 表，找出最近一周内发送过消息的用户；
对于每一个活跃用户，执行一次 insightUpdate Lambda 函数。
insightUpdate Lambda
该算法的目标是基于用户查询生成独特的用户洞察。生成的洞察数量应足够多以具备实用价值，但不能太多，以免无法在 LLM 上下文中被有效使用。为确定可用洞察的最大数量，需要进行一定实验。
考虑到当前问题的约束条件和可用数据，这个过程可以清晰地建模为一个聚类优化问题（clustering optimization problem）。我们希望找到若干个聚类数量 k，要求：
k 小于预设的最大聚类数量（max_clusters）；
各聚类内部的方差尽可能小（低内部离散性）；
并排除离群点（outliers）。
// lower is betterfn eval_clusters(clusters: &Vec<Vec<&V>>) -> f64;fn knn(k: u32, vectors: &Vec<V>) -> Vec<Vec<&V>>;let mut best: f64 = 1.0;let mut best_clustering: Vec<Vec<&V>> = Vec::new();for k in 1..MAX_CLUSTERS {let clusters = knn(k, &vectors);let eval = eval_clusters(&clusters);if eval < best {best = eval;best_clustering = clusters;}}
一旦完成聚类，就可以用大语言模型对用户的消息进行分析，通过精心设计的提示词，引导模型生成类似 ChatGPT 所展现的洞察结果。同时，也可以以确定性的方式添加时间戳。
async fn generate_insights(clusters: Vec<Vec<&V>>) -> Result<Vec<Insight> {let future_insights = clusters.into_iter().map(|cluster| async move {generate_insights(cluster).await}).collect::<Vec<_>>();tokio:join_all(future_insights).await}async fn generate_insight(cluster: Vec<&V>) -> Result<Insight> {let (message_texts, dates) = cluster.into_iter().map(|vector| (vector.message_content, vector.date)).collect::<(Vec<_>,Vec<_>)>();let message_text = message_texts.join('\n');let formatted_date: String = format_date(dates);let insight_text = ai::simple_completion().system_prompt("Prompt to get similar insights to GPT".to_string()).user_message(message_text).complete().await?;Ok(Insight {text: insight_text,formatted_date})
最终，这些洞察可以被整理进一张简单的表格，并在用户对话中作为上下文附加到模型中。
用户体验
在 ChatGPT 上直接使用 OpenAI 模型的体验要优于直接调用 API，这不仅是许多人的直观感受，作者本人也有类似观察。虽然提示词工程在塑造 ChatGPT 的“智能感”中确实起到了一定作用，但内存系统也必然在其中扮演了重要角色。尽管内存机制可能会影响模型的评测表现，但作者目前找到的基准测试都不是在 ChatGPT 平台上进行的，因此无法体现这些系统带来的优势。
也许，比起分析功能或参数，更值得玩味的是这样一个现象：“ChatGPT”正在走向“动词化”的语言命运，就像当年的 “Google” 一样。人们开始说“我去 ChatGPT 一下”，这不仅是一种口语转变，更是市场主导地位的语言注脚。尽管这种现象部分可以归因于先发优势，但 OpenAI 能在浪潮翻涌的竞争中持续站稳脚跟，意味着它交付出的产品，不只是“不输”，而是“有得一拼”，甚至“别有风味”。
在 ChatGPT 的诸多功能中，“记忆”机制的影响最为直接，因为它的内容由用户亲手塑造。用户可以通过系统提示词设定偏好，让 ChatGPT 回应得更“对胃口”。但问题也随之而来：那些最有可能受益于定制化体验的普通用户，恰恰可能不知道如何表达自己的偏好，更不用说让 ChatGPT“记住”它们了。
“用户洞察”机制，正是为了解决这个悖论而诞生的。它将“你是谁，你喜欢什么”这件事，从“要你告诉我”，变成“我自己看得出”。它用自动化的方式捕捉偏好，用细腻入微的理解避免语义歧义，还能根据用户的理解方式，重新组织信息的表达方式。拿我自己来说，系统知道我偏爱技术原理而不是打比方讲故事，因此它会少一些“就像做菜那样”，多一些“这是因为底层调用了这个接口”。
短期对话记忆的实际影响很难精准界定，尽管理论上讲，让一个聊天机器人了解用户最近的行为是合情合理的设想。在更高级的系统中，这种短暂记忆甚至可以让用户在一次全新的对话中抛出含糊不清的问题，而机器人依然能从先前的交互中“意会”出含义。
但至少以作者本人的使用体验来看，ChatGPT 并没有让他产生这种“它记得我刚说过什么”的感觉，也无法举出具体例子说明它曾调用过我上一轮对话的内容。
至于对话历史，它更像是在试图赋予聊天机器人一种“人类记忆”般的语境延续——就像我们与人交谈时，理所当然地期待对方记得我们之前聊过些什么。共享的对话背景可以避免无休止的重复、绕圈子，或逻辑自我打架。但要让这个机制发挥作用，关键在于能否准确提取并运用“有用的那部分”历史，而不是一味堆砌回忆。
至于到底哪一种机制对 ChatGPT“智能感”的提升作用最大？除非进一步实验，否则无法下定论。但就作者目前的观察而言，倾向认为“用户洞察系统”功劳最大，占比可能超过 80%。虽然这个判断尚无严谨数据支撑，但从试验来看，这套基于细致提示的机制确实有效提升了表现，而且它不像对话历史那样依赖复杂的检索流程。
在文末，作者还附上了一些试验过程中的札记，记录了他推导结论时的思考片段与探索线索。尽管这些内容未必严谨周全，却展现了一个技术使用者与系统之间持续互动、不断试探的过程。如果你对这些背后的推理路径与思维细节感兴趣，不妨前往原文一探究竟。
