1. プログラム、そのパラメータ、および業務上の追跡を分離する
コードはプログラムの動作を記述します。設定は負荷を指定します:モデル、データ、バッチ、精度、出力先です。シークレットは必要なリソースへのアクセスを提供します。これらの要素を分離しておくことで、コードを書き直したり共有ファイルにトークンをコピーしたりせずに、試行を変更できます。
Kernodeckの注文参照により、アカウント内のレンタルコンテキストを特定できます。試行IDは、その期間中のプログラムの実行を区別します。役立つ場合はノートで両者を関連付けても構いませんが、スクリプトに支払いステータスから計算状態を推測させないでください。
同じサンプルで複数回起動する必要がある文書分類プロジェクトを例に考えます。プログラムの契約は、入力ファイル、許容されるパラメータ、出力フォルダ、エラーの返し方を記述します。データに関するガイドではコンテンツの検証を説明しますが、ここではこれらの段階をつなぐインターフェースを整理します。
2. 明示的でバージョン管理された入力契約を書く
必須フィールドと許容される値を文書化します。モデルやデバイスのように結果を変える決定に対して、暗黙のデフォルト値は避けてください。スキーマ番号は設定の形式をコードのバージョンと区別しますが、後者を置き換えるものではありません。
この教育用の例では、JSONファイルにスキーマ、入力パス、バッチ、要求されたデバイスが含まれています。相対パスは設定フォルダから読み取られます。この例で選ばれたこのルールにより、同僚がコマンドを起動するディレクトリに依存することを避けられます。
有効なJSONを読むことは、その構文を検証するだけです。その後、プログラムは型、フィールド、プロジェクトの制約を確認する必要があります。エラーの場合、高コストなリソースの読み込み前に停止し、修正すべきパラメータを名指しするメッセージを表示する必要があります。
{
"schema_version": 1,
"input": "../data/pilote.jsonl",
"batch_size": 4,
"device": "cuda"
}3. 単純なエラーを拒否するエントリポイントを準備する
argparse を使うと、オプションを宣言し、コマンドのヘルプを生成できます。以下の例は事前チェックのみを構成します:設定を読み込み、そのフィールドを確認し、既に使用されている出力フォルダを検出します。モデルやデータをメモリに読み込まず、GPUの可用性もテストしません。
この教育用コードを適応させたい場合は prepare_run.py に保存してください。実行が保証されたものではありません。次に、最終的なメッセージを計算結果と見なすのではなく、アプリケーションに独自の業務チェックを追加してください。デバイス cuda はあくまで要求です;PyTorch は ROCm でもこの名前を使用します。
既存の出力ディレクトリの拒否は、ここでは試行の混在を防ぐための規約です。真の再開コマンドは、別個のオプションとチェックを受け取る必要があります。ファイルが存在するからといって、新規起動を暗黙の再開に変えないでください。
import argparse
import json
from pathlib import Path
parser = argparse.ArgumentParser(description="プロジェクトの起動を検証する")
parser.add_argument("--config", type=Path, required=True)
parser.add_argument("--run-dir", type=Path, required=True)
args = parser.parse_args()
try:
config_path = args.config.resolve()
config = json.loads(config_path.read_text(encoding="utf-8"))
except (OSError, UnicodeError, json.JSONDecodeError) as exc:
parser.error(f"設定を読み込めません : {exc}")
expected = {"schema_version", "input", "batch_size", "device"}
if not isinstance(config, dict) or set(config) != expected:
parser.error("必要なフィールド : schema_version, input, batch_size, device")
if type(config["schema_version"]) is not int or config["schema_version"] != 1:
parser.error("schema_version は 1 である必要があります")
if type(config["batch_size"]) is not int or config["batch_size"] < 1:
parser.error("batch_size は正の整数である必要があります")
if config["device"] not in ("cpu", "cuda"):
parser.error("device は cpu または cuda である必要があります")
if not isinstance(config["input"], str) or not config["input"]:
parser.error("input は空でないパスである必要があります")
input_path = (config_path.parent / config["input"]).resolve()
run_dir = args.run_dir.resolve()
if not input_path.is_file():
parser.error("入力ファイルがありません")
if run_dir.exists():
parser.error("新しい出力フォルダを選択してください")
print(json.dumps({
"status": "configuration_validated",
"input": str(input_path),
"run_dir": str(run_dir),
"device_requested": config["device"],
"batch_size": config["batch_size"]
}, ensure_ascii=False))python prepare_run.py --config config/pilote.json --run-dir runs/pilote-0014. 実行とその結果に識別情報を与える
各実行を、キャンペーン内で一意の短い識別子に関連付けます。コードのリビジョン、スキーマ、実際に使用したパラメータを記録し、さらにデータとモデルの参照も書き留めます。これらの値を出力とともに保存することで、結果が後から変更された設定ファイルに依存しないようにします。
2つのバッチサイズを比較するには、2つの試行と2つのディレクトリを作成します。同じサンプルを維持し、意図的な違いを特定してください。pilote-001とpilote-002という名前だけでは何が変わったかを説明できません。マニフェストが名前とパラメータを結びつけます。
ツールで読み取れるサマリー形式を用意します。受信済み、成功、拒否、未処理の要素を区別できるとよいでしょう。完全な成功の基準を定め、最初の結果が書き込まれた時点で試行を終了とマークしないようにします。プログラムの終了コードは、この結論と一貫している必要があります。
表をスクロールしてすべての列を表示してください。| ファイルまたは状態 | 役割 | 期待されるチェック |
|---|---|---|
| manifest.json | コード、データ、パラメータの識別情報 | 実際に使用された値。シークレットは含めない。 |
| results.jsonl | 承認された要素ごとに出力1つ | 既知の識別子と準拠した形式。 |
| errors.jsonl | 拒否された要素と有用な理由 | 黙った消失も、不要な機微な内容もなし。 |
| summary.json | 試行の結論とカウンタ | 合計が一貫し、最終ステータスの前にファイルを再読み込み。 |
5. ツールにとって有用なイベントを公開する
いくつかの遷移を可視化します。設定の受理、データへのアクセス、モデルの読み込み、最初の出力の書き込み、処理の終了です。トレースがあれば、ドキュメントやプロンプトをコピーすることなく「この実行はどこまで進んだか」に答えられます。ステップと試行の識別子をメッセージに関連付けます。
Python の logging モジュールを使うと、メッセージをレベルと出力先で整理できます。次に、独自のイベント規約を選び、それを文書化します。エラーを書き込んだ後に成功で終了するアプリケーションは自動化を誤らせます。逆に、すべての警告が結果を使えないことを意味するわけではありません。
発行されたイベントと永続的な結果を混同しないでください。「バックアップ開始」というメッセージは、ファイルが再読み込みされたことを証明しません。長時間の実行については、専用ガイドでプロセスとセッションの関係を説明しています。あなたのインターフェースは特に、対話型接続の終了後もアクセス可能な結論を保持すべきです。
6. 失敗、再開、最終検証を定義する
有用な失敗を分類しましょう。無効な設定、存在しないリソース、計算エラー、要件を満たさない結果です。それぞれについて次のアクションを示します。どの効果が繰り返し可能かを決めずに自動リトライを導入してはいけません。すでに受け入れられた出力の書き直しとチェックポイントからの再開では、必要なルールが異なります。
最終的な手順書には、起動、観察、停止、再開、エクスポートの方法を記載します。ドキュメント処理の場合は、完了した識別子と再処理が必要な識別子のリストを保持します。トレーニングの場合は、保存された状態を新しいプロセスで検証するプロトコルを使用します。空でないディレクトリは、正しい再開の証拠にはなりません。
最後に、既知の設定と別の出力先を使い、新しい呼び出しでプロジェクトを確認します。想定された拒否を検証し、その後で小さな一連の流れを完全に実行します。このページの事前チェックは、同時アクセス、サービスの公開、ストレージの権限をカバーしていません。これらには個別の設計が必要です。