分析ノート

某所でMeCabは半角スペースを無視するというコメントを見かけ、ちょっと疑問に思ったので調べました。そのついでに、スペースと似たような文字(全角スペースやタブ、改行など)についても調査しています。
ちなみに、Pythonラッパーの mecab-python3==1.0.4 で動作確認していますがコマンドラインの生MeCabでも挙動は同様です。

まず前提として、単語(形態素)の途中に半角スペースが入った場合、MeCabはその半角スペースの位置で単語を区切ります。こういう意味ではMeCabは半角スペースを無視しないと言えます。

print(tagger.parse("メロスは激怒した"))
"""
メロス	名詞,一般,*,*,*,*,*
は	助詞,係助詞,*,*,*,*,は,ハ,ワ
激怒	名詞,サ変接続,*,*,*,*,激怒,ゲキド,ゲキド
し	動詞,自立,*,*,サ変・スル,連用形,する,シ,シ
た	助動詞,*,*,*,特殊・タ,基本形,た,タ,タ
EOS
"""

# 激怒 の激と怒の間に半角スペースを挟むと単語が割れる
print(tagger.parse("メロスは激 怒した"))
"""
メロス	名詞,一般,*,*,*,*,*
は	助詞,係助詞,*,*,*,*,は,ハ,ワ
激	名詞,サ変接続,*,*,*,*,激,ゲキ,ゲキ
怒	動詞,自立,*,*,五段・ラ行,体言接続特殊２,怒る,イカ,イカ
し	動詞,自立,*,*,サ変・スル,連用形,する,シ,シ
た	助動詞,*,*,*,特殊・タ,基本形,た,タ,タ
EOS*,特殊・タ,基本形,た,タ,タ
EOS
"""

これだけ見ると、MeCabは半角スペースを無視しないじゃないか、という話なのですが、実はそれは僕の早とちりで、MeCabが半角スペースを無視するケースはありました。それは単語と単語の間に半角スペースがあった場合です。

今度は「激怒」の前に半角スペースを置いてみます。そして事業をもっと正確に見るために、単語の生起コストと連接コストを出力するようにします。
参考: MeCabの出力形式を変更する
%cが生起コストで、%pcが連接コストです。

# コストを表示する設定でtaggerを生成
tagger = MeCab.Tagger(f"-d {dicdir}/ipadic" +
                      r" -F %m\\t%c\\t%pC\\t%H\\n"
                     )

print(tagger.parse("メロスは激怒した"))
"""
メロス	9461	-283	名詞,一般,*,*,*,*,*
は	3865	-3845	助詞,係助詞,*,*,*,*,は,ハ,ワ
激怒	4467	238	名詞,サ変接続,*,*,*,*,激怒,ゲキド,ゲキド
し	8718	-5350	動詞,自立,*,*,サ変・スル,連用形,する,シ,シ
た	5500	-7956	助動詞,*,*,*,特殊・タ,基本形,た,タ,タ
EOS
"""

# 激怒の前(はの後ろ)に半角スペースを挟む
print(tagger.parse("メロスは 激怒した"))
"""
メロス	9461	-283	名詞,一般,*,*,*,*,*
は	3865	-3845	助詞,係助詞,*,*,*,*,は,ハ,ワ
激怒	4467	238	名詞,サ変接続,*,*,*,*,激怒,ゲキド,ゲキド
し	8718	-5350	動詞,自立,*,*,サ変・スル,連用形,する,シ,シ
た	5500	-7956	助動詞,*,*,*,特殊・タ,基本形,た,タ,タ
EOS
"""

結果が全く同じになりましたね。注目すべきは、はと激怒の間の連接コスト、238です。
前の単語との連接コストが計算されているのですが、空白との連接コストではなくその前の「助詞,系助詞のは」との連接コストが使われています。
この例では、半角スペースは無視された、と言えるでしょう。

ちなみに、タブ、改行(\n)は半角スペース同様に無視されます。一方で全角スペース、改行(\r\n)は無視されません。(正確には\r\nの\n部分は無視されますが、\rが記号,一般として残ります。)

# タブは無視される
print(tagger.parse("メロスは\t激怒した"))
"""
メロス	9461	-283	名詞,一般,*,*,*,*,*
は	3865	-3845	助詞,係助詞,*,*,*,*,は,ハ,ワ
激怒	4467	238	名詞,サ変接続,*,*,*,*,激怒,ゲキド,ゲキド
し	8718	-5350	動詞,自立,*,*,サ変・スル,連用形,する,シ,シ
た	5500	-7956	助動詞,*,*,*,特殊・タ,基本形,た,タ,タ
EOS
"""

# 改行(\n)も無視される
print(tagger.parse("メロスは\n激怒した"))
"""
メロス	9461	-283	名詞,一般,*,*,*,*,*
は	3865	-3845	助詞,係助詞,*,*,*,*,は,ハ,ワ
激怒	4467	238	名詞,サ変接続,*,*,*,*,激怒,ゲキド,ゲキド
し	8718	-5350	動詞,自立,*,*,サ変・スル,連用形,する,シ,シ
た	5500	-7956	助動詞,*,*,*,特殊・タ,基本形,た,タ,タ
EOS
"""

