Open QAbot-zh opened 11 months ago
我也在考虑这个问题,群聊中多人在提问时,GPT是需要将某个人的答复完了之后才会回答下一个人的,响应上感觉不是那么友好
我也在考虑这个问题,群聊中多人在提问时,GPT是需要将某个人的答复完了之后才会回答下一个人的,响应上感觉不是那么友好
如果异步处理,同时发送多条消息,会不会触发微信的账号风控机制(我不清楚)。同步机制我认为是合理的。
我也在考虑这个问题,群聊中多人在提问时,GPT是需要将某个人的答复完了之后才会回答下一个人的,响应上感觉不是那么友好
如果异步处理,同时发送多条消息,会不会触发微信的账号风控机制(我不清楚)。同步机制我认为是合理的。
异步处理不一定要同时发送,发送消息时间很短,而gpt请求响应时间略长,可以做成异步请求gpt回复,回复内容放入一个消息队列,由发送线程按最少1s时间间隔从消息队列里取内容、发送消息,就是很多搬运工、一个发货员的模式。就是实现起来要复杂很多。
我也在考虑这个问题,群聊中多人在提问时,GPT是需要将某个人的答复完了之后才会回答下一个人的,响应上感觉不是那么友好
如果异步处理,同时发送多条消息,会不会触发微信的账号风控机制(我不清楚)。同步机制我认为是合理的。
异步处理不一定要同时发送,发送消息时间很短,而gpt请求响应时间略长,可以做成异步请求gpt回复,回复内容放入一个消息队列,由发送线程按最少1s时间间隔从消息队列里取内容、发送消息,就是很多搬运工、一个发货员的模式。就是实现起来要复杂很多。
你就是要异步请求openai API,然后在wx和API之间加一层消息队列以此来增加响应速度。 实现起来太复杂,而且用户使用成本增高。 但如果第二条消息快于第一条消息,那不就乱了吗。
我也在考虑这个问题,群聊中多人在提问时,GPT是需要将某个人的答复完了之后才会回答下一个人的,响应上感觉不是那么友好
如果异步处理,同时发送多条消息,会不会触发微信的账号风控机制(我不清楚)。同步机制我认为是合理的。
异步处理不一定要同时发送,发送消息时间很短,而gpt请求响应时间略长,可以做成异步请求gpt回复,回复内容放入一个消息队列,由发送线程按最少1s时间间隔从消息队列里取内容、发送消息,就是很多搬运工、一个发货员的模式。就是实现起来要复杂很多。
你就是要异步请求openai API,然后在wx和API之间加一层消息队列以此来增加响应速度。 实现起来太复杂,而且用户使用成本增高。 但如果第二条消息快于第一条消息,那不就乱了吗。
不太理解用户使用成本提高这点。可能我们的日常使用场景不同,我给身边几个同学用的,基本都是跟小号机器人私聊,很少有在群里@的,大概都不想被其他人看到提问的内容,所以如果某个消息请求卡住了,串行同步的其他人只能被动等待,这个时间成本还是有的。 至于消息乱这点,也是可以通过其他方法来缓解,比如我在 #83 设想过的使用微信的引用回复功能。由于作者使用的hook暂不支持引用回复功能,我现在使用的是在回复消息前面加上提问者的问题文本,来尽量避免提问和回答乱掉。
我也在考虑这个问题,群聊中多人在提问时,GPT是需要将某个人的答复完了之后才会回答下一个人的,响应上感觉不是那么友好
如果异步处理,同时发送多条消息,会不会触发微信的账号风控机制(我不清楚)。同步机制我认为是合理的。
异步处理不一定要同时发送,发送消息时间很短,而gpt请求响应时间略长,可以做成异步请求gpt回复,回复内容放入一个消息队列,由发送线程按最少1s时间间隔从消息队列里取内容、发送消息,就是很多搬运工、一个发货员的模式。就是实现起来要复杂很多。
你就是要异步请求openai API,然后在wx和API之间加一层消息队列以此来增加响应速度。 实现起来太复杂,而且用户使用成本增高。 但如果第二条消息快于第一条消息,那不就乱了吗。
不太理解用户使用成本提高这点。可能我们的日常使用场景不同,我给身边几个同学用的,基本都是跟小号机器人私聊,很少有在群里@的,大概都不想被其他人看到提问的内容,所以如果某个消息请求卡住了,串行同步的其他人只能被动等待,这个时间成本还是有的。 至于消息乱这点,也是可以通过其他方法来缓解,比如我在 #83 设想过的使用微信的引用回复功能。由于作者使用的hook暂不支持引用回复功能,我现在使用的是在回复消息前面加上提问者的问题文本,来尽量避免提问和回答乱掉。
我说的用户指的,使用作者当前项目的用户,对于一些人而言,能搭建好目前的这一套已经很不容易了。我想表达的意思是其实很多人并非技术出身,服务设备性能也不优秀,加太多东西怕扛不住。
我也在考虑这个问题,群聊中多人在提问时,GPT是需要将某个人的答复完了之后才会回答下一个人的,响应上感觉不是那么友好
如果异步处理,同时发送多条消息,会不会触发微信的账号风控机制(我不清楚)。同步机制我认为是合理的。
异步处理不一定要同时发送,发送消息时间很短,而gpt请求响应时间略长,可以做成异步请求gpt回复,回复内容放入一个消息队列,由发送线程按最少1s时间间隔从消息队列里取内容、发送消息,就是很多搬运工、一个发货员的模式。就是实现起来要复杂很多。
你就是要异步请求openai API,然后在wx和API之间加一层消息队列以此来增加响应速度。 实现起来太复杂,而且用户使用成本增高。 但如果第二条消息快于第一条消息,那不就乱了吗。
不太理解用户使用成本提高这点。可能我们的日常使用场景不同,我给身边几个同学用的,基本都是跟小号机器人私聊,很少有在群里@的,大概都不想被其他人看到提问的内容,所以如果某个消息请求卡住了,串行同步的其他人只能被动等待,这个时间成本还是有的。 至于消息乱这点,也是可以通过其他方法来缓解,比如我在 #83 设想过的使用微信的引用回复功能。由于作者使用的hook暂不支持引用回复功能,我现在使用的是在回复消息前面加上提问者的问题文本,来尽量避免提问和回答乱掉。
我说的用户指的,使用作者当前项目的用户,对于一些人而言,能搭建好目前的这一套已经很不容易了。我想表达的意思是其实很多人并非技术出身,服务设备性能也不优秀,加太多东西怕扛不住。
技术畅想嘛,你看其它帖子,包括作者自己以前也有很多想法。而且其实目前都是配置式的,工作量主要在开发者那里,项目用户没有那么大的搭建成本,按流程走就行了。 至于性能嘛,现在这个项目量跟其他项目比起来真的不咋吃性能,我一个挂机宝都跑得起来。实在跑不起来的也可以跑老版本呀。这不应该是制约一个项目发展的理由。
Search for answers in existing issues
Feature description
小小地畅想一下,要是支持异步处理消息的机制,应该会很不错。比如有调用ChatGPT的,有调用plugin的,它们并不会造成资源的冲突,但是没有异步处理的话它们只能串行等待执行,响应速度就咔咔掉了。
Motivation
No response