akaza-im/akaza-default-model

make evaluateが動作しない

Closed this issue · 6 comments

tkng commented

make evaluate すると、以下のようなエラーが出ます。

Error: Cannot load file: reader.cc:94: MARISA_IO_ERROR: file == NULL, file=data//default/unigram.model

直接のエラーはこちらで出ているのでこちらのリポジトリにissueを起こしていますが、原因は https://github.com/akaza-im/akaza/blob/2e9dd541e1bb48f80e44e671c42bdb35766733ad/libakaza/src/engine/bigram_word_viterbi_engine.rs#L121 でmodel_nameがdefaultになっていることです。model_nameという概念に対するルールを明確にする必要があるように感じます。

  • 環境変数は AKAZA_MODEL_DIR なので、今 data/ 内にあるデータを data/default に移しても動作はする
    • この場合、MODEL_DIR内にmodel_nameがディレクトリ名として存在する、というルールになる
    • akaza-default-model の立場からすると、1モデル1リポジトリなので、data/default にデータを入れるのは単に煩雑になる
  • 環境変数を AKAZA_MODEL_NAME に変えるなら、環境変数 AKAZA_MODEL_NAME が指定されている場合はdefaultというモデル名は付加しない、という挙動がよさそう
  • AKAZA_MODEL_DIR が指定された場合はそのディレクトリから、そうでない場合は ~/.local/share/akaza/model/{MODEL_NAME} から読み込む、という仕様でも、特に矛盾は生じなさそう

個人的には3番目の選択肢が良いように思います。

余談ですが、環境変数で指定させる方式には以下のように（微妙な）問題があると感じています。

  • akaza-data --help したときに情報が出てこない。（もちろん、出てくるようにはできますが…）
  • ライブラリユーザー側からすると、環境変数でライブラリの挙動が変わるのは、便利な一方で、セキュリティ面で考慮漏れが発生しそうな怖さがある
    • ライブラリ初期化時に渡す文字列のチェックは（root権限で動かすことなどを考慮して）厳しくやっていたとして、そのライブラリ特有の環境変数に対する考慮は、見落としてしまうかもしれない

現実的にセキュリティの脅威があるかというと考えづらいですし、利便性を考えると XDG_DATA_HOME のようなメジャーな環境変数で挙動を変えるのは便利だしユーザーの期待にも沿うと思うのですが、 AKAZA_MODEL_DIR のような独自の環境変数は、将来的にはなくしたほうがベターだと考えます。

tokuhirom commented

なるほど。。
一旦場当たり的に対応したのですが、たしかにご指摘の通り、独自の環境変数は筋が悪いと思いますので、将来的に廃止していきたいと思います。ありがとうございます！

tokuhirom commented

修正しましたので close します

tkng commented

最新の状態に更新してから実行してみたのですが、以下のようなエラーがでます 😢

Error: Cannot find "romkan/default.yml" in XDG_DATA_HOME or XDG_DATA_DIRS(XDG_DATA_HOME="/home/tkng/.local/share/akaza/", XDG_DATA_DIRS=["/usr/share/mate/akaza", "/usr/share/mate/akaza", "/usr/share/gnome/akaza", "/home/tkng/.local/share/flatpak/exports/share/akaza", "/var/lib/flatpak/exports/share/akaza", "/usr/local/share/akaza", "/usr/share/akaza", "/var/lib/snapd/desktop/akaza"])
  • make evaluate コマンドは開発中のモデルを動かすためのものなので、インストール後のディレクトリを見に行くべきではないと思います。（混ざるとよくわからないことになってしまう）
  • エラーを解消するためには、 BigramWordViterbiEngine がRomkanConverterを持つのをやめるのが簡単で、コードの構成としてもそれが自然なような気がします。（ローマ字かな変換は仮名漢字変換の外でやるべきで、ibus-akazaが担当するべき。実際、コードを見た感じ、ibus-akazaがすでにローマ字かな変換をやっているように見えます。）

別件になってしまいます（余談や別件が多くすみません…）が、make evaluate すると ~/.cache/akaza 以下にキャッシュが作られるようです。上記と同様の理由で、開発中のモデルは、動作中のIMが使っているディレクトリを読み書きすべきではないと思います。

tokuhirom commented

make evaluate コマンドは開発中のモデルを動かすためのものなので、インストール後のディレクトリを見に行くべきではないと思います。（混ざるとよくわからないことになってしまう）

まったくその通りだと思います。

エラーを解消するためには、 BigramWordViterbiEngine がRomkanConverterを持つのをやめるのが簡単で、コードの構成としてもそれが自然なような気がします。（ローマ字かな変換は仮名漢字変換の外でやるべきで、ibus-akazaが担当するべき。実際、コードを見た感じ、ibus-akazaがすでにローマ字かな変換をやっているように見えます。）

はい。こちら、いろいろ依存があって外しにくかったのですが、設定を整理していく中で外しやすくなっていたのではずしました。

別件になってしまいます（余談や別件が多くすみません…
いえいえ。ひじょうに助かっております。

が、make evaluate すると ~/.cache/akaza 以下にキャッシュが作られるようです。上記と同様の理由で、開発中のモデルは、動作中のIMが使っているディレクトリを読み書きすべきではないと思います。

たしかにそうですね。。キャッシュ機能を入れるタイミングでその観点が漏れていました。キャッシュ機能のオンオフを切り替えられるようにして、akaza-data evaluate コマンドではキャッシュ機能をオフにするようにしました。

tokuhirom commented

akaza-im/akaza#231
そもそも、Engine で必要な設定とそうじゃないものがフラットにならんでいるのも良くないと思ったので、階層化しました

tkng commented

手元の環境で make evaluate の動作の確認が取れたのでcloseします。