大模型“记忆”与“个性化”：从上下文管理到用户画像的工程实践

围绕新一代大模型的能力演进，“记忆”与“个性化”正在从演示性的亮点功能，转变为决定应用可用性的基础设施。业界普遍认为，下一代模型竞争的焦点之一，是能否在长周期交互中稳定地“记住该记的、忘掉该忘的”，并据此提供一致的个性化服务。本文从工程视角拆解这两条技术主线，讨论其能力分层、实现路径与评测方法。

一、先厘清概念：三种“记忆”不是一回事

讨论记忆之前，必须先区分三个层次，否则很容易把工程问题误当成模型能力问题。

1. 上下文窗口内的短期记忆

这是最容易被误解的一层。上下文窗口扩大，确实让模型在一次请求内“看到”更多信息，但它本质上是无状态的：请求结束，一切归零。窗口再大也只是“看得更多”，而不是“记得更久”。把它当作记忆系统，会带来两个直接后果：成本随长度线性上升，以及长上下文中的信息衰减（即“中间遗忘”现象）。

2. 跨会话的长期记忆

这一层才对应通常所说的“记忆功能”。它需要外部存储支撑，核心动作是写入、检索、更新、遗忘。典型流程是：从对话中抽取值得保留的事实与偏好，结构化写入存储；下次交互时按相关性召回，注入提示词。

3. 模型参数内的“记忆”

即训练数据固化到权重中的知识。它更新成本高、不可按用户隔离，因此不适合承载个性化信息。把用户偏好写进参数既不现实也不合规。

工程上真正可落地的是第二层：用外部存储构建可控、可审计、可删除的记忆系统。

二、记忆系统的四步闭环

一个可用的长期记忆系统，通常包含抽取、存储、检索、治理四个环节。

2.1 抽取：从对话到结构化事实

原始对话包含大量冗余与噪声，直接整段落库会导致检索质量下降。推荐做法是做一次轻量抽取，产出结构化条目：

{
  "user_id": "u_123",
  "type": "preference",
  "key": "output_format",
  "value": "偏好表格形式的对比结论",
  "confidence": 0.86,
  "source_turn": 12,
  "created_at": "2025-01-01T10:00:00Z",
  "ttl_days": 180
}

几个关键设计点：

• 类型化：区分事实（用户所在行业）、偏好（回答风格）、任务状态（正在处理的项目）三类，检索策略不同。
• 置信度：由抽取环节给出，低置信度条目进入待确认区，避免错误信息污染画像。
• 来源可追溯：保留原始轮次引用，便于用户质询与人工复核。
• 时效字段：偏好会漂移，必须支持过期。

2.2 存储：分层选型

不同记忆对读写模式的要求差异很大，建议分层：

记忆类型	典型特征	存储选型建议
会话内上下文	高频读写、生命周期短	内存缓存 / 键值存储
结构化画像	低频写、按用户精确读	关系型数据库
语义记忆片段	需要相似度检索	向量检索 + 元数据过滤
原始对话归档	写入密集、需长期保留	对象存储

实践中常见组合是：关系型数据库存画像与元数据，向量索引存语义片段，原始日志落对象存储供审计。在云上部署时，上述能力可分别对应关系型数据库、向量检索服务、对象存储与日志服务等通用类目，按需组合即可。

2.3 检索：相关性不等于有用性

记忆召回最常见的失败不是“找不到”，而是“找太多”。把十几条记忆无差别塞进提示词，既推高成本，又稀释了关键信息。建议的召回策略：

1. 硬过滤：按用户、租户、记忆类型、有效期过滤，保证隔离与合规。
2. 混合排序：向量相似度 + 时间衰减 + 置信度加权，公式可简化为 score = α·sim + β·recency + γ·confidence。
3. 条数与 token 预算双限：例如最多 8 条、总长不超过 800 token。
4. 冲突消解：同一 key 存在多条记录时，以时间最新且置信度达标者为准，其余降权而非删除。

