Numpy与Scipy：两台机器上含NaN的np.dot计算结果差异显著

我之前也碰到过类似的跨机器数值一致性问题，结合你提到的全NaN向量、归一化+点积替代余弦距离的场景，咱们一步步拆解可能的原因和解决办法：

• NaN处理的底层实现差异：scipy.spatial.distance.cosine、np.dot以及不同版本的BLAS库，对NaN的处理逻辑并没有完全统一的标准。尤其是全NaN向量的情况，有些库会直接返回NaN，有些可能在计算流程中隐含了对NaN的过滤或特殊处理，而本地和服务器的库版本/实现不同，就会导致结果偏差。
• 硬件与浮点优化差异：本地和服务器的CPU架构（比如x86 vs ARM）、浮点运算单元（FPU）不同，再加上BLAS库的硬件优化策略差异，会让浮点计算的精度误差被累积放大。当计算大量向量时，这种微小误差在遇到NaN时会变得更显著，最终呈现出“显著差异”。
• 归一化步骤的隐性差异：你用归一化后点积替代余弦距离的思路没问题，但归一化过程中如果遇到全NaN向量，不同环境下的np.linalg.norm对NaN的处理可能不一致——比如有些环境下归一化全NaN向量会返回NaN，有些可能返回0，这直接影响后续的点积结果。

• 先隔离NaN向量的影响：先把全NaN向量单独筛选出来，验证非NaN向量在两台机器上的计算结果是否一致。如果非NaN向量结果吻合，那问题就完全集中在全NaN向量的处理逻辑上。可以用np.all(np.isnan(vec))来识别全NaN向量，单独统一处理（比如固定返回NaN或某个预设值），避免干扰整体计算。
• 手动统一NaN处理逻辑：不要依赖库的默认行为，自己实现对全NaN向量的判断和处理，比如：

  def normalized_dot_with_nan(vec_a, vec_b):
      # 处理全NaN向量的情况
      if np.all(np.isnan(vec_a)) or np.all(np.isnan(vec_b)):
          return np.nan  # 根据你的业务需求调整返回值
      
      # 对非NaN部分做归一化（避免NaN影响归一化结果）
      valid_a = vec_a[~np.isnan(vec_a)]
      valid_b = vec_b[~np.isnan(vec_b)]
      norm_a = valid_a / np.linalg.norm(valid_a) if len(valid_a) > 0 else 0
      norm_b = valid_b / np.linalg.norm(valid_b) if len(valid_b) > 0 else 0
      
      # 补回NaN位置的0，保证向量长度一致后做点积
      vec_a_norm = np.where(np.isnan(vec_a), 0, norm_a)
      vec_b_norm = np.where(np.isnan(vec_b), 0, norm_b)
      return np.dot(vec_a_norm, vec_b_norm)
  

  这样强制统一全NaN向量的处理逻辑，就能消除不同库带来的差异。
• 统一BLAS库版本：如果两台机器用的是不同的BLAS后端（比如本地是MKL，服务器是OpenBLAS），可以尝试在两台机器上安装相同的BLAS库（比如通过conda安装mkl或openblas），确保底层运算逻辑一致。
• 用误差容忍的方式比较结果：不要直接用==判断结果是否相等，而是用np.allclose()设置合理的误差阈值（比如rtol=1e-05, atol=1e-08），判断结果是否在可接受的浮点误差范围内。

注意归一化后的点积等价于余弦相似度，而余弦距离是1 - 相似度，如果你的代码里把相似度直接当成距离用，要确认逻辑没问题，但这应该不是跨机器结果差异的原因。

内容的提问来源于stack exchange，提问作者Slowpoke