[DM] 关于此项目memory储存方式的改进策略和长期维护（长期讨论帖）

[xiaoyueyoqwq]

嗨，又见面了 这几天我一直在观察您的项目，我先对您对此项目做出的努力表达由衷的敬意，在这几天的使用开发和观察过程中我认为最大的问题还是在memory方向，特别是在某些极端情况下不正确的memory上下文记忆处理和储存可能导致严重的模型思维混乱；在此过程中我有一位朋友 @MrHua269 对您的项目十分感兴趣，我希望可以帮您完善一下这个项目，最后感谢您一直以来对我下游调试做出的技术帮助

接下来所有改进方案您都可以直接与他进行沟通🚀

[shuakami]

好的。谢谢您的肯定。

不过我需要您（@xiaoyueyoqwq ）或者您朋友（@MrHua269）的日程安排（就是大概什么时间段有空）。这样我才能合理安排计划或任务。

谢谢您。

[xiaoyueyoqwq]

好的。谢谢您的肯定。

不过我需要您（@xiaoyueyoqwq ）或者您朋友（@MrHua269）的日程安排。这样我才能合理安排计划或任务。

谢谢您。

他目前已经在着手改善此模块，到时候会创建一个fork用来提交pr 稍后他会在此帖下与您沟通（他说等他写完再说

[xiaoyueyoqwq]

好的。谢谢您的肯定。

不过我需要您（@xiaoyueyoqwq ）或者您朋友（@MrHua269）的日程安排（就是大概什么时间段有空）。这样我才能合理安排计划或任务。

谢谢您。

我不确定您是否能够接受，我朋友使用了java+kt混合多线程写了一个简单的bot，测试可以正常使用（但是模型温度貌似有点问题，没有目前我们这个项目的框架热情），最主要还是希望您能参考一下他的memory存储方式，这次修改他直接把所有用户的数据都进行了隔离，并以lmdb的格式存储在了专用文件夹内

附件: AmyalmondBotKt.zip

[shuakami]

好的，稍后我会看看

[shuakami]

我目前稍微查看了一下，这好像是在代码中使用的记忆逻辑：

首先是用了用户记忆分别存储（数据隔离）和持久化，这个实现很棒，但我的问题是 AmyAlmond_bot主要是为了群聊聊天所设计，使用分群组记忆可以让群员记忆之间有更多关联..而用户记忆分别存储似乎针对的更多是单人对话或角色扮演对话的处理方式。不过这种方式对我来说有一定的启发/很感谢您和您的朋友。

不过很抱歉的是，因为我个人对于Java的熟练度非常低。所以在以后的开发中可能仍然会使用Python作为主要开发语言。

过几天我可能会规划一份新的记忆逻辑重构计划。再次感谢您和您朋友提供的思路。

[xiaoyueyoqwq]

我目前稍微查看了一下，这好像是在代码中使用的记忆逻辑：

首先是用了用户记忆分别存储（数据隔离）和持久化，这个实现很棒，但我的问题是 AmyAlmond_bot主要是为了群聊聊天所设计，使用分群组记忆可以让群员记忆之间有更多关联..而用户记忆分别存储似乎针对的更多是单人对话或角色扮演对话的处理方式。不过这种方式对我来说有一定的启发/很感谢您和您的朋友。

不过很抱歉的是，因为我个人对于Java的熟练度非常低。所以在以后的开发中可能仍然会使用Python作为主要开发语言。

过几天我可能会规划一份新的记忆逻辑重构计划。再次感谢您和您朋友提供的思路。

不客气，我很期待接下来的更新！

[shuakami]

https://marble-repair-490.notion.site/d8dfbc8218d841ae918a6ca19c94ecc0?v=09520b55e4f2447e9242b4c9338a1a25&pvs=4

您好，最新方案已经写出来了。 您可以告诉我您的意见

[xiaoyueyoqwq]

https://marble-repair-490.notion.site/d8dfbc8218d841ae918a6ca19c94ecc0?v=09520b55e4f2447e9242b4c9338a1a25&pvs=4

