LLM 应用记忆模式怎么选型更合理

一、什么是 LLM 应用中的“记忆”

在基于大语言模型构建对话式应用时，“记忆”并不是模型自身具备的持久存储能力，而是应用层为了维持多轮对话连贯性所设计的一套上下文管理机制。简单来说，记忆决定了每一次调用大模型时，哪些历史信息会被重新放入提示词中，哪些信息会被丢弃、压缩或改写。

从技术视角看，记忆模式解决的核心问题是：在有限上下文窗口和成本约束下，如何让模型尽可能准确地理解当前对话背景。 从业务视角看，它决定了一个对话应用能够支撑多长的交互轮次、多大的用户规模，以及能否在跨会话场景中保持用户偏好和事实信息。从使用视角看，记忆模式直接影响用户感知——回答是否连贯、响应是否变慢、是否“忘记”了之前说过的话。

理解记忆模式的本质，是理解每一种方案在“信息保真度”“token 成本”“响应延迟”“跨会话能力”四个维度上的取舍。

二、为什么记忆模式需要被认真对待

早期 LLM 应用开发中，开发者往往采用最简单的做法：把对话历史全部保存，每次请求时完整拼接。这种方式在原型阶段没有问题，但随着对话轮次增加和用户规模扩大，三个问题会集中暴露。

第一，成本随对话长度非线性增长。 假设每轮对话用户与助手合计产生约 100 token，那么第 n 轮调用时累计输入约为 n×(n-1)/2×100 token 的量级。第 10 轮约 5,500 token，第 50 轮约 127,500 token，第 100 轮约 505,000 token。如果输入单价为每千 token 0.01 美元，单用户第 100 轮的单次调用成本约为 0.5 美元。以 1000 个日活用户计算，仅输入成本每日就可能达到数百美元量级，月度成本极为可观。

第二，响应延迟与上下文长度并非线性关系。 大模型的推理时间与输入 token 数的关系通常近似二次方增长。将上下文从 16K 扩展到 128K，推理时间可能不是增加 8 倍，而是增加数十倍。这直接导致用户在使用过程中感受到“越聊越慢”，严重影响体验。

第三，长上下文并不意味着更好的理解效果。 多项研究表明，大语言模型在长上下文中存在注意力分布不均匀的现象，中间部分的输入信息更容易被忽略，即所谓“中间信息丢失”问题。同时，较早的历史信息可能对当前回答产生干扰，使模型混淆事实或产生错误推理。换句话说，信息放进去并不等于信息被有效利用。

此外，缓冲记忆通常是会话级的。用户刷新页面、更换设备或会话过期后，所有历史信息即告丢失，无法实现真正的用户级记忆。

三、七种主流记忆模式解析

工业界目前常用的记忆模式大致可归纳为七种，从简单到复杂依次如下。

1. 缓冲记忆

原理： 保存所有对话历史，每次调用 LLM 时完整传递。

优点： 信息无损，实现最简单，通常一行代码即可完成，且兼容所有大模型接口。

缺点： token 成本随对话长度快速攀升，长对话下响应变慢，超出上下文窗口后需要截断，且不具备跨会话能力。

适用场景： 一次性短对话（通常不超过 5 轮）、开发调试环境、对信息完整性要求极高且成本不敏感的业务场景。典型应用如临时问答工具、简单 FAQ 机器人。

2. 滑动窗口记忆

原理： 只保留最近 K 轮对话，更早的历史信息直接丢弃。

优点： 实现简单，token 消耗可控，响应速度稳定。

缺点： 早期对话中的关键事实会丢失，如果用户在后续对话中引用前面提到的信息，模型将无法感知。

适用场景： 对话状态变化较快、对历史依赖较弱的场景，例如实时客服中的快速轮转问答、短期任务型对话。

3. 滑动窗口 + 摘要记忆

原理： 保留最近 K 轮完整对话，同时对更早的历史内容进行摘要压缩，将摘要与最近对话一起传递给模型。

优点： 在控制 token 成本的同时保留了对早期信息的“模糊记忆”，比单纯滑动窗口具有更好的连贯性。

缺点： 摘要过程本身需要额外的 LLM 调用或计算消耗，摘要质量直接影响模型对历史信息的理解准确性，且摘要中的关键细节可能被泛化或丢失。

适用场景： 中等长度对话、需要保持一定上下文连贯性但对细节精度要求不极端的场景，如个人助理类应用、多轮任务引导。

4. 实体记忆

原理： 从对话中提取结构化实体及其属性（如用户姓名、偏好、订单号、地址等），以结构化数据形式存储，调用时按需注入。

优点： 信息密度高，token 消耗低，跨会话可持久化，适合用户画像和偏好管理。

缺点： 依赖实体提取的准确性，提取过程需要额外处理逻辑或模型调用，对于非结构化、临时性信息覆盖不足。

适用场景： 电商客服、预约系统、个性化推荐等需要长期维护用户属性信息的应用。

5. 向量检索记忆

原理： 将历史对话切分为片段，通过嵌入模型转换为向量并存入向量数据库。每次新对话到来时，根据语义相似度检索最相关的历史片段，与当前上下文一起注入。

优点： 支持大规模长期记忆，检索按语义进行而非简单时间顺序，跨会话可用，token 成本可控。

缺点： 系统架构复杂度较高，需要维护嵌入模型、向量数据库和检索逻辑，检索质量依赖切分策略和嵌入模型效果，可能漏召回关键信息。

适用场景： 知识密集型对话、个人知识库助手、长期陪伴型应用、需要跨多个会话保持事实一致性的场景。

6. 图记忆

原理： 将对话中的实体、事件、关系构建为知识图谱结构，以图查询或子图注入的方式向模型提供上下文。