2.4 治理：遗忘比记住更重要

没有删除能力的记忆系统在生产环境不可接受。至少需要支持：

• 用户主动删除：按条目、按类型、按时间区间。
• 自动过期：依据 ttl_days 定时清理。
• 租户隔离：存储层与检索层双重校验，杜绝跨用户召回。
• 变更审计：记录谁在何时写入或修改了哪条记忆。

三、个性化：从画像到策略

记忆是原料，个性化是产品化输出。两者之间还差一层“策略”。

3.1 画像的三层结构

• 稳定属性：行业、角色、语言偏好，变化慢，可长期复用。
• 行为偏好：回答长度、格式倾向、术语深度，中等频率更新。
• 即时意图：当前任务目标，随会话变化，通常不落长期库。

分层的意义在于更新策略不同：稳定属性可批量刷新，行为偏好需增量更新，即时意图只存在于会话上下文。

3.2 个性化的注入方式

常见有三种，复杂度递增：

方式一：系统提示词拼接。 把画像摘要渲染成一段文字注入。实现简单，适合冷启动。

方式二：检索增强。 按当前 query 动态召回相关记忆片段，与提示词一起送入模型。灵活但对检索质量依赖高。

方式三：策略路由。 依据画像选择不同的提示模板、工具集或后处理规则。例如对偏好简洁输出的用户跳过详细展开环节。

def build_prompt(user_id, query):
    profile = profile_store.get(user_id)          # 稳定属性
    memories = memory_store.search(                # 动态召回
        user_id=user_id, query=query, top_k=8
    )
    style = profile.get("output_format", "default")
    template = TEMPLATES.get(style, TEMPLATES["default"])
    return template.render(profile=profile, memories=memories, query=query)

3.3 效果与成本的平衡

个性化不是越多越好。经验上应遵循三条原则：只注入与当前任务相关的记忆、对画像做摘要而非原文透传、为召回结果设置 token 上限。否则很容易出现“个性化带来了 30% 的成本上升，却只换来边际的体验改善”。

四、如何评测：把“感觉更好”变成指标

记忆与个性化最容易被含糊处理的地方是评测。建议至少覆盖四类指标：

• 记忆准确率：抽取条目与人工标注的一致率，可用抽样评估。
• 召回命中率：需要记忆的场景中，正确条目进入提示词的比例。
• 一致性：跨会话重复询问同一偏好，回答是否稳定。
• 污染率：错误记忆被召回并影响输出的比例，这项最应被监控。

离线可用构造多轮对话测试集，在线则通过用户纠正行为（如重复说明同一偏好）作为负向信号。把“用户第二次说同一件事”的比例作为核心观测指标，往往比主观评分更敏感。

五、风险与边界

隐私与合规是首要约束。记忆系统存储的是用户长期行为数据，必须做到目的明确、最小必要、可删除、可导出。跨租户隔离要在存储与检索两层同时校验，不能只依赖应用层过滤。

错误记忆的放大效应同样值得警惕。一条错误偏好一旦写入，可能在数十次会话中持续影响输出，且用户难以察觉来源。因此低置信度条目应延迟生效，并保留可解释的来源引用。

能力边界也需要诚实对待：当前阶段的“记忆”本质是检索增强的外部状态管理，模型本身并不具备持续学习能力。把它宣传成“模型记住了你”容易造成预期错配，工程上更准确的说法是“系统为你维护了一份可检索的偏好档案”。

六、结语

记忆与个性化的技术栈并不神秘，难点不在单点算法，而在闭环设计：抽取要准、存储要分层、检索要克制、治理要彻底、评测要可量化。对开发者而言，与其等待模型能力的下一次跃迁，不如先把这套外部状态管理的基础设施搭稳——它决定了应用能否在长周期使用中保持一致体验，也决定了当更强的模型到来时，你能否以最小成本承接其能力。

真正决定产品上限的，往往不是模型记得多少，而是系统记得对不对、该忘的有没有忘。