Closed Moonlit7 closed 1 year ago
lobechat主项目就不应该固定发送内容给GPT总结(因为此时还没有内容),插件处理后的后续逻辑是不是交给插件自定义比较灵活
这个是 GPT 自行决定的,我没有在代码里写死直接进行总结。所以任务的自动化串行是支持的:
想要复现的话,你可以试一下添加这个助手: https://chat-preview.lobehub.com/market?agent=frontend-architect ,然后在设置面板里勾上 网页爬虫 插件,并把模型切换为 GPT-4。
命令:请帮我介绍下前端浏览器的 OPFS 的 API 有哪些
补充: 我自己试下来只有 GPT-4 才能在没有 systemRole 的情况懂多轮工具的使用。如果是 GPT-3.5 可能需要尝试在 system 上强化工具使用的 prompt。
我想这也是为啥 ChatGPT 的插件只有 GPT-4 才能用的一个原因
触发插件逻辑时,并不是最终一步到位的结果,而是需求用户进行更复杂的数据输入,综合function call提取的用户输入信息完成最终的渲染。
这个需求是合理的,而且我在构思更加复杂的插件时也有发现这个问题。所以 #149 会进一步增强这块的能力。到时候是可以支持上了。
插件处理后的后续逻辑是不是交给插件自定义比较灵活?
这块后续我会写个 RFC 讨论下,看看如何开放插件的逻辑控制比较合适。
你可能没有完全理解我的问题,实际上我不需要GPT能在单轮对话里完成多插件的调用效果,这太过于依赖语言模型本身的能力了,我看了一下目前插件的代码逻辑(可能理解有误),插件层处理完数据return给lobechat,lobechat接收到这条数据,执行插件渲染,同时把数据再次发送给GPT,这部分逻辑是写死的吧? 我的需求只需要第一步GPT能正常触发function call,进入插件逻辑,本质上插件就是一个独立的网页,可以做任何事情,只是UI上嵌入在对话气泡里,此时插件应该要能正常渲染出来,但此时插件还没产生最终的结果,不能直接通知lobechat将插件数据丢给GPT处理,在插件完成本身的独立流程后,主动将结果和后续指令传递给lobechat,再跟GPT做后续的交互
这对于插件开发的限制还是蛮大的,目前这个机制插件只能开发一些简单的数据渲染模版类型的
你可能没有完全理解我的问题,实际上我不需要GPT能在单轮对话里完成多插件的调用效果,这太过于依赖语言模型本身的能力了,我看了一下目前插件的代码逻辑(可能理解有误),插件层处理完数据return给lobechat,lobechat接收到这条数据,执行插件渲染,同时把数据再次发送给GPT,这部分逻辑是写死的吧?
我的需求只需要第一步GPT能正常触发function call,进入插件逻辑,本质上插件就是一个独立的网页,可以做任何事情,只是UI上嵌入在对话气泡里,此时插件应该要能正常渲染出来,但此时插件还没产生最终的结果,不能直接通知lobechat将插件数据丢给GPT处理,在插件完成本身的独立流程后,主动将结果和后续指令传递给lobechat,再跟GPT做后续的交互
我明白你的意思,这是下一期插件迭代里要支持的功能。核心是允许插件控制发回内容给会话流的时机。这样在插件侧就可以实现很多复交互了。
这对于插件开发的限制还是蛮大的,目前这个机制插件只能开发一些简单的数据渲染模版类型的
你说的没错。当前的 LobeChat 的插件机制是基本上follow ChatGPT 的。 ChatGPT里的插件现在就基本都是展示型的组件,没有富交互能力。
这也是我觉得现在有问题的点。
Vercel 的ai sdk 文档里也提到了function call 的三阶段,第三阶段就是富交互 https://x.com/jaredpalmer/status/1673350963191508993?s=46&t=S01sh5U8Nv8bRLy2GXeJJw
LobeChat 现在处于第二阶段。
我看了一下目前插件的代码逻辑(可能理解有误),插件层处理完数据return给lobechat,lobechat接收到这条数据,执行插件渲染,同时把数据再次发送给GPT,这部分逻辑是写死的吧?
就是这一层发送数据的时机可以变成一个配置,默认是现在这样自动。然后支持 纯用户手动确认 和 程序化控制。
纯用户手动确认相当于在消息中多增加一个按钮,只有用户点了以后,才会把消息放进 content,并触发进一步会话。
程序化控制 则是提供一个消息通知机制,只有当接受到插件侧发送的消息以后,才会把消息写入 content,触发会话。这样控制权可以全部给到插件。让插件来决定啥时候往下执行
没错,我们的理解是一致的,期待插件三期,大有可为
不知道插件这部分在roadmap里的优先级如何,个人建议可以把优先级提升一些,我们一直在接触B/C/G端一线市场需求,插件这块带来的想象空间和商业化价值远比做一个好看好用的套壳工具大的多,这也是我觉得目前lobechat相比同类开源项目最具差异化和优势的一点。
不知道插件这部分在roadmap里的优先级如何,个人建议可以把优先级提升一些,我们一直在接触B/C/G端一线市场需求,插件这块带来的想象空间和商业化价值远比做一个好看好用的套壳工具大的多
接下来是 发布 1.0 前的个别扫尾工作了。
插件三期原本是预期 1.0 发布后进行。这个 issue 里讨论到的我先构思起来,不冲突。
明白。
@arvinxx 请问一下,这里面的 搜索引擎、网络爬虫 的插件 是如何定义的啊,有相关文件指向吗,想看看prompt是如何定义的。
在 Readme 和 wiki 的插件部分有介绍 @lucasjinreal
:tada: This issue has been resolved in version 0.95.0 :tada:
The release is available on:
Your semantic-release bot :package::rocket:
@Moonlit7 0.95.0 已支持新模式。通过在 manifest.json 中新增 type: standalone
开启。参考模板中的 https://github.com/lobehub/chat-plugin-template/blob/main/public/manifest-standalone.json。
另外测试了一个项目应该也初步可用: https://github.com/arvinxx/image-prompts
Lobe 官方插件的案例我在思考中。
@Moonlit7 做了个 standalone 类型的时钟插件:https://github.com/lobehub/chat-plugin-clock-time 。不包含任何后端 API。纯前端实现,已上线插件市场
https://github.com/lobehub/lobe-chat/assets/28616219/206b4c94-4674-4007-ac4f-450b9778d7f6
@arvinxx 大佬,请教一下你这个缩放的动画是怎么录制的? 另想请教你这个插件支持多轮对吗?
就比如说最上面的询问前端的问题,再次询问的时候,如何对返回内容进行进一步回答
就比如说最上面的询问前端的问题,再次询问的时候,如何对返回内容进行进一步回答
可以的,看个示例:
这个对话默认是开启了爬虫插件的吗? 如果用自己的大模型服务,是不是每一次发起会话,都要跑一次调用插件的逻辑
这个对话默认是开启了爬虫插件的吗?
这个对话使用的是这个助手:
和这个助手的对话,就会包含爬虫插件。
如果用自己的大模型服务,是不是每一次发起会话,都要跑一次调用插件的逻辑
不是, 只有当 ai 识别到需要调用插件服务时,才会去调用。正常会话不一定触发插件逻辑的调用
@Moonlit7 做了个 standalone 类型的时钟插件:https://github.com/lobehub/chat-plugin-clock-time 。不包含任何后端 API。纯前端实现,已上线插件市场
https://github.com/lobehub/lobe-chat/assets/28616219/206b4c94-4674-4007-ac4f-450b9778d7f6
我这两天在测试插件功能的时候,发现这类standalone的插件,如果没有返回结果给GPT进行总结,接下来的对话中GPT会认为这个问题没有解决,会再次调用这个插件。
以时钟为例,调用时钟后,仅在前端页面展示了时钟,而role=function的content是空,意味着接下来的对话仍然建立在不知道时间的基础上。
不过这应该是对插件开发者提出的需求,但对于普通用户来说就会显得非常迷茫。
Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑🤝🧑👫🧑🏿🤝🧑🏻👩🏾🤝👨🏿👬🏿
@Moonlit7 made a standalone clock plug-in: https://github.com/lobehub/chat-plugin-clock-time. Does not contain any backend API. Pure front-end implementation, has been launched on the plug-in market
https://github.com/lobehub/lobe-chat/assets/28616219/206b4c94-4674-4007-ac4f-450b9778d7f6
When I was testing the plug-in function in the past two days, I found that for this type of standalone plug-in, if no results are returned to GPT for summary, in the subsequent dialogue, GPT will think that the problem has not been solved and will call the plug-in again.
Take the clock as an example. After calling the clock, only the clock is displayed on the front-end page, and the content of role=function is empty, which means that the subsequent dialogue is still based on not knowing the time.
However, this should be a requirement for plug-in developers, but it will be very confusing for ordinary users.
我这两天在测试插件功能的时候,发现这类standalone的插件,如果没有返回结果给GPT进行总结,接下来的对话中GPT会认为这个问题没有解决,会再次调用这个插件。
以时钟为例,调用时钟后,仅在前端页面展示了时钟,而role=function的content是空,意味着接下来的对话仍然建立在不知道时间的基础上。
这个的确是个问题,插件层面需要把信息反填进 content。 你提的这个问题可以作为 standalone 类插件开发的注意事项。
Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑🤝🧑👫🧑🏿🤝🧑🏻👩🏾🤝👨🏿👬🏿
When I was testing the plug-in function in the past two days, I found that for this type of standalone plug-in, if no results are returned to GPT for summary, in the subsequent dialogue, GPT will think that the problem has not been solved and will call the plug-in again.
Take the clock as an example. After calling the clock, only the clock is displayed on the front-end page, and the content of role=function is empty, which means that the subsequent dialogue is still based on not knowing the time.
This is indeed a problem. The plug-in level needs to backfill the information into the content. The question you raised can be used as a note for the development of standalone plug-ins.
🥰 需求描述 | Feature Description
简单的了解了一下Lobechat的插件流程,在function call触发后。lobechat把function name和参数传递给插件,插件进行渲染,同时lobechat主项目固定将插件处理后的结果发送到LLM做一条总结,这个流程相对比较固定。 我正在尝试开发一个插件,触发插件逻辑时,并不是最终一步到位的结果,而是需求用户进行更复杂的数据输入,综合function call提取的用户输入信息完成最终的渲染。举个例子,我想开发一个excel数据生成图表的插件,触发插件后插件显示上传文件组件,拖拽文件上传,解析xslx,转化成图表结构化配置,用charts组件渲染,再把数据丢给语言模型做总结,后续对话也可以基于图表数据做问答,那么在插件第一步渲染时,lobechat主项目就不应该固定发送内容给GPT总结(因为此时还没有内容),插件处理后的后续逻辑是不是交给插件自定义比较灵活?
🧐 解决方案 | Proposed Solution
调用插件后主项目的后续处理逻辑开放给插件自定义控制
📝 补充信息 | Additional Information
No response