出力・元データ・設定を迷わず見つけられるように。

説明できる構造を選びましょう

プロジェクト名を付けたフォルダを作り、役割が明確ないくつかの保管場所を用意します。人名や今日の日付だけでは、6週間後に内容を理解するのに十分とは限りません。ルートに置いたメモに、入力、進行中の試行、採用した納品物がどこにあるかを書き記しておきましょう。

ケンブリッジ大学は、早い段階で整理方法と一貫した命名規則を決めておくことを推奨しています。以下のモデルは、小規模なセッション向けにBriefGPUが提案するものです。お使いのソフトウェアがすでにプロジェクト構造を定めている場合は、それに合わせて調整してください。プロジェクトが関連リソースを正しく参照できることを確認せずに、それらを移動しないでください。

受け取った入力を識別できる状態に保つ

最初の処理の前に、元の名前と保存場所を記したソース一覧を作成しましょう。Cornell が生データについて推奨しているように、これらの入力の無傷のバージョンを保存しておきます。「originals」という名前だけでは内容は守られません。ソフトウェアには別の出力フォルダを指定し、テストファイルでその動作を確認してください。

計算の前に入力を変換したりトリミングしたりする必要がある場合は、その下準備を明示された工程として扱いましょう。受け取ったソースとのつながりを保ちます。そうすれば、もともと存在していた不具合、下準備の問題、GPU 処理による影響を区別できます。

新しいソースが古いものを置き換えるときは、バージョンと見直すべき出力を記録しましょう。理解したい実験で使われているファイルを、黙って上書きしてはいけません。大切なのは有用な来歴を残すことであって、作業コピーをいつまでもすべて保持することではありません。

各作業単位に安定した識別子を付ける

image-001 のような短い識別子は、同じ入力を複数の実験にわたって追跡するのに役立ちます。出力が採用されてもその役割は変わりません。「良い」「悪い」「ほぼ最終」といった名前でファイルを絶えず改名するのではなく、検証状態は一覧表で管理しましょう。

100件の場合、番号001から100までが規則的な目印になります。納品に必要な場合は、業務上の参照番号も加えましょう。photo.pngという名前の2つのファイルを別々のサブフォルダで受け取ったからといって、同じものを指していると決めつけないでください。エントリの完全なパスは、識別子と関連付けたままにしておく必要があります。

出力先のツールで使える名前を選びましょう。Windowsでは特にコロン、疑問符、アスタリスクが予約されており、通常の規則では大文字と小文字だけでの区別も確実にはできません。image-007_essai-02.pngのような名前なら、こうした曖昧さを避けられます。万能な互換性を約束するのではなく、他のツール固有の制約を確認してください。

例：2回のテスト、1つのソースコレクション

2つのフォルダに8枚の画像が届いたとします。インベントリは image-001 から image-008 を割り当て、元のパスを保持します。最初のパスでは試行01の設定を使用し、そのすべての出力は対応するフォルダに入ります。image-003 と image-006 の不具合により、この2件だけに限定した2回目の試行を行うことになります。

最初の試行で得られた6つの良好な結果は、フォルダをより均一にするために再計算されることはありません。台帳には、各入力に対してどの出力が採用されたかが記録されています。納品v01には期待される名前の8つのファイルが含まれますが、その由来は2回の試行に分かれています。この例は整理方法を説明するものであり、設定によって必ず結果が改善されることを前提としていません。

試行時の設定を保存しましょう

essai-02.txtという名前のファイルは、ソフトウェアがパラメータをエクスポートできない場合、単なるメモでもかまいません。ツールのバージョン、該当する場合はモデル、対象となる入力、選択した値を記録しましょう。前回の試行からの変更理由も加えます。パラメータがウィンドウに表示されるだけの場合は、スクリーンショットでメモを補足できます。

毎回の実行後に上書きされる「現在の設定」という単一のメモは避けましょう。それでは最後の試行は説明できても、以前の出力は説明できなくなります。複数の試行が同じパラメータを使用する場合は、同じ設定を無駄に書き写すのではなく、特定した同じ構成を参照しましょう。

ソフトウェアのバージョンとパラメータは結果の説明を容易にしますが、それだけで同一の再現が保証されるわけではありません。アプリケーションによっては追加の情報やリソースが必要です。特に学習状態の場合など、正確な再現が必要なときは、そのドキュメントに従いましょう。

判断を説明する日誌をつけましょう

日誌は台帳を補完します。台帳は「この入力は今どうなっているか」に答え、日誌は「なぜ変更したのか」に答えます。日付入りの数行で十分です。対象の試行、観察、判断、次の確認事項を記録します。誰も活用できないなら、ソフトウェアの各メッセージを書き写すのは避けましょう。

たとえば、役立つ記録はこうなります。「試行01：image-003 と image-006 で輪郭が不完全。この2件を設定Bでやり直す。他の出力は最終確認待ちとして保持する。」レビューの後、実際の判断を追記します。最初の観察を、不具合がなかったかのように書き換えないでください。

技術ログを送信する前に読み返しましょう。個人用のパスやアクセス手段が含まれている可能性があります。機密情報はドキュメントフォルダとは別に保管してください。同僚向けのメモは、その人が必要とする情報を用いて作業を説明するものでなければなりません。

整理・納品・バックアップを区別しましょう

作業フォルダは、あなたの判断に必要な試行を保持します。納品フォルダは、受け取り手が受け取るべきものをまとめます。バックアップは、必要な要素を別の保存先に保持し、コピーの確認を行います。同じ領域に並べた3つのフォルダだけでは、この3つの役割を果たすことはできません。

すべてのソースを各試行フォルダにコピーしないでください。台帳を通じて出力を入力に結びつけます。納品では、自立した一式を渡すために選択したコピーが役立つことがあります。その場合は、その由来とバージョンを記録しましょう。バックアップについては、転送後の台帳と確認を詳しく説明した専用のガイドに従ってください。

除外したバリアントを整理する前に、判断の説明や作業のやり直しに必要なものが残っているかを確認しましょう。この整理方法は保持期間を定めるものではありません。何を残す価値があるかを判断し、その後で基準となるコピーを見つけられるようにするものです。

ランダムに選んだ出力で確認を行いましょう

まずソフトウェアを開かずに納品ファイルを1つ選んでください。その名前と一覧から、エントリー、それを生成した試行、設定、承認判断をたどれます。手直しが必要だった出力でも同じことを繰り返してください。この流れが記憶に頼るなら、追跡にリンクが足りていません。

次に数量を確認します。予定していた入力の数、採用した結果、除外した要素、除外したバリエーションなどです。整理されたフォルダでも、内容が不完全なことはあります。この小さなチェックは、差異に理由があり、他の人も使うべきファイルを理解できる状態になれば完了です。