PyTorchコミュニティがInductorの損失関数チェック不備を報告、ラベルのサイズ不一致でも値を返す可能性

PyTorchコミュニティは10月8日、学習の正確性に関わる最小再現例を報告した。torch.nn.functional.nll_lossに空間サイズの合わないラベルを渡すと、通常のeager実行とtorch.compile(backend="aot_eager")はいずれも入力を拒否する。一方、Inductorを使うと損失テンソルが返される。報告環境は開発版の2.15.0a0+git1a080e5で、現在もissueはオープンしており、ページには修正PRが掲載されていない。コミュニティの報告

このケースでは入力を(2, 3, 2, 2)に設定しており、2つのサンプル、3つのクラス、2×2の空間次元を表す。一方、ラベルの形状は(2, 2, 1)だった。公式ドキュメントでは、多次元の負の対数尤度損失について、ラベルの形状はクラス軸を除いた入力の各次元に対応する必要があるとしている。したがって、この場合の正しい形状は(2, 2, 2)となる。ドキュメントは、入力が対数確率であること、ラベル値が有効なクラス範囲内にあることも求めている。APIドキュメント

注目すべき点として、再現例では入力に乱数を使っている。焦点は損失値が妥当かどうかではなく、誤った形状が拒否されるかどうかにある。aot_eagerも計算グラフを追跡して実行するが、こちらでは例外が維持される。報告者はこの違いを根拠に、問題の所在をInductorのloweringまたはdecompositionの経路に絞っている。これは対照結果に裏付けられた手がかりだが、メンテナーが根本原因を確認したことを意味するものではない。再現例とバックエンドの比較

エンジニアリングチームにとって、こうした挙動の違いにより、データ前処理のサイズ誤りの発見が遅れる可能性がある。たとえばピクセル分類の処理で幅の誤ったラベルが生成された場合、損失が有限値かどうかだけを確認していると、入力の契約違反を見逃しかねない。これは事例から導かれるリスクであり、元の報告では学習全体、勾配の結果、モデル品質の低下までは示されていない。

コンパイルを使った学習を行うチームは、データを損失関数に渡す前に形状を確認し、意図的に誤った形状のラベルを作るケースをeagerとコンパイル後のバックエンドの比較テストに加えるとよい。今後は、上流で影響を受けるバージョンが確認されるか、サイズチェックが復元されるか、例外動作の回帰テストが追加されるかを注視したい。現時点の証拠から、すべての正式リリースや正しい形状の入力まで影響を受けるとは推論できない。