您好，最新方案已经写出来了。 您可以告诉我您的意见

我认为目前来说方案2较为稳定，可以先尝试使用方案2后再观察具体可能会消耗多少token

token消耗这个数值我目前测评出来的结果是有些许玄学，可能你生成一句5个字的对话回答消耗5000左右的token，但生成一句20字甚至30字的对话依旧消耗的是5000左右的token，我也不能具体查证中间到底是出了什么问题

顺便一提，关于数据隔离方面我们有考虑过群与群之间的数据隔离吗，目前我的bot还在测试阶段因此没有尝试过跨群处理数据，但是这方面的数据安全问题我依旧还是比较关心的

[shuakami]

群与群之间的数据安全我可以肯定，至少目前没有安全风险。

---

群A72FE39A6开头： 群 2D17A7F开头：

[shuakami]

我认为目前来说方案2较为稳定，可以先尝试使用方案2后再观察具体可能会消耗多少token

token消耗这个数值我目前测评出来的结果是有些许玄学，可能你生成一句5个字的对话回答消耗5000左右的token，但生成一句20字甚至30字的对话依旧消耗的是5000左右的token....

了解您的意见，后面会出专门的计划的。但可能需要比较久的时间

[MrHua269]

emmm关于记忆错乱那个是因为有损压缩导致的（在memorymanager里那个compress的方法里让ai压缩记忆的），那个会导致对话与对话者关系缺失

[shuakami]

谢谢您指出问题。后续会优化此方法并加强压缩日志输出。

[shuakami]

一个好消息是： 已经敲定了最终方案，使用MongoDB +Faiss这样的架构。

如果运气好的话，大概3~9天可以出第一版测试版 <3

明天就开始开发

[xiaoyueyoqwq]

一个好消息是： 已经敲定了最终方案，使用MongoDB + Milvus这样的架构。

如果运气好的话，大概3~9天可以出第一版测试版 <3

明天就开始开发

Glad to hear that! 祝一切顺利👋

[shuakami]

您好。目前主要部分已经开发、测试完成了，还剩一些闲杂项。 如果不出意外的话，下午 15:00-18:00 这一个时间段将会发布开发版更新。 因为本次改动较大，建议您提前复制整个项目保存为压缩文件备份。

<3

[xiaoyueyoqwq]

您好。目前主要部分已经开发、测试完成了，还剩一些闲杂项。 如果不出意外的话，下午 15:00-18:00 这一个时间段将会发布开发版更新。 因为本次改动较大，建议您提前复制整个项目保存为压缩文件备份。

<3

辛苦，我会尽快跟进下游测试🚀

[shuakami]

您好，最新开发版已经推送。很抱歉晚了一些

[xiaoyueyoqwq]

您好，最新开发版已经推送。很抱歉晚了一些

没事，刚好我也在吃饭 稍候我会进行测试，刚好我刚刚在研究项目最近推出的插件模块，您有考虑过专门推出一份third-party插件开发文档吗？

[shuakami]

有写~ 但是好像不够详细而且很混沌...我先把前面的问题都解决了再写文档吧

[xiaoyueyoqwq]

有写~ 但是好像不够详细而且很混沌...我先把前面的问题都解决了再写文档吧

了解，这几天辛苦咯😇

[xiaoyueyoqwq]

有写~ 但是好像不够详细而且很混沌...我先把前面的问题都解决了再写文档吧

hi, 我刚才测试了一下并且发现了一个可能出现的缺漏：您可能没有及时更新develop分支的config.yaml，因为我在启动时被质询要求提供MongoDB数据库信息，但是我并不清楚该如何配置

[shuakami]

您可以运行core/db/setup/mongodb/mongodb_setup_configs.py和core/db/setup/elasticsearch/elasticsearch_configs.py

进行自动配置（前提是您已经安装） 后续可能会写的更加清楚，给您带来不便还请见谅

[shuakami]

安装脚本在core/db/db_status_checker.py

如果这个不行，您可以手动尝试运行core/db/install下的脚本进行安装

