Spring AI生产化改造：对话记忆落Redis、向量检索落ES，重启不再丢上下文

你有没有遇到过这种情况：本地调试什么问题都没有，用户连续追问好几轮，AI都能根据上下文给到连贯的回答。结果一上生产环境就翻车——用户刷新一下页面、负载均衡把请求切到另一台实例、或者你发个版本重启一下应用，AI立刻“失忆”，开始反问“你是谁”“我们刚才聊到哪了”。

多数人第一反应是模型不行，或者Prompt没写对。但我做过一次生产化改造之后可以负责任地说：大部分“失忆”，根本原因在Spring AI默认把对话记忆存在了JVM内存里。内存一没，上下文就没了。想根治这个问题，最直接的做法就是把状态迁出进程——对话记忆落到Redis，向量检索落到Elasticsearch，让应用重启之后还能把上下文找回来。

这篇内容我会把整个改造思路、关键代码、序列化陷阱、ES索引配置、多实例部署问题，以及实测“重启不丢”的验证过程完整过一遍。如果你正在用Spring AI做聊天机器人、知识库问答，或者想把原型项目推向生产环境，这篇文章应该能帮你省掉不少弯路。

1. 改造前复盘：本地记忆的两种典型“失忆”场景

1.1 单实例重启就清空：内存态ChatMemory的天然缺陷

先说说Spring AI里对话记忆的默认实现。早期的Spring AI提供了ChatMemory接口，常用实现是InMemoryChatMemory。从名字就能看出来，它内部只是一个并发Map，以会话ID为key，存消息列表。这个实现简单、零依赖，写Demo没问题，但生产环境里它就是最大的隐患。

我举个例子。你本地起一个服务，聊十轮，模型能准确记得第一轮提到的细节。接着你重新打包、重启服务，再用同一个会话去问“我最初说的那件事是什么”，模型直接傻眼。因为在JVM进程里维护的历史消息随着进程销毁一起没了。用户感知到的就是“AI失忆了”。

这里需要理解Spring AI的对话机制：每次请求时，MessageChatMemoryAdvisor会从ChatMemory里读取历史消息，塞进Prompt上下文。如果存储层没有数据，Advisor拿到的历史列表就是空的，模型自然只能根据当前这一条消息回答。所以问题不是模型记性差，而是我们没给模型提供记忆来源。只要存储还在应用进程内部，这个问题在架构上就无解——进程生命周期就是记忆生命周期。

1.2 多实例轮询导致上下文错乱：比“重启丢”更隐蔽的坑

单实例重启丢还能通过“少发布、别重启”来逃避，但多实例部署就逃不掉了。我用某团队的项目做过一次演练，部署了两台实例，前面挂着负载均衡。第一次请求打到实例A，第二次请求被负载均衡切到实例B。因为两台实例各有一份独立的本地内存，实例B里根本没有实例A写入的对话历史，于是用户发现AI说话上下文接不上，甚至每刷一次页面，回答风格都变一次。

有些团队会尝试用会话粘滞（Session Sticky）来解决，让同一用户的请求始终落在同一台实例上。但粘滞只能缓解，不能根治：实例发布重启、连接池重建、负载均衡节点扩缩容，都会让粘滞失效。就算粘滞一直生效，单实例重启后内存照样清空。归根到底，只要对话状态不在所有实例共享的存储里，分布式环境下就一定会出现上下文断裂。

想通这点之后，改造方向就非常清晰了：把对话记忆从JVM内存挪到外部存储，把向量数据也从本地临时索引挪到共享的向量存储里。于是就有了这篇文章的标题——记忆落Redis，向量落ES，重启再也不丢。

2. 对话记忆落Redis：从继承ChatMemory接口开始

2.1 为什么选Redis而不是MySQL

