您的功能请求是否与问题相关?请描述。
可用的 ChatMemory
和 TokenWindowChatMemory
实现(确切地说)在生产环境中并不十分有用。我认为这些内存实现是出于易于实现而不是有用性的原因而产生的。我明白 - 看起来您在这里有很多工作要做。
描述您希望的解决方案
我认为现在是讨论优先考虑“物有所值”的实现,例如 backed by a vector store 或 conversion summary 的时候了。我最感兴趣的是:
- 您是否考虑过新的内存类型?
- 对此有任何预期的时间表(或者您认为这项工作应该具有什么样的优先级)?
- 有些人如何帮助解决这个问题?*
描述您考虑过的替代方案
替代方案是手写实现,但那样我们就会有很多针对特定用例的闭源实现,因此更不通用且更小,但是由 X 个团队维护 X 次。
附加上下文
在上面的 LangChain 文档中。
#1067 可能是一个正确的方向,但我认为它肯定不能解决问题。
- 如果我正确理解问题的话,这将是一项艰巨的任务。不仅需要实现,还需要与框架/矢量存储/LLMs 集成的工作,这可能对一个人来说太多了。
7条答案
按热度按时间nfs0ujit1#
对于这次拖延的道歉。我这里有一个非常粗略的草稿,关于
SummarizedTokenWindowChatMemory
: #1351pbgvytdp2#
你好,
是的
没有
你可以协助实现。应该不会太复杂,可以使用
ChatLanguageModel
作为新实现的组件(用于总结),以及/或者使用EmbeddingModel
和EmbeddingStore
接口作为新实现的组成部分。6ju8rftf3#
你好,这条评论是否仍然相关?不确定你是否已经删除了它,还是GitHub出现了问题。
2024年6月1日,星期六,下午6点41分,John Sosoka ***@***.***>写道:我们可以在构造时设置一个接受ChatLanguageModel的SummarizedChatMemory。我们可以将滑动出窗口的消息摘要存储在一个为给定的ChatMemoryStore预留的索引中,但该索引中的元素最终可能会变得太大。我需要更多地思考如何将其与嵌入存储结合。我可以想到很多方法来实现更先进的内存。无论我们做什么,我认为在消息数组中保留一个用于提示摘要和/或来自嵌入存储的结果的预留索引可能是前进的方向。在进行更多讨论后,我有兴趣尝试实现它。——直接回复此电子邮件,查看GitHub上的<#1184 (comment)>,或取消订阅 < https://github.com/notifications/unsubscribe-auth/A7RGMWTV7RFF7HNT5V5Q5VLZFH2TRAVCNFSM6AAAAABILWS4O2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBTGUYDSMRZHE > 。您收到此邮件是因为您发表了评论。消息ID:***@***.***>
vsmadaxz4#
@johnsosoka
6tdlim6h5#
我删除了它,因为这是一个半成品的想法。我可以在
SummarizedWindowChatMemory
上工作。我已经在一个私人的LangChain4J项目中实现了类似的功能。我可以将聊天摘要存储在消息索引中的预留消息中。两个问题ttygqcqt6#
你好@johnsosoka,我首先会查看在线现有的实现(例如LangChain,LlamaIndex等)。
将摘要放入系统消息中是否安全?(在现有的消息后追加摘要,如果不存在则添加新的消息)
可能安全,但应该用引号括起来以减少提示注入的可能性。
另一个需要考虑的问题是:当RAG内容被注入到系统消息中时,这将如何工作?或者当用户添加一个常规系统消息时,又会如何?
对于摘要消息过大的问题有什么想法吗?
我想进一步压缩/总结?:)
以防万一,我想总结不应该每次将新消息添加到内存时都执行,对吧?
由于这是一个相当耗费资源的操作,它可能应该在N次操作中执行一次,例如
ArrayList
调整大小。WDYT?mgdq6dx17#
@langchain4j
Should we assign a ticket for
SummarizedWindowedChatMemory
implementation to me? I can take that on and have a PR this week. The embedding store solution should be implemented as a separate task/ChatMemory IMHO.