# 全角スペースは無視されない
print(tagger.parse("メロスは　激怒した"))
"""
メロス	9461	-283	名詞,一般,*,*,*,*,*
は	3865	-3845	助詞,係助詞,*,*,*,*,は,ハ,ワ
　	1287	-355	記号,空白,*,*,*,*,　,　,　
激怒	4467	341	名詞,サ変接続,*,*,*,*,激怒,ゲキド,ゲキド
し	8718	-5350	動詞,自立,*,*,サ変・スル,連用形,する,シ,シ
た	5500	-7956	助動詞,*,*,*,特殊・タ,基本形,た,タ,タ
EOS
"""

# 改行(\r\n)も無視されない。printすると見えませんが表層形に\r だけ残ります。\nは消えて。
print(tagger.parse("メロスは\r\n激怒した"))
"""
メロス	9461	-283	名詞,一般,*,*,*,*,*
は	3865	-3845	助詞,係助詞,*,*,*,*,は,ハ,ワ
	4769	-71	記号,一般,*,*,*,*,*
激怒	4467	-272	名詞,サ変接続,*,*,*,*,激怒,ゲキド,ゲキド
し	8718	-5350	動詞,自立,*,*,サ変・スル,連用形,する,シ,シ
た	5500	-7956	助動詞,*,*,*,特殊・タ,基本形,た,タ,タ
EOS
"""

4パターンとも激怒の前に各記号を入れましたが、無視されるものと考慮されるものに分かれました。全角スペースや\rについては形態素の一つとして扱われ、その次の単語である「激怒」の前の単語との連接コストの計算にも反映されています。

テキストデータを前処理するときに、表記揺れの対応として全角スペースを半角スペースに置き換えたり、改行コードを\r\nを\nに揃えたりといったことをよくやっていたのですが、この操作はその後の形態素解析の結果に影響を与えてしまっていたのですね。
大体その後、改行を空白スペースに置換したりするのですが、これは影響なさそうです。

この改行を無視して、その前の単語との間の連接コストが形態素解析の結果に反映されるというのは僕にとっては非常に驚きでした。(BOSを挿入してるわけではないので、言われてみればそうかという気もしますが。)

例えば、次の2つのテキスト中の「中国語を勉強します。」の形態素分析結果が違う、ということが予想できた人ってあまりいなのではないでしょうか。

text1 = """来月から留学します。
中国語を勉強します。"""
text2= """来月から留学します
中国語を勉強します"""

# 文末に。があるテキストの場合
print(tagger.parse(text1))
"""
来月	5123	-316	名詞,副詞可能,*,*,*,*,来月,ライゲツ,ライゲツ
から	4159	-4367	助詞,格助詞,一般,*,*,*,から,カラ,カラ
留学	5355	2	名詞,サ変接続,*,*,*,*,留学,リュウガク,リューガク
し	8718	-5350	動詞,自立,*,*,サ変・スル,連用形,する,シ,シ
ます	5537	-9478	助動詞,*,*,*,特殊・マス,基本形,ます,マス,マス
。	215	-3050	記号,句点,*,*,*,*,。,。,。
中国語	5383	-952	名詞,一般,*,*,*,*,中国語,チュウゴクゴ,チューゴクゴ
を	4183	-4993	助詞,格助詞,一般,*,*,*,を,ヲ,ヲ
勉強	4452	-1142	名詞,サ変接続,*,*,*,*,勉強,ベンキョウ,ベンキョー
し	8718	-5350	動詞,自立,*,*,サ変・スル,連用形,する,シ,シ
ます	5537	-9478	助動詞,*,*,*,特殊・マス,基本形,ます,マス,マス
。	215	-3050	記号,句点,*,*,*,*,。,。,。
EOS
"""

# 句読点が省略されたテキストの場合
print(tagger.parse(text2))
"""
来月	5123	-316	名詞,副詞可能,*,*,*,*,来月,ライゲツ,ライゲツ
から	4159	-4367	助詞,格助詞,一般,*,*,*,から,カラ,カラ
留学	5355	2	名詞,サ変接続,*,*,*,*,留学,リュウガク,リューガク
し	8718	-5350	動詞,自立,*,*,サ変・スル,連用形,する,シ,シ
ます	5537	-9478	助動詞,*,*,*,特殊・マス,基本形,ます,マス,マス
中国	4757	825	名詞,固有名詞,地域,国,*,*,中国,チュウゴク,チューゴク
語	7810	-7313	名詞,接尾,一般,*,*,*,語,ゴ,ゴ
を	4183	-4541	助詞,格助詞,一般,*,*,*,を,ヲ,ヲ
勉強	4452	-1142	名詞,サ変接続,*,*,*,*,勉強,ベンキョウ,ベンキョー
し	8718	-5350	動詞,自立,*,*,サ変・スル,連用形,する,シ,シ
ます	5537	-9478	助動詞,*,*,*,特殊・マス,基本形,ます,マス,マス
"""

text1の方は、「中国語」という単語が登場しましたが、text2の方は、「中国」と「語」という2つの単語に割れましたね。
これは、改行を無視して、その前の単語である「助動詞のます」との連接が考慮された結果になります。「記号,句点の。」と「中国語」の連接コストは小さいですが、「ます」と「中国語」の連接コストは大きい(1436)ので「中国語」という形態素が採用されなかったのです。(中国と語の連接コストが非常に小さく、単語が一つ増えるデメリットがあまりなかったのも要因)

以上をまとめると、以下のようになるでしょうか。
– 全角スペースや\rは他の文字と同じように形態素(単語)として扱われる。
– 半角スペース、タブ、改行(\n)は区切り位置として使われその位置で必ず形態素は切られる。
– 半角スペース、タブ、改行(\n)はそれ自体は形態素としては扱わず結果にも表示されない。
– 半角スペース、タブ、改行(\n)は連接コストの計算時は無視される。