[shuakami]

您可以使用core/db/upgrade/db_upgrade.py把您之前的数据迁移到新数据库架构中

[xiaoyueyoqwq]

core/db/db_status_checker.py

我再尝试运行这几个脚本自动配置时我遇到了一个找不到的前置：core 之前所有报错缺失的前置我都通过pip install手动安装了，但貌似只有这个无法解决

[shuakami]

您好，我这边需要2-3小时的时间进行更新修复，您看这样可以吗

[xiaoyueyoqwq]

您好，我这边需要2-3小时的时间进行更新修复，您看这样可以吗

可以的，正好我这边的机器人上线审核被腾讯驳回了😡 对了，如果您有事情找我的话可以直接联系我这个邮箱xiaoyueyoqwq@outlook.com 祝您好运🤗

[shuakami]

很抱歉，可能要多加几天了。 现在我又发现了更加严重的恶性问题，正在紧急修复。

[xiaoyueyoqwq]

很抱歉，可能要多加几天了。 现在我又发现了更加严重的恶性问题，正在紧急修复。

没事，那这几天就得辛苦一下你咯😇

[shuakami]

您好，开发版更新 Version: 1.2.0 (Beta_824001) (PATCH 1)已推送。

您可以更新后执行tools/db_tools.py进行操作

[xiaoyueyoqwq]

tools/db_tools.py

嗨，早上好 我刚刚发现了一个错误，详细请看截图

应该是在安装Elasticsearch时出现的语法错误？

[xiaoyueyoqwq]

您好，开发版更新 Version: 1.2.0 (Beta_824001) (PATCH 1)已推送。

您可以更新后执行tools/db_tools.py进行操作

我刚才尝试手动复现了一下问题，您脚本步骤应该是按照CSDN上写的吧？那上面缺失了一个步骤，您可以按照这份教程修改以下脚本：https://cloud.tencent.com/developer/article/1657534

[shuakami]

您好，MongoDB安装脚本也会出现同样的问题吗？

[shuakami]

我刚才尝试手动复现了一下问题，您脚本步骤应该是按照CSDN上写的吧？那上面缺失了一个步骤，您可以按照这份教程修改以下脚本：https://cloud.tencent.com/developer/article/1657534

您好，已经尝试修复并推送 您可以下载： elasticsearch_install_p1.zip

我的是参照https://mirror.tuna.tsinghua.edu.cn/help/elasticsearch/写的。实在是不太严谨，后续会使用虚拟机测试后再上线

[xiaoyueyoqwq]

我刚才尝试手动复现了一下问题，您脚本步骤应该是按照CSDN上写的吧？那上面缺失了一个步骤，您可以按照这份教程修改以下脚本：https://cloud.tencent.com/developer/article/1657534

您好，已经尝试修复并推送 您可以下载： elasticsearch_install_p1.zip

我的是参照https://mirror.tuna.tsinghua.edu.cn/help/elasticsearch/写的。实在是不太严谨，后续会使用虚拟机测试后再上线

已测试，应该没有大问题 记忆测试方面我貌似收到了一份关于append_to_long_term_memory的异常报告，您可以查看一下这份log ALERT: 请在PC上打开此日志防止网页卡死 https://paste.ubuntu.com/p/YqFtt4XQXM/

我知道这样的极限压力测试可能导致这样的问题发生，但如果发生了这样的问题我们有什么方法可以修复或重置数据库吗？亦或者通过类似热重启的方式释放一些记忆缓存？

[shuakami]

这是遗留问题，我现在修复，稍后推送

对数据库应该没有影响

[shuakami]

您好，最新修复已经推送

[xiaoyueyoqwq]

您好，最新修复已经推送

测试完毕，目前没有发现问题复现，我会一直追踪直到确认 不过我再次在log中收到了一份错误日志，并且这份日志也和memory有些许关系？因为我总是在相似的指令下频繁收到这个报错：https://paste.ubuntu.com/p/QMsH5tY6S5/

[shuakami]

