search

lobehub / lobe-chat

🤯 Lobe Chat - an open-source, modern-design AI chat framework. Supports Multi AI Providers( OpenAI / Claude 3 / Gemini / Ollama / Azure / DeepSeek), Knowledge Base (file upload / knowledge management / RAG ), Multi-Modals (Vision/TTS) and plugin system. One-click FREE deployment of your private ChatGPT/ Claude application.
https://chat-preview.lobehub.com
Other
39.91k stars 9.08k forks source link

[Question] 历史消息会话在重新进入角色后会消失 #407

Closed liaoke01 closed 9 months ago

liaoke01 commented 10 months ago

🧐 问题描述 | Proposed Solution

新建一个机器人之后与他聊天之后退出，再点进去之前的聊天记录会没有会保存到历史聊天记录中去，并且每一场对话都有最大限制，当左下角那个数耗尽之后，就要退出去重进，然后历史消息都会没有，然后重新聊天，这是我的问题还是项目本来就是这样的。我希望参考一下chatgpt next web的聊天模式

📝 补充信息 | Additional Information

No response

arvinxx commented 10 months ago

新建一个机器人之后与他聊天之后退出，再点进去之前的聊天记录会没有会保存到历史聊天记录中去

这个能否有个录屏的复现？可能是个 bug

并且每一场对话都有最大限制，当左下角那个数耗尽之后，就要退出去重进

有一种方式是你可以设定历史记录的条数：

image

这样会话就只会存在一部分上下文，可以持续聊下去。但是会有个缺点就是 5 条之前的信息就会忘记。

我希望参考一下chatgpt next web的聊天模式

我们知道 chatgpt next web 有个聊天功能非常不错： 自动压缩历史记录，进而减少 token 数。我们有创建一个 issue 来跟进这个功能特性 #34 。目前正处于方案构思阶段，计划将会在 1.x 版本中实现。

liaoke01 commented 10 months ago

新建一个机器人之后与他聊天之后退出，再点进去之前的聊天记录会没有会保存到历史聊天记录中去

这个能否有个录屏的复现？可能是个 bug http://liaoke.cyou:5244/%E9%98%BF%E9%87%8C%E4%BA%91%E7%9B%98/screen-20231105-134138.mp4，复现如上

并且每一场对话都有最大限制，当左下角那个数耗尽之后，就要退出去重进

有一种方式是你可以设定历史记录的条数：

image

我的历史记录是开无限制的，我指的是那个笑脸旁边的数字，当遇到长文本时，人工智能会返回达到最大限制，然后就得退出重进，然后消息又会消失，保存为历史聊天记录，我希望这个能进行一定改善，不然真的很麻烦 Screenshot_20231105-134222_雨见

这样会话就只会存在一部分上下文，可以持续聊下去。但是会有个缺点就是 5 条之前的信息就会忘记。

我希望参考一下chatgpt next web的聊天模式

我们知道 chatgpt next web 有个聊天功能非常不错： 自动压缩历史记录，进而减少 token 数。我们有创建一个 issue 来跟进这个功能特性 #34 。目前正处于方案构思阶段，计划将会在 1.x 版本中实现。

最后我希望对于联网任务的处理可以参考一下https://github.com/potatodoctor/ChatGPT-Next-Web-LangChain，经过我的多次对比，此项目的联网任务处理能力尚不及LangChain版本的Chatgpt next web。希望能够参考该项目的联网任务处理，其次在输出的流畅度上有明显的僵硬感，手机端使用搭建在vercel上的服务整体有些卡顿，希望以后能得到优化

arvinxx commented 10 months ago

关于消息消息消失的问题，请尝试点击这个地方：

image

image

目前看上去关于历史记录的查看，我们在界面上做的不够明显。

@canisminor1990 感觉可以考虑做成助手下方直接显示当前的话话题名称。并有个下拉的图标。

image

我的历史记录是开无限制的，我指的是那个笑脸旁边的数字，当遇到长文本时，人工智能会返回达到最大限制，然后就得退出重进，然后消息又会消失，保存为历史聊天记录，我希望这个能进行一定改善，不然真的很麻烦

目前有两个解决方案，看你倾向哪种：

A. 通过一个新开消息的按钮，点击后可以直接开启一个新的会话； B. 提供压缩上下文历史记录的功能，即现有的 Chat Next Web 的能力；

最后我希望对于联网任务的处理可以参考一下https://github.com/potatodoctor/ChatGPT-Next-Web-LangChain，经过我的多次对比，此项目的联网任务处理能力尚不及LangChain版本的Chatgpt next web。希望能够参考该项目的联网任务处理

感谢提供输入，我们会研究下其能力的实现，看下怎么样可以提升效果。我们目前的联网插件逻辑比较轻，要提升效果的话估计需要研究研究。

