-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Limited Extensibility in ChatMemoryRepository Design #3288
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Actually, I have a similar question myself. From what I understand, the implementation of The default implementation currently provided, My confusion lies in this: Is the @ThomasVitale , could you please help clarify this for us? We'd greatly appreciate it. |
I really need this feature: "Store the complete conversation history while only loading the most recent messages." In the older version, there seemed to be a similar configuration (CHAT_MEMORY_RETRIEVE_SIZE_KEY), but it has been removed in the latest version. |
It seems that the SpringAI team believes ChatMemory is only suitable for short - term storage. As a result, they don't plan to offer any solutions for long - term storage. This situation forces developers to implement ChatMemory and ChatHistory separately rather than using a single shared storage. This not only increases the complexity of the development process but may also lead to inefficiencies in data management. It would be beneficial if the SpringAI team could consider the need for long - term storage and explore ways to integrate ChatMemory and ChatHistory more effectively, perhaps by providing some guidelines or design patterns to help developers better handle this aspect of the application. This would greatly enhance the usability and scalability of the overall system and reduce the burden on developers. We hope to see some positive changes and discussions around this issue in the near future. |
Issue Title: Limited Extensibility in ChatMemoryRepository Design
Description:
In the latest Spring AI 1.0.0 release, the
ChatMemory
interface and its defaultMessageWindowChatMemory
implementation (using fixed-window conversation history) provide good extensibility for custom implementations. However, there appears to be tight coupling between the storage mechanism and windowed memory implementation through theChatMemoryRepository
interface.The current
ChatMemoryRepository
interface:Presents two key limitations:
saveAll
method requires full overwrite of existing messages, preventing incremental storage of conversation history.findByConversationId
forces retrieval of all messages, making it impossible to implement partial retrieval patterns (e.g., top-N messages).This design essentially binds
ChatMemoryRepository
implementations to work exclusively with the windowed memory approach used byMessageWindowChatMemory
. Developers cannot implement alternative strategies like:The current architecture forces complete reimplementation of both
ChatMemory
and storage mechanisms for non-windowed use cases, negating the interface's intended extensibility benefits. Could we reconsider this design to better separate storage concerns from memory management strategies?Suggested Improvements:
addMessage
method)The text was updated successfully, but these errors were encountered: