by ご近所のきよきよ

　曖昧性を「うなぎ文」で考えてみましょう。おやつの時間に信子が「私はアップルパイ」と言ったとき、明らかに、「I am a piece of apple-pie.」では無いことは分かります。「(Noun)は(Noun) 」構文にはis_a関係とselect関係の２つの意味選択があって、曖昧なのです。これを例にして、「学習と曖昧性管理」を考察していきたいと思います。

　曖昧性を判断するには文脈を見ないといけません。文脈とは何でしょうか。シーンとかステージとか・・・つまり、あのときの状況だから、この意味・・・ということになります。それと、この状況ではこの意味しかあり得ないと推論することです。信子は人間で、アップルパイでないことは明らかですから、「私はアップルパイ」は選択の意味である、更に推論して、「アップルパイを食べる」と言う意味を酌まねばなりません。ここが大事な所です。単にシーンだけ、シーンのモデルにそんな記述があったというだけでは本物の推論にならないのです。デフォルトではシーンモデルを見るとして、本当は、消去法で本来の意味を推論していくのです。

　ステージ、シーンを持った情報はコーパスであるわけで、コーパスの中の表層表現と深層表現対を検索するのが、デフォルト値取得の第一弾であるわけです。おやつの時間のステージ、シーンはコーパスの中に散在しています。その全てをなぞって、表層表現「(Noun,+human)は(Noun)」を得て、その深層表現「(Noun,+human）have(Noun)」もしくは「(Noun,+human)select(Noun)」を決定していくのです。

　そんな処理をしていくには、表層構文「(Noun,+human)は(Noun)」の定義情報に曖昧性候補があるとの情報が必要です。消去法適用コマンドも推論のために必要でしょう。それは、表層構文「（Noun,+human)は(Noun)」モデルの保持する情報なわけです。

　このように、学習とはコーパスを蓄積することであり、そして、それを抽象化して、推論を働かせるための情報をモデルを創っていく過程であります。

　ところで、ＲＤＢで知識ベースを構築しますと、テーブル名にアルファベット大文字以外は使えませんから、モデルテーブル名と実際のモデル名との対応関係を持つテーブルが必要です。

　更に工夫すべきことは、生のデータをコーパスに保存するとしましたが、全ての動画像データを保持することは容量を考えると不可能です。重複するデータは保持しないとか、モデルの持つ情報を充実させて（モデルの風景を詳細に覚えるとか）、できるだけ時系列となることを避ける（身体性を利用するとか）など工夫が必要です。データ圧縮技術に通じることです。圧縮技術よりも強力なのは、いかに記憶しないかということを追求する技術であるところでしょうか。精確に記憶する必要はない・・・。生きていくのに十分な精度で記憶すればよい・・・。それが身体性記憶の極意です。

おわり