在输出的流畅度上有明显的僵硬感，手机端使用搭建在vercel上的服务整体有些卡顿，希望以后能得到优化

僵硬感是指什么？有没有你觉得流畅的参考对象？

arvinxx commented 10 months ago

联网能力优化 在 https://github.com/lobehub/chat-plugin-search-engine/issues/6 跟进

arvinxx commented 10 months ago

可能另外一个相关的问题：

liaoke01 commented 10 months ago

从我目前来看，该项目发展前景是非常好的，只是以下几个方面有待改进: 1.我使用的是雨见浏览器，火狐内核，在搭建在vercel上的项目运行起来有明显的延迟与卡顿有时候点一个按钮要几秒后才能做出反应 2其次是人工智能的回答，有可能是因为手机上运行该项目整体程序延迟太大了，导致我主观偏向它回答也很卡顿慢 3联网能力，其余的插件都是联网之后对信息进行总结之后回答，但是目前该项目的搜索好像真的只是搜索，将网上的信息复述，然后再转发给你一遍，体验效果不佳 4个人感觉项目的交互逻辑可以再进一步改善，一般的chatGPT项目，都是将对话聊天记录和角色绑定在一起的。但该项目将角色和聊天记录分开，这个对于有意向进行专业的工作生产的人来说是有益的，但交互逻辑还有进步空间。我觉得可以在首页，将最顶部的随便聊聊删除，只留助手列表，然后项目初始会创建一个机器人名为闲聊，然后机器人下面有按钮创建新机器人，然后点进机器人进行聊天聊天，完了之后点击退出，并不会主动将消息保存为历史消息（除非自己主动点击新建聊天，才会保存为历史消息），而是利用历史消息压缩技术保留，下一次点进去之后还会保留原消息，默认打开如果遇到信息超出，自动舍弃以前消息（并且搭配历史消息压缩技术）（具体的配置可以人为在机器人设置中更改，具体详情配置可以参考chatgpt next web） 5如果可以的话，可以试试添加多token功能每个token对应着一个代理地址（如果不主动填写token_1代理地址，则token-1为默认代理地址），可以以-数字大小为设置优先级，以及在环境变量中添加搜索密钥的环境变量 6应该在b站多宣传一下，增加项目的知名度，大力发展项目的插件生态

liaoke01 commented 10 months ago

至于到底要不要打开助理新建一个对话，我觉得也可以添加一个设置开关

arvinxx commented 10 months ago
  1. 我使用的是雨见浏览器，火狐内核，在搭建在vercel上的项目运行起来有明显的延迟与卡顿有时候点一个按钮要几秒后才能做出反应

Firefox 我们之前没有怎么做个测试。最近会尝试一下看下是否存在明显的性能问题

  1. 其次是人工智能的回答，有可能是因为手机上运行该项目整体程序延迟太大了，导致我主观偏向它回答也很卡顿慢

你的手机型号能反馈给我们一下吗？手机性能相比 Web 是会差一些。可能针对各种性能的手机要做更多的测试验证和优化

  1. 联网能力，其余的插件都是联网之后对信息进行总结之后回答，但是目前该项目的搜索好像真的只是搜索，将网上的信息复述，然后再转发给你一遍，体验效果不佳

目前阶段我们的搜索引擎插件的确是这么做的。不过我们的搜索结果的展示上是有自己的想法，也就是会将搜索结果进行展示，这样可以让用户清楚了解到搜索引擎到底搜到了什么。

因为之前在我使用 GPT 4 的搜索插件时，很多时候返回的结果都不会包含我预期的结果。比如下方：

image

这种时候在 ChatGPT 的这样的交互模式下就很尴尬，因为上面三个都不是我想要的，但你并不知道它搜索了什么才给出这种结果，有可能中间过程的搜索其实能查到结果，只是被 ai 过滤了。以及你也不知道GPT搜索了关键词，才出现了这些结果。因为这些中间过程不可控，所以最终结果的有效性会大大折扣。

比如下面这样的问题，我其实期待 ChatGPT 能给出有效的结果，但经过一番尝试后，发现这三个库都不行。然后我就没法办法进行更进一步的检查了

image

但换做是 LobeChat 现在的方案：它会给出搜索结果、中间过程与最后的总结。哪怕最后的总结不对，你也可以在中间环节直接点查询搜索结果，相比起 ChatGPT 的交互方案，我们现有的模式对用户会更加可控。

LobeChat_前端研发专家_2023-11-05 (1)

arvinxx commented 10 months ago

4个人感觉项目的交互逻辑可以再进一步改善，一般的chatGPT项目，都是将对话聊天记录和角色绑定在一起的。但该项目将角色和聊天记录分开，这个对于有意向进行专业的工作生产的人来说是有益的，但交互逻辑还有进步空间。我觉得可以在首页，将最顶部的随便聊聊删除，只留助手列表，然后项目初始会创建一个机器人名为闲聊