对话记忆存Redis，这在当时几乎没有犹豫。对话历史的读写特征是高频、单条数据量小、只有最近的若干条有价值，而且天然需要过期策略。Redis的String结构做覆盖写、设置TTL（过期时间）都很直接，读写延迟通常在亚毫秒级别。如果存MySQL，你得建表、设计清理任务、面对慢查询风险，为了几十条文本消息动用数据库，性价比太低。Redis还可以用主从、哨兵、集群来保证可用性，和Spring Boot的集成也成熟，所以它是这个场景里最自然的选项。

需要注意的是，这一步不是换个存储就完事，还要处理序列化、TTL设计和接口语义对齐。下面把核心实现说透。

2.2 自定义RedisChatMemory：核心写法和序列化陷阱

Spring AI的ChatMemory接口抽象得很干净，大致是三个方法：add()写入/覆盖某个会话的历史消息，get()读取最近N条，clear()清空。我们要做的就是用Redis的String结构来实现这三个方法。我这里给出一个精简但完整的写法：

public class RedisChatMemory implements ChatMemory { private final StringRedisTemplate redisTemplate; private final ObjectMapper objectMapper; private final Duration ttl; public RedisChatMemory(StringRedisTemplate redisTemplate, ObjectMapper objectMapper, Duration ttl) { this.redisTemplate = redisTemplate; this.objectMapper = objectMapper; this.ttl = ttl; } private String key(String conversationId) { return "chat:memory:" + conversationId; } @Override public void add(String conversationId, List<Message> messages) { List<MemoryMessage> dtos = messages.stream() .map(MemoryMessage::fromMessage) .collect(Collectors.toList()); String json = objectMapper.writeValueAsString(dtos); redisTemplate.opsForValue().set(key(conversationId), json, ttl); } @Override public List<Message> get(String conversationId, int lastN) { String json = redisTemplate.opsForValue().get(key(conversationId)); if (json == null) { return List.of(); } List<MemoryMessage> dtos = objectMapper.readValue( json, new TypeReference<List<MemoryMessage>>() {}); return dtos.stream() .map(MemoryMessage::toMessage) .skip(Math.max(0, dtos.size() - lastN)) .collect(Collectors.toList()); } @Override public void clear(String conversationId) { redisTemplate.delete(key(conversationId)); } }

这里有几个细节必须展开说。

第一，为什么用StringRedisTemplate而不是RedisTemplate？StringRedisTemplate默认使用String序列化器，key和value都是字符串，不会出现常见的乱码问题。如果你用默认的RedisTemplate配合JDK序列化，存进去可能是一堆二进制乱码，排查起来非常痛苦，所以这里直接选StringRedisTemplate更省事。

第二，为什么要把Message转成MemoryMessage。Spring AI里的Message是一个接口，有UserMessage、AssistantMessage、SystemMessage等多种实现，里面还带着metadata等复杂结构。如果你图省事直接把接口类型交给Jackson序列化，反序列化时大概率会碰到多态类型解析问题。版本一变、类加载路径一变，就可能直接抛异常。稳妥做法是自定义一个精简的记录类型，只保留我们真正关心的人类可读字段：

public record MemoryMessage( String role, String content, Map<String, Object> metadata) { public static MemoryMessage fromMessage(Message message) { return new MemoryMessage( message.getMessageType().name(), message.getText(), message.getMetadata()); } public Message toMessage() { if ("USER".equals(role)) { return new UserMessage(content, metadata); } if ("ASSISTANT".equals(role)) { return new AssistantMessage(content, metadata); } return new SystemMessage(content, metadata); } }

这样我们序列化的是一份完全可控的JSON，不依赖框架内部类的任何特殊标记。虽然损失了“原样保存”的便利性，但换来了跨版本稳定，这个取舍非常值。

第三，为什么用String覆盖写而不是Redis List。可能有人觉得对话历史是线性消息，天然适合List结构。但注意ChatMemory的add()语义是“把当前传入的完整消息列表作为该会话的最新状态”，不是“追加一条”。如果用List结构，执行add()之前要先清空再全量重推，稍不注意就会产生重复消息。用String一次性覆盖写入，逻辑直接、排查简单，而且每次读出来也只是反序列化一个整体字符串，性能上没有任何问题。对话历史不过几十上百条消息，单次读写毫秒级完成，完全够用。

