Ultralytics 8.4.160、アノテーションキャッシュの更新漏れを修正し、OOM再試行時にオプティマイザーの状態を保持

Ultralyticsは9月22日に8.4.160をリリースし、データのアノテーションが変更されても学習時に古いキャッシュが使われ続ける問題を修正した。あわせて、メモリ不足の発生後にバッチサイズを自動で縮小する際の復旧処理を調整した。GitHubの正式リリースとPyPIパッケージはいずれも公開済みで、今回の変更は学習データと学習状態の整合性に関わる。[リリース告知](https://github.com/ultralytics/ultralytics/releases/tag/v8.4.160)、[PyPIリリース履歴](https://pypi.org/project/ultralytics/8.4.160/)

キャッシュの問題は、単純な操作で発生する。YOLOラベルのクラスを0から1に変更しても、ファイル長は変わらない。旧版ではパスとファイルサイズの合計からキャッシュキーを生成していたため、変更後も既存のキャッシュにヒットする可能性があった。修正の提出者は画像1枚のデータセットで問題を再現し、2回目の読み込みでもクラス0が取得されることを確認した。修正を適用すると再スキャンが実行され、クラス1が取得された。[修正の説明](https://github.com/ultralytics/ultralytics/pull/26283)

新版の共通関数`get_hash`は、各ファイルのパス、個別のファイルサイズ、ナノ秒単位の更新時刻を順次取り込み、SHA-256を計算する。確認するのはファイルのメタデータであり、ファイル全体を読み込んで内容のハッシュを計算するわけではない。公式ドキュメントにも、この実装が反映されている。物体検出、深度推定、セマンティックセグメンテーションなど、この共通関数を使うデータキャッシュが影響を受け、アップグレード後は既存のキャッシュについて一度再スキャンが行われる。[関数ドキュメント](https://docs.ultralytics.com/reference/data/utils/)、[適用範囲](https://github.com/ultralytics/ultralytics/pull/26283)

同じリリースに含まれるもう一つの修正は、最初の学習エポック中に発生するOOMの再試行に対応する。従来の処理では、データローダーを再構築する際にオプティマイザーも再構築していたため、蓄積済みのモメンタムや適応的な更新に使う統計量、さらにはチェックポイントから復元した状態まで失われる可能性があった。今回の変更により、オプティマイザーと学習率スケジューラーは、オプティマイザーがまだ存在しない場合にのみ作成される。バッチサイズを縮小した後は元のオブジェクトを再利用し、関連する重み減衰係数を再計算する。[学習状態に関する修正](https://github.com/ultralytics/ultralytics/pull/26284)

二つの修正には、依然として明確な限界がある。データ同期ツールがファイルサイズと更新時刻の両方を保持する場合、キャッシュは引き続き内容の変更を見逃す可能性があり、影響を受けるキャッシュを手動で削除する必要がある。また、OOMからの復旧では、引き続き該当エポックを再実行する。オプティマイザーの状態が保持されても、失敗したバッチから正確に再開できるわけではない。修正の提出者は、OOMを強制的に発生させたローカル環境での検証を報告しているが、専用の回帰テストは後にメンテナーによって当該PRから除外された。[キャッシュの制約](https://github.com/ultralytics/ultralytics/pull/26283)、[再試行と検証の記録](https://github.com/ultralytics/ultralytics/pull/26284)

エンジニアリングの観点では、アノテーションの修正や学習の再開を繰り返すチームは、既知のクラス変更を使ってキャッシュが再構築されることを確認し、OOM発生前後のモメンタムと学習率を抜き取りで点検すべきだ。初回の再スキャンにかかる時間もスケジュールに織り込み、アップグレード後のデータ読み込みコストを学習性能の低下と誤認しないようにする必要がある。古いキャッシュがどの学習成果物に影響した可能性があるかは、引き続きデータのバージョンと実行記録を照合して調べる必要があり、アップグレードだけで過去に学習を終えたモデルが修復されるわけではない。