【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。

1. ChatMemoryRepository：存储层的抽象。支持 InMemory、Redis、JDBC 等多种实现。

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

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

1. 添加依赖

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

<dependency><groupId>com.alibaba.cloud.aigroupId><artifactId>spring-ai-alibaba-starterartifactId><version>1.0.0-M6.1version> 
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();  }
}

测试效果：

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 检索回来注入上下文。

五、 常见误区排查

问题现象	可能原因	解决方案
模型完全不记得上文	未注册 MessageChatMemoryAdvisor	检查 ChatClient 构建链
记住了别人的对话	conversationId 固定或未传	确保每个会话有唯一 ID
报错 Token Limit Exceeded	maxMessages 设置过大	减小窗口或启用 Token 级别的截断
Redis 连接超时	序列化配置错误	检查 Message 对象的序列化器配置

六、 总结

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 文档

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