2.3 TTL、Key设计与Redis持久化的配套考虑

对话记忆不能无限膨胀，所以设置TTL是必须的。一般建议比用户会话的活跃周期略长，比如24小时或48小时。如果你做的是客服场景，用户可能隔几天再来，那可以把TTL设到7天，同时做一个定时清理任务去淘汰明显过期的会话。我习惯在key里带上业务前缀和用户维度，像chat:memory:{userId}:{sessionId}，这样即使同一个用户在PC端、App端各开一个会话，也不会串上下文。

这里还要考虑Redis自身的持久化。很多人改造完应用层就以为万事大吉，但Redis如果没开持久化，一旦它自己重启，应用层做得再好也白搭。生产环境我建议至少开启AOF：

appendonly yes appendfsync everysec

再加一份RDB作为兜底快照。这样Redis进程挂了之后能从磁盘恢复，才真正对得起“重启再也不丢”这句话。如果你的Redis是主从架构，还要确保从节点和主节点都配置了持久化，否则主节点宕机切从，从节点只有空数据，一样会出问题。

3. 向量搜索迁到Elasticsearch：语义检索的地基工程

3.1 向量库选型：为什么在ES生态里落这个

对话记忆是结构化的文本，用Redis就能解决，但知识库问答场景里还需要向量检索。Spring AI提供了VectorStore接口，官方实现有Redis、Elasticsearch、PGVector、Milvus等。我最终选Elasticsearch的原因很接地气：团队运维栈里本来就有ELK，ES的运维经验和告警体系都是现成的，不需要再额外引一套专用向量数据库。

ES从8.x开始内置了dense_vector字段类型和HNSW索引，做中小规模的向量检索完全够用。所谓向量检索，简单理解就是把“语义相近”的文本转化成一串数字，然后用数学距离度量相似度。你可以把它类比成给每段文本算一个“语义指纹”，查询的时候把问题的指纹和库里所有文本的指纹做比对，找到最接近的几段，再把这些原文交给大模型作为参考知识。

3.2 索引Mapping第一次就要写对：dims、similarity与HNSW

ES里向量字段的Mapping必须提前设计好，这是一步到位的活。很多朋友栽在维度不匹配上：你用的Embedding模型输出1536维向量，但索引里定义的是768维，写入文档时直接报错。所以第一步要确定Embedding模型，比如用text-embedding-3-small，输出是1536维；用本地BGE模型，常见是768或1024维。定下来之后，索引Mapping就要按这个维度写死。

我给出一个ES 8.x的mapping示例：

PUT /ai_memory_doc { "mappings": { "properties": { "content": { "type": "text" }, "embedding": { "type": "dense_vector", "dims": 1536, "similarity": "cosine", "index": true, "index_options": { "type": "hnsw", "m": 16, "ef_construction": 100 } } } } }

这里有几个点提醒一下。similarity选cosine比较符合文本语义相似度场景；index设为true表示启用HNSW近似索引，否则这个字段只能暴力计算，数据量上来后会慢到没法用。另外，ES的mapping一旦创建，dims等参数基本就不能改了，所以初期就要规划清楚。如果文档结构会演进，更稳妥的做法是使用索引别名，底层加版本号，需要调整mapping时重建一个新索引再切换别名，而不是在线修改旧索引。

如果你不想手动建索引，Spring AI的ElasticsearchVectorStore也可以在初始化时自动建索引，但它默认的mapping不是你能控制的。我实践中更倾向自己提前建好索引，再让应用层只负责读写，减少“自动建出来但不满足需求”的窘境。

3.3 Spring AI接ES：VectorStore的注入和使用逻辑

接入代码其实不复杂，核心是注册一个VectorStore的Bean。我这里写一个典型配置：

