AI测试 算法测试该怎么报 bug

feifeihuanming · 2021年06月08日 · 最后由 零渡 回复于 2021年06月10日 · 864 次阅读

对于算法测试测试来说,传统的报 bug 的方式感觉不太适合。

比如说算法有个问题,暗光下人脸检测的准备率不高。我们是可以报一个暗光下检测率不高的 bug,但是会有问题:
算法很有可能永远不能彻底解决找个问题,那么就会出现这个 bug 报了之后就关不掉,一直放在那里。

不知道相关同学是怎么做的?

共收到 12 条回复 时间 点赞

一码归一码,如果是个广告系统,提过 “某情况下,A 的预测点击率应该比 B 高” 这种 bug,改完 A 比 B 高算解决。
图像识别可能就提 “这张图没识别出来”?改了能识别算解决。

bug 肯定要提,置于 Bug 的类别归属是放到体验优化中,必解 bug,还是其他类别,那得看你们自己怎么去和 rd 约定的了

加个约定俗成的缺陷类别就行了

其实还有一个问题,就是对于识别类或者检测类算法来说,RD 一般是不会针对具体的几张图片去解决问题的。特别是用神经网络训练出来的模型,基本上具有不可解释性,RD 更多的是解决一类问题。如果报 bug 的时候,只报几张图片,其实对于 RD 来说没有什么意义

feifeihuanming 回复

解决一类问题,是不是应该测试一批图片,报识别率的问题・_・?

“暗光下人脸检测的准确率” 的需求是多少?90%?
那低于 90% 都是 BUG 咯……说到底还是没有明确需求呗

是的,像算法测试,一定是有个阈值的,比方说需要到达百分之多少,然后就以阈值报 bug 就好了,或者优化

按照类别报 bug,会有一个问题。一般情况下影响算法的因素大体来说就那么几种,比如光线问题,角度问题等。按照类别报的话,就会出现一个算法产品就那么几个 bug。
隐隐觉得传统的 bug 设计思路不是很适合算法测试

你通过的标准是什么,那改到那个标准就通过

按照精确度、召回率那些指标看呗,如果总体已经符合要求了就不提,不符合的话把不符合的 case 整理出来,统一提

1.测试集从哪来的?
2.数据量有多大,F1 等相关指标多少?
如果这两条没有,那大概率就会被吐槽了,也不会理你的 BUG。。。

这个可以定量数据去定 BUG, 依据楼主信息, 我理解是在某一光亮度同一环境下测试如 10000 的成功率, 场景如下:摄像头在某地 6 点识别、7 点、8 点等识别成功率要达到多少,去定义你们的产品是否有 BUG

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册