优点： 对复杂关系和推理支持最好，信息组织方式更接近人类认知结构，适合多实体关联分析。

缺点： 构建和维护成本最高，信息抽取、关系识别、图存储和查询链路复杂，对实时性要求高的场景有挑战。

适用场景： 复杂业务系统、医疗问诊辅助、法律信息梳理、企业知识管理等高价值、强逻辑关联场景。

7. 混合记忆

原理： 组合上述多种模式，根据对话阶段、信息类型和查询需求动态选择记忆策略。例如短期对话使用缓冲或滑动窗口，长期用户画像使用实体记忆，历史知识检索使用向量记忆。

优点： 灵活度最高，可以在信息保真度、成本和延迟之间取得接近最优的平衡。

缺点： 系统设计和工程实现最为复杂，需要统一调度多种记忆模块，维护成本高。

适用场景： 企业级对话平台、复杂的智能助手产品、需要同时处理短期任务和长期用户关系的应用。

四、如何选择适合的记忆模式

选择记忆模式不能只凭直觉，需要从以下四个维度进行系统评估。

对话长度。 如果应用的典型对话在 5 轮以内，缓冲记忆完全可以满足需求，不必过度设计。如果对话可能持续数十轮甚至跨会话，必须引入滑动窗口、摘要或向量检索等机制。

信息类型。 需要保留的是“事实性信息”“偏好性信息”还是“过程性信息”？事实性信息适合用实体记忆或向量检索保存，偏好性信息适合实体记忆，过程性信息用滑动窗口即可。

成本敏感度。 面向大规模用户的产品必须优先控制单次调用 token 消耗，缓冲记忆在大规模场景下几乎不可持续。

工程能力。 向量检索记忆和图记忆需要额外的基础设施支持，选择前需要评估团队在数据管道、向量数据库、嵌入模型调用等方面的工程能力。百度智能云提供的大模型平台及配套的向量数据库、对象存储、消息队列等云服务，可以帮助开发者降低构建复杂记忆系统的门槛，但具体选型仍需根据业务需求决定。

五、缓冲记忆的替代策略实践

以一个中等长度的客服对话为例。用户在第 1 轮提供订单号，第 2 轮询问物流进度，第 3 轮要求修改收货地址，第 4 轮确认修改结果。如果使用纯缓冲记忆，四轮信息全部保留，消耗可控。但如果对话延伸到 30 轮，且用户在不同轮次中提及多个订单和不同诉求，缓冲记忆会迅速膨胀。

此时可以采用“滑动窗口 + 实体记忆”的方案：将订单号、收货地址、用户联系方式等结构化信息抽取到实体记忆层，对话中仅保留最近 5 轮完整上下文。每次调用模型时，将实体记忆中的关键字段与最近 5 轮对话组合注入。这样既保证了关键事实不丢失，又大幅降低了 token 消耗。

如果应用场景涉及用户长期知识积累，例如个人学习助手，则适合采用“向量检索 + 滑动窗口”的混合模式。每次会话中近期的对话保留完整，更早的知识点以向量形式存储，新问题到来时按语义相似度检索相关历史片段并纳入上下文。

通用伪代码示例如下：

function build_context(user_input, short_memory, entity_memory, vector_memory):
    # 短期记忆：最近 K 轮完整对话
    recent = short_memory.get_recent(k=5)
    # 实体记忆：按需抽取用户相关字段
    entities = entity_memory.query(user_id)
    # 向量记忆：语义检索相关历史片段
    retrieved = vector_memory.search(user_input, top_k=3)
    # 组合为最终提示词
    context = format_context(recent, entities, retrieved)
    return context + user_input

上述示例仅为通用逻辑说明，具体实现需根据所用平台和框架调整。

六、使用注意事项

上下文窗口限制。 无论采用何种记忆模式，最终注入的上下文总量都不能超过模型的最大上下文窗口。即使使用 128K 窗口的模型，也不建议将上下文填满，因为长上下文下的注意力衰减和推理延迟会显著影响效果。

信息一致性。 使用摘要或实体记忆时，需要关注压缩或提取过程中可能引入的事实偏差。建议在设计中对关键事实字段采用原样存储策略，避免经过模型改写。

延迟预算。 向量检索、实体提取、摘要生成等环节都会增加端到端延迟，需要纳入整体响应时间预算进行优化。对于实时性要求高的场景，应尽量简化记忆链路。

隐私与安全。 长期记忆涉及用户数据的持久化存储，需要明确告知用户并遵循相关合规要求。敏感信息应支持手动清除或自动过期机制。

可观测性。 复杂记忆系统需要提供调试能力，开发者应能够查看每次调用实际注入了哪些记忆内容，以便定位回答偏差的来源。

七、总结

LLM 应用中的记忆模式本质上是上下文管理策略，不同方案在信息保真度、成本、延迟和跨会话能力之间进行了不同的取舍。缓冲记忆是最简单直接的方案，适合短对话和原型验证，但绝不是所有场景下的默认选择。随着对话长度增长和用户规模扩大，滑动窗口、摘要、实体记忆、向量检索、图记忆以及混合记忆提供了更多的设计空间。开发者应基于对话长度、信息类型、成本预算和工程能力进行系统选型，避免盲目套用缓冲记忆导致成本失控或效果劣化。

对于需要在生产环境中构建复杂记忆体系的团队，可以借助百度智能云的大模型平台及向量数据库、对象存储、消息队列等配套云服务，逐步搭建适合自身业务的记忆架构。但无论采用何种技术底座，选型逻辑始终应回到业务需求本身：需要记住什么、需要记多久、愿意为记忆付出多少成本。