「開発日誌」と銘打っておきながら、そういえばこのブログでは本サイトの使命の保守本流であるエスペラント語日本語翻訳システム（Ermitejo）自体の開発状況等を殆ど全く書いていませんでした。
遅まきながら気付いたというよりは、なかなか趣味のプログラミングの時間を取れないままに世界エスペラント大会が過ぎてしまったことを無意識的に頭から消していたのかも知れません。世界エスペラント大会のような節目に、せめてβ版でも公開出来ればと考えていたのですが、流石にそう甘くはありませんでした。
そこで、開発の過去を振り返りつつ、現在の状況を明らかにし、未来への展望を開いていく一環として、「開発記」という分類をブログに設け、投稿を行って行くことにしました。自然言語処理関連の検索語を用いて検索エンジンを経由して本サイトにお越しになる方もいらっしゃいますが、本サイトがそのご参考になるかどうかは怪しいものです。なお、ttt.ermitejo.comのトップページに掲げていた文書も、「開発記」の分類に属するものとして、過去に遡ってこのブログに取り込んでおきました。
あまり時系列に沿って過去・現在・未来を書けた物でもないので、まずは今回はこれまでの形態素解析を簡単に振り返りつつ、目下開発中の構文解析について述べて参ります。
形態素解析に軸足を置いたこれまでの開発
機械翻訳の一般的な方式
Ermitejoが志向する機械翻訳は、『自然言語処理』p.463（参照：参考文献一覧）の通り、概ね以下の一般的な構成要素から成り立つものです。
- 形態素解析
- 構文解析
- 意味解析
- 意味変換
- 構文生成
- 単語列生成
- 形態素生成
2007年8月現在では、形態素解析から構文解析へと開発の軸足を移している状況です。まずは形態素解析の現状をご紹介します。
形態素解析の現状
形態素解析については、概ね当初の予定通りの結果を得られています。エスペラントの特長である規則性をそのままPerlで書いていく方法です。
広高正昭(Vastalto)氏の『実用エスペラント小辞典(PEJVo) 第1.5版』を辞書データに用いた辞書引き機能（オンライン辞書引き機能）として括りだして本サイトで提供しています。この公開テストの甲斐もあり、仕様の漏れや実装のまずさが次々に洗い出され、それなりのところまで持って来られました。翻訳サイトを目指しておきながら単なる辞書引き機能しか提供出来ておらずお恥ずかしいのですが、遅まきながらこの盆休みに広高氏に二次利用のご報告を私信にて差し上げた次第です。この場でも、改めてお礼を申し上げます。
ただし、形態素解析はまだ未実装の部分も少なからず存在します。例えば、未知語の処理についてまだ手厚く作業をしていませんので、後続処理のためには当該部分を「それなりのところ」まで持って行く必要があります。また、辞書引き単独で見た場合にも、単語を渡しての辞書引きのみならず、文章を渡して各々の単語を一遍に辞書引きするという使い易さを求める必要があります。
とはいえ、あまり形態素解析ばかりにかまける訳にも参りませんので、2007年3月下旬から構文解析機能の開発を行っています。
エスペラントに於ける構文解析は簡単か？
HPSG + CYK法
エスペラント語日本語翻訳システム”Ermitejo”の構文解析については、LiLFeSと同様の接近方法である、以下の組み合わせにより実装すべく、設計と開発を行っています。
素直にLiLFeSを採用しなかったのは、以下のような理由によります。
- 勉強と趣味のために車輪の再発明を行う
- ホスティングサービスを利用しているのでLiLFeSをインストール出来ない
何とも情けない理由ですが、特に二点目は如何ともし難い問題でした。数年前は自宅サーバを構築・公開していたのですが、セキュリティにかなりの水準まで気を遣う労力が増しそうで、取り潰した経緯があります。単なるWeb + APサーバなのですが、利用者によるユーザ辞書登録等も行いたいと考えており、そうすると限りある資源（趣味に避ける時間と、私の乏しい知識・技術）を選択して集中することが最適解だと思い至った次第です。
このうち、CYK法に基づいたパーサは、既に作成を終えています。しかし、パーサに与える文法がなければ、構文解析は成り立ちません。文法についてはそもそもまずはHPSGについての勉強から始めているようなところで、1年程経ちますがなかなか理解が追いつかない状態です。
エスペラントの文法を機械翻訳の俎上に載せることがどの程度難しいのか、実例を交えて以下にご紹介します。
time flies like an arrowとtempo flugas kiel sago
英語では、5通りの構文解釈（意味上の解釈はさらに増えます）を誇るtime flies like an arrow.という有名な諺があります。これは、以下のように解釈出来ます。
- S[ NP/Time VP[ VP/flies PP[ PREP/like NP[ DET/an N/arrow ] ] ] ]
- S[ VP/Time NP[ NP/flies PP[ PREP/like NP[ DET/an N/arrow ] ] ] ]
- S[ NP[ ADJ/Time NP/flies ] VP[ V/like NP[ DET/an N/arrow ] ] ]
- S[ NP[ NP/Time NP/flies ] VP[ V/like NP[ DET/an N/arrow ] ] ]
- S[ VP[ V/Time NP/flies ] PP[ PREP/like NP[ DET/an N/arrow ] ] ]
これに相当するエスペラント文のTempo flugas kiel sago.では、以下の1通りの解釈しか出来ません。
- S[ NP/Tempo VP[ VP/flugas PP[ PREP/kiel NP/sago ] ] ]
それでは、エスペラントに於ける構文解析も楽に実装出来るのでしょうか？
答えは残念ながら否です。なぜならば、上記の解析絞り込みの成果は、各単語の品詞を一意に同定出来たことに負うものであるからです。「S(文)がNP(名詞句)とVP(動詞句)から成り立つ」であるとか「NP(名詞句)がADJ(形容詞)とN(名詞)から成り立つ」というような句構造規則をいくつか用意するだけで実現出来てしまう解析結果なのです。
文法は16箇条のみに非ず
それでは、16箇条しかないエスペラントは、機械翻訳用文法も楽に記述出来るのでしょうか？
これも、残念ながら否です。A4の紙1枚に収まる16箇条の文法とはいえ、まさかそれだけで文法が完結したとすれば、PAG(Plena Analiza Gramatiko)の本の厚みは生じないでしょう。CFG(Context-Free Grammer)の書き換え規則でも然りですし、HPSGのスキーマでも然りです。そもそもHPSGは辞書をこそ重要視する文法なので、PIV(Plena Ilustria Vortaro)のような厚みもまた納得出来るというものです。
エスペラントは無味乾燥で無機質な冷え切った言語ではありません。いかに人造言語といえど、自然言語のエッセンスを抽出した言語である以上、自然言語と同様の奥行きが待っているのです。実装する側にとっては手の掛かる可愛い子のようなもので、その意味では、大変ですが頑張り甲斐があります。
エスペラントに於けるHPSGも他言語と基礎部分はあまり変わりません。例えば、granda leonoまたはleono grandaというNP（実際にはNPの素性構造）は、主辞のNであるleonoがADJを下位範疇化して生成します。この際の制約(条件)としては以下のようなものがあります。
- N（にあたる素性構造、以下同様）とADJの格が一致していること。grandan leononは許容されるがgrandan leonoは拒否されます。
- NとADJの数が一致していること。grandaj leonojは許容されるがgrandaj leonoは拒否されます。
- ADJはNの左右どちらでも構わない。日本語ともまた違って、NP → ADJ, N (granda leono)もあればNP → N, ADJ (leono granda)もあり得ます。
このようにして文法を記述して行くわけですが、幸いにしてエスペラントの規則性ゆえ、語彙を山ほど用意して個別に細かな特例等を記述する必要がないので、Ermitejoでは語彙辞書をあまり深くまでは書かずに構文解析を実現しようとしています。
まとめ ～ それなりに時間が掛かりそうです
エスペラントに於ける形態素解析は或る意味で正直な処理で、愚直に書いていけば何とかなるような代物であったりします。過去のエントリでも「品詞推定に隠れマルコフモデル等を使う必要が皆無」と述べた通りです。しかし、構文解析ともなると自然言語処理の本領発揮といったところで、実装には或る程度の言語学的な素養と情報科学的な技術が必要となり、元歴史学徒の金融系SEには荷が勝つ代物になって参りました。
生憎と本業の合間を縫って趣味のシステム設計およびプログラミングに割ける時間が厳しいのですが、存外に気分転換になる楽しい作業でもあるので、多忙を言い訳にせず（このエントリだけで十分している気がなきにしもあらずです）に邁進する所存です。
記事の配信