【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 一贯的抽象原则：
- ChatMemory 接口：定义了
add,get,clear等标准操作。 - MessageChatMemoryAdvisor：这是核心组件！它以 Advisor（拦截器） 的形式介入 ChatClient 的请求链路。
- Before Request：自动从 Memory 中读取历史消息，注入到 Prompt 中。
- After Response：自动将用户的提问和模型的回复写入 Memory。
- 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
@Configuration
public class AiConfig {
@Bean
public ChatMemory chatMemory() {
// 生产环境建议替换为 RedisChatMemoryRepository
return MessageWindowChatMemory.builder()
.chatMemoryRepository(new InMemoryChatMemoryRepository())
.maxMessages(20) // ⚠️ 关键参数：保留最近20条消息
.build();
}
@Bean
public ChatClient chatClient(ChatModel chatModel, ChatMemory chatMemory) {
return ChatClient.builder(chatModel)
.defaultSystem("你是一个专业的Java技术顾问，回答简洁明了。")
.defaultAdvisors(
new MessageChatMemoryAdvisor(chatMemory) // 👈 挂载记忆 Advisor
)
.build();
}
}
3. 发起多轮对话
@RestController
@RequestMapping("/api/chat")
public class ChatController {
private final ChatClient chatClient;
public ChatController(ChatClient chatClient) {
this.chatClient = chatClient;
}
@GetMapping
public String chat(@RequestParam String message,
@RequestParam(defaultValue = "default") String conversationId) {
// conversationId 用于隔离不同用户/会话的记忆
return chatClient.prompt()
.user(message)
.advisors(a -> a.param(CHAT_MEMORY_CONVERSATION_ID_KEY, conversationId))
.call()
.content();
}
}
测试效果：
- 发送：“我叫张三” → 回复：“你好张三...”
- 发送：“我叫什么名字？” → 回复：“你叫张三。” ✅ 记忆生效！
四、 进阶：生产环境的 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 检索回来注入上下文。
五、 常见误区排查
| 问题现象 | 可能原因 | 解决方案 |
|---|---|---|
| 模型完全不记得上文 | 未注册 MessageChatMemoryAdvisor |
检查 ChatClient 构建链 |
| 记住了别人的对话 | conversationId 固定或未传 | 确保每个会话有唯一 ID |
| 报错 Token Limit Exceeded | maxMessages 设置过大 | 减小窗口或启用 Token 级别的截断 |
| Redis 连接超时 | 序列化配置错误 | 检查 Message 对象的序列化器配置 |
六、 总结
Spring AI Alibaba 通过 Advisor 模式，将大模型短时记忆的实现从“手动拼接数组”提升到了“声明式配置”的高度。掌握 ChatMemory 不仅是实现多轮对话的基础，更是构建复杂 Agent 工作流的第一步。
下一步学习建议：
- 尝试集成 Redis 实现分布式会话记忆
- 研究
VectorStoreChatMemoryAdvisor实现长短期记忆融合 - 阅读 Spring AI Alibaba 官方文档关于 Function Calling 与 Memory 的配合使用
参考资料：
- Spring AI Alibaba 官方文档
- Spring AI Reference - Chat Memory
- 阿里云百炼平台 - 通义千问 API 文档
如果这篇文章对你有帮助，欢迎点赞👍收藏⭐关注🔔三连支持！有问题欢迎评论区交流~
