Spring AI项目中VectorStoreChatMemoryAdvisor的内存持久化问题解析

在Spring AI项目的最新版本中，开发人员发现了一个关于聊天记忆持久化的重要问题。这个问题主要影响了使用AWS Bedrock Converse流式API时的聊天记忆存储功能。

问题背景

当开发者使用VectorStoreChatMemoryAdvisor结合PostgreSQL的PG Vector扩展存储对话记录时，发现系统无法正确保存AI助手的响应消息。这个问题在M8版本中并不存在，但在升级到RC1版本后开始出现。

技术分析

问题的核心在于VectorStoreChatMemoryAdvisor的after方法没有被正确调用。在之前的M8版本中，该类实现了StreamAroundAdvisor接口，能够正确聚合消息响应并写入向量存储。但在RC1版本中，该实现被移除，转而依赖after方法。

在RC1版本中，after方法的调用依赖于AdvisorUtils.onFinishReason()的测试结果。只有当响应元数据中包含finishReason时，才会触发after方法。然而，在使用AWS Bedrock的Converse API时，虽然系统会生成MessageStopEvent，但这个事件似乎没有被正确处理，导致finishReason字段未被填充。

影响范围

这个问题直接影响使用以下技术组合的开发者：

• Spring AI RC1版本
• AWS Bedrock作为底层LLM服务
• PostgreSQL的PG Vector扩展作为向量存储
• 流式对话交互模式

解决方案

项目团队已经通过PR #3193修复了这个问题。最新版本的1.0.0-SNAPSHOT已经包含了修复代码。修复后的版本中，MessageAggregator能够正确调用BedrockProxyChatModel的AggregationHandler中的adviseStream方法。

遗留问题

虽然主要问题已经解决，但仍有一个需要注意的细节：MessageStopEvent的处理机制仍需完善。当前实现中，响应元数据的finishReason字段仍然没有被正确填充，这可能会在未来引发其他问题。

最佳实践建议

对于使用类似技术栈的开发者，建议：

1. 升级到包含修复的最新版本
2. 密切关注MessageStopEvent相关问题的进展
3. 在关键业务场景中增加对聊天记忆持久化的验证逻辑
4. 考虑实现自定义的监控机制来确保消息存储的完整性

这个问题提醒我们，在升级框架版本时，需要特别注意依赖关系和接口变更可能带来的影响，特别是在涉及流式处理和持久化存储的复杂场景中。