@Bean VectorStore vectorStore(EmbeddingModel embeddingModel, ElasticsearchClient elasticsearchClient) { return new ElasticsearchVectorStore( ElasticsearchVectorStoreOptions.builder() .indexName("ai_memory_doc") .dimensions(1536) .similarity(Similarity.COSINE) .build(), elasticsearchClient, embeddingModel ); }

需要注意的是，Spring AI不同版本里ElasticsearchVectorStore的构造函数和参数类可能有差异，建议以你实际依赖的版本API为准。整体思路是不变的：把EmbeddingModel和ES客户端交给VectorStore，写入时它会自动把文本转成向量再入库，检索时它会自动调用ES的knn查询。

写入向量之前，长文本要切分。直接拿一篇几千字的文章去Embedding，效果很差，而且ES单条文档过大也不合理。我习惯用Spring AI的TokenTextSplitter做切分，把每段控制在300词左右，保存时记下原始来源：

TextSplitter splitter = new TokenTextSplitter(400, 100, 50, 1000, true); List<Document> chunks = splitter.split( new Document("这里是被索引的正文内容", Map.of("source", "某文档ID"))); vectorStore.add(chunks);

检索时用自然语言问句去查，指定topK和相似度阈值：

List<Document> docs = vectorStore.similaritySearch( SearchRequest.builder() .query("Spring AI生产化改造要注意什么") .topK(5) .similarityThreshold(0.5) .build());

得到的候选文档片段拼进Prompt，模型就能基于真实的内部知识库来回答，而不是凭空发挥。这一步完成后，即使应用重启、实例间切换，向量数据也都稳稳躺在ES里，语义检索结果不会因为进程重新拉起而改变。

4. 生产环境缝合：会话ID传递、多实例与配置固化

4.1 动态conversationId：从请求头解析到Advisor注入

存储层就绪之后，还有一个关键问题：conversationId从哪里来？在写Demo时，大家经常写死一个固定ID。但生产环境里，每个用户、每个会话都必须有独立ID，而且这个ID要能从请求里解析出来。

我用的是最简单的方案：让前端在请求头里传X-Chat-Id，后端用一个Filter把它读出来，放进请求上下文。然后构造ChatClient时，把“获取当前会话ID”的逻辑作为Supplier传给MessageChatMemoryAdvisor：

@Bean ChatClient chatClient(ChatModel chatModel, ChatMemory chatMemory) { return ChatClient.builder(chatModel) .defaultAdvisors(new MessageChatMemoryAdvisor( chatMemory, () -> ChatContext.getCurrentSessionId() )) .build(); }

这样每次请求进来，Advisor都会先从请求上下文拿到会话ID，再去Redis里加载对应的历史消息。不同用户之间互不干扰，同一个用户多轮对话也能保持上下文。如果接的是微信公众号这类渠道，可以用“用户标识+消息类型”拼成会话ID，保证多端隔离。

这个设计的核心思路是：会话ID由请求链路动态决定，而不是写死在业务代码里。否则你只是把存储换成了Redis，但所有用户还是共用同一个会话，那问题比不改造更大。

4.2 多实例部署下的路由策略：有Redis兜底之后，还要不要粘滞

对话记忆和向量都放进共享存储后，理论上不再依赖粘滞会话。但我在生产环境仍然建议保留粘滞配置，原因很简单：减少不必要的Redis读写。虽然Redis性能很好，但每次请求都读一次历史、写一次历史，频率还是相当高。如果应用本身无状态，负载均衡可以做least_conn或一致性哈希，让同一用户的请求尽量落到同一实例；即使落到不同实例，因为记忆在Redis，上下文依然连贯。

这里有个容易忽视的点：粘滞会话在实例重启后通常会失效，但因为对话状态不在本地内存里，所以实例重启并不会导致用户上下文丢失。用户感知上最多是本次请求稍微慢一点，说明架构已经达到了“状态与实例解耦”的目标。