半角スペースも形態素結果に表示してほしいよ、という場合は、表示形式のオプションで、%Mを使うことで表示できます。半角スペースの次の単語の表層系に存在したスペースをくっつけて表示してくれるようです。ただ、正直これを使う場面がすぐには思いつきません。

# %m の代わりに %M を使うと半角スペースも表示される
tagger = MeCab.Tagger(f"-d {dicdir}/ipadic" +
                      r" -F %M\\t%H\\n"
                      )

print(tagger.parse("メロスは 激怒した"))
"""
メロス	名詞,一般,*,*,*,*,*
は	助詞,係助詞,*,*,*,*,は,ハ,ワ
 激怒	名詞,サ変接続,*,*,*,*,激怒,ゲキド,ゲキド
し	動詞,自立,*,*,サ変・スル,連用形,する,シ,シ
た	助動詞,*,*,*,特殊・タ,基本形,た,タ,タ
EOS
"""

激怒、の前にスペースが入って半角1文字分字下げされているのがわかりますね。
読みはゲキドだけなので、原型、読み、発音では無視されたままであることもわかります。

今回もNumPyの小ネタです。特に難しい処理ではないのですが、NumPyの行列(2次元配列)から三角行列を取り出したいことがあります。
自分の場合は、距離行列とか相関行列などに対して、$x_i$と$x_j$の距離や相関と、$x_j$と$x_i$の距離や相関は等しいから一方だけでいいとかそういう状況が多いです。

まぁ、値を取り出すだけなら、2重のforループなどをちゃんと書けば済む話なのですが、前回の記事で紹介したようなちょっとしたテクニックを使いたい場合など、明示的に三角行列を作りたいことがあります。
参考: NumPyの多次元配列から値が大きいn個のインデックスを取得する

自分で実装しても特に難しくないのですが、NumPyに専用関数が用意されていたのでこの記事ではそれを紹介したいと思います。

とりあえず、適当な行列を作って自分でやってみましょう。(実は実務では要素数が数万*数万みたいな巨大行列扱うことがあり、2重for文回すのはちょっと待つので嫌だなと思うのですが、小さい行列ならこれで十分です)

対角成分も0にする、狭義の下三角行列を作る場合は以下のようになるでしょうか。

import numpy as np

# 適当にデータを生成する
np.random.seed(4)
ary = np.random.randint(10, 100, size=(5, 5))
print(ary)
"""
[[56 65 79 11 97]
 [82 60 19 68 65]
 [65 67 46 60 54]
 [48 62 13 10 65]
 [31 31 83 48 66]]
"""

# 上三角成分を0にすることで下三角行列を作る
for i in range(ary.shape[0]):
    for j in range(i, ary.shape[1]):
        ary[i, j] = 0

print(ary)
"""
[[ 0  0  0  0  0]
 [82  0  0  0  0]
 [65 67  0  0  0]
 [48 62 13  0  0]
 [31 31 83 48  0]]
"""

はい、何も難しくなくできましたね。

これを2重のfor文を使わずにやる場合、NumPyには triuとtril というそれぞれ上三角行列と下三角行列を取り出すメソッドが用意されています。
参考:
numpy.triu — NumPy v1.22 Manual
numpy.tril — NumPy v1.22 Manual

とりあえず、動かしてみましょうか。２個目にkっていうオプションの引数(デフォルトは0)を取り、これを調整することで対角成分を残すかどうか、また対角成分に限らずどの斜めラインまで成分を残すかを調整できます。

# もう一回データを生成する
np.random.seed(4)
ary = np.random.randint(10, 100, size=(5, 5))

# 上三角行列
print(np.triu(ary))
"""
[[56 65 79 11 97]
 [ 0 60 19 68 65]
 [ 0  0 46 60 54]
 [ 0  0  0 10 65]
 [ 0  0  0  0 66]]
"""

# k=1とすると、対角成分も消える。(消える行が右上に広がる)
print(np.triu(ary, k=1))
"""
[[ 0 65 79 11 97]
 [ 0  0 19 68 65]
 [ 0  0  0 60 54]
 [ 0  0  0  0 65]
 [ 0  0  0  0  0]]
"""

# k=2とすると、さらに消える(消える行が右上に広がる)
print(np.triu(ary, k=2))
"""
[[ 0  0 79 11 97]
 [ 0  0  0 68 65]
 [ 0  0  0  0 54]
 [ 0  0  0  0  0]
 [ 0  0  0  0  0]]
"""

# k=-1とすると、逆に残す範囲が左下に広がる。より小さい負の数も同様。
print(np.triu(ary, k=-1))
"""
[[56 65 79 11 97]
 [82 60 19 68 65]
 [ 0 67 46 60 54]
 [ 0  0 13 10 65]
 [ 0  0  0 48 66]]
"""

# trilは下三角行列
print(np.tril(ary))
"""
[[56  0  0  0  0]
 [82 60  0  0  0]
 [65 67 46  0  0]
 [48 62 13 10  0]
 [31 31 83 48 66]]
"""

# tril の k=1 は残す範囲が広がる。境界線が右上にスライドするという意味ではtriuと同じ。
print(np.tril(ary, k=1))
"""
[[56 65  0  0  0]
 [82 60 19  0  0]
 [65 67 46 60  0]
 [48 62 13 10 65]
 [31 31 83 48 66]]
"""

