NaiveBayse、SVMによる文書分類を試す
NaiveBayse, SVMによる文書分類
文書分類とは与えられた文書をあるカテゴリに分類することです。例えば、ニュース記事がスポーツか政治社会かということを分類します。
ここではフリーで入手可能なコーパスを用いて、文書分類の代表的な手法であるNaiveBayseとSVMを使います。
文書分類に用いる素性は、文書中の名詞のTF・IDF値としました。
TF・IDFは単純に説明すると、様々な文書で使われる語の重みは小さく、一部の文書でのみ使う語の重みを大きくするような、語に対する重みです。
もう少し踏み込むと、TF(語の頻度)とIDF(出現する文書数の逆数)の積となります。
以上の素性を用いて、NaiveBayseおよびSVMで分類を行います。
NaiveBayseの理解のためにgihyo.jpの記事を写経して作ったものがここにあります。(今回利用した訳ではありません。)
SVMはパターン識別器を与えられた正解データから作成する機械学習器です。
詳細は割愛します(というよりも詳しくはっきりは理解できていません。)
ソースコード
一部、独自の単語分割器が使用されています。MeCabを用いる際は、名詞の表層形を取り出します。
xmlの読み込みは適当にパースします。
結果
ナイーブベイズよりSVMのほうが4ポイントほど良い結果を示しました。感想
Scikit-learnを用いると意図も簡単に文書分類を試すことができました。手軽に実験するために、Scikit-learnを使いこなさねばと思いました。
機械翻訳尺度METEORについて
代表的なBLEUを始め、RIBESやMETEORなどがあります。
評価尺度のうちの1つであるMETEORについて文献を軽く読みました。
その内容について、簡単にまとめたものです。
An Automatic Metric for MT Evaluation with Improved Correlation with Human Judgments
文献情報
Satanjeev Banerjee, Alon Lavie, METEOR: An Automatic Metric for MT Evaluation with Improved Correlation with Human Judgments, Proceedings of the SecondWorkshop on Statistical Machine Translation, pp.228–231, 2007
概要
METEORという機械翻訳尺度の提案です。参照訳と出力のユニグラムの合致数をもとにした評価尺度です。
ユニグラムの適合率と再現率および、どれくらい並びが参照訳と似ているかを計算します。
文単位の評価手法です。
なぜMETEORか?
人手評価から自動評価尺度BLEUへと変わったことにより、機械翻訳システムの評価が容易になりました。しかし、1つの評価尺度だけで、機械翻訳の評価をするのは厳しいです。(それぞれの評価尺度が評価しやすい項目と苦手な項目があるためです。)
METEORは人手評価との相関が高くなるような評価手法です。
BLEUは再現率を直接考慮したものではないかわり、短い文に対してペナルティを加えています。
そこらへんを含めて、METEORは良い評価軸を求めます。
METEORとは?
BLEUの弱いところに勝つような自動評価尺度を目指します。参照訳が複数ある場合は一番スコアの高い物を出力します。
ワードネットの同義語を使ったり、ステミングをしたもの(語形変化)を候補とすることもできます。
F値(適合率と再現率の調和平均)を用います。
単語単位で適合率および再現率を計算します。
なお、文献中では適合率1:再現率9となっています。
ペナルティを計算します。
正解の単語列が続かない場合にペナルティが大きくなります。
最終的なMETEORスコアはF値とペナルティを用いて、下記のように表されます。
評価
アラビア語-英語翻訳と中国語-英語翻訳で評価します。人の評価との相関を確認します。
(精度や再現率はMETEORの一部です。)
評価尺度 | 相関 |
---|---|
BLEU | 0.817 |
NIST | 0.892 |
適合率 | 0.752 |
再現率 | 0.941 |
F1 | 0.948 |
Fmean | 0.952 |
METEOR | 0.964 |
今後
ペナルティをデータから決める必要があります。現時点では、人手で良い感じのものを決め打ちです。
同義語以外の意味的な関連性を評価に落とし込みます。
いろいろな参照訳をうまく使う方法も考えないといけないです。
おわりに
METEORの日本語用類語辞書が無さそうなので、複数表現を考慮した日本語の評価は難しそうです。日英翻訳では、システム評価に利用出来そうです。
CentOS7(GTX1080)にディスプレイドライバのインストールとCUDAをインストール
GPGPU環境の構築を行います。
具体的には、GTX1080を搭載したCentOS7マシンにディスプレイドライバおよびCUDAをインストールします。
ディスプレイドライバのインストール
マニュアルを見ながらインストールします。
Nouveauドライバの無効化
nouveau(ヌーヴォー)はNVIDIAのビデオカード用のフリードライバです。
これを無効化した後にインストールします。
イメージのコピー
mv /boot/initramfs-3.10.0-327.el7.x86_64.img /boot/initramfs-3.10.0-327.el7.x86_64-nouveau.img
dracut --omit-drivers nouveau /boot/initramfs-$(uname -r).img $(uname -r)
dracutはinitrdをカスタマイズするツール。
/etc/modprobe.d/modprobe.conf
を作成して、編集します。
もし、上記ファイルがない場合は、blacklist-nouveau.conf
などを作ればいいかと思います。
blacklist nouveau
options nouveau modeset=0
編集した後に、再起動します。
ランレベルを下げる
systemctl set-default multi-user.target
ドライバのインストール
GEFORCEのサイトからドライバをダウンロードします。
Manual Driver SearchでGeForce GTX 1080, Linux 64-bit, Japaneseを選び、検索します。
Linux x64(AMD64/EM64T) Display Driverをダウンロードします。
sh NVIDIA-Linux-x86_64-367.44.run
実行後にAcceptを押下。
32-bitライブラリをYes
nvidia-configがどうのこうのをYes
CUDAのインストール
CUDAをダウンロード
ダウンロードサイトからダウンロード
- Linux
- x86_64
- CentOS
- 7
- rpm(local)
インストール
公式ページにあるとおりに実行します。
結構時間がかかります。
rpm -i cuda-repo-rhel7-8-0-local-8.0.44-1.x86_64.rpm
yum clean all
yum install cuda
cudnnもインストールします。
tar zxvf cudnn-8.0-linux-x64-v5.1.tgz
cp cuda/include/cudnn.h /usr/local/cuda/include/
cp cuda/lib64/* /usr/local/cuda/lib64/
もう一度、ディスプレイドライバをインストール
なぜか、nvidia-smiなど使えないため、もう一度ディスプレイドライバをインストールします。
(手順を勘違いしているか、バグかのどちらかだと思います。)
sh NVIDIA-Linux-x86_64-367.44.run
- Install DKMS kernel module
- Install and overwrite existing
ランレベルを戻す
systemctl set-default graphical.target
再起動
shutdown -r now
参考にしたサイト
4
辞書整備は大変だ
後輩とああだこうだと議論しています。
そもそも「辞書」とは
ここでの辞書とは、国語辞典や大辞林のような人間向けの辞書ではなく、プログラムが利用する知識のことです。辞書は言語処理における1つの方法であり、辞書を頼りに言語を解体および分析します。
ほとんどの日本語形態素解析器は辞書を頼りとして、形態素に分割しています。
例えばどんな記述か。
表記ゆれ解消辞書の例をあげます。人間ならば「りんご」と「リンゴ」と「林檎」が同じ単語であることは言うまでもありません。
しかしながら、コンピュータ君がこれら3つの表記を同じものとは見なしてくれません。
そこで、これら3つが同じ単語だよということを辞書という知識により与えます。
上記は単純な例ですが、実際は多種多様に渡ります。
シソーラスは単語間の意味を上位・下位で分類したもので、これも辞書の1つと捉えることができます。
他に動詞の振る舞いを抽象化したものなどもあります。
辞書整備の難しさ
完璧な辞書はないよ
完璧な辞書は作れないと言うことです。「辞書」という単語を聞くと、森羅万象すべての語を網羅しているように感じますがそうではありません。
想定外のことが起きまくる
思いの及ばないような表現がたくさんあります。自分はネイティブだから網羅できるかというと、そんなわけありません。
また、解析システムと辞書の体系がかけあわさって表出する、複合的な問題もあります。
メンテナンスが大変だ
決まり文句のように言われることです。基本的に辞書は人手でメンテナンスされます。
新しい単語の扱いの問題や、そもそものデータ構造の理解が難しい問題。
他には、複数人が関わるとどうしても基準が揺らいできます。
そこをどのように制御するかという問題があります。
では、どうしましょう
問題ばかりと嘆いていても仕方がありませんから、作りましょう。小さな規模で作ってみよう
小さな規模で辞書を作成すると、なんとなく粗が見えてきます。この時点でできる限りの致命的な構造の欠点を修正します。
これで、「完璧な辞書が作れない」ということを認識すること。
つまり妥協点と目標をすりあわせることです。
小さな規模で作成してみると、作業時間がどれくらいのものか分かってきます。
かなり難しいのが、整備や追加にかかる作業時間の見積もりです。
勘としか言いようがないですが・・・
メンテナンスの負荷の軽減に
簡潔なデータ構造と明確な設計思想(ドキュメント)、メンテナンスツールが肝かと思います。簡潔なデータ構造とは、変更を加える際に変更する点が少なくかつ明確な構造です。
明確な設計思想は、作業者が判断のよりどころにするためのものです。
作業を1人でやろうが複数人であろうが、人間の基準は曖昧で揺れます。
これをできるだけ、設計思想や例で補います。
最後にメンテナンスツールです。
いかに簡単に変更を加えることができ、またその変更による影響はどのようなものかということを可視化できることが大事です。
これにより変な変更や、変更によるストレスを軽減することができます。
おわりに
辞書整備をしていて思うのが、先の偉大な研究者の方々が作成した辞書があまりにも素晴らしいということです。様々な問題を抱えながら、1つの終着点にたどり着く辞書作成がいかに難しいかを痛感しています。
辞書整備の難しさはなかなか共有しにくいものですので、何かコメントやその他チップスなど教えて頂けると幸いです。
テスト
テストです。
書き込みテストです。
個人専用だと、研究のメモにも使えますね。