例行检查
问题描述上游报错显示被禁用,后续上游恢复几小时后,渠道仍未启用
复现步骤
预期结果
相关截图如果没有的话,请删除此节。
ecbunoof1#
这个自动激活渠道,必须要经过testall测试后才能自动启用吗?
vptzau2j2#
对于这个渠道的自动禁用和激活,测试下来感觉是有改进的空间的,主要的场景如下:
现在基本都是把3.5和4.0分成两个渠道,然后当自动测试时,选取的是渠道的第一个模型,在4.0的中就会被默认成dalle3,dalle3的完成时间是较长的,又会触发渠道的时间阈值,就会被自动禁用,以此会往复循环,而且还会造成不必要的测试的额度浪费(测试频率较高下)。
如果后期接入了某些开放文生图,文生视频之类的api,时间阈值这一项会很尴尬,对于text长了不好,没有测试的意义,对于image短了又会有1的情况发生。
所以在上述的问题下,对于自动测试可以采取对于渠道指定测试模型,如果没有选取则从该渠道的models列表里面随机一个,然后加上 #1059 这个issue设置一个响应阈值,具体的方案看作者想如何改动,我可以帮忙进行pr。
yv5phkfx3#
是的,这里预期今天优化。
ki0zmccv4#
目前仅支持测试被禁用的渠道,其他功能需要等待后续优化。
4条答案
按热度按时间ecbunoof1#
这个自动激活渠道,必须要经过testall测试后才能自动启用吗?
vptzau2j2#
对于这个渠道的自动禁用和激活,测试下来感觉是有改进的空间的,主要的场景如下:
现在基本都是把3.5和4.0分成两个渠道,然后当自动测试时,选取的是渠道的第一个模型,在4.0的中就会被默认成dalle3,dalle3的完成时间是较长的,又会触发渠道的时间阈值,就会被自动禁用,以此会往复循环,而且还会造成不必要的测试的额度浪费(测试频率较高下)。
如果后期接入了某些开放文生图,文生视频之类的api,时间阈值这一项会很尴尬,对于text长了不好,没有测试的意义,对于image短了又会有1的情况发生。
所以在上述的问题下,对于自动测试可以采取对于渠道指定测试模型,如果没有选取则从该渠道的models列表里面随机一个,然后加上 #1059 这个issue设置一个响应阈值,具体的方案看作者想如何改动,我可以帮忙进行pr。
yv5phkfx3#
是的,这里预期今天优化。
ki0zmccv4#
目前仅支持测试被禁用的渠道,其他功能需要等待后续优化。