记一次采坑经历

起因

为了验证RGB格式和BRG格式的输入数据对模型预测结果产生的影响，分别在gpu01和gpu02上做了AB测试。用同一张图预测是否为户型图，果然结果有差别，但差异很小，预测分数分别为97.49%和97.47%。这时候误以为验证了假设，开心的在两台机器部署了一样的程序，结果发现预测结果还是不一样，开始了排坑之旅。。

过程

假设1

第一反应是2台机器使用的模型不一样，通过 md5sum 验证，结果相同，所以模型没问题

假设2

模型没问题，就可以验证模型的直接输入，此时把两台机器模型预测的np数组分别保存下来，做元素一致性对比，结果果然不一样，遂逐元素进行对比，先将多维数组压缩为一维，然后用二分查找法对比不一致元素，发现在比较靠前的元素就有不一致的，这个时候复杂的来了

假设3

这个时候还是怀疑 RGB 顺序的问题，将多维数组拆到 R,G,B 三个通道，分别对比，结果发现还是不一致，遂排除RGB顺序的影响

假设4

这时开始拿出一部分元素进行对比，发现绝大多数元素值还是相同的，一直到223这个位置的元素值开始有不一样的，此时表现出来的现象是主要在一些边缘位置有差异

假设5

这时从源头出发，怀疑输入图片经过网络传输后字节流会稍微不太一致，遂用 md5sum 验证保存的图片，结果是一样的

假设6

排除了开头，排除了结尾，通过不断缩小范围，这时就只有一个地方了，就是图片在输入模型前的压缩转换。仔细看了下代码，有这么一行

img = cv2.resize(img, target_size, interpolation=cv2.INTER_CUBIC)

结合前面观察到的边缘位置元素不一致，一下明白了，大胆怀疑是 opencv 的问题，遂分别看两台服务器的 opencv 版本，结果如下

opencv1

opencv2

凶手找到了，opencv 不同版本resize的结果稍不同

结论

这个问题不太容易暴漏，万万没想到居然是 opencv 版本不一致引起的，一开始压根就没往这方面想，得到的教训就是统一环境配置太重要了，这种环境不一的情况平时可能暴漏不出来啥问题，即使有，影响也很轻微，但是需要排查问题的时候就极其痛苦，需要不断做假设，做验证，然后推倒重来。珍爱生命，统一环境，从我做起。