请说明可能的因素及解决对策
Q&A
1 Answers
这里所谓的“软件端”指的是使用IB Service调用灵闪Task的进程吧。解决这类问题，首先要明确灵闪的2个产品设计：
- 灵闪中的算法工具不携带任何随机性（深度学习工具除外），即在图片输入、算法参数（含ROI）一致的情况下，算法输出必然一致；
- 使用IB Service调用灵闪时，自动采用“高速模式”进行作业执行
那么分析一下这里有可能产生“检测结果不一致”现象的点：
- 算法工具未被正常加载
- 图片输入不一致
- 算法参数（含ROI）不一致
- “高速模式”影响
- 算法工具的“随机性”不符合设计预期
根据以上问题逐一判断即可，以下提几个比较容易碰到的情况，需优先排查：
- 检查算法工具是否正常加载：通过vs附加到进程，在“模块”界面查看algorithmTool目录下的dll（如flowLogic.dll、DeepTool.dll）是否被正常加载；其中flowLogic.dll内不包含授权限制，其他的dll一般包含独立授权，若：
- 所有算法库都未被正常加载，则大概率是调用端的某些配置导致dll加载路径失效
- flowLogic正常加载、其他dll未加载，则大概率是授权异常
- 检查图片输入是否一致：需要对各种图片的类型有一定的了解，非常常见的问题例如：jpeg格式是有损压缩格式，例如灵闪中使用了无损压缩的图片（包括相机直接采集的图片数据）、IB Service使用了有损压缩的图片，那么就可能导致结果不一致；再如：一边使用的是3通道彩图，另一边未正确设置使用的是单通道黑白图，也可能导致结果不一致；
- 入参检查：主要是调用方需要确认没有在执行前设置一些不该设置的参数；
- 高速模式：一般在灵闪中配置task时大家不会开启高速模式，而IB Service默认开启高速模式，这可能导致两边看起来结果不一致。当然，按照产品设计，无论开不开高速模式，被绑定在输出参数代理里的数据也应该是一样的，我们需要考虑这里是否有软件bug，判断方式如下：
- 首先确保关注的结果已经被正确地绑定在“输出参数代理”中，这样它在高速模式下仍然会被正常计算
- 在灵闪中打开高速模式，查看灵闪内部关注的结果是否发生变化，若发生变化，则需提工单反馈问题至研发；若该结果无变化，则说明问题不是高速模式引发的
- 若以上问题都不存在，还有一种可能性极小（但也发生过）的bug，即底层算法内部存在随机行为。此情况下，即便仅使用IB Service单方面进行验证，也可能出现同一张图执行2次，输出结果不一样的现象。若发生此情况，也请提工单反馈至研发。
Related