GitHub user xintongsong added a comment to the discussion: Short-Term Memory Design
1. This is a good point. I think we should not define a memory is short-term or long-term based on whether it is shared across keyed partitions. Visible to other keyed partitions or not is more like a property or restriction of the memory, rather than definition. Offline discussed with @coderplay about this. Here are something we came up with. - Short-Term Memory - Stores states and information into Flink's state backend - Accessed directly in a get-X style, e.g., `get(field_name)`, `get_recent(list_name, n)` - Needs retention control supports for fields of collection types. When the collection size (number of elements, or total size in bytes) reaches a threshold, the framework should either remove the earliest / least-recently-used element or call a user defined aggregation function to reduce the collection size. - Long-Term Memory - Stores in a vector storage - Accessed in a searching style - The vector storage can be either external or built-in (like rocksdb). - The vector storage should also support snapshots, to be integrated with Flink's checkpointing mechanism. - We can also support automatically moving short-term memory into long-term memory, as an option of the retention control. GitHub link: https://github.com/apache/flink-agents/discussions/40#discussioncomment-13728340 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
