How to migrate from v0.0 memory
The concept of memory has evolved significantly in LangChain since its initial release.
Broadly speaking, LangChain 0.0.x memory was used to handle three main use cases:
| Use Case | Example |
|---|---|
| Managing conversation history | Keep only the last n turns of the conversation between the user and the AI. |
| Extraction of structured information | Extract structured information from the conversation history, such as a list of facts learned about the user. |
| Composite memory implementations | Combine multiple memory sources, e.g., a list of known facts about the user along with facts learned during a given conversation. |
While the LangChain 0.0.x memory abstractions were useful, they were limited in their capabilities and not well suited for real-world conversational AI applications. These memory abstractions lacked built-in support for multi-user, multi-conversation scenarios, which are essential for practical conversational AI systems.
This guide will help you migrate your usage of memory implementations from LangChain v0.0.x to the persistence implementations of LangGraph.
Why use LangGraph for memory?
The main advantages of persistence implementation in LangGraph are:
- Built-in support for multi-user, multi-conversation scenarios which is often a requirement for real-world conversational AI applications.
- Ability to save and resume complex state at any time for error recovery, human-in-the-loop workflows, time travel interactions, and more.
- Full support for both LLM and chat models. In contrast, the v0.0.x memory abstractions were created prior to the existence and widespread adoption of chat model APIs, and so it does not work well with chat models (e.g., fails with tool calling chat models).
- Offers a high degree of customization and control over the memory implementation, including the ability to use different backends.
Migrations
These guides assume some familiarity with the following concepts:
1. Managing conversation history
The goal of managing conversation history is to store and retrieve the history in a way that is optimal for a chat model to use.
Often this involves trimming and / or summarizing the conversation history to keep the most relevant parts of the conversation while having the conversation fit inside the context window of the chat model.
Memory classes that fall into this category include:
| Memory Type | How to Migrate | Description |
|---|---|---|
ConversationBufferMemory | Link to Migration Guide | A basic memory implementation that simply stores the conversation history. |
ConversationStringBufferMemory | Link to Migration Guide | A special case of ConversationBufferMemory designed for LLMs and no longer relevant. |
ConversationBufferWindowMemory | Link to Migration Guide | Keeps the last n turns of the conversation. Drops the oldest turn when the buffer is full. |
ConversationTokenBufferMemory | Link to Migration Guide | Keeps only the most recent messages in the conversation under the constraint that the total number of tokens in the conversation does not exceed a certain limit. |
ConversationSummaryMemory | Link to Migration Guide | Continually summarizes the conversation history. The summary is updated after each conversation turn. The abstraction returns the summary of the conversation history. |
ConversationSummaryBufferMemory | Link to Migration Guide | Provides a running summary of the conversation together with the most recent messages in the conversation under the constraint that the total number of tokens in the conversation does not exceed a certain limit. |
VectorStoreRetrieverMemory | No migration guide yet | Stores the conversation history in a vector store and retrieves the most relevant parts of past conversation based on the input. |
2. Extraction of structured information from the conversation history
Memory classes that fall into this category include:
| Memory Type | Description |
|---|---|
BaseEntityStore | An abstract interface that resembles a key-value store. It was used for storing structured information learned during the conversation. The information had to be represented as a dictionary of key-value pairs. |
ConversationEntityMemory | Combines the ability to summarize the conversation while extracting structured information from the conversation history. |
And specific backend implementations of abstractions:
| Memory Type | Description |
|---|---|
InMemoryEntityStore | An implementation of BaseEntityStore that stores the information in the literal computer memory (RAM). |
RedisEntityStore | A specific implementation of BaseEntityStore that uses Redis as the backend. |
SQLiteEntityStore | A specific implementation of BaseEntityStore that uses SQLite as the backend. |
UpstashRedisEntityStore | A specific implementation of BaseEntityStore that uses Upstash as the backend. |
These abstractions have not received much development since their initial release. The reason is that for these abstractions to be useful they typically require a lot of specialization for a particular application, so these abstractions are not as widely used as the conversation history management abstractions.
For this reason, there are no migration guides for these abstractions. If you're struggling to migrate an applications that relies on these abstractions, please open an issue on the LangChain GitHub repository and we'll try to prioritize providing more guidance on how to migrate these abstractions.
The general strategy for extracting structured information from the conversation history is to use a chat model with tool calling capabilities to extract structured information from the conversation history. The extracted information can then be saved into an appropriate data structure (e.g., a dictionary), and information from it can be retrieved and added into the prompt as needed.
3. Implementations that provide composite logic on top of one or more memory implementations
Memory classes that fall into this category include:
| Memory Type | Description |
|---|---|
CombinedMemory | This abstraction accepted a list of BaseMemory and fetched relevant memory information from each of them based on the input. |
SimpleMemory | Used to add read-only hard-coded context. Users can simply write this information into the prompt. |
ReadOnlySharedMemory | Provided a read-only view of an existing BaseMemory implementation. |
These implementations did not seem to be used widely or provide significant value. Users should be able to re-implement these without too much difficulty in custom code.
Related Resources
Explore persistence with LangGraph:
- LangGraph quickstart tutorial
- How to add persistence ("memory") to your graph
- How to manage conversation history
- How to add summary of the conversation history
Add persistence with simple LCEL (favor langgraph for more complex use cases):
Working with message history: