constants.rsの更新忘れを気づけるようにしたい

[sevenc-nanashi]

内容

generate_constants.pyをWorkflowで実行して、constants.rsの更新忘れに気がつけるようにしたいです。

Pros 良くなる点

更新忘れに気が付けるようにする

Cons 悪くなる点

ないはず？

実現方法

generate_constants.pyに--check引数を作る

その他

infer側のWorkflowにするべきか（inferのファイル構造が変わって動かなくなるという事態に気づける）、train側のworkflowにするべきか（train側の更新で結果が変わったことに気づける）で悩んでます。
workflowのpathsのフィルタを消しさればどっちでもよくなりますが...

[Hiroshiba]

たしかにどちらでやるべきか…
たぶんtrainにとって問題ではないから、やるならinfer側なんですが、これ結局trigerが空中配線になりますね………

他の解決策考えてましたが、モノレポなのでバージョン固定ができないですねぇ。これが弱点のひとつ…？

アイデア！

• 全リポジトリで共通する定数なら、モノレポのルートに置いちゃう
  • 言語依存性どうすべきか困りそう
• infer側で別途定義しちゃう
  • 今モデルってtrainの見てるんでしたっけ、見てないならむしろこっちのが合ってる気もする…？
• inferワークフローのtrigerにtrainを追加する
  • 空中配線

[sevenc-nanashi]

#48 のWorkflowは4分くらいしかかかってないのでpathsを消し去っても良さそうな気がしてきました。
消し去った上でinferに記述、でも良さそう？

[Hiroshiba]

うーん･･･という気持ちはあります！

おそらく空中配線しているのは良くない気がするなーと思っていて（ここの感覚の違いはありそう？）、良くない仕様に合わせて変えるのもなぁという気持ちはあります。
疎結合でなくなっているのと、pathsをまとめるとスケールしなくなる感じ･･･？

[sevenc-nanashi]

アイデア：trainでモデルを吐く時にchar_map.jsonみたいなのも吐くようにして、それを読み込む形とか？

[Hiroshiba]

ありだと思います！
ここでコメントしたことと似てそう。（どこでコメントしたかわからなくなったのでissue立てるときリンクすると良いかもしれない）

ちょっとどうなるかわからないけど、学習後に吐くファイルは１ファイルにまとめておくと取り回ししやすそうな気もしました！

[sevenc-nanashi]

学習後に吐くファイルは１ファイルにまとめておくと取り回ししやすそうな気もしました！

exportしたときのファイルが一つ、のほうがやりやすそう。

現実的なのは、例えばzipで固めるとかですかね？

[Hiroshiba]

あっ！　学習後に吐く情報ファイルは１つ、という意図でした！！
たしかinfo.yamlみたいなの出力してませんでしたっけ。それに加える形だと取り回ししやすいのかな〜と思った次第です！

[sevenc-nanashi]

train_info.ymlは吐いてますね：

❯ cat ~/voicevox/e2k/train/outputs/2025_03_22_15_14_11_test/train_info.yml
git_sha: fa209b0c3243e33a891388811bb3917398ca0f52
use_cuda: true

[sevenc-nanashi]

とはいってもランタイムで必要な情報（文字マップ）と学習ログに相当するもの（git_sha、use_cuda）を一緒に吐くのはなんか違いそう？

[Hiroshiba]

まあたしかに･･･。

うーん！　infer側に普通に実装するのが無難な気がしてきました！

infer側は前提をいくつか持ってて、たとえばpthのネットワーク構造が違ってると正しく動かないはず。
トークンのマップも同じように前提とするのが丸い気がしてきました。
そうしないとランタイムで書かないといけない情報と、ランタイムが前提とする部分がちぐはぐになりそう。
例えば「0番目がsosトークン」みたいな情報はどっちが持つ？　そもそもsosトークンから始めるべきという情報はどっち？　みたいな。

trainとinferを疎結合にするために、これは重複させるのが良い気がしました！！

[sevenc-nanashi]

となると「今のtrainのコードで吐いたモデルがちゃんと今のinferで動くか」も確かめないといけなさそう？

[Hiroshiba]

あーこれはどうすべきか難しいですね。。

今のlatestのtrainモデルが必ずinferで動くべきなら、そうなはず。
ただ必ずしもinferリポジトリのコードで動かす必要はなさそう。
あとこれをやると、trainモデルをアップデートするタイミングと同時にinferも作らないとで、それはそれで大変そう。

「なるべくinferでも動くようにする。trainを破壊的変更するときはinferのこと考える。」という紳士協定でも良いのかも。

ちょっとこれはどっちが良いかわからないです。。 😇
contributing.mdで「学習モデルは高速な推論コードで動かしてる、モデルが大幅に変わる場合は一度相談して」とか書いとくだけで良いのかもしれない！！
（APIの破壊的変更と似てるのかもしれない）

[Patchethium]

横から失礼だが、本家のe2kでメタデータをモデルに含ませるように更新した。safetensorsも同じようにしたので、ここにはピッタリだと思う。
https://github.com/Patchethium/e2k/releases/tag/0.4.0