4.3 Redis持久化与配置清单：把易变项钉死在配置里

改造完后，我把所有易变配置统一放到配置文件里，方便不同环境切换。下面这个表格是我实际使用时的配置项建议：

在配置TTL参数时，我从配置中心读取Duration，初始化RedisChatMemory时传入：

@Bean ChatMemory chatMemory(StringRedisTemplate redisTemplate, ObjectMapper objectMapper, @Value("${chat.memory.ttl:24h}") Duration ttl) { return new RedisChatMemory(redisTemplate, objectMapper, ttl); }

这样既不写死，又能支持运维在不停机的情况下调整会话保留时长。还要提醒一句，Redis连接池、ES连接池的路由和超时参数也值得单独调优，特别是接口调用量上来之后，默认连接池很容易被打满。

5. 重启不丢的实测过程

5.1 验证方法设计：kill进程、重启、再追问

改造完成之后，我在测试环境做了一轮“刻意制造失忆”的实测。整个过程很简单，但能完整验证“重启再也不丢”是否真的成立。

第一步，启动应用，用curl发起对话，让模型记住一个自定义信息：

curl -X POST http://localhost:8080/chat \ -H "Content-Type: application/json" \ -H "X-Chat-Id: test-session-001" \ -d '{"message": "我叫老王，请记住这个名字"}'

再发一条追问，确认当前会话内上下文有效：

curl -X POST http://localhost:8080/chat \ -H "Content-Type: application/json" \ -H "X-Chat-Id: test-session-001" \ -d '{"message": "我叫什么名字？"}'

此时模型应该能正确回答出“老王”。

第二步，直接kill -9干掉应用进程，模拟生产环境最恶劣的崩溃场景：

kill -9 $(pidof java)

第三步，重新启动应用，再用同一个X-Chat-Id发一条追问：

curl -X POST http://localhost:8080/chat \ -H "Content-Type: application/json" \ -H "X-Chat-Id: test-session-001" \ -d '{"message": "你还记得我的名字吗？"}'

改造前的现象是：模型完全不记得，甚至会把这个问题当成全新对话。改造后，模型能准确说出“你叫老王”。我也顺便做了向量检索的验证：向ES里写入几份测试文档，重启应用后重新检索，返回结果和重启前完全一致。

5.2 边界情况与后续优化：哪些坑可以提前避开

实测通过不代表可以高枕无忧，有几个边界情况我建议提前规划。

第一，TTL导致的长期记忆缺失。Redis里的对话记忆有24小时或48小时的有效期，过期后用户重新发起对话，模型会“忘记”更早之前的事情。如果产品需要跨月、跨年的长期记忆，就不能只靠Redis，而是要把重要信息定期抽成摘要，写到数据库或专门的长期存储里，在下一次对话开始时把摘要作为“初始记忆”载入。

第二，向量索引的膨胀和重建。ES索引越写越大，检索效率和维护成本都会上升。后续应该考虑按时间或业务模块分索引，用别名做切换。因为ES的mapping字段维度不可变，索引重建需要走“新索引+别名切换”的流程，这个操作一定要先在测试环境验证一次。

第三，Redis和ES本身的可用性。应用层“重启不丢”依赖于Redis和ES还活着。所以Redis至少要做主从+哨兵，ES至少要部署多节点，这已经不是Spring AI的问题，而是基础设施清单里必须覆盖的部分。

这次改造让我最深的体会是：拿到一个“AI应用”之后，不能只盯着Prompt和模型参数，状态存储的架构设计才是决定生产环境稳定性的关键因素。对话记忆放Redis，是因为它快、稳定、有TTL；向量数据放ES，是因为它和团队的运维体系天然匹配。你完全可以根据自己的情况换成PGVector或者其他存储，但核心原则只有一条——别把状态留在JVM内存里。如果你正在用Spring AI做项目，我建议趁线上还没出“失忆”事故，尽早把这个改造做了，把ChatMemory换到Redis，真的只需要半天工作量。