- 各単語ごとに「消すかどうか」「右で区切るかどうか」を推定するアプローチと、
- BERTとかで区切りトークンを含んだ列を生成するアプローチがある
サーバで動かすことを考えるとあんまり重たいものにしたくないなぁと前者を考えていたのだが、このアプローチでは書き換えをサポートしようとすると途端にダメになる
「重いかもしれない」で後者を避けないで、やってみるべきか
教師データがどうなるべきか
- 今まで、悪い例や、人間による分割の例を散発的に記録してきていた
- BERTに入れるなら区切りトークン刻みの列かな
- 現状のルールベースのものでは書き換えを表現しにくいと考えていたが、前処理で文字列置換してしまえばよい
- そうすればそのあとは普通にトークンに刻まれている
- 最悪、ルールベースの事前書き換えだけルールベースで残しても良い
2021/3/29
-
現状のルールベースのものでの分割結果をファイルに吐く
-
悪い分割結果にx、良い分割結果にoをつける
- 何もつけなくてもいい
- 何もつけてないものはまあまあ許容範囲ということでoにしても良い
-
少なくとも今の「失敗事例がフォーマットの揃わないメモの形」よりマシ
-
ルールの修正を行った時に悪い分割が減ると良い
-
出力をマージしたい
-
機械学習？
- パラメータ調整の範疇でいけるのでは
-
将来的にBERTに食わせるとしても数百のデータは集まってからにしたい
-
この形でとっておけば、分割して「ダメな例」が含まれてなければ教師データに使うアプローチができる
-
コードを確認した
- 予期せず壊すことを防ぐために回帰テスト用のJSONが出力されてた
- これは「分割結果」をリストで持ってる
- リストだから「この結果は悪い」と印をつけらない
- 回帰テスト自体は今後も有用
- ✅辞書を別途持てば良い
- 今はルールベースだからスコアの高い順に刻んでるけど、スコア0.5以上なら確実に分割した上で、まだ長すぎるものがあったら別途刻む方が良いか
2021-03-30
- 格助詞のどれかで分割が必要になった時にどの格助詞で分割するのが僕にとって自然に感じられるのかは、格助詞の種類だけでは決まらなさそうだなという感じがする
- 隣の格助詞の種類と距離によるかな…