feat: 公式マルチシード再現と CI（pytest + repro-smoke）

[koki3070]

Summary

• 公式のマルチシード・バックエンド比較入口として experiments/run_backend_multiseed.py を追加し、読者向けに REPRODUCIBILITY.md と README.md（Known Constraints 含む）を整備する。
• .github/workflows/ruff.yml に pytest と、run_backend_multiseed.py の軽量 repro-smoke（1 epoch・seed 1・mahalanobis のみ）を追加し、README / REPRODUCIBILITY の CI 記述と一致させる。

Depends on

• feat: 損失・学習ループ・公式 main（losses / trainer / main） #57（PR6 がマージされるまで本 PR の差分には PR1〜6 の変更も含まれる。マージ後は main に対して PR7 分のみの差分に収束する想定。）

Test plan

• CI（ruff / pytest / repro-smoke）が緑になる
• ローカルで uv run pytest と README の smoke コマンドが通る

Made with Cursor

[t-uda]

依存管理まわりで一点、確認・修正した方がよさそうです。

現状、.github/workflows/ruff.yml と REPRODUCIBILITY.md は pytorch-topological について

git submodule update --init --recursive

を実行する前提の記述になっていますが、この PR head では .gitmodules が存在せず、実際には submodule 登録されていないように見えます。そのため、現在の運用は「submodule 優先」ではなく、実質的には pytorch-topological/ という repo root 直下の path dependency を CI で不足時に shallow clone する形になっています。

ただし、pyproject.toml では

torch_topological = { path = "pytorch-topological", editable = true }

としているため、再現性の観点では pytorch-topological の中身の commit も固定されるべきです。単に git clone --depth 1 https://github.com/aidos-lab/pytorch-topological.git pytorch-topological だと、upstream HEAD に依存して将来の CI / 再現実行が変わる可能性があります。

推奨は次のどちらかです。

1. pytorch-topological を正式に submodule 登録し、.gitmodules と submodule commit を追跡する。CI/docs は git submodule update --init --recursive に寄せ、clone fallback は削除または非常時扱いにする。
2. submodule にしない方針なら、CI/docs から submodule 前提の記述を消し、clone fallback でも特定 commit を checkout する。

この repo の目的が再現性確保なので、私は 1 の submodule 登録の方が自然だと思います。

[t-uda]

Codex review item 1（backend comparison の confounding）については、これは現時点の実験設計上ある程度避けられないものとして、明文化して扱う方針がよいと思います。

現状では、Mahalanobis backend は TopologicalLoss から渡される outlier probability を距離重みに織り込めますが、ellphi backend は tangency distance のみを使い、probability weighting は未実装です。したがって、この multiseed driver の比較は厳密には

Mahalanobis distance + outlier-probability weighting
vs
ellphi tangency distance without outlier-probability weighting

であり、「distance backend だけを完全に isolate した比較」ではありません。

ただし、これは必ずしも PR blocker ではないと思います。実装上・数学上、ellphi tangency distance に Mahalanobis 側と同型の probability weighting を直ちに入れるのは自然な一行修正ではなく、むしろ比較対象の定義を曖昧にする危険があります。したがって当面は、README / REPRODUCIBILITY / 実験ログの説明で、次を明確に書くのがよいです。

• この比較は backend-only ablation ではない。
• 同一のデータ・学習スケジュール・設定表面の下で、現行実装の二つの位相損失パイプラインを比較している。
• backend delta は、距離関数そのものの差だけでなく、probability weighting の有無も含む差として解釈する。

もし将来的に backend-only ablation を追加するなら、Mahalanobis 側でも probs=None に固定した variant を別実験として設けるのが自然だと思います。

[koki3070]

Issue 4531819747:
PR1 で third_party/pytorch_topological.ref と scripts/ensure_pytorch_topological.sh を導入済みです。本 PR の README / REPRODUCIBILITY / CI もその手順に揃え、未 pin の shallow clone を主手順から外しました。

[koki3070]

Issue 4531912256:
README / REPRODUCIBILITY に、Mahalanobis（確率重みあり）と ellphi（未実装）の差を含む比較である旨を明記しました。backend-only ablation ではないこと、同一スケジュール・設定表面でのパイプライン比較として読む旨を追記しています。

[t-uda]

スカッシュコミット 5b61c98 を main に直接 push して適用済み（squash merge 累積によるコンフリクト回避）。