feat: Add a feature to serialize and deserialize memory types to and from JSON

[Aditya-k-23]

Description: Add a feature to serialize and deserialize the memory types into JSON format,
Issue: #11275,
Dependencies: No new dependencies,
Tag maintainer: @baskaryan, @eyurtsev, @hwchase17
Co-Authors: @D3nam, @avaove, @malharpandya

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
langchain	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 7, 2024 7:19pm

[Aditya-k-23]

Our changes add the serialization and deserialization to and from the following memory types:

• ConversationBufferWindowMemory
• ConversationBufferMemory
• ConversationSummaryBufferMemory
• ConversationSummaryMemory
• ConversationEntityMemory
• ConversationTokenBufferMemory
  For the following types an additional llm argument needs to be passed for deserialization, this is because the current BaseLLM class is not lc_serializable:
• ConversationSummaryBufferMemory
• ConversationSummaryMemory
• ConversationEntityMemory
• ConversationTokenBufferMemory
  In the future, our implementation allows for extension to include Knowledge graphs and Vector Stores, if their lc_serializable methods are implemented to support both serialization and deserialization.

[hwchase17]

thanks for opening this up. i dont think we want to do this quite yet. a few reasons:

1. the memory abstractions may not be the best/most stable, so we want to rethink
2. we generally make things serializable in both python and js at the same time

Curious to hear - why the desire to have them serializable?

[Aditya-k-23]

We understand. We chose this issue as there were a lot of user requests for making storage of memory types available in a JSON format. We chose to couple it with deserialization because we thought it made sense to continue where users left off their work. We think this feature provides the capability to efficiently share, reuse, and manage memory objects across sessions and even with other users. To add a particular use case I would like to reference the issue #11275. Maybe @lameTookan can shed more light on what their use case was.

[rupertlssmith]

@hwchase17 Curious to hear - why the desire to have them serializable?

Currently building a system where each step in the conversation is produced by invoking a stateless API. So any conversation state must be passed in to the parameters used to invoke the API.

@Aditya-k-23 Why do these memory types require an llm to deserialize?

• ConversationSummaryBufferMemory
• ConversationSummaryMemory

For example, to my thinking the ConversationSummaryBufferMemory contains a list of Human and AI conversation steps, a current buffer size or token count, and maybe a summary of the conversation so far to capture the overflow from the buffer. A serialized representation could hold these 3 things, and the state could be completely recovered from them.

What we want to avoid is having to make extra calls to the llm to re-create the summary from the conversation steps when deserializing, as this is potentially costly/time consuming.

[hwchase17]

i am going to close this. this isnt something we want to make serializable yet