黒橋研究室で開発している日本語形態素解析器 JUMAN についてのメモ。

何をしているのか。他の解析器 (ChaSen と Mecab) との比較など。

最近だと Yahoo! JAPAN の形態素解析 API なんてものがあるけど、仕様がよくわからない。

タスク: 日本語の形態素解析

1. 文を形態素に区切る
2. 各形態素に品詞を割り当てる
   • 「名詞」や「動詞」など

内容物

• プログラム
• デフォルトの文法辞書
• デフォルトの形態素辞書

プログラムは放置で、実質的に辞書のみの更新。誰かどうにかしてほしいレガシーコード。

文法辞書と形態素辞書は利用者が自由に定義できるとマニュアルではうたっているが、デフォルト以外の辞書が配布されている例を知らない。

ChaSen と MeCab は配布のレベルで、プログラムと辞書を分離している。

IPAdic, NAIST jdic, UniDicなど

エンコーディング

• デフォルトで EUC-JP
  • Windows 版は Shift_JIS
  • ウェブページを解析するときに、エンコーディングの変換で問題が起きたりする
  • 誰かが作った UTF8 版がブランチを切ってレポジトリに入れられているが、放置状態
• 英数字なども2バイトでの入力を前提とする
  • 1バイトだと未定義語扱い

入力

• 1行1文で入力

形態素解析は非常に局所的な文脈しか見ないので、別に複数文を一度に入れても問題ない。構文解析でそれをやると、計算量が爆発するし、結果が気持ち悪いことになる。

出力

• 1行1形態素
• 最後の行は EOS (end of sentence)

子ども こども 子ども 名詞 6 普通名詞 1 * 0 * 0 "カテゴリ:人 代表表記:子供/こども"
は は は 助詞 9 副助詞 2 * 0 * 0 NIL
リンゴ りんご リンゴ 名詞 6 普通名詞 1 * 0 * 0 "カテゴリ:植物:人工物-食べ物 ドメイン:料理・食事 代表表記:林檎/りんご"
が が が 助詞 9 格助詞 1 * 0 * 0 NIL
すきだ すきだ すきだ 形容詞 3 * 0 ナ形容詞 21 基本形 2 "代表表記:好きだ/すきだ"
EOS

処理内容

• 入力に対して、形態素辞書を引いて出力 (形態素列) の候補をを列挙
• コストにより最適な候補を選択

品詞体系

• 益岡・田窪文法
  • 学校文法 (橋本文法) と異なる
  • ChaSen と MeCab でデフォルトで採用されている IPA 品詞体系とも異なる
    • 相互の変換は困難
  • ナ形容詞の扱いが微妙だと思う

UniDic の品詞体系の位置づけがよく分からない。IPA 品詞体系と同じく学校文法ベースだが、完全に同じではないのか

候補の選択

1. 形態素辞書と連接辞書により、形態素と、形態素同士の連接にコストを付与
2. コスト最小のパスを選択

パラメータ (コスト)

• 人手で設定
• ChaSen/MeCab は機械学習 (HMM/CRF) により訓練データから学習したもの

精度で完全に MeCab に負けているが、放置状態

同形

• コストが同じ複数の候補は同形として出力
• @ から始まる出力行があるもの
  • 出力は単に辞書引きの順番なので、どちらが正しいというわけでもない
  • 方針として、JUMAN は曖昧性の候補を列挙するのみ; 選択は KNP で行う

かぜ かぜ かぜ 名詞 6 普通名詞 1 * 0 * 0 "漢字読み:訓 カテゴリ:抽象物 代表表記:風/かぜ"
@ かぜ かぜ かぜ 名詞 6 普通名詞 1 * 0 * 0 "カテゴリ:抽象物 ドメイン:健康・医学 代表表記:風邪/かぜ"
で で で 助詞 9 格助詞 1 * 0 * 0 NIL
おくれた おくれた おくれる 動詞 2 * 0 母音動詞 1 タ形 10 "可能動詞:送る/おくる 代表表記:送れる/おくれる"
@ おくれた おくれた おくれる 動詞 2 * 0 母音動詞 1 タ形 10 "付属動詞候補（基本） 自他動詞:他:遅らせる/おくらせる 自他動詞:他:遅らす/おくらす 代表表記:遅れる/おくれる"
EOS

同形が出力されるのは分割とコストが同じ場合のみという微妙仕様 (e.g., おさない == 幼い != 押さない) だが、結構使える

同じコストになるのはコストを人手で調整しているから

