ChatGPT Memory 架构解析：长上下文、向量检索与跨会话持久化

ChatGPT Memory 不是『神奇的记忆』——它是三层架构组合：1.05M token 长上下文 + 向量检索（RAG）+ 跨会话持久化。本文从架构师视角拆这三层、给自家产品搭 Memory 的选型建议、写入策略、压缩算法、token 成本控制。

Memory 三层架构

┌─────────────────────────────────────────────┐
│  Layer 1: 长上下文（1.05M token）             │
│  - 最近 N 轮对话原文                          │
│  - 当前会话摘要                               │
│  - 用户偏好缓存                               │
└─────────────────────────────────────────────┘
              ↑ 召回 / 写入
┌─────────────────────────────────────────────┐
│  Layer 2: 向量检索层                          │
│  - 语义匹配（用户 query → 候选 memory 项）      │
│  - top-K 召回 + 重排序                        │
│  - 返回 (memory_id, text, score, timestamp)   │
└─────────────────────────────────────────────┘
              ↑ 持久化
┌─────────────────────────────────────────────┐
│  Layer 3: 持久化存储                          │
│  - Vector store（pgvector / Pinecone）        │
│  - KV store（偏好 / 设置）                    │
│  - 完整对话存档（用于重训练 / 审计）           │
└─────────────────────────────────────────────┘

每层承担不同职责：

• Layer 1（长上下文）：给模型『回忆』窗口。1.05M token 看似大，但每次调用都塞满 cost 极高，所以只放『最近 N 轮 + 当前摘要』。
• Layer 2（向量检索）：按需召回历史 memory。Layer 1 放不下时，从 vector store 找 top-K 相关项塞 prompt。
• Layer 3（持久化）：memory 数据落盘。新对话进来 → 摘要 → 写入；用户删除 → 删除；跨设备同步。

核心设计原则——memory 不是用来替代 prompt 的，是用来减少重复输入和保留跨会话上下文的。

Vector store 选型

生产环境选型取决于规模：

pgvector 实操：

-- 启用 pgvector
CREATE EXTENSION IF NOT EXISTS vector;

-- memory 表
CREATE TABLE memories (
  id BIGSERIAL PRIMARY KEY,
  user_id TEXT NOT NULL,
  conversation_id TEXT,
  memory_text TEXT NOT NULL,
  embedding vector(3072),  -- text-embedding-3-large 维度
  memory_type TEXT,        -- 'preference' / 'fact' / 'summary'
  confidence FLOAT,
  created_at TIMESTAMPTZ DEFAULT now(),
  version INTEGER DEFAULT 1
);

-- HNSW 索引（快速近似最近邻）
CREATE INDEX ON memories USING hnsw (embedding vector_cosine_ops)
  WITH (m = 16, ef_construction = 64);

召回 SQL：

-- top-5 召回
SELECT id, memory_text, memory_type,
       1 - (embedding <=> $1) AS similarity
FROM memories
WHERE user_id = $2
  AND version = (SELECT MAX(version) FROM memories WHERE user_id = $2)
ORDER BY embedding <=> $1
LIMIT 5;

性能上 pgvector + HNSW 在 100K 向量下召回 < 10ms，足够生产用。

Memory 写入策略

错误做法：每 turn 都写。1 个对话 50 turn 就写 50 条 memory，存储爆炸、噪声多。

正确做法：对话结束后生成三段式 summary 一次写入。

def summarize_and_store(conversation):
    response = client.responses.create(
        model="gpt-5.6-luna",  # 摘要用最便宜的
        input=[
            {"role": "system", "content": """你是 memory 摘要器。给定一段对话，输出三段：

1. 用户偏好（preferences）：用户表达的偏好、习惯、风格要求
2. 关键事实（facts）：用户提到的事实性信息（住址 / 工作 / 朋友名字等）
3. 对话摘要（summary）：1-3 句话总结这次对话的核心内容

每段用 JSON 数组，每个元素 ≤ 200 字。只保留 confidence 高的，标记低 confidence 的不输出。"""},
            {"role": "user", "content": format_conversation(conversation)},
        ],
    )

    result = parse_summary(response.output_text)

    # 写入 vector store
    for memory in result.preferences + result.facts + [result.summary]:
        if memory.confidence < 0.7:
            continue
        embed = embed(memory.text)
        db.insert_memory(
            user_id=conversation.user_id,
            memory_text=memory.text,
            embedding=embed,
            memory_type=memory.type,
            confidence=memory.confidence,
            conversation_id=conversation.id,
        )