您有更加详细的日志吗？DEBUG等级的

[xiaoyueyoqwq]

您有更加详细的日志吗？DEBUG等级的

稍等，我已经切换到debug模式尝试复现此问题了 稍后我会将更详细的日志放出

[xiaoyueyoqwq]

您有更加详细的日志吗？DEBUG等级的

嗨，很幸运地我很快就复现了此问题 日志如下：https://paste.ubuntu.com/p/HSvHrDy2hd/

顺便一说，我还是希望加入一个能一键清空数据库记忆的功能脚本，毕竟我也不确定目前我们的数据库可承载的数据量到底是多少，并且这样产生的一些碎片数据是否会得到自动整理等长期问题

[shuakami]

看起来像是您的OpenAI API 问题，我检查了一下您的payload，发现也没有问题。 建议您：

• 更换API提供商
• 增加config.py的MAX_CONTEXT_TOKENS
• 简化您的SystemPrompt

如果后续依然复现，您可以随时发给我

[xiaoyueyoqwq]

看起来像是您的OpenAI API 问题，我检查了一下您的payload，发现也没有问题。 建议您：

• 更换API提供商
• 增加config.py的MAX_CONTEXT_TOKENS
• 简化您的SystemPrompt

如果后续依然复现，您可以随时发给我

了解，感谢您的帮助

[xiaoyueyoqwq]

看起来像是您的OpenAI API 问题，我检查了一下您的payload，发现也没有问题。 建议您：

• 更换API提供商
• 增加config.py的MAX_CONTEXT_TOKENS
• 简化您的SystemPrompt

如果后续依然复现，您可以随时发给我

memory测试报告：依旧需要改进

目前我所测试的长期记忆已经相当好了，但是需要注意的是我们貌似只保留了AI的长期记忆，这就导致AI在每一次回答时都会花费大量时间索引以往的所有memory，这可能会带来严重的io负担和大量数据碎片误导AI做出不正确的回答，我认为我们可以保留一下以前的记忆存储模式，将其分类的短期记忆和长期记忆处理

如果您有什么需要补充的欢迎提出

[shuakami]

我真的很高兴听到您说，目前所测试的长期记忆已经相当好了。 不过实际上目前的架构设计就是由MongoDB负责短期记忆，Elasticsearch负责长期记忆。

您的建议我会考虑的。后续会使用根据相关性得分选择是否要插入记忆，例如先进行MongoDB短期记忆搜索，如果没有再进行...好像这样又负担太大了....

<3

[xiaoyueyoqwq]

我真的很高兴听到您说，目前所测试的长期记忆已经相当好了。 不过实际上目前的架构设计就是由MongoDB负责短期记忆，Elasticsearch负责长期记忆。

您的建议我会考虑的。很感谢您的测试反馈~

<3

我看出来了，话说您愿意来实地记录一下情况吗，我愿意将最精准的情况实时分享给您，如果您愿意的话可以发邮件向我要即可

对了，我朋友待会也回来补充一点内容，稍候他就会来

[shuakami]

您好。实际上来说测试数据对于我来说非常有用，特别是在改进逻辑上。 您可以打包后邮件发送给我，谢谢您。

[xiaoyueyoqwq]

您好。实际上来说测试数据对于我来说非常有用，特别是在改进逻辑上。 您可以打包后邮件发送给我，谢谢您。

好的，很高兴能听到您这么说，哈哈

[MrHua269]

记忆丢失的问题在压缩上，其实可以搞个遗忘机制用来忘掉一些"热点"或者"权重"较低的记忆，索引可以按照你压缩记忆的办法生成一次然后按照遗忘机制忘记部分用来减轻记忆堆积

[shuakami]

记忆丢失的问题在压缩上，其实可以搞个遗忘机制用来忘掉一些"热点"或者"权重"较低的记忆，索引可以按照你压缩记忆的办法生成一次然后按照遗忘机制忘记部分用来减轻记忆堆积

您好。您的建议很有建设性，我会在之后的代码中结合此建议修改的