※ 「ucdict について論評する」とかそういうものではなく、主に「自分が理解するために自分の頭で考えてみる」というものです。色々難しいので…。
ucdict の登録の仕方は、mkworddic/ucdict の先頭部分を参照。
内部の動作等、詳しい話は G-HAL 氏の日記(?)の Mon,05 Oct,2009 以降を参照。
【どっちをキーにするか】
「身を委ねる」を出したい場合、ucdict は基本的には(フラグが「-」の場合には)文節の順番通り「身→委ね」となるように登録するらしい。
- 2 み を ゆだね * 身 を 委ね *の場合だと、「注目文節の候補の中に『身を』が見つかったら、直後の文節の候補の中に『委ね*』があるか探し、もし見つかったら『身を』と『委ね*』の双方を加点する」という風に動作する(んだと思う)。
「読み的に『委ねる』の方が他の候補とバッティングしにくいから、よりキーとして相応しいだろう」と思って、「委ね→身」となるように登録すると、別の意味になってしまう。つまり、
- 2 ゆだね * み を 委ね * 身 をとすると、「委ねた身を」などを出すための登録になってしまい、「身を委ねる」を出すための登録にはならない。
言い換えると、文節の順序と登録の順序とが一致していなければならないらしい。
文節の順序: 「身を委ねる」なら「身」が先、「委ねる」が後
登録の順序: ○「身 を 委ね *」 ×「委ね * 身 を」
フラグを「b」にすれば逆方向も見るようになる。
しかし、逆方向のみというのは登録できないように思う。
・文節の順番は右方向限定。これは問題ないか?
左方向にも適用したい場合、フラグで指定する。
・用例辞書が適用される前に既に文節区切りは終わっている
・先頭候補だけでなく、候補リスト中のすべての候補について検索する
ので、多分問題ない。
【間に別の文節が挟まると効かない】
b 2 ばしょ * あけ * 場所 * 空け *が登録されていて、「あけた」の第一候補が「開けた」である場合に、
ばしょをあけた → |場所を|空けた|
ばしょをさっとあけた → |場所を|さっと|開けた|
連続しないケースがあることは分かった上でこうなってる。10/18 の項では
・現状では、連続した文節限定。と書かれているので、変わるかも。
フラグにて間に他の内容が1文節入るケースも許容するか?
【連続してるが故に誤変換することもある】
b 3 ほん * あつ * 本 * 厚 *が登録されていて、「あつい」の第一候補が「熱い」である場合に、
|部屋が|厚いと|本に|よくない|
用例辞書の登録がなければ、「熱い」が第一候補なので「熱いと」になるはずで、これも不正解ですが…。
b 3 へや * あつ * 部屋 * 暑 *も登録されていれば、「厚い」と「暑い」が共に同じだけ(優先度「3」)加点されるので、元のスコアが高い方が先に来ると思う。
辞書は
あつ #KY*403 熱 #KY*402 暑 #KY*301 厚なので、「暑い」が上に来そう。
しかし、この場合だと、
|暑い|部屋と|暑い|本|
になると思われる。
# 「複数の用例が重複した場合、重複加算は行わない」とのことなので、
# この「暑い」と「厚い」の話は間違ってるかもしれない。
(例が意地悪すぎる気もしますが、)これを解消しようとするのは難しい…。
思いつくのは、「あついので」「あついから」でも同様のことが起こるが、「と」「ので」「から」は確か接続助詞(2つ目の「本と」の「と」は並立助詞か)。接続助詞ということは、2つの文を繋いでる。言い換えれば、前の文と後の文とは別個の文。従って、「付属語に接続助詞があったら、それを跨いで用例辞書を適用することはしない」というルールがあれば防げる。
でも、実際にやるのは多分無理。
また、接続助詞(接続詞もか)を挟むパターンじゃないものもあるかもしれない。
↓
あった。
|違う|場所で|空いてと|あった|
(|違う|場所で|相手と|会った|)
【付属語の判断が難しい】
上からの続き。
色々考えたが、誤適用を避けるためには間の付属語で判断するしかない。
でも、どの付属語が OK で、どの付属語が NG かを人手で一つ一つ登録するのは非常に大変。
【同語彙異表記の順序がひっくり返される】
辞書が
てんぷら #T35*252 天ぷら #T35*251 てんぷら #T35*201 天麩羅 #T35*200 テンプラで、用例辞書に
b 3 てんぷら * あげ * てんぷら * 揚げ *がある場合、辞書の候補順序がひっくり返される。
てんぷらをあげる → |てんぷらを|揚げる|
「そば/蕎麦/ソバ」「きつね/狐/キツネ」のように、「同じ語だけど表記が違う」というものは多い。辞書では、ウェブ検索での hit 数を元に一応順序を付けてあるので、あまり理由もなくひっくり返されたくない。
こういう事態を避けるためには、用例辞書に登録する表記は、辞書に合わせる必要がある(下位の表記を使うべき理由がある場合は別として)。
多分、スクリプトで簡単に洗い出せると思うが、品詞情報がないとゴミが多くなるかも。
ちなみに、ucdict には「てんぷら/天ぷら/天麩羅/テンプラ」のうちのどれかで登録してあれば、他の表記の登録は不要なはず。つまり、「『てんぷら』には表記が 4つあるから、どれでも行けるように 4つとも登録しなきゃならないんじゃないか」ということはない。優先したい表記だけを登録すればよい。
【登録数が増えると管理が大変】
既に登録されているのに気づかずに、同じものを登録してしまったりしないか?
→ hash が衝突するものは make 時に上がってくるようになっているので、そこで気づく。
でも、それは登録した後の話なので、「無駄な登録を避ける」ことはできない。登録する前に検索をかけるのも、毎回やるのは大変。
「『注目文節の自立語の読み』で sort する」とか?
→ 今見たら、「ペア文節の自立語の読み」で sort されてるっぽいので大丈夫そう。
【品詞コードがないと判断できない場合があるのでは】
これは元々 corpus の例文をいじってて思ったこと。
Anthy の corpus の例文は
|せんせいの|いうことに|まちがいは|なく| |先生の|言うことに|間違いは|なく|
という風に登録し、これを自動で解析して自立語部と付属語列に分けたり、自立語の品詞を探したりしてるんだと思いますが、上の例文の場合、「なく」の部分はひらがな表記なので
・形容詞『無い』の連用形
・カ行五段動詞『泣く』等の終止形
の 2つの可能性がある。でも、anthy にはどっちが正しいかを判断する手立てがない。どっちかに決めなければいけないので、どっちかを選んではいると思いますが、仮に後者を選んでたとしても、anthy は責められない。情報がなくて正しく判断できないんだから。
「|間違いは|無く|」と漢字表記にすれば品詞の判定は正しくできるようになりますが、今度は「ない」というひらがな表記よりも「無い」という漢字表記が優先されるようになって、それも嬉しくない。
そんな訳で、個人的には corpus の例文に自立語部分の品詞情報を付けるべきではないのかなぁと常々思ってます。
但し、辞書の品詞コード(T35 とか K5 とかの)ではなく、名詞、動詞、形容詞、連体詞等の大分類的なもの(anthy なら POS_*)。小分類的な辞書の品詞コードだと却ってよくない気がする。
|あつい|ふろに|はやく|はいりたい| |熱い|風呂に|早く|入りたい| |A|NOUN|AV|V|
みたいな感じで。
で、ucdict にも同じことが言えるのではないか。
例えば「金がない」「金はなかった」等を出したくて
- 2 かね * な * 金 * な *としたとすると、「な*」の部分は
・形容詞「無い」のひらがな表記、
・カ行五段動詞「泣く」等のひらがな表記
・ラ行五段動詞「鳴る」等のひらがな表記
・(他にもガ行五段動詞、サ行五段動詞などのひらがな表記)
が合致することになってしまい、「鐘が鳴る」が「|金が|なる|」になったりするのではないかと思う。
今気づいたけど、ucdict の場合、付属語というか活用語尾がワイルドカードになるので、大分類では情報が足りないかも…。
ともかく、活用語でひらがな表記のものは品詞情報がないと不味い気がする。
(いや、漢字表記でも「直(す)」と「直(る)」、「楽し(い)」と「楽し(む)」みたいなのがあるから、不味いかも)
【関連する記事】
係り受けの解析が必要そうですね。
http://blog.ruigo.jp/kokublog/218
南瓜とかが「係り受けの解析」をどうやって機械的にやっているかは全然分からないですが、anthy でやるとなると大改造になりそう…。
ただ、
-----
http://sourceforge.jp/projects/anthy/lists/archive/dev/2007-March/003415.html
> 茶筌の出力に対して形態素が自立語か判断がつけば係り受けの
> 解析までは要らないんじゃないかと思ったりしますが、
> 省力化でしょうか?
はい、実際は茶筌が読み付与、飲茶(YamCha)が文節区切り、南瓜が文節間の係
り受けを見ているので、茶筌と飲茶まであればできますが、飲茶で作るより南
瓜で作ったほうが手抜きできる(南瓜が自動で飲茶と茶筌を呼んだ結果を保持
してくれる)ので、こうしてあります。
-----
と言われてるので、係り受け解析まではいらないようにも思います。
あと、言語工学研究所のブログがあるとは知りませんでした(しばらく前に見たらシソーラスが使えなくなっててショックだった…)。
辞書に意味情報を持たせることについては、ちょっと他に考えたことがあるので、明後日以降に書いてみたいと思ってます。
> # 「複数の用例が重複した場合、重複加算は行わない」とのことなので、
> # この「暑い」と「厚い」の話は間違ってるかもしれない。
同一文節の同一候補に対しては、1回しか加点を行いません。
同一文節の別候補に対しては、各候補毎に加点を行います。
例えば、「部屋 → 暑」(優先度 3)と「暑 → 夏」(優先度 4)の2つの用例がある場合、「|部屋の|暑い|夏|」という候補の「暑」への加点は、優先度 4(優先度の大きい方)の1回しか行いません。
また、「部屋 → 暑」(優先度 3)と「厚 → 本」(優先度 3)の2つの用例がある場合、「|部屋の|[あつい]|本|」という候補の第2文節への加点は、書かれている通り、「暑」と「厚」の両方に加点があります。
それから、単に全く同じ内容が書かれている重複登録は、メッセージも出さずに黙って無視する様にしてあります。
コーパスの用例の適用にて「間に別の文節が挟まった状態で適用された挙句の変な変換」に、ちょくちょく遭遇するので、連続した文節限定にしています。
加点の大きさを減らして適用するか、迷っていますが。
> 【品詞コードがないと判断できない場合があるのでは】
用例データを作るのがさらに輪を掛けて面倒になるとか、品詞に関して造詣の深くない人が用例データを作れなくなってしまうとか、問題もあるので迷っていましたが、品詞情報も必要そうですね。
> 【連続してるが故に誤変換することもある】
「|(名詞)|(形容詞)|(文の続き)」の形よりも「|(形容詞)|(名詞)|」や「|(名詞)|(形容詞)|(文の終わり)」の形の方が多い、とか、「|(動詞)|(名詞)|」よりも「|(名詞)|(動詞)|」の方が、とか、偏りがありそうな気がするので、その辺を使うと多少マシになりそうな気もしますが。
それってコーパスの確率情報そのままな気が。
本格的かつ大規模に整備するのは、全て手作業で行うのは無理かと思います。
その辺を自動化した手法こそが統計的手法だと言う話もありますが。
手動での整備は、薬味か隠し味程度が落とし所ではないかと。
> 同一文節の同一候補に対しては、1回しか加点を行いません。
> 同一文節の別候補に対しては、各候補毎に加点を行います。
お、勘が当たってましたか。
> コーパスの用例の適用にて「間に別の文節が挟まった状態で適用された挙句の変な変換」に、ちょくちょく遭遇するので、連続した文節限定にしています。
> 加点の大きさを減らして適用するか、迷っていますが。
ucdict の場合は、組み合わせる語などを人手で登録するので、あまりストイックにならなくてもいいように思います。誤適用があってもそれは仕方がないと諦められますし。
連続した文節に限定すべきなのはどっちかというと、句読点まで無差別に用例化するコーパスの用例機能の方ですよね…(正直呆れました)。
# あんまりだと思ったので、例文から句読点、カッコ、感嘆符、疑問符を抹殺しました
なので、私は「間に別の文節が挟まっても可」派ですが、実装するのが面倒であれば、無理してまでやることもないとも思ってます。要するに、お任せします(笑
> 品詞情報も必要そうですね。
実は昨日ちょっと anthy-7100b に alt-{cannadic,depgraph} を入れてみようとしたんですが、その時、udict と gcanna.ctd とで品詞コードの違ってるものがずらずらとエラーで上がってきました。
もしかしたらですが、この頃は品詞コード部分も使っていたのかもしれません。チェックだけして、実際には使ってない可能性もなきにしもあらずですが。
> 本格的かつ大規模に整備するのは、全て手作業で行うのは無理かと思います。
> その辺を自動化した手法こそが統計的手法だと言う話もありますが。
そうですね。同感です。
> 手動での整備は、薬味か隠し味程度が落とし所ではないかと。
コーパスの例文に突っ込んでも直らないものを登録してみる、という感じでしょうか。
そもそも文節区切りが間違ってるものはどうしようもないですが、それでも正しく区切り直した時に期待の候補が最初に来てくれれば、ストレスもいくらかは軽減されますね。
ハッ、でも、その判断ができる人ってどれだけいるんだろう…?
# 今、2009X25 版(with alt-{cannadic,depgraph}&ちょっと手を入れた)使って書いてるんですが、なんか調子いいかも
例文に品詞が付いていないのは「変換のログから自動的に例文を作る」方法が使えないからではないかと思います。肯定あるいは否定となる様な情報を探していたものの見つかりませんでしたが。
変換のログに品詞情報を付けるには、変換候補に「なく[#KY]」や「なく[#K5]」等と品詞も表示した上で、ユーザに間違いなく選んでもらわないといけません。
でも、注釈表示機能はありませんし、大抵の人には #?? を見ても何の事やら判りませんし。
現状、変わっていませんので、多大な労力を費やさずにコーパスの例文に品詞情報を付ける方法が、無いままだと思います。
> anthy-7100b(略)udict と gcanna.ctd とで品詞コードの違ってるものがずらずらとエラーで上がってきました。
それはちょっと気になりますね。と言う事で調べてみましたら。
7100b では「読み仮名、品詞、変換後の字面」の3つが一致するかどうか(anthy.dic上のオフセットアドレスを単語の ID として使用)にて、一致判定していました。
7500b では、現行仕様通り「変換後の字面のハッシュを ID として使用」していました。
諸般の仕様変更の巻き添えで読み仮名・品詞を使わなくなった様な印象を受けました。
> その判断ができる人ってどれだけいるんだろう…?
その辺を積極的に期待するのは諦めています。
もし使い手が現れればラッキー、くらいの感じで。
「変換のログから自動的に例文を作る」方法というのは、多分 ANTHY_HISTORY_FILE のことだと思いますが、これは例文を集めるために "後から" 追加された機能なので([Anthy-dev 3429]に至る流れ参照)、これが理由ではないと思われます。
ANTHY_HISTORY_FILE が登場する前から例文の形式は今と同じでしたので。
例によって勝手な憶測ですが、多分、「anthy-morphological-analyzerを流用すれば、品詞はそこから推定できるから例文には不要」という判断だったのではないかと思います。「誤判定もあるかもしれないが、面倒だし、そこは無視」みたいな感じだったんだろうと。
# anthy-morphological-analyzerを半角にするとコメント蹴られる orz
# アホか、厳しすぎだろ > seesaa
# 気づくまでに半日掛かった…
> 変換のログに品詞情報を付けるには、変換候補に「なく[#KY]」や「なく[#K5]」等と品詞も表示した上で、ユーザに間違いなく選んでもらわないといけません。
品詞は小分類/細分類的な辞書の品詞コード(KY、K5)までは要らないのではないかと思ってます。「なく」なら「動詞なのか形容詞なのか」、「ない」なら「名詞なのか形容詞なのか」といった、大分類的な品詞が分かれば、誤判定による悪影響はかなり防げるのではないかと(今現在どのくらい悪影響があるのかも知らずに、憶測でこんなこと言うのはいけないんですが)。用例辞書と違って、例文には付属語が明確に付いているので。
また、ユーザに「辞書の品詞コードどおりに付けて」というのは仰る通り無理があると思いますが、大分類の「名詞、動詞、形容詞、副詞、連体詞、形容動詞」だけならユーザにお願いする事も可能ではないかと。自動でできなくても、何とか手作業でやってもらえる範囲かな…と思うんですが、甘いかな…。
あるいは、「基本的には今のように品詞コードを自動で判定する、但し、例文に品詞コードが指定してあれば、その品詞コードを(正解として)使う」と言う風にできれば、人手で品詞を指定する部分が大幅に減らせそうな気もしますが(誤判定した/しそうなところのみで済む)。
# 私の場合は、「できるかどうか」とか「どのくらい大変か」とかは全く分からずに好き勝手言ってるだけなので、「そうできたらいいけどねぇ」くらいの軽い気持ちで読んで下さい。
何れにせよ、実際にやるには他の点で問題があると思いますし、ある程度「やればよくなる」という見通しが立ってないとユーザにお願いするわけにも行きませんし(やらせといて「ダメでした」じゃ叩かれそう)、送って貰った例文をチェックする作業は必須だと思うので、やるとなったら大変ですが。
例文専属のメンテナが必要。
> それはちょっと気になりますね。と言う事で調べてみましたら。
ありがとうございます。
早くも 7500b で現行仕様となっていたとは…。
anthy-morphological-analyzer について記事を探してみましたが、品詞も読み仮名も文節区切りも一切情報無しの状態で、変換結果の文の内容だけを使って、統計情報を得る方法を試されていた時期もあるらしいのが、ちょっと気になりました。
これはもしかして、anthy-c74rc1(WinAnthy で使われてる anthy ( www.kmc.gr.jp/proj/winanthy/ ))の calctrans/Makefile.am にある「proc_raw:」の部分のことでしょうか?
# って、そうだったとしても、自分に言えることは何もないんですが XD