RAKEのストップリスト生成
-
キーワードに隣接するがキーワードに含まれない単語がストップワードの良い候補である
-
キーワードに含まれる頻度がキーワードに隣接する頻度よりも高い単語をストップリストから除外することによってプレシジョンもリコールも改善した
-
F値は一番ストップリストの大きいものが一番良いし、もっと大きくすることでもっと良くなりそうな気配
- DFだけで作ったストップリストは逆に悪化する
- なお2000本のアブストラクトのうち1000件で学習して、DFがそれぞれ10以上、25以上、50以上、で試している
- TFではなくDFを使うの興味深い 感想
-
言われてみればなるほど感
- 「多いか少ないか」でスパッと2値に分けてしまうことには違和感があるけど、それはこのアルゴリズムの問題ではなくそもそもストップワードの概念が持ってる問題
- 確率の領域に拡張して考えると、ある単語が観測されたときの、それがキーワードの一部である確率と、キーワードの隣接である確率、といえる
- キーワード候補の端にある場合、候補を広げるかどうかと考えると「隣接である確率の方が高いから伸ばさないでおこう」となるのは合理的
- キーワード候補の中にある時は違うよなぁ
- 例えば「の」とか「of」はキーワード候補の中の端には存在確率が低いけど、中には割とある
- 過剰に分割しても2回以上出てくるなら再度結合されるわけだが、良いバランスかどうか…
- 単語ごとに「キーワード候補の中に入る確率」がある
- ストップワードはそれが0である、と近似してる状態
- 掛け算されるスコア
- 文法的にキーワードとして適切な形であるかどうかのスコア
- トークン列のスコアが各トークンのスコアの積で計算されている
- これがストップリストの要素かどうかで0/1になってる状態
- 確率値なら、掛ければ掛けるほど小さくなる
- →短いキーフレーズが選ばれるバイアス
- 長いキーフレーズが選ばれるバイアスで相殺
- ストップワードはそれが0である、と近似してる状態
- 「多いか少ないか」でスパッと2値に分けてしまうことには違和感があるけど、それはこのアルゴリズムの問題ではなくそもそもストップワードの概念が持ってる問題
-
Scrapboxみたいな「既にある程度キーワードがマークアップされてる文書」がある場合、そこからストップリストを獲得できる