# tril で対角成分も消したい場合はk=-1
print(np.tril(ary, k=-1))
"""
[[ 0  0  0  0  0]
 [82  0  0  0  0]
 [65 67  0  0  0]
 [48 62 13  0  0]
 [31 31 83 48  0]]
"""

狭義の三角行列(要するに対角成分も0)を取り出したい時、上三角行列(triu)の時はk=1で、下三角行列(tril)の時はk=-1 ってのがちょっと厄介ですね。まぁ、境界線が上に移動するか下に移動するかと考えるのが誤解が少ないかと思います。

三角行列といえば、NumPyには、tri という 三角行列を生成するメソッドもあります。(これもkという引数を取ります。)
参考: numpy.tri — NumPy v1.22 Manual
このtriで生成した三角行列を使ってマスクすることで、三角行列を作ることも可能です。というより、triuやtril の実装をみるとそういう作りになっています。
参考: triuのソースコード(GitHub)

NumPyのwhereメソッドとか使っていい感じに実装されていいますが、ぶっちゃけ掛け算(要素積)するだけで良いでしょう。

# tri で三角成分が1の三角行列を作れる
print(np.tri(5, k=-1))
"""
[[0. 0. 0. 0. 0.]
 [1. 0. 0. 0. 0.]
 [1. 1. 0. 0. 0.]
 [1. 1. 1. 0. 0.]
 [1. 1. 1. 1. 0.]]
"""

# これを要素積すると、元の行列は下三角行列になる。
print(ary * np.tri(5, k=-1))
"""
[[ 0.  0.  0.  0.  0.]
 [82.  0.  0.  0.  0.]
 [65. 67.  0.  0.  0.]
 [48. 62. 13.  0.  0.]
 [31. 31. 83. 48.  0.]]
"""

# 上三角行列が欲しいなら転置してから掛ける
print(ary * np.tri(5, k=-1).T)
"""
[[ 0. 65. 79. 11. 97.]
 [ 0.  0. 19. 68. 65.]
 [ 0.  0.  0. 60. 54.]
 [ 0.  0.  0.  0. 65.]
 [ 0.  0.  0.  0.  0.]]
"""

さて、最後に処理時間を見ておきましょう。最初に少しぼやいていましたが、2重for文のデメリットは巨大な行列を処理する場合の処理時間です。2万行*2万行(要素数4億)の行列で見てみましょう。

データ生成。

big_ary = np.random.randint(100, size=(20000, 20000))

まず、tirlです。こちら3秒ちょっとで終わりました。

% % time
big_ary_tril = np.tril(big_ary, k=-1)

"""
CPU times: user 1.18 s, sys: 1.33 s, total: 2.5 s
Wall time: 3.25 s
"""

次にfor文を回した場合です。こちらは50秒近くかかっています。もう少しで1分超えますね。

% % time
for i in range(big_ary.shape[0]):
    for j in range(i, big_ary.shape[1]):
        big_ary[i, j] = 0

"""
CPU times: user 45.3 s, sys: 1.59 s, total: 46.8 s
Wall time: 49.5 s
"""

速度、計算効率的にはtirl/triuを使った方が良いということが確認できました。

triu/trilは実装上は全ての要素に対して残すか0埋めするかの判定をかけているのに対し、for文の方は0で埋める要素だけにアクセスしているので、計算量というか演算回数だけならfor文の方が半分以下のはずですが、for文の方が圧倒的に遅いのが不思議です。NumPyのもっとコアな部分で並列処理がかなりしっかりと作り込まれているのでしょう。

NumPyの多次元配列(といってもここで扱うのは2次元の行列ですが)の要素の中から、値が大きい順に数個取り出して、そのインデックスが欲しいことがありました。
これが多次元ではなく、1次元の配列だったら、argsort使えば一発です。
参考: numpyのarrayを並び替えた結果をインデックスで取得する

多次元になるとargsordだけではうまく動きません。
まともに実装すると、やや手間だったのですが、unravel_index というメソッドを使うとうまく書けたので紹介します。

とりあえず参考に使うデータを用意しておきます。実際はもっと巨大なデータでやったのですが、この記事では結果を確認しやすいように 5*5の行列の25個の要素から上位5要素のインデックスを取得することを目指します。
まずデータを作っておきます。

import numpy as np


np.random.seed(4)
ary = np.random.randint(10, 100, size=(5, 5))
print(ary)
"""
[[56 65 79 11 97]
 [82 60 19 68 65]
 [65 67 46 60 54]
 [48 62 13 10 65]
 [31 31 83 48 66]]
"""

このデータから値が大きい順に5このインデックスを取得することを目指します。もし、欲しいのがインデックスではなく値であればこれは簡単です。ravel() か flatten()、reshape()あたりで1次元に変形してソートするだけです。こんな感じに。

np.sort(ary.ravel())[-5:]
# array([68, 79, 82, 83, 97])

今回の用件では欲しいのは、これらの値が入ってたインデックスです。つまり、
[[1, 3], [0, 2], [1, 0], [4, 2], [0, 4]] を求めたいのです。

単純に argsortすると、行ごとにその行内でソートして結果を返してくれます。
また、axis引数にNoneを指定すると行列全体でソートしてくれるのですが結果が、ravel等で1次元に直した後にargsortしたようなイメージで帰ってきます。

