セッションを越えて残すべきものを決める
まず、再現するのが難しいものから始めます。唯一の原本、注釈、承認された選択、設定、承認済みの結果などです。作業を理解して再開するために必要なファイルも加えます。キャッシュは容量が大きくても必須ではないことがあり、逆に小さな設定の忘れが大きなアーカイブを使い物にならなくすることがあります。
納品物と再開用アーカイブは分けましょう。受け取る人に必要なのは、承認された出力と短い説明です。あなたには入力、バージョン、試行、役立つ中間状態も必要です。却下された案、技術ログ、確定ファイルが混在したクライアントフォルダーは、誤った出力を使ってしまうリスクを高めます。
| Usage | À conserver pour la reprise | À remettre au destinataire |
|---|---|---|
| 画像 | 原本、やり取り、設定、必要なバージョン。 | 承認されたビジュアルと納品リスト。 |
| アシスタント | 許可された文書、モデル/バージョン、指示、質問、評価。 | 読み直した結果と利用上の制限。 |
| 計算またはトレーニング | 必要なデータ、プログラム、設定、適切な再開状態。 | 解釈できる結果とその読み取り方法。 |
記憶に頼らない棚卸しを作る
各ファイルに安定した場所を与え、入力と出力のつながりを保ちます。リストには相対パス、ファイルの役割、サイズ、状態（採用、やり直し、試行を理解するためだけに保持）を記載できます。相対パスを使えば、特定のマシン名を残さずにフォルダーを移動できます。
目的、ソフトウェアのバージョン、必須コンポーネント、作業手順、確認用の入力を記した再開メモを追加します。後で取得する予定の公開ファイルは、正確なバージョンとともに記録しておきましょう。将来入手できる保証はないため、かけがえがなく保持が許可されているものはローカルに保存しておいてください。
設定のエクスポートやログを共有する前に、もう一度確認しましょう。アーカイブに含めるべきでないパスワード、キー、アクセス用リンクは削除してください。メモには、正規のアクセスを復旧する方法を説明する必要がありますが、メモ自体に秘密情報を含めてはいけません。
モデルについて、利用と学習の再開を区別する
モデルの重みと完全な作業状態では、果たす役割が異なります。PyTorch では、モデルの state_dict がパラメータと一部の状態を保持します。学習を再開するには、オプティマイザの状態や進捗状況など、学習ループで使われる要素も必要です。正確に何が必要かはプログラムによって異なり、スケジューラ、混合精度、乱数シードも関係することがあります。
保存ポイントは、解決したい問いに応じて選びましょう。「もう一度予測する」のか「この段階から続ける」のかです。期待される構造を文書化し、自分のファイルを実際に再読み込みしてみてください。checkpoint-final のような名前は、再開に必要な要素がすべて保存されていることを保証するものではありません。
時間が足りなくなる前にコピーを計画する
アクセスを自分で管理できる保存先を用意し、その容量を確認しましょう。プロジェクトの開始時に小さくコピーし、その後、すでに安定した要素を中間コピーします。アーカイブは識別できるバージョンで保管してください。最終転送中に出力が変わると、どの状態を復元したのか分からなくなります。
最後のコピーの前に、予定している書き込みを終えるか、ソフトウェアが提供する整合性の取れたバックアップ方法を使ってください。書き込み中のファイルは、一覧作成とコピーの間で変わることがあります。学習が続いている場合は、フォルダに見えているだけの一時ファイルではなく、明示的に完了した再開ポイントを利用しましょう。
データ量、小さなファイル、中断は復元に影響します。この工程を3日、7日、30日のスケジュールに組み込みましょう。短い転送テストから、アーカイブ全体にかかる時間を確実には見積もれません。展開と開く時間も考慮に入れてください。
内容を確認し、次にコピーの整合性を確認する
まず、想定されるパスとファイル数を比較しましょう。サイズは空のファイルや途中で切れたファイルを見つけるのに役立ちますが、サイズが同じでも内容が異なるファイルが存在し得ます。バイト単位で確認するには、安定した各ソースファイルの SHA-256 ハッシュを計算し、そのコピーに対しても同じハッシュを計算します。Python ではこの計算が hashlib に記載されており、ほかのツールでも同じアルゴリズムが提供されています。
ハッシュの一覧は、それが記述するファイルとは別に保管し、一覧自体に自分のハッシュを含めようとしないでください。差分はコピーの誤りから生じることもありますが、2回の計算の間にソースファイルが変更されたことから生じることもあります。何かを置き換える前に原因を特定しましょう。
ハッシュが同じでも、成果物の品質を判断できるわけではなく、それだけでファイルの作成者を証明できるわけでもありません。ぼやけた画像や良くないモデルでも、改変なしにコピーされることがあります。そのため、整合性の確認と、代表的な出力を開くことや自分の基準を満たしているかの確認を組み合わせましょう。
例：画像100枚、使えるファイル202件
100枚のビジュアルの納品を想像してみましょう。再開用のアーカイブには、100枚のオリジナル、100枚の承認済み画像、1つの設定ファイル、1つの再開メモが含まれます：100 + 100 + 1 + 1 = 202ファイルです。別の一覧がこの202個の要素を記述しており、この一覧を含めるとフォルダには203ファイルあります。これは整理方法の一例であり、特定の処理をうたうものではありません。
コピー後、数え上げでは記述された202個の要素が見つかりましたが、1つのハッシュが異なります。つまり、一致したファイルが201個、確認が必要なファイルが1つあり、合計数が正しいだけでは不十分です。ソースファイルが変わっていなければ、その要素をコピーし直し、ハッシュを再計算します。ソースが変更されていれば、まず保持するバージョンを選び、一覧を整合性を保つように更新します。
次に、コピーから大きな画像、透明部分のある画像、テキストを含む画像を1つずつ開いてください。期待される100個の名前が納品物に含まれているかも確認します。この3つの開封は的を絞ったチェックを示すものであり、他のすべてのビジュアルの品質を保証するものではありません。処理中に報告された事例は個別に確認する必要があります。
古いパスを使わずに再開を繰り返す
バックアップ場所または別のテストフォルダからプロジェクトを開きます。最初の環境から依存関係をこっそり探すことなく、手順どおりにメモをたどってください。すると、欠落しているリンクファイル、フォント、拡張機能のバージョン、絶対パスが明らかになります。
画像の場合は、保存した設定でエントリを再開し、エクスポートを開きます。アシスタントの場合は、構成を再読み込みし、そのドキュメントを使って確認の質問を再生します。計算の場合は、状態の読み込みと、期待される小さなステップを確認します。検証は有用な結果まで到達する必要があり、エクスプローラーでフォルダが見えるだけではその再開をテストしたことにはなりません。
チェックの範囲を書き留めておきます。納品物が開くことは確認できても、自分のコンピューターで計算を再実行するために必要なソフトウェアを持っていない場合があります。その場合は、何が検証済みで、何が互換環境で試すべきまま残っているかを正確に記述してください。
偽の安心感を与えるエラーを見分ける
作業ディスク上の単一のアーカイブは、そのディスクとともに消える可能性があります。同期されたコピーは、誤った削除をそのまま複製する可能性があります。したがって、同じ場所に2つのフォルダが見えるからといって、データを復元する独立した2つの手段があることにはなりません。その重要性に応じた保存の仕組みを選び、想定した復元経路をテストしてください。
その他の落とし穴はもっとありふれたものです。最後のエクスポートがない、書き込みが終わる前にアーカイブがコピーされた、バージョン管理されていないパラメータ、受信者が持っていないアクセス権で保護されたファイルなどです。実際の保存先から、チェックリストで最終確認を行います。異常が未解決のままである限り、それを修正するために必要な要素を保管しておいてください。
- 期待される納品物が存在し、識別されている。
- 目録が採用したコピーと一致している。
- 確認用ファイルが保存先から開ける。
- 再開メモに依存関係と残る制限が記述されている。
- 必要なアクセス権は、共有ファイルとは別に管理されている。