1. 要件確認        → タスク種別・データ・制約を整理
2. リソース見積もり → GPU/VRAM/ディスク/訓練時間の概算（下記参照）
3. Web調査         → 最新API・モデルクラス・損失関数を調査
4. データ前処理    → データ読み込み・前処理・DataLoader構築
5. モデル構築      → Web調査結果を基にモデルを構築
6. 訓練設定        → optimizer/scheduler/W&B設定
7. スモークテスト  → 小規模データ（100件）で訓練ループが回ることを確認
8. 訓練実行        → 訓練ループ実行・進捗監視
9. 評価            → 検索指標で性能評価
10. 保存・共有     → モデル保存・HuggingFace Hub公開（任意）

訓練開始前に必ず以下を確認:

GPU:
  - torch.cuda.is_available() で GPU が利用可能か確認
  - GPU 無しでの BERT ファインチューニングは非現実的（1エポック数日）
  - VRAM 容量に応じたバッチサイズを選択（後述の目安表参照）

訓練時間の概算:
  total_steps = len(dataset) / batch_size * num_epochs
  → 1ステップあたりの時間をスモークテストで計測
  → total_steps * step_time で総訓練時間を見積もる
  → 24時間を超える場合はデータ量・エポック数・モデルサイズを再検討

ディスク容量:
  - ベースモデル: 0.4〜2GB（ダウンロード時）
  - チェックポイント: モデルサイズ x 3（model + optimizer state）x 保存数
  - 例: 335Mモデル + AdamW = 約4GB/チェックポイント
  - 10エポック保存 = 40GB+（cleanup_checkpoints で古いものを削除）

RAM:
  - データセット全件メモリ展開: 件数 x 平均テキストサイズで概算
  - 100万件超は streaming=True を検討

大規模コーパスから検索したい？
├→ Yes → レイテンシ制約厳しい？
│        ├→ Yes → Bi-Encoder（ANN検索と組み合わせ）
│        └→ No  → ColBERT or Bi-Encoder + Cross-Encoder リランキング
└→ No  → ペア単位の精密判定？
         ├→ Yes → Cross-Encoder
         └→ No  → SPLADE（キーワード＋セマンティック両立）

1. sentence-transformers 公式ドキュメント
   → https://www.sbert.net/
2. HuggingFace Hub - モデルカード
   → https://huggingface.co/models?library=sentence-transformers
3. sentence-transformers GitHub リポジトリ
   → https://github.com/UKPLab/sentence-transformers
4. HuggingFace Transformers ドキュメント
   → https://huggingface.co/docs/transformers/
5. PyPI - sentence-transformers
   → バージョン・変更履歴の確認

- "sentence-transformers {version} training example {year}"
- "sentence-transformers {loss_function} usage {year}"
- "huggingface {model_type} fine-tuning tutorial {year}"
- "sentence-transformers CrossEncoder training guide {year}"
- "ColBERT v2 training huggingface {year}"
- "SPLADE training sentence-transformers {year}"

1. WebSearch で最新のチュートリアル・公式ドキュメントを検索
2. WebFetch で公式ドキュメント・GitHub の具体的コードを取得
3. 取得したコードのバージョン互換性を確認
4. 既存コードベースの依存バージョンと照合
5. 不整合があればフォールバック戦略を実行

Random Negative   → 簡単、だが非効率
Hard Negative     → BM25/既存モデルで取得、高品質
In-Batch Negative → バッチ内の他ペアを流用、GPU効率良

- Dynamic Padding: バッチ内の最大長に合わせてパディング
- collate_fn でバッチ構築ロジックをカスタム
- num_workers はCPUコア数の半分を目安
- pin_memory=True（GPU使用時）

# 注意: 具体的なimport・APIは Web調査で最新を確認すること
for epoch in range(num_epochs):
    model.train()
    for batch in tqdm(train_dataloader, desc=f"Epoch {epoch+1}"):
        optimizer.zero_grad()
        loss = compute_loss(model, batch)
        loss.backward()
        optimizer.step()
        scheduler.step()
    # 検証・チェックポイント保存
    evaluate(model, val_dataloader)
    save_checkpoint(model, epoch)

import wandb

wandb.init(
    project="search-model-training",
    name=f"{model_name}-{dataset_name}",
    config={
        "model_name": model_name,
        "learning_rate": lr,
        "batch_size": batch_size,
        "num_epochs": num_epochs,
        "loss_function": loss_fn_name,
        "max_seq_length": max_seq_length,
    },
)

- fp16: NVIDIA Volta以降（V100, A100, RTX 30xx+）
- bf16: Ampere以降（A100, RTX 30xx+）、勾配のダイナミックレンジ広い
- 選択: bf16対応GPU → bf16、それ以外 → fp16

実効バッチサイズ = バッチサイズ × accumulation_steps
→ VRAM不足時にバッチサイズを擬似的に拡大
→ accumulation_steps = 目標バッチサイズ / GPUバッチサイズ

- VRAM使用量を大幅削減（計算時間は10-20%増）
- 大規模モデル（>300Mパラメータ）で特に有効
- model.gradient_checkpointing_enable() で有効化

- エポック進捗: tqdm(range(num_epochs), desc="Training")
- ステップ進捗: tqdm(dataloader, desc=f"Epoch {epoch}")
- postfix で loss/lr をリアルタイム表示
- tqdm.write() でログ出力（進捗バーを崩さない）