print(np.argsort(ary))
"""
[[3 0 1 2 4]
 [2 1 4 3 0]
 [2 4 3 0 1]
 [3 2 0 1 4]
 [0 1 3 4 2]]
"""

print(np.argsort(ary, axis=None))
"""
array([18,  3, 17,  7, 21, 20, 12, 15, 23, 14,  0, 13,  6, 16,  9, 19,  1,
       10, 24, 11,  8,  2,  5, 22,  4])
"""

axis=Noneの方の結果(小さい順なので最後の5つ、[8, 2, 5, 22, 4]が求める5つの数のインデックス)を元の(5*5)の配列に読み替えると欲しい結果が得られることになります。
1次元でインデックスが8ってことは9番目の要素で、5*5行列の9個目の要素は[1, 4]だ、同様に2は[0, 2]、5は[1, 0] と読み替えていくわけですね。割り算と余りを使って実装できそうです。やってみると次のようになります。

for i in np.argsort(ary, axis=None)[-5:]:
    print([i//5, i%5])

"""
[1, 3]
[0, 2]
[1, 0]
[4, 2]
[0, 4]
"""

上記の変換をあらかじめ用意されたメソッドで行うのが、この記事冒頭で名前を出した unravel_index です。
ドキュメント: numpy.unravel_index — NumPy v1.22 Manual

動かしてみます。

# 以下の引数を渡していることに注意して見てください。
# np.argsort(ary, axis=None)[-5:] = [ 8  2  5 22  4]
# ary.shape = (5, 5)

print(np.unravel_index(np.argsort(ary, axis=None)[-5:], ary.shape))
# (array([1, 0, 1, 4, 0]), array([3, 2, 0, 2, 4]))

かなり近いところまで来ましたね。最終的な結果が二つのarrayからなるタプルになっていますが、それぞれから1個ずつ値を取り出してペアにすれば欲しい結果になっています。

人間が見るには微妙に扱いにくい形に見えるのですが、次のように値を取り出すのに使えます。

index_list = np.unravel_index(np.argsort(ary, axis=None)[-5:], ary.shape)
print(ary[index_list])
# [68 79 82 83 97]

今回はインデックスの方が欲しかったので、これを人が見ても見やすい形にするため、vstackして、さらに転置(.T)しても良いでしょう。

print(np.vstack(index_list).T)
"""
[[1 3]
 [0 2]
 [1 0]
 [4 2]
 [0 4]]
"""
# 以下のように書けば1行で可能。
print(np.vstack(np.unravel_index(np.argsort(ary, axis=None)[-5:], ary.shape)).T)

以上で欲しかった結果が得られました。unravel_indexがちょっと馴染みが薄かったのでまだ慣れないのですが、個人的にはこれが一番いいのではないかと思います。

大き方から順ではなく、小さい方からとたい、って時は、argsortに対するスライスの部分を少し変えるだけで対応できます。([-5:]ではなく[:5]に。)

ちなみに、argsort/ unravel_index/ vstack など少々マイナーなメソッドをいくつも使うのが嫌な場合は次のような方法もあります。多次元の配列を、インデックスと値のペアのようなデータ構造に変換してソートするやり方です。

# インデックスと値を組にしたデータにする。
lil_ary = [(i, j, ary[i, j]) for i in range(ary.shape[0]) for j in range(ary.shape[1])]
print(lil_ary[:5])  # 中身を一部確認
# [(0, 0, 56), (0, 1, 65), (0, 2, 79), (0, 3, 11), (0, 4, 97)]

# 3番目の要素(indexは2)をキーにしてソート
lil_ary.sort(key=lambda x: x[2])
# 最後の5項目を取る
print(lil_ary[-5:])
# [(1, 3, 68), (0, 2, 79), (1, 0, 82), (4, 2, 83), (0, 4, 97)]

あとはこれの、タプルのそれぞれの先頭2要素を取り出せば欲しかったインデックスです。
何をやっているのかはこちらの方がわかりやすいかも、と思っていますがこのやり方はメモリ効率などの観点でデメリットもあるので巨大なデータへの適用はお勧めしません。

会社と私物でそれぞれMacbookを持っていて、AWSのアカウントとそこで動くEC2インスタンスもそれぞれあり、さらにDocker等含めていくつもPython環境を使っています。その中の一つで、突然PythonからMeCabが動かせなくなってしまったのでその解決方法のメモです。

具体的にはそれまで普通にMeCabが動かせていた環境にもかかわらず、次の様なエラーが出るようになってしまいました。MeCabをインポートして、MeCab.Tagger()するだけでエラーになるのでお手上げ状態でした。

>>> import MeCab
>>> MeCab.Tagger()

Failed initializing MeCab. Please see the README for possible solutions:

    https://github.com/SamuraiT/mecab-python3#common-issues

If you are still having trouble, please file an issue here, and include the
ERROR DETAILS below:

    https://github.com/SamuraiT/mecab-python3/issues

issueを英語で書く必要はありません。

------------------- ERROR DETAILS ------------------------
arguments:
error message: [ifs] no such file or directory: {Macのユーザー名を含む長いPathなのでマスク}/site-packages/unidic/dicdir/mecabrc

この事象が発生した環境には、MeCabは正常にインストールされていて、元々 MeCab.Tagger() も正常に実行できていました。

mecabrc ファイルも $ mecab-config –sysconfdir で取得できる場所、
つまり、/usr/local/etc/mecabrc にしっかり配置されているのに、全然違う .pyenv が管理してる各種ライブラリの配置場所を見に行ってそこに mecabrc が無いというエラーを起こしています。

原因調査編

確認してみると確かに site-packages ディレクトリ配下に mecabrc ファイルはありませんでした。というよりも、site-packages/unidic/dicdir 自体がありませんでした。

ネットで検索するとこのエラーメッセージで表示されたパスに /usr/local/etc/mecabrc をコピーして配置するという応急処置を取っている人がいましたが、ここは pipやcondaなどのパッケージ管理システムが管理している場所なので軽はずみに手動でいじりたくはありません。ということで腰を入れて原因と対策を調査しました。

結果、以下のことが原意で起きてるのがわかりました。
– transformers を、ドキュメントに沿って、[ja] というオプション付きで入れた。
-依存パッケージとしてunidic(MeCabの辞書の一つ)が一緒にインストールされた。
– unidicはインストールしただけでは辞書本体がダウンロードされない。
参考: unidic · PyPI
– 最近のmecab-python3はunidicを優先的に使おうとする。
(事象が発生したのは mecab-python3==1.0.4。mecab-python3==0.996では発生しない。)

transformers というのはBert等の学習済みモデルを手軽に使えるパッケージですね。インストール時にtransformers[ja] として入れると、日本語モデルを使うためのパッケージも一緒に入れてくれます。

これをやった時に、unidicというパッケージが入ったのです。
そして、unidicのドキュメントにある通り、この時点では辞書本体は端末にダウンロードされていませんでした。

しかし、インストールはされているので、Pythonコード上で、 import unidic は成功するし、unidic.DICDIR という値も取得できるわけです。(しかしそのディレクトリに辞書本体は無い。)

そしてさらに、このエラーが発生した環境のmecab-python3は割と最近の version 1.0.4 が入っていたのです。

mecab-python3のリポジトリで、 Add support for unidic installs via pypi というコミット を見ていただくとわかりやすいと思うのですが、この修正以降、 unidicが import できたら unidic を使おうとするようになっています。

def try_import_unidic():
    """Import unidic or unidic-lite if available. Return dicdir.
    This is specifically for dictionaries installed via pip.
    """
    try:
        import unidic
        return unidic.DICDIR
    except ImportError:
        try:
            import unidic_lite
            return unidic_lite.DICDIR
        except ImportError:
            # This is OK, just give up.
            return


class Tagger(_MeCab.Tagger):
    def __init__(self, rawargs=""):
        # First check for Unidic.
        unidicdir = try_import_unidic()
        args = rawargs
        if unidicdir:
            mecabrc = os.path.join(unidicdir, 'mecabrc')
            args = '-r "{}" -d "{}" '.format(mecabrc, unidicdir) + args

        # The first argument here isn't used. In the MeCab binary the argc and
        # argv from the shell are re-used, so the first element will be the
        # binary name.
        args = ['', '-C'] + shlex.split(args)

        # need to encode the strings to bytes, see here:
        # https://stackoverflow.com/questions/48391926/python-swig-in-typemap-does-not-work
        args = [x.encode('utf-8') for x in args]

        try:
            super(Tagger, self).__init__(args)
        except RuntimeError as ee:
            raise RuntimeError(error_info(rawargs)) from ee

Tagger作る時に最初に unidicを調べて、インポートに成功したら、引数に
args = ‘-r “{}” -d “{}” ‘.format(mecabrc, unidicdir) + args
として、unidicのmecabrcファイルと辞書のパスを追加していますね。

私物のMacの環境は、 mecab-python3 のバージョンが古く、この処理が無かったので素直にIPA辞書を使ってくれているようです。そして、このエラーが発生した環境は、つい最近までunidicが入ってなかったので、 「# This is OK, just give up.」 のコメントの通り、importできなかったので、unidicを使うのを諦めてIPA辞書を使ってくれていたようです。

対応編

エラーになる原因が分かったので対応案を検討してやっていきましょう。

案1. mecab-python3のバージョンを下げる。

要するにversion 0.996 だったら無理してunidic使おうとしないので解決です。
ただ、この先ずっとmecab-python3だけバージョンを上げずに使い続けるのか、という問題があるので個人的にはこれはお勧めしません。僕も採用しませんでした。

案2. unidicの本体をダウンロードする。

unidicのimport ができるのに、辞書本体がダウンロードされていないのが原因なので本体ダウンロードしましょうというのが方針です。実際はこれを採用しました。

コマンドはドキュメントの通りです。1回だけ実行すればOK。

python -m unidic download

これを実行すると、 MeCab.Tagger() が成功するようになりました。ただし、デフォルトでunidicが使われるようになります。 テキストをparseした結果の品詞等の情報の出力がIPA辞書と全然違うものになってしまいました。

今後、IPA辞書を使いたいときは次のようにしてIPA辞書のディレクトリを明示的に指定する必要があります。ちょっと面倒になりました。(環境によってIPA辞書のパスは違うので注意してください。)

import MeCab
MeCab.Tagger("-d /usr/local/lib/mecab/dic/ipadic/") 

案3. mecabrc ファイルパスを指定してTaggerを生成する。

実はこれも試し、成功しています。何らかの事情でunidicをダウンロードしたく無い場合は、
-r オプションで mecabrc ファイルを指定し、-d で辞書を指定することで動かすことができます。 上で参照した mecab-python3のソースコードで、
「args = ‘-r “{}” -d “{}” ‘.format(mecabrc, unidicdir) + args」
となっていますが、自分が指定した -r と -d もargsとしてMeCabに渡す引数に加えられるようなのです。そしてこれらはどちらも1つしか指定できないので後に付け加えられる分が先に書かれたunidic分を上書きしているようです。

具体的には次のように使います。(具体的なパスは環境に応じて変えてください。)

MeCab.Tagger("-r /usr/local/etc/mecabrc -d /usr/local/lib/mecab/dic/ipadic/") 

-r と -d は両方必須なので面倒です。片方だけだと指定しなかった方が unidicを見に行ってしまいます。(mecabrcファイル内に辞書ディレクトリのパスが指定されていますが、-dで指定した方が優先。)
結局これは採用しませんでした。記述量が多いから。

感想と今後の方針

MeCabは動かせるようになりましたが、デフォルトの辞書がunidicになってしまって毎回IPA辞書を指定しないといけない不便を感じるようになりました。

しかし、そもそもなぜ mecab-python3がunidic推しになったのかという問題があります。これは結構明らかで、IPA辞書がかなり昔に更新が止まってしまっているのに対して、unidicの方は最近も更新が続いているからでしょう。

新目の単語がIPA辞書に含まれていないので、その点では確かにunidicの方が優れているのですが、ざっと比較したところ、全面的にunidicが優秀というわけでもなく慣れもあってまだ個人的にIPA辞の方が使いやすい印象でいます。語彙だけでなく出力形式はかなり違いますし。

とはいえ、これを機会に、unidicの思想や特徴、活用方法をきちんと学んで、こちらを使うように寄せていくことも検討した方がいいのかなと思う出来事でした。

とりあえず、MeCab.Tagger() したときの挙動が僕が持っている環境間で異なり、コードの使い回しがしにくくなったというのが目下の自分の課題なので、これをどうにかしていこうと思います。全環境でIPA辞書を指定したコードを書くのか、もう諦めて全面的にunidicに移行するのか。

以前、MeCabのユーザー辞書を作る方法を紹介しました。
参考: MeCabでユーザー辞書を作って単語を追加する

システム辞書に無い単語をユーザー辞書に登録して使えば、当然システム辞書の単語とユーザー辞書の単語の両方を使って形態素解析が行えるようになります。
この時にもし、システム辞書に登録済みの単語を改めてユーザー辞書に登録してしまったらどのような挙動になるのか気になったのでドキュメントを確認してみましたがそれらしい記載がありませんでした。(他サイトにユーザー辞書がシステム辞書を上書きするという情報もあったのですが、本当にそうなのか疑わしいとも思いました。)
そこで実験してみようと思ったのがこの記事です。

また、MeCabは起動時にシステム辞書は1つしか指定できませんが、ユーザー辞書は複数指定できます。その複数のユーザー辞書に登録したらどういう挙動になるのかも確認しました。
それとついでにですが、1個のユーザー辞書に同じ単語を複数回登録した場合(これはもうただの辞書作成時のミスでしかあり得ないのですが。)の事象も見ています。

え、システム辞書に登録されてる単語をユーザー辞書に登録することなんてある？と思われる方もいらっしゃると思いますが、これは普通にあります。気づかずに登録してしまった、という場合はもちろんですが、解析結果の誤りを修正するために生起コストの設定を変えたいというケースがあるのです。

例えば、IPA辞書そのままだと、「りんごジュース」の形態素解析結果は次のように誤ったものになります。

$ echo りんごジュース | mecab
りん	副詞,助詞類接続,*,*,*,*,りん,リン,リン
ご	接頭詞,名詞接続,*,*,*,*,ご,ゴ,ゴ
ジュース	名詞,一般,*,*,*,*,ジュース,ジュース,ジュース
EOS

IPA辞書に「りんご」が登録されていないわけではありません。バッチリ含まれています。

# ビルド前のIPA辞書のファイルが含まれているディレクトリで実行
$ grep りんご * -r
Noun.csv:りんご,1285,1285,7277,名詞,一般,*,*,*,*,りんご,リンゴ,リンゴ

「りんご」自体の生起コストが高いこととか、「BOS」と「名詞,一般」の連接コストなどの諸々の事情によりこのような誤りが発生しています。これを是正する手段の一つが、「りんご」をもっと低い生起コストで登録することなのです。

とりあえず、生起コストを5000に落としてやってみます。下のコードでcatしてるようなテキストをファイルを作り、ユーザー辞書をコンパイルしてMeCabを動かしてみます。

# seedファイルの中身確認
$ cat apple1.csv
りんご,1285,1285,5000,名詞,一般,*,*,*,*,りんご,リンゴ,リンゴ
# コンパイル
$ /usr/local/Cellar/mecab/0.996/libexec/mecab/mecab-dict-index -d /usr/local/lib/mecab/dic/ipadic -u apple1.dic -f utf-8 -t utf-8 apple1.csv
reading apple1.csv ... 1
emitting double-array: 100% |###########################################|

done!
# 生成されたユーザー辞書を使って形態素解析(生起コストも表示)
$ echo りんごジュース | mecab -F %m\\t%c\\t%H\\n -u apple1.dic
りんご	5000	名詞,一般,*,*,*,*,りんご,リンゴ,リンゴ
ジュース	3637	名詞,一般,*,*,*,*,ジュース,ジュース,ジュース
EOS

ユーザー辞書に登録した生起コスト5000のりんごを使って形態素解析されましたね。
この結果だけ見ると、システム辞書にある単語をユーザー辞書に登録したら情報が上書きされたように見えます。ただし、実際の動きはそうでは無いのです。

上書きされたように見えるだけで、システム辞書とユーザー辞書それぞれのりんごは別々の独立した単語として処理されていて、解には生起コストが低いユーザー辞書のりんごが採用されたというのが正確な動きになります。このことはN-Best解を表示すると確認できます。

$ echo りんごジュース | mecab -F %m\\t%c\\t%H\\n -N3 -u apple1.dic
りんご	5000	名詞,一般,*,*,*,*,りんご,リンゴ,リンゴ
ジュース	3637	名詞,一般,*,*,*,*,ジュース,ジュース,ジュース
EOS
りん	4705	副詞,助詞類接続,*,*,*,*,りん,リン,リン
ご	6655	接頭詞,名詞接続,*,*,*,*,ご,ゴ,ゴ
ジュース	3637	名詞,一般,*,*,*,*,ジュース,ジュース,ジュース
EOS
りんご	7277	名詞,一般,*,*,*,*,りんご,リンゴ,リンゴ
ジュース	3637	名詞,一般,*,*,*,*,ジュース,ジュース,ジュース
EOS

3番目の解として、システム辞書の生起コスト7277のりんごもバッチリ登場していますね。上書きされて消えているわけでは無いのです。

つまりユーザー辞書に単語を登録しても、元のシステム辞書より高い生起コストを設定してたらそれは1番目の解としては使われないということです。apple2って名前で、生起コスト8000のりんごを登録してやってみます。

$ cat apple2.csv
りんご,1285,1285,8000,名詞,一般,*,*,*,*,りんご,リンゴ,リンゴ
$ /usr/local/Cellar/mecab/0.996/libexec/mecab/mecab-dict-index -d /usr/local/lib/mecab/dic/ipadic -u apple2.dic -f utf-8 -t utf-8 apple2.csv
reading apple2.csv ... 1
emitting double-array: 100% |###########################################|

done!
$ echo りんごジュース | mecab -F %m\\t%c\\t%H\\n -u apple2.dic
りん	4705	副詞,助詞類接続,*,*,*,*,りん,リン,リン
ご	6655	接頭詞,名詞接続,*,*,*,*,ご,ゴ,ゴ
ジュース	3637	名詞,一般,*,*,*,*,ジュース,ジュース,ジュース
EOS

システム辞書だけの場合と結果変わりませんでしたね。このことからも、ユーザー辞書の単語がシステム辞書の単語を上書きする説は誤りであることがわかります。

実は元々、他のサイトの記事で単語が上書きされる説を見かけて、ユーザー辞書を複数登録したら最後にどっちの単語が残るんだ？という疑問からこの検証を始めています。
しかし、「そもそも上書きしないで別の単語として扱われる」が結論であれば、同じ辞書に複数回単語登録したり、ユーザー辞書を複数使用してそれぞれに重複してた単語があったとしても、別の単語として扱われて生起コストで判定される、と予想が付きます。

一応、「りんご」が2回登録された辞書も作って、上で作った2辞書と合わせて3辞書で動かしてみましょう。

$ cat apple3.csv
りんご,1285,1285,6000,名詞,一般,*,*,*,*,りんご,リンゴ,リンゴ
りんご,1285,1285,4000,名詞,一般,*,*,*,*,りんご,リンゴ,リンゴ
$ /usr/local/Cellar/mecab/0.996/libexec/mecab/mecab-dict-index -d /usr/local/lib/mecab/dic/ipadic -u apple3.dic -f utf-8 -t utf-8 apple3.csv
reading apple3.csv ... 2
emitting double-array: 100% |###########################################|

done!

$ echo りんごジュース | mecab -F %m\\t%c\\t%H\\n -u apple1.dic,apple2.dic,apple3.dic -N6
りんご	4000	名詞,一般,*,*,*,*,りんご,リンゴ,リンゴ
ジュース	3637	名詞,一般,*,*,*,*,ジュース,ジュース,ジュース
EOS
りんご	5000	名詞,一般,*,*,*,*,りんご,リンゴ,リンゴ
ジュース	3637	名詞,一般,*,*,*,*,ジュース,ジュース,ジュース
EOS
りんご	6000	名詞,一般,*,*,*,*,りんご,リンゴ,リンゴ
ジュース	3637	名詞,一般,*,*,*,*,ジュース,ジュース,ジュース
EOS
りん	4705	副詞,助詞類接続,*,*,*,*,りん,リン,リン
ご	6655	接頭詞,名詞接続,*,*,*,*,ご,ゴ,ゴ
ジュース	3637	名詞,一般,*,*,*,*,ジュース,ジュース,ジュース
EOS
りんご	7277	名詞,一般,*,*,*,*,りんご,リンゴ,リンゴ
ジュース	3637	名詞,一般,*,*,*,*,ジュース,ジュース,ジュース
EOS
りんご	8000	名詞,一般,*,*,*,*,りんご,リンゴ,リンゴ
ジュース	3637	名詞,一般,*,*,*,*,ジュース,ジュース,ジュース
EOS

3つの辞書に登録した4つのりんごと、システム辞書に元々あったりんごが全部使われていますね。

NBest解に登場する順番もシンプルに生起コストの順番になっています。
ユーザー辞書で指定した順番に上書きされて最後の辞書の一番最後の単語しか残らないんじゃ無いか、みたいなことを懸念していましたが、そんなことは全くありませんでした。