くる:子音動詞ラ行 (繰る) と くる:カ変動詞 (来る) のように品詞が一部違っても同形になる

MeCab は同形の曖昧性を考慮せずにパラメータを推定しているので、どちらとも言えないような場合でも、とにかく一つの解に決めてしまう。N-best にすれば複数の解を出力するが、N をいくつにすれば良いかは事前にはわからない。

そもそも同形の曖昧性解消を N-gram の情報で行うのが適当とも思えないから、JUMAN/KNP の方針は妥当だろう

「おくれた」のような用言の曖昧性解消は、KNP が格フレームを使って行う。その結果が正しいかは誰もちゃんと調べていないはず。

辞書の整備方針

• 形態素数は削減する方向
  • 基本語彙のみを人手で整備し、残りは自動獲得したい
  • 基本語彙には人手で様々な意味情報を付与
    • 意味情報: 形態素解析そのものでは使わないが、係り受け解析や情報検索で使う知識

      e.g. 代表表記, カテゴリ, ドメイン, 可能動詞, 付属動詞候補（基本） など

新聞記事に出てこない難しい単語や固有名詞などは、IPA dic の方が豊富

JUMAN/KNP を用いた日本語固有表現認識の論文でも、精度を上げるために MeCab の解析結果を参照するという変態的な処理をやっている

それ以外にも、なぜ登録されているのか不思議な形態素が辞書に残っていたりする

代表表記

• 基本語彙に付与されている
• 表記ゆれをある程度吸収する
  • 風邪, かぜ -> 代表表記:風邪/かぜ
  • 代表表記は単なるキー; これが標準的な表記と主張しているわけではない

形態素よりも長い「キーワード」レベルでの表現の揺れの吸収はキーワード蒸留型クラスタリングによる大規模ウェブ情報の俯瞰が詳しい (ヒューリスティクスの塊)

カテゴリ・ドメイン

• カテゴリは荒っぽい抽象化の単位
• 付与されたカテゴリの半分ぐらいが「抽象物」という設計ミスまがいの状態

カテゴリ・ドメインを作った目的の一つは言葉同士の意味の近さを大雑把にはかること。シソーラスを使うのが普通のやり方だけど、粒度が細かすぎたり、シソーラスと異なる分類軸もあったりして、思ったほど直観に近い値を返さない。他には権利の問題とか。カテゴリとドメインという2軸を組み合わせれば、大雑把な分類としては十分ではないかという見通しだったらしい。

その他の意味情報

• 付属動詞候補（基本）
• 可能動詞
  • 元の動詞 (戻せる -> 戻す)

  可能で使われる可能性があることを示すだけで、文中の個々の形態素が可能動詞の用法で使われているとは主張していない

  これに限らず、JUMAN/KNP では、可能性があるために付与されている情報と、解析の結果　(いくつかの可能性の中から選択された結果) 付与された情報が混在している

• 自他動詞などの対応関係 [開発版]
  • 自動詞や他動詞、形容詞派生など

    目的は、構文レベルの表現のゆれの吸収

その他の既知の問題

• 数字、音・訓、連濁等の読みは適当
  • 翻字や音声合成には使えない
  • UniDic はちゃんとやる方針らしい
• 口語表現に弱い
  • 特に文頭の文法的制約が強すぎる
• 形態素の単位が不統一
• 変な混ぜ書きが悪さする
  • 「茄子」に対する「な子」など
• 接頭辞が後続形態素の振る舞いを変える

  完熟:サ変 -> 未完熟:ナ形容詞 は放置

  赤:普通名詞 -> 真っ赤:ナ形容詞, 青:普通名詞 -> 真っ青:ナ形容詞 は、後者を1形態素扱いで処理

付属の Juman.pm

• Perl のモジュール
  • 形態素解析に関する基本的な処理をスクリプトから行える

ChaSen と MeCab の Perl モジュールは、XS を使ってライブラリの関数をスクリプト側から直接呼び出している。Juman.pm はプロセス間通信で JUMAN 本体とデータをやりとりするので、やや効率が悪い。

ChaSen と MeCab の Perl モジュールは、基本的に形態素解析処理を呼び出すためだけのライブラリ。Juman.pm は、それに加えて、形態素解析結果を Perl のオブジェクトに変換した上で操作を行う機能を提供している。だから、例えば、一旦ファイルに書き出しておいた形態素解析結果も読み込める。形態素解析結果を使ったアプリケーションを作るなら、Juman.pm の方が便利なはず。

バインディングされている言語が Perl のみ。研究室が Perl に囲い込まれている。脱 Perl 計画に進展なし。