随便聊聊在 LobeChat 的产品交互中是必要的，一方是它承载了新用户的落地，另一方面是各个角色的兜底助手。以及在 1.x 后面它会承载更加丰富的能力（例如角色的召唤、@其他助手等）。

点进机器人进行聊天聊天，完了之后点击退出，并不会主动将消息保存为历史消息 至于到底要不要打开助理新建一个对话，我觉得也可以添加一个设置开关

其实这两个是一回事。如果打开助手就会新建一个会话，那就意味着每次会话就会自动保存到历史记录。这样下次进来就都是新的消息。 如果每次聊天完以后不自动新建历史记录，那么下次打开助手的时候，显示就是旧的信息，只有用户在点击新建话题的时候，才会将当前的消息创建一个新的会话。

5 如果可以的话，可以试试添加多token功能每个token对应着一个代理地址（如果不主动填写token_1代理地址，则token-1为默认代理地址），可以以-数字大小为设置优先级，以及在环境变量中添加搜索密钥的环境变量

这个的需求来源是什么？什么时候需要这个功能？

6应该在b站多宣传一下，增加项目的知名度，大力发展项目的插件生态

感谢认可。我们最近将会重点放在插件生态的构建上。计划推出 MJ、SD、Wikipedia 、代码执行器等各种插件。等待插件生态更加完善后，加大推广力度。

liaoke01 commented 10 months ago

@arvinxx 我的手机型号是小米8 至于多密钥的功能，我觉得在薅羊毛的地方可以用到 还有环境变量里面建议添加搜索密钥的环境变量 至于打开助手会不会新建对话，在设置里面弄一个开关挺好的 就我自己目前体验来说，最大的问题就是流畅性以及对长文本的处理能力了，建议将默认的配置调试好，符合大多数人的口味，降低上手难度，就比如说默认的那个消息限制，就有点小恶心，到达一定程度就不能说话了，还要自己手动修改

leeyiding commented 10 months ago

我来解释一下第五条需求 目前gpt3.5的api_key很便宜，几块钱就可以买一个5刀的key，但是如果想要使用4.0的话，就需要购买中转了。 如果在中转场景下使用3.5模型，并不比直接买的3.5 api_key划算。 所以场景就是，提供两个或多个api_key，在api_key1中使用3.5模型，在api_key2中使用4.0模型

arvinxx commented 10 months ago

@leeyiding 明白了，也有合理性。

MartialBE commented 9 months ago

关于综合搜索功能，其实这个很难做的，因为不可控因素太多了。 我试过其他插件基本都一样，即便是类似 https://tavily.com 这种使用了向量查找返回相关性高的方案，质量要好一些但是也没到特别好。 所以专业性的问题还是用垂直领域的api解决。 关于lobe的搜索插件，返回数据太多了... 虽然让插件界面好看了，但是全丢给openai完全没必要，只要把标题、网址、摘要给openai就好了。大量无用的数据也会降低openai的准确性的。

关于支持多key的问题。我觉得完全没必要。 一个工具解决某类的问题，不能奢求什么功能都有。而且还不是每个人都有需求的。你说的多key 使用oneapi完全能解决你的需求。还能负载均衡。

期待插件3期尽快更新。因为没有鉴权或者参数定义，每弄一个插件都要起一个服务，关键这服务还只是一个反代... 期待早日支持openAPI格式。

lobehubbot commented 9 months ago

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

Regarding the comprehensive search function, it is actually very difficult to implement because there are too many uncontrollable factors. I have tried other plug-ins and they are basically the same. Even solutions like https://tavily.com that use vector search to return high correlations have better quality but not particularly good. Therefore, professional issues are still solved using APIs in vertical fields. Regarding the lobe search plug-in, too much data is returned... Although it makes the plug-in interface look good, there is no need to leave it all to openai. Just give the title, URL, and abstract to openai. A large amount of useless data will also reduce the accuracy of openai.

Regarding the issue of supporting multiple keys. I think it's completely unnecessary. A tool can solve certain types of problems and cannot be expected to have all functions. And not everyone needs it. Using oneapi for the multiple keys you mentioned can completely solve your needs. It can also load balance.

Looking forward to the plugin issue 3 being updated as soon as possible. Because there is no authentication or parameter definition, every plug-in requires a service. The key is that this service is just a reverse generation... We look forward to supporting the openAPI format soon.

arvinxx commented 9 months ago

release on v0.103.0

lobehubbot commented 9 months ago

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

release on v0.103.0

lobehubbot commented 9 months ago

✅ @liaoke01

This issue is closed, If you have any questions, you can comment and reply.\ 此问题已经关闭。如果您有任何问题，可以留言并回复。