【要約】【Julia×Python】サロゲートモデル構築(応用編) 第4回：PyG へのデータロードと 0-based Contract の威力 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
Julia（Catlab）とPython（PyG）では、頂点インデックスの基数が異なる（1-based vs 0-based）。この差異を曖昧に扱うと、シリアライズやロード時にインデックスの補正漏れや二重適用が発生し、グラフのトポロジーが物理的に誤った状態で学習が進む致命的なリスクがある。
// Approach
JSONを「Single Source of Truth（単一の真実源）」と定義する「0-based Contract」を採用。Julia側のエクスポート境界において一度だけインデックスを-1し、JSON内は常に0-basedで保持する。これにより、Python側は補正処理を一切行わず、型キャストのみで安全にPyGのDataオブジェクトを復元できる。
// Result
インデックス補正の責任境界が明確化され、実装の複雑性とバグ混入リスクが低減された。Python側のローダは torch.long へのキャストと形状整形に特化でき、レビューの容易性も向上する。次回は、このデータ構造を用いたGCNの数理実装へと続く。
Senior Engineer Insight
> 異言語間連携における「インデックスの基数問題」は、一見些細だが、大規模な物理シミュレーションやグラフ学習においては、モデルの収束を妨げる、あるいは物理的に無意味な結果を導く致命的なバグに直結する。本稿が提案する「エクスポート境界での一度限りの変換」という設計は、責任境界を明確にし、デバッグコストを劇的に下げる優れたプラクティスである。実装の単純化（Python側での補正排除）は、運用時の予期せぬ副作用を防ぐ観点からも極めて合理的であり、システム全体の堅牢性を高める。実戦投入においては、こうした「データの契約」をドキュメント化し、CI/CDのテスト項目に含めるべきである。