考察:「意味理解」

by ご近所のきよきよ


 
 動画システム作成クラスをコーディングし終えて、さてデバックをと思いきや、なんか大事なことを落としているのではないかと思うにいたりました。動画システムができたとして、意味を理解したと言えるでしょうか。確かに、単語の意味は記号として収集できて、動詞とその周りの格も把握して、物語ならステージ、シーンとして、場所や時間、アクターを明確に時系列として解析結果を保持しています。でも、何か不満。
 
【問題点1】
(例文)「牟礼で列車に乗った。外の景色は綺麗だった。山はもう緑だ。30分くらいして列車は長野に到着した。列車を降りて本屋に行った。」
 
 この文に対して、「どこにある本屋でしょうか?」とか「私は今どこにいるでしょうか?」なんて、質問されたらどう答えられるでしょう。長野にいることを推論するにはどうしたらいいでしょう。
 列車の動きによって、「私」も付随して移動していることを認識しなくてはなりません。この情報は動画システムにはないですから、特別な機構を持たねばなりません。動画システムは移動する列車の中にも展開されねばならないということです。動画システムはアクターを管理しますから、アクター(列車もアクターとして管理している)毎に独自の動画システムを持たねばならにということです。
 地面を中心にした動画システムしか考えずに、動画システム作成クラスを作ってしまったので、これを拡張しないといけません。つまり、文章の抽象動画システムでステージとかシーンとかを管理しない時系列のカットセットを管理し、起点のデフォルトの動画システムを地面(地球上)ということで管理することにします。後は、登場人物(アクター)毎に固有の動画システムを管理していくことになります。その中で場所と時間が明確になったら、抽象動画システムにタイムスタンプと場所を記述していくことになります。
 工夫すべき事は、文のパターン定義とそのときの動画システムへのコマンドをどう記述し、処理していくかですね。スクリプト言語で大がかりでやりたいのですが、ま、当面、ラインコマンドぐらいで実現することを試行するつもりです。
 
【問題点2】
(例文)「私は空に浮いた雲を見つめていた。」
 
 この文は、「私は空に浮く」は「雲が空に浮く」とくらべると現実性がないわけで、曖昧性は減少させなくてはいけないのですが、この処理やってないですね。問題です。基本的に文コーパスを作って対処するつもりです。前から考えていた技術ですが、やっと実現させる時が来たようです。
 
 
 
【問題点3】
(例文)「レストラン行こうということになった。未夢は先に行くと朝から街に出て行った。私がレストランに入ると、実際先にきていた。」
 
 「レストランに先に来ていたのは誰?」という問いに、「未夢」と答えられるでしょうか。未夢がレストランに行くことは、前の2文から、特に第1文の内容から判断しなくてはなりません。ま、現実解は「私がレストランに入ると、実際先に来ていた」の「来ていた」の主語は、この文の前方、近辺のアクターであると判断すべき・・・という規則になります。
 こんな規則をコーディングなしで、データで与えることができるでしょうか。欠落値充填パターン辞書を設けることになりますね。
 
【問題点4】
(例文)「私は未夢にりんごをあげた。」
 この文は、未夢の視点からは、「未夢は私からりんごを貰った。」となります。
 
 アクターをきっちり管理するのであれば、アクターの視点から自在に状況を表現できなくてはなりません。これは結構きつい問題なのです。
 未夢が2階にいて、私が1階にいれば、未夢を見ることは「見上げる」ことですし、未夢からは「見下ろす」ことです。「俯瞰」もできるでしょう。これは本質的に「文脈空間」の話題なのですが、ここはフレームを用意し、視点と単文セットを関連づけて管理して、知識さえ多ければ対応できる・・・ということを目指したいと思います。
 
 
 
【問題点5】
(例文)「庭で赤い花と黄色い花を花瓶に入れた。床の間にいたとき、花瓶の花を一つくださいといわれて、一本あげた。その花は今玄関を飾っている。」
 「玄関の花は何処から採ったものか?」という問いに、「庭で採った」と答えられるでしょうか。
 
 「花」が現れる文から後、ずっとトレースしなくてはなりません。「花瓶」をコンテナとして(ステージとして)「花」を保持させ、「床の間」へと移動させます。「花瓶の花を」で、このコンテナの中の「花」と認識して、「取り出す」イメージを持ちます。「その花」は「花瓶」コンテナにあったものという事を理解して、「玄関の花」は「庭の花」と推測します。パターン「〜で〜を〜に〜いれる」は「〜で〜を採取して〜に〜いれる」と解釈して最終回答を得ることになります。
コンテナという概念は重要です。また、文のパターンの相同性管理も基本的な作業となります。様々な表現を内部的に規格化して、適切な推論ができるようしなくてはなりません。
 
 
 
 コンピュータが意味を理解するとはどうゆうことでしょうか。チューリングテストでないですが、読んだ文章をベースにして人間が質問したとき、人間レベルの解答をできるということではないでしょうか。
 問題点1,2,3、4、5と今の未夢プロジェクトが解決しなくてはならない技術は沢山あります。こんなことをプログラムコードで記述するのは多分不可能でしょう。プロダクションシステムに倣ったコマンドパターンで対応していくしかありません。今やっとその緒についたところです。未夢プロジェクトが何処まで成長するか楽しみです。

 
 それで、Prologベースでの意味処理の表現ですが、それはそれで重要だと思うのです。未夢プロジェクトはあくまでも推論の基盤となるデータを作ることです。それすら巨大なデータとなります。解析推論プログラムをPrologで表現できれば、必要な情報はオンデマンドで収集できます。データ量が遙かにすくなく、不要なデータはシステムに持たなくできます。だから、Prologベースも考えていきたいと思います。
 前回の考察は大分怪しいProlog表現でしたが、「Prolog入門 太細孝他緒 啓学出版」などを読んだりしますと、なかなか大きな作業ができるのですごいと思いました。現在も拡張作業はなされているのでしょうか。私としては、Prologの項をオブジェクト指向にして、プログラムとは別の所にプールしたいと考えています。項を目標に応じて詳細化したり、追加機能を付加したりを簡単にしかも動的に行えるようにしたいからです。文章を表現したProlog文に対する、メタなプログラムというものを作ってあらゆる問い合わせに対処できるようにしたいというのが趣旨です。
 
 さてさて、意味処理どうなることになりますか。28年の努力が報われるかどうかの正念場です。
 
 

おわり