【Spring AI Alibaba 实战】大模型也有“金鱼记忆”？详解短时记忆（Chat Memory）核心原理与生产级实践

摘要：在使用 Spring AI Alibaba 开发大模型应用时，你是否发现模型总是“记不住”上一轮对话的内容？这并非模型智商问题，而是缺少了“短时记忆”机制。本文将深入剖析 Spring AI Alibaba 中 Chat Memory 的设计哲学，从内存存储到 Redis 持久化，手把手带你构建具备上下文感知能力的智能应用，并附上生产环境的避坑指南。

一、 为什么大模型需要“短时记忆”？

在 LLM（大语言模型）的底层原理中，模型本身是无状态（Stateless）的。每一次 API 调用对模型来说都是全新的开始，它并不知道你 3 秒前问了什么。

所谓的“多轮对话”，本质上是在每次请求时，将历史消息列表（History Messages）连同当前用户输入一起打包发送给模型。

[系统提示词] + [历史消息1] + [历史消息2] + ... + [用户最新提问] --> LLM --> 回复

Spring AI Alibaba封装了这一繁琐过程，提供了ChatMemory接口，让 Java 开发者能够像操作普通对象一样管理对话上下文。

短时记忆 vs 长时记忆

• 短时记忆 (Short-Term Memory)：即本文重点。指当前会话窗口内的上下文，受限于模型的 Context Window（如 8k/32k/128k tokens）。特点是读写极快、精确匹配、随会话结束而消失。
• 长时记忆 (Long-Term Memory)：通常基于向量数据库（Vector Store）实现 RAG。用于检索跨会话的历史知识，特点是模糊检索、持久化、容量无限。

二、 Spring AI Alibaba 中的 ChatMemory 架构

在 Spring AI Alibaba 1.0+ 版本中，记忆模块的设计遵循了 Spring 一贯的抽象原则：

1. ChatMemory 接口：定义了add,get,clear等标准操作。
2. MessageChatMemoryAdvisor：这是核心组件！它以Advisor（拦截器）的形式介入 ChatClient 的请求链路。
   • Before Request：自动从 Memory 中读取历史消息，注入到 Prompt 中。
   • After Response：自动将用户的提问和模型的回复写入 Memory。
3. ChatMemoryRepository：存储层的抽象。支持 InMemory、Redis、JDBC 等多种实现。

💡核心变化提示：在旧版本中我们可能直接使用ChatMemory，但在新版 Spring AI 中，推荐使用MessageChatMemoryAdvisor配合ChatClient，这是目前最优雅的声明式用法。

三、 快速上手：3 步实现多轮对话

1. 添加依赖

确保你的pom.xml包含 Spring AI Alibaba Starter：

<dependency><groupId>com.alibaba.cloud.ai</groupId><artifactId>spring-ai-alibaba-starter</artifactId><version>1.0.0-M6.1</version><!-- 请使用最新版本 --></dependency>

2. 配置 ChatClient 与 Memory

@ConfigurationpublicclassAiConfig{@BeanpublicChatMemorychatMemory(){// 生产环境建议替换为 RedisChatMemoryRepositoryreturnMessageWindowChatMemory.builder().chatMemoryRepository(newInMemoryChatMemoryRepository()).maxMessages(20)// ⚠️ 关键参数：保留最近20条消息.build();}@BeanpublicChatClientchatClient(ChatModelchatModel,ChatMemorychatMemory){returnChatClient.builder(chatModel).defaultSystem("你是一个专业的Java技术顾问，回答简洁明了。").defaultAdvisors(newMessageChatMemoryAdvisor(chatMemory)// 👈 挂载记忆 Advisor).build();}}

3. 发起多轮对话

@RestController@RequestMapping("/api/chat")publicclassChatController{privatefinalChatClientchatClient;publicChatController(ChatClientchatClient){this.chatClient=chatClient;}@GetMappingpublicStringchat(@RequestParamStringmessage,@RequestParam(defaultValue="default")StringconversationId){// conversationId 用于隔离不同用户/会话的记忆returnchatClient.prompt().user(message).advisors(a->a.param(CHAT_MEMORY_CONVERSATION_ID_KEY,conversationId)).call().content();}}

测试效果：

1. 发送：“我叫张三” → 回复：“你好张三…”
2. 发送：“我叫什么名字？” → 回复：“你叫张三。” ✅ 记忆生效！

四、 进阶：生产环境的 4 个关键考量

在 Demo 中使用InMemoryChatMemoryRepository没问题，但在生产环境中，你必须考虑以下问题：

1. 持久化存储选型

服务重启后内存数据会丢失。推荐方案：

• Redis：首选。TTL 天然适配会话过期，读写性能高。Spring AI 已内置RedisChatMemoryRepository。
• MySQL/PostgreSQL：适合需要复杂查询、审计或已有成熟 DB 基础设施的团队。
• Cassandra/MongoDB：适合超大规模并发写入场景。

2. 窗口大小策略 (Window Size)

不要盲目设置maxMessages=100！

• Token 成本：历史消息越多，每次调用的 Token 消耗呈线性增长。
• 注意力分散：过长的上下文可能导致模型“迷失”，忽略中间的关键信息（Lost in the Middle 现象）。
• 建议：一般客服场景 10-20 条即可；复杂编程助手可设为 30-50 条，并配合 Summary 策略。

3. 会话隔离与安全

永远不要使用默认 conversationId！
必须从 JWT Token、Session ID 或业务订单号中提取唯一标识。否则会导致用户 A 看到用户 B 的聊天记录，这是严重的 P0 级安全事故。

4. 当短时记忆不够用时

如果对话超过了窗口限制，不要简单地丢弃旧消息。可以考虑：

• 摘要压缩：使用另一个小模型对旧消息进行 Summarize，将摘要作为 System Prompt 的一部分。
• 混合记忆：将溢出的历史消息异步写入 Vector Store，当用户提及“上周讨论的方案”时，通过 RAG 检索回来注入上下文。

五、 常见误区排查

六、 总结

Spring AI Alibaba 通过 Advisor 模式，将大模型短时记忆的实现从“手动拼接数组”提升到了“声明式配置”的高度。掌握ChatMemory不仅是实现多轮对话的基础，更是构建复杂 Agent 工作流的第一步。

下一步学习建议：

1. 尝试集成 Redis 实现分布式会话记忆
2. 研究VectorStoreChatMemoryAdvisor实现长短期记忆融合
3. 阅读 Spring AI Alibaba 官方文档关于 Function Calling 与 Memory 的配合使用

参考资料：

• Spring AI Alibaba 官方文档
• Spring AI Reference - Chat Memory
• 阿里云百炼平台 - 通义千问 API 文档

如果这篇文章对你有帮助，欢迎点赞👍收藏⭐关注🔔三连支持！有问题欢迎评论区交流~