关键设计：

• 用最便宜的模型（gpt-5.6-luna）做摘要，节省成本。
• confidence 阈值过滤噪声（< 0.7 不写入）。
• 三段式比单一 summary 更结构化，召回时按 type 过滤更精准。

上下文压缩策略

1.05M token 不能每次都塞满 prompt。三种压缩策略叠加用：

Sliding window（最近 N 轮）

# 最近 20 轮对话原文
recent_turns = conversation.messages[-40:]  # 20 turn = 40 message

固定窗口，简单可靠，适合实时对话。

Hierarchical summary（旧对话压缩）

# 超过 20 轮的部分，用 summary 代替
if len(conversation.messages) > 40:
    older_summary = summarize_older(conversation.messages[:-40])
    prompt_messages = [
        {"role": "system", "content": f"对话历史摘要：{older_summary}"},
        *recent_turns,
    ]

每次对话结束，更新一次 summary。

按需召回（vector store 检索）

# 用户问题进来时，按问题召回相关 memory
relevant_memories = recall_top_k(user_query, user_id, k=5)

prompt_messages = [
    {"role": "system", "content": f"用户历史相关记忆：{format_memories(relevant_memories)}"},
    {"role": "system", "content": f"对话历史摘要：{older_summary}"},
    *recent_turns,
    {"role": "user", "content": user_query},
]

召回的 memory 只塞 top-K，不全塞。

Token 成本控制

Memory 系统的成本由三部分组成：

# 假设：每次调用 prompt ≈ 50K tokens（20 turn + summary + 5 memory）
# GPT-5.6 Terra: $2.50/$15 per MTok
cost_per_call = (50 * 0.001 * 2.5) + (1 * 0.001 * 15)  # ≈ $0.14

# 100 万次调用 / 月 = $140K
monthly_cost = 1_000_000 * 0.14  # $140K

优化：

四件套上齐，月成本从 $140K 降到 ~$35K。

跨会话一致性

跨设备 / 跨会话保持 memory 一致的关键是版本化：

# 写入时带 version
db.insert_memory(
    user_id=user_id,
    memory_text=memory.text,
    embedding=embed,
    version=current_version + 1,  # 单调递增
    created_at=now(),
)

# 召回时只取最新 version
SELECT ... WHERE user_id = $1
  AND version = (
    SELECT MAX(version) FROM memories WHERE user_id = $1
  )

关键设计：

• 每条 memory 带 (user_id, version, created_at, conversation_id)。
• 召回时只取最新 version，旧 memory 软删除（标记 deleted=true）。
• 用户可以『回滚』——撤销最近一次 memory 写入。

常见坑

1. 每 turn 都写：存储爆炸 + 噪声多。改用对话结束一次性摘要。
2. 不标 confidence：低质量 memory 污染召回。LLM 输出时强制 confidence 评分。
3. 不压缩直接塞：1.05M 看似大但成本高。用 hierarchical summary + sliding window。
4. 跨会话版本冲突：用户 A 在手机和电脑同步时 memory 冲突。用 version + timestamp 解决。
5. GDPR 不支持删除：欧盟用户有权要求删除所有 memory 数据。架构上要支持 user_id 级别的整批删除。
6. 召回的 memory 当成事实：memory 是用户 / 模型生成的，可能错。让模型在 prompt 里知道 memory 是『用户过去说的话』，不是客观事实。

下一步

• 想了解 ChatGPT UI 端的 Memory 用法？读 《ChatGPT Memory 完全使用手册》。
• 想了解 Memory 的实际应用场景？读 《ChatGPT Memory 12 个高价值使用场景：从技术栈到家庭信息》。
• 想了解 GPT-5.6 家族的长上下文能力？读 《GPT 模型完全指南（2026-07）：GPT-5.6 Sol / Terra / Luna 选型》。