自然言語処理スレッド その４
■ このスレッドは過去ログ倉庫に格納されています
前前スレ 自然言語処理スレッド その２
http://mimizun.com/log/2ch/tech/1173105287/
前スレ 自然言語処理スレッド その３
http://mimizun.com/log/2ch/tech/1235129481/
このスレッドでは、日本語の構文解析、談話理解、情報検索、
文章生成などの技術に関する理論と(おもに)実装を扱います。
あくまでアプリケーションプログラミングの技術的な面に重点をおきたいので、
学術的な話はアリですが、いわゆる人工無能や哲学的AI話、
言語学の話題などは他のスレッドでお願いします。 >>695
「ぞんさい」と「そんさい」はあるかもしれない。
「無人島」も、「むにんとう」「ぶにんとう」「むじんとう」
の訓があるわけだし。小笠原には「ムニンノボタン」が
生えているし、英語だと「ぶにんとう」→「ボーニン・アイランド」だし。 理屈っぽさと独創的なプログラミングスキルには負の相関がある、
と誰かが言ってたな
理屈こねて長文レスしまくってる人はもうプログラミングやめた方がいいかも >>697
ご意見はありがたく拝聴しておくが、
「じゃあ、おまえはどんなプログラムを書いたんだ？」と
質問しておこう。
せめて、まともな理屈くらいこねてくれ。 >>679
＞ちんぽは自分の意思でシコシコするから
ならオシッコを我慢するときは？ >>496
＞テレビゲームのような仮想世界をインプットして、
人体というのは宇宙のように広大で、コンピューターには入り切らないぞ？
>>485
＞CycはFredがひげをそっている間、Fredはそれでも人間なのかと尋ねた。
人間の動作というのはそれだけ複雑だってことだな。 >>700
SF だけど、『未来の二つの顔』でやってたな。
星野之宣さんのマンガでやってたけど、
仮想空間の中でコンピュータに目玉焼を作らせようと
したら、フライパンの中に割らずに卵を載せて
しまうとか …。
で、「これは、やっぱり実際の空間の中でやんなきゃ
ダメだ！」っつーんで、コンピュータ制御の戦闘用ドローンと
武器を持った人間が、宇宙ステーションの中で
ドンパチをやるという話。 自然言語処理と関係なくなっちゃいそうだから、
それっぽいものも足しておこう。
『２００１：宇宙のオデッセイ』
『ヴァレンティーナ』
『月は無慈悲な夜の女王』
『ウォー・ゲーム』（映画）
『ノーラの方舟』
『アメリカの黒船』（笑） >>703
×『アメリカの黒船』
〇『マンハッタンの黒船』
諸星大二郎。「デモクラシー・マシン」という、
国民に端子を埋め込んでおいて、その測定値を
もとに、コンピュータが政策決定をするという話。
あれ読んどくと、幕末史がかなりよくわかる。
ついでに、『ゴースト・バスターズ２』を観ると、
けっこう笑える。
こう、どうしようもなく暑いと「ドンマイ・ダンス」（＝ええじゃないか）を
踊りたくなるよなぁ。川原泉も『笑う大天使（ミカエル）』で、
ウルトラマンと鉄腕アトムと超人ロックにドンマイ・ダンスを
踊らせてたし。 >>699
腹筋運動で腹に力を入れるってのと同じ。 >>701
＞フライパンの中に割らずに卵を載せてしまうとか …。
ゆでたまごとは違うからなあ。 日本語処理をやってて困るのは、
「葱」を「ネギ」と訓むと気持が悪く、
「キ」と訓みたくなることと、
「タマネギ」を漢字で書くときに、
「玉葱」ではなく「玉根葱」と
書きたくなることだな。 >>699
オシッコの時とオナニーの時とでは、役割が全然違う。 第13回テキストアナリティクス・シンポジウム
あたりに出てみたら？ いまのところ思いつきでしかないんだが、
日本語の「文語」「旧漢字」「旧かなづかい」と
いうのは、自然言語処理における暫定的な
ピボット言語として、けっこう実用的なのでは
ないか、と思う。
戦後に教えられている、日本語の現代国語の文法は、
文語文法ほど厳密ではない。
「常用漢字への置き換え」のせいで、本来の字義が
わかりづらい文字がある。
旧かなづかひには、文語文との歴史的な関連があり、
合理性がある。
で、「現代語」「常用漢字」「新かなづかい」への
変換は、わりと標準的辞書とそれなりのアルゴリズム、
そこそこのマシン環境があれば、実用上は不自由な
感じがなく可能だ。
いけそうに思うのだが、どうだろう。 >>713
どこの？
おれは出席できるのか？
発言権とか議決権とかはあるのか？
どういう影響力があるのか？ >>714
会議って学会のでしょ。
論文書いて採択されたら誰でも発表できるはず。 >>715
日本ソフトウェア科学会の自然言語処理の
分科会で、ボロクソに叩かれたのが、いまだに
トラウマになっている。
当時は JUMAN 以外の形態素解析システムは
認められていなかったので、分科会の座長に
「益岡 隆志 ・田窪 行則の『基礎日本語文法』を
読んでから来なさい」と一蹴されてそれっきり。
資料をほじくり返せば、どっかから名前が
出てくるだろうが、それも野暮な話だろうと
思って遠慮している。
形態素解析で、おれらに勝てると思ってる
奴がいたら、喧嘩売ってこい。ぜんぶ
買ってやる。 ついでながら、大修館の『言語』の
『言語空間』で、国広哲弥先生と
がっぷり四つに組んでバトルをしたのは、
うちらの親玉だ。 >>714
＞発言権とか議決権とかはあるのか？
人工知能研究は何とか大学で何とか言う学位を得たとかいう専門家達の小難しい数式ではなく、
こうした何気ない日常生活の中から何かを発見していくことのほうが大切と思われる。
↓
485 デフォルトの名無しさん 2018/03/24(土) 22:53:15.70 ID:6mZ6T11K
（第1章 はじめに 2頁）
たとえば、CycはFredという名前の男が朝にひげをそるという話が理解できなかった。
Cycの推論エンジンは、この話の中に矛盾を見つけた。Cycは人間には電気の部品がないことは知っているが、
Fredが電気カミソリを持っていたので、エンティティ「Fredがひげそり中(FredWhileShaving)」
には電気の部品が含まれていると考えた。したがって、CycはFredがひげをそっている間、
Fredはそれでも人間なのかと尋ねた。
『深層学習』
著者:
Ian Goodfellow, イアングッドフェロー,
Yoshua Bengio, ヨシュアベンジオ,
Aaron Courville, アーロンカービル >>718
「日本語の動詞の活用は、
末尾の音との対応によって決まる」
んだが、しょっちゅう使う動詞に関しては、
この対応関係が崩れることがある、という
話をした。
いわゆる「サ変（する）」「カ変（「来る」）」は
知られているが、それ以外に「言う」「行く」と、
「乞う」「問う」は、その原則から外れていると
いうのを、実際のテキストデータ（コーパス）を
コンピュータによって篩にかけて実証したんだが、
侮辱されただけで終わった。
> こうした何気ない日常生活の中から何かを
> 発見していくことのほうが大切と思われる。
たしかに大切だと思うのだが、それが学会で
評価されると信じるのは、「いつか王子様が」
みたいなファンタジーでしかない。 「創傷熱や産褥熱は、医者や看護師の手を
介在して感染するので、医療行為を行う人間は
よく手を洗え」と主張したイグナーツ・ゼンメルワイスは、
精神病院に収容されたあげく、看護人に殴られて
死んだ。
世の中はそんなもんだ。過去にではなく、
現在もだ。 あんたの考えてることが他人に説明できないなら戯言でしかない
それすらできないくせに歴史的英雄に自分を重ねてこんなとこで自慰をするのは無様で恥知らずとしか言いようがない
人工知能学会でも自然言語処理学会でもいいから論文を出せ
日本でダメなら国際会議で訴えろ
甘利ににらまれた金谷は国際会議で訴えた >>721
＞こんなとこで自慰をするのは
ところでだ。「チンボがシコシコする」という日本語表現は、文法的に正しいのか？
チンボ「を」シコシコするのではなくて、チンボ「が」シコシコする。この場合、「チンボ」は主語となる。
オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンボ）が繋がっている場合と、
全体（俺）と部分（チンボ）が別々になっている場合とが考えられる。けれども「チンボ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
違うか？
「頭がズキズキする」は良いが、「チンボがシコシコする」はダメな理由を、５０字以内で述べろ！>>98 人間発見国立情報学研究所教授 新井紀子さん ＡＩ時代を生き抜く力(3)
ttps://www.nikkei.com/article/DGKKZO33940070Y8A800C1EAC000/
娘の身を案じ猛反対する両親を押し切って米国へ留学。大学院に進んだが教官のセクハラに遭い、一度は研究者の道をあきらめ
かけた。
１年後には帰国して就職か結婚をする、と約束し、ようやく両親に留学の許可をもらいました。大学４年の1984年７月に日本を出発、
数学基礎論が盛んだったイリノイ大学に入学しました。イリノイ大は１年で卒業。卒業時に優秀賞をとり、奨学金を得たので大学院に
進学しました。
ところが大学院では指導教官からのセクハラに遭い、つらい日々を過ごしました。遠距離結婚して間もない夫も心配して米国に来て
くれましたが、セクハラが止むことがなく、学内で訴えを起こしました。当時は米国でもようやくセクハラへの関心が高まり始めたばかり。
当時は米国でもようやくセクハラへの関心が高まり始めたばかり。学内規則が不十分だったこともあり、決着をつけることはできず、
博士号をとれずに失意のまま帰国することになりました。
帰国後、娘が生まれたこともあり、一度は家庭に入って専業主婦になろうと考えました。今も研究を続けているのは、このとき夫が
「あきらめるな」と励ましてくれたからです。広島市立大学に情報科学部が新設されることを知った夫は、応募してはどうかと勧めて
くれました。「もう一度やってみよう」とタイプライターを買い込んで論文を書き始め、一橋大の先生方のサポートもいただいて完成。
助手に採用されました。 >>772
構文的には正しいが、運用論的には疑問がある。
【解説】
「目がシパシパする」は構文的に正しいので、
「チンポがシコシコする」も構文的に間違っているとは
いえない。「麺がシコシコしている」は運用論的に
正しいが、語彙的に「シコシコする」が一般的な
用法に含まれているか、には疑問の余地がある。 >>721
> あんたの考えてることが他人に説明できないなら
説明して理解できる奴が日本中探しても おそらく十人以下だ（笑）
> 歴史的英雄に自分を重ねて
ゼンメルワイスは説が入れられず不遇のうちに生涯を終えた。
看護師でもゼンメルワイスの名前を知らない奴が多い。
> 人工知能学会でも自然言語処理学会でもいいから論文を出せ
記述文法をやってる奴がそもそもいない。
> 日本でダメなら国際会議で訴えろ
膠着語の記述文法は欧米人に理解できるとも思わん。
そんなわけで実装して製品化を試みたが、
ある会社は会社が分裂してプロジェクトが頓挫、
ある会社は業績が悪化してプロジェクトから撤退、
ある会社は不正経理のせいで他の会社に乗っ取られて
プロジェクトが消滅、
ある会社は資金がショートしてチーム解散、
ある会社は別プロジェクトが大手の企画と
バッティングして経営難になり、チームのメンバーが
逃走、
その他もろもろあって、「呪われたシステム」と
謂われている。 n バイトの文字列に対して、 n バイト以下のコードから
なる単語辞書を用いて、「すべての部分文字列に対する
辞書引き（これを、直積検索：ダイレクト・プロダクション
検索、または全件検索という）」を行なうことを考える。
このとき、最悪の場合でも n^2 + n の手間しかからない
アルゴリズムが存在する。
もちろん、バイト単位で考えれば 256 分木で表現すれば
いいのだが、それをやるとデータがやたらに大きくなる
（スペースファクターが悪い）ので、これを圧縮して
（木の末端部はスパースなので、重ならないように格納
する工夫の余地がある）一次元配列に押しこむことを考える。
有名なものとしては Google が使っているダブル配列法が
あるが、その原形であるトリプル配列法のほうが、マルチ
バイト文字を考えると、かえってスペースファクターが
向上するケースがあることがわかっている。 一次元配列の要素は、
バイアス、アドレス、データ識別子である。
ここで、添字０を起点としよう。バイアスとアドレスは
添字であるとする。（なお、以下の方法にはバリエーションが
あるが、ここではもっとも素朴な例を示す）
ある添字 X が、文字列のどこか（たとえば、元文字列のどこか
にある “ab”）のどこかを指しているとする。
そのとき、次の文字 c が続く文字列 “abc” が辞書にあるか
どうかを調べるとき、X+c 要素のバイアスが c に等しいかを
見る。これは、X+c が X を指しているということなので、
データ識別子の先に語彙データが存在する（もちろん “abcd” が
辞書にあって "abc" がないこともあるので、そこはチェックが
必要だ）。さらに、その先を探すためには、要素 X+c のアドレス
部を見る。その値がアドレスで無意味だったら、その先に続く
文字列は辞書にない、ということになる。 辞書引きは一応片付いたことにして、次は形態素解析だ。
語彙の部分には、品詞の分類というものがある。ただ、
これがなかなかの難物なのだ。
たとえば日本人なら、日本語の動詞をそのまんま
書いて「動詞」と書いておけば辞書として役に立つ。
ただ、外国人やコンピュータ様は動詞の語幹部分を
別々の形態素として辞書登録しておいて、辞書引きが
終わった段階でパーツを組み立てて「これはどういう
品詞のナニナニ形だ」と提示しなければならない。
するってぇと、たとえば「書かされたがらなかった」
はどうなるかというと「動詞・書k+使役・as＋
受動・aれ＋欲求・た＋表出・が＋否定・なk＋
過去または完了・aった」と、別々の品詞として
辞書登録しておかなければならなくなる。
「こんなんやっとれるかぁ！」と怒りだす奴が
いそうだが、これは辞書を「形態素（＝名前のない
形態素）」の辞書と「品詞（＝名前のある形態素）」に
分けて、前者は「開始点の文法属性＋マッチング文字列＋
終点の文法属性」として管理し、後者は「品詞＋辞書登録形」
で辞書かしておいて、適当なツールで「開始点の文法属性＋
マッチング文字列＋終点の文法属性」に変換してやる（もちろん、
マッチングに不必要な活用語尾は取り去る）という操作を
行なうわけだ。
これによって、解析開始点から「解析開始点の属性」→
「開始点属性」→「マッチング文字列」→「終点属性」ときて、
ここから次々と「終点属性」を「開始点属性」とみて
探索を行なってゆけば、自動的に形態素解析が行なえてしまう、
ということになる。
なお、単なる「かな漢字変換」レベルの処理だったら、
これだけで市販の IME が吹っ飛ぶくらいの威力のある
変換システムができあがる。もちろん、候補の優先度とかいった
塩梅は必要ではあるのだが。 この処理系の実装にあたっては、再帰を使って
木探索（ツリー・リトリーブ）で書くのが簡単だが、
それでは面白みに欠ける。
「どの点のどの開始属性から探索する」という
タスクを何らかのデータ構造（C なら構造体、
Java ならオブジェクト）の形で表現しておいて、
データプール（コンテナ）に放り込み、
一個取り出しては探索処理を行なって、
次の探索店をまたデータプールに突っ込む、
ということをする。
これがスタックだと深さ優先探索、
これがキューだと幅優先探索になるので、
プッシュとポップを工夫するだけで、
探索戦略を切り替えることができる。
こういう手法を「チャート法」といい、
構文解析（形態素解析ではなく、だ）の
分野ではよく知られた手法だ。
なお、この手法、ビットマップ上の
領域の塗りつぶしや迷路探索にも
使える。横溝正史の『八つ墓村』に、
金田一耕助がチャート法を使って
巨大洞穴を探索する場面が出てくる。 >>729 の話は、要するに「文法属性の始めと終わりを
マッチング文字列で橋渡しする」ことで文法定義を
しちゃって、チャート法の解析エンジンだけで処理を
片づけるという、無精ったらしいことをしているわけだ。
このとき、「マッチング文字列がヌルストリングのとき、
うっかり循環参照かなんかを作りこんじゃったら
無限ループに陥っちゃうだろうが！」という
話になる。
文法そのものがそんなに大袈裟なものじゃない（二千行あれば、
充分書ける）ので、あんまり気にしなくていいのだが、
それでもチェックは入れておいたほうがいい。 >>731
これには二つの方策があって、
１）実行前に、スクリプトから実行形式にコンバートするときに、
チェックして対処する。
２）実行時に、同じ位置に同じ文法属性が来たら、そこでハネる。
のどっちか、という話になって、（１）は実行時のオーバーヘッドが
なく、（２）は実行時のチェックのためのオーバーヘッドが生じる。
これはどっちでもよさそうだが、どのみち「辞書と文法を区別しない」の
で、（１）で工夫はするとして、いちおう（２）の機能も組込んで
おくのが安全。 >>732 については、一度、大騒ぎしたことがある。
「書いてる」は「書いている」の省略形なので、
「『いる』の語幹『い』の省略」と記述したら、
困ったことに「連用形の現在」が、語幹と一致する
「い」だったのだな。
「お持ち帰り」のように、連用形は連用形に接続するので、
「書いてる」が「書いて（ここに「い」が無限個省略されて
いる）る」と解析されて、いきなりスタックオーバーフロー（笑）。
さんざん解析に手間取ったあげく、「ている」「でいる」の
「てい」「でい」をそれぞれ形態素として登録して逃げた。
このあたり、「どう処理するのが本当か」という話はあるのだが、
>>1 で
> 言語学の話題などは他のスレッドでお願いします。
と言われているので、このスレでの議論は避けることにする。 とりあえず、>>1 で
> このスレッドでは、「日本語の構文解析・談話理解・情報検索・
> 文章生成」などの技術に関する理論と(おもに)実装を扱います。
> あくまで、「アプリケーション・プログラミング」の
> 技術的な面に重点をおきたい
というコトになっているんだが、よく見れば「形態素解析」と
いうのは「自然言語処理スレッド」からは排除されているんだよな。
そのあたりに関する、スレ民の意見は伺いたいと思う。 >>735
ありがとう。
実装は任せた。
ソースコードは
無償で提供する。
「束（そく。Latteice）から束への建艦」が、
一意に成立するかどうかが疑問だったのと、
それが、その程度効率的なのかについて、
充分なデータが揃っていなかったのだ。
どっかの大学（を含む研究機関）で、
マジメに検証してくれれば、
ありがたいと思う。 >>736
×「束（そく。Latteice）から束への建艦」が、
〇「束（そく。Lattice）から束への変換」が、
HyperLisp とかいった、ちょっと古い処理系を
知ってるんなら、説明も楽なんだけど、
有限束から説明すると、半順序構造とか、
いろいろ面倒臭い話があるので、
このスレではパスさせていただく。 形態素解析は隣接関係だけで
記述できるからいいのだが、
構文解析となると「係り受けの関係
（の非・交差則）」と「文法格の
一意性」っちゅーのがあるので、
処理がワンランク複雑になる。
そうなると冨田法みたいに
スタックが乱立する（スタックが
分岐するので、「カクタス・スタック」、
直訳すると「サボテンスタック」という）
ので非常にややこしく、プログラムを
書くのがややこしい。
BNF で記述して LALR 法かなんか使って
コードに落としこもうとしても、日本語は
省略が多いうえに語順が不定なんで
うまくいかない。
しかたがないので、「なんか分かりやすいシェーマは
ないのか？」と考えたところ、二次元の表を使うことを
思いついた。そうなると、コンピュータ将棋のプログラムが
応用できそう（他の駒の利き筋を通過できないから、
実際はもっと簡単）な感じがしている。 >>739
トリップつけても忘れるんだよな (-_-!)
そもそも、アルゴリズムとかシステム・デザインとかに関する
知的所有権は保護されないし、企業に所属していると
「トレード・シークレット（業務上の秘密）」とか言われて
民事訴訟とか起こされても対抗する手段がない。
原告側（訴えた側）に対抗するには、被告側（訴えられた側）が
証拠を出して反証しないといかんのだが、証拠はたいてい原告側が
握っている。被告側が訴訟に勝てば訴訟費用は取り戻せる
建前にはなっているが、原告側が払ってくれるとは限らないし、
そもそもが「被告側に経済的な負担を与えるために、
金をかけてでも訴訟を起こす（これを SLAPP 訴訟という）」
場合もある。企業は「法人」といって人格権があるので、
企業が原告になることができる。で、倒産しちゃえば「原告が
死亡」したことになるので、けっきょく裁判はチャラになって
しまうので、「計画倒産と SLAPP 訴訟がワンセットで
襲ってくる」みたいなコトも往々にしてある。
で、日本の司法機関は、知的所有権にかかわる訴訟を、あまり
扱ったことがないので、最高裁まで争ってもマトモな判決が
出る可能性は乏しく（企業が個人を訴えた場合、「企業のほうに
理がある」と頭から決めつけるケースが多い。企業には顧問弁護士が
ついてくるが、個人が対抗して弁護士を雇おうとしても、そういう訴訟に
慣れた弁護士はなかなか見つからない）、途中で和解に持ちこもうとして
裁判官がゴネるケースが多々ある。
青色 LED の中村修二さんは、「けっきょく、裁判費用で結果的に
足が出た」とボヤいていらっしゃった。 そんなワケで、トリップは遠慮しとく。
おれに用があったら、アスキーの西さんとか、
おなじく出版技術部の TEX を維持してるチームとか、
インプレスの井芹さんとか、アップルの元「ことえり」の
チームとか、メタボール・アルゴリズムで有名な大村 皓一さんとか、
そのあたりの人に「JAI-Perser の開発者の
S さんという人に心当たりはありませんか？」と訊いて
もらえば、住所氏名電話番号メールアドレスくらいは
解るはずだ。 >>741
もっとも、西さんは井芹さんと塚本さんがアスキーを
退社してインプレスを立ち上げたために、ソフトウェア
開発部門が解散してしまったために VJE-β のチームが
解散したとか、井芹さんは会社を立ち上げたばかりで
企業体力がなかったので訴訟を避けたかったとか、
出版技術部はアスキーとインプレスの両方と
関連があったので JAIP プロジェクトとは距離を
置かざるを得なかったとか、「ことえり」チームは
ジョブスが不在だった時期で日本市場に力を入れる
余力がなかったとか、大村 皓一さんは もんたよしのり
とのコラボに関わったら芸能関係の その筋の方々と
モメて行方をくらましていたとか、いろいろと
薄らぐらい事情もあったので、逃げ出すかもしれんが。
いちばん捕まえやすいのは、農工大の小谷善行さんかな？
でも、パズル懇話会のときに、NHK−BS の『パズルへの招待』
の件で話しかけようとしたら、「所長の顔を見るなり逃げ腰に
なっていた」という話を聞いたこともあるしなぁ（笑） 板違い（本来はム板ではなくてマ板の話題）であり、
スレ汚しでもあり（日本語処理そのものとは、あまり関係がない）、
ひとり語りになってしまう（けっこう長い話なので）のだが、
勘弁してくれい。
時は一九八十年代半ば、まだ代表番号の末尾が「１」だった
時代（電話交換機が、電子交換機ではなく、クロスバー交換機
であり、ステップ・バイ・ステップ交換機が残っていて、
電話回線がトーン回線だった頃）に、現在のファクシミリみたいに
音声回線でデータ通信を行なっていた時代の話である。
通信速度は、300 bps とか 600 bps とか 1200 bps とか 2400 bps
とかだった時代である。 当時、「草の根 BBS」という「アコースティック・モデム＋
音声回線」による電子掲示板が、ちょっとしたブームに
なっており、SONY からも BBS 電話が発売されたり、
アーサー・Ｃ・クラークの「二〇〇一年」の続編
にあたる「二〇一〇年」製作にあたって、原作者の
クラークと監督のピーター・ハイアムズがワープロを
使って交信していたり（『オデッセイ・ファイル
― アーサー・C・クラークのパソコン通信のすすめ』と
いう本になっている）していたので、うちの
所長は PC-98 とヘイズ規格の AT モデムを使って、
BBS のホストシステムを構築したそうだ。 MS-DOS はシングルタスクなので、回線が（不用意に）
切れたときの対処が難しい。しょうがないので
上のプログラムから下のプログラムを起動し、
回線が切れたら下のプログラムが落ちて上のプログラムに
制禦が戻る、という形になっていた。
そうしたら、所長の後輩の HASH くんが、「OS/9 は
マルチタスクですよ wwwww」と言って、FM-11／AD2+
と OS/9 を使って BBS のホストシステムを作ってしまった。
のちに、ANA かなんかが同じ構成で航空券の予約システムを
構築したらしいが、関連があるのかどうかは知らない。 時は移って大喪の礼の当日である。
世の中が静まり返っている休日だが、
同じころに「マンガの神様」である手塚治虫
さんも亡くなっていた。そこで、ネットで
知りあったHASH くんを交えたハッカー四人が
「手塚アニメ追悼上映会をしよう」というので、
HASH くん宅に集まった。
そのとき、『ToolBox 100 の定跡』の小池 邦人さんが
そこに加わっていた。 じつは、そのとき小池さんがそこにいたと
いうことを、所長はすっからかんに忘れて
おり、後にそれを小池さんに言われて大いに
狼狽した、という話を聞いている。
で、「Mac の ToolBox には、ISAM
（順編成索引つきファイル）が入っている」
という話があったらしい。その話は所長も
憶えていないという。
このあたりから、自然言語処理の話になる。 当時、Macintosh は高価だった。そんなわけで、
グァム島とかハワイとかに、観光ついでの
Mac 買い出しツアーとかがあった。
ところが、問題なのは、マニュアルが英語で
あることのである。電子データでそれなりの
情報は入ってくるのだが、困ったことに、
専門用語交じりなのである。
This is a Pen とか I have an apple. なら
分かるのだが、コンピュータ関係の専門用語は、
そこいらの辞書には載っていないのだ。
しかも、辞書を引くのはめんどくさい。
「コンピュータ関係の専門語だけでも
辞書引きをやってくれるような、
お手軽なシステムはないのか？」
という話になった。 「なんとかならんか？」
「簡単だよ。ISAM 載ってんだろ？」
「だって、ISAM は完全一致だろう？
語尾が変化したら一致しないんじゃないか？」
「変化しそうな部分を取っちゃってから
検索すればいい。坂井 利之先生の
『翻訳するコンピュタ ー 情報革命と
語学の壁に挑む』（講談社ブルーバックス）に
書いてある」
「だけど、一致しても、複数の候補がヒット
しちゃうだろう」
「大した数じゃねぇから、一個一個チェックすりゃあいい」 「…… だけど、末尾から語尾を削ったら
本体がなくなっちゃったらどうする？」
「ヌルストリングはキーにならないのか？」
「― なるな。じゃあ、そういうプログラム書けるか？」
「書こうか？」
というので、辞書引きツール “rStone” というツールがで
きた。最初は「ロゼッタ・ストーン」という名前にしたのだが、
なんか商標登録の関係で引っかかった、という。 rStone は、“BeerWare” として配布された。
「使って、気にいったらビール券を送ってこい」。
そうしたら、ユーザから、「正式に製品化して
サポートしてくれ」という話になった。
当時は知的所有権関係の法整備が進んでいなかったので、
しょうがないから、当時勤務していた企業から
製品としてリリースすることになった。 rStone は、売れた。
そうしたら、会社が「英和があるんなら、
和英が欲しくなるよな？」と言いだして、
たしか四か月くらいかけて、「日本語の
形態素解析システムを搭載した、日本語の
漢字かな交じり文／かな表記文両用の
辞書引きシステム」を開発した。
このあたりの話は面白いんだが、長くなるので省略。
あっちゃこっちゃに書いているので、たぶん
自然言語処理をやってる人間なら知ってると
思う。 この、「rStone 和英版」（rStone-JE）は、
C 言語で記述されていて、中身は再帰呼び出し
を使った木探索プログラムだった。
これが非常にめんどくさい。人工知能システムでいう
プロダクション・システムで、IF 〜 THEN 〜 ELSE が
延々と続く砂漠のようなコードであり、しかも相互に
影響しあっているので、メンテナンスが大変なんである。
そういうわけで、「こんなんやっとれるかぁ！」と
所長がキレた。 で、「文法記述用のスクリプト言語」
「プロダクション・システム駆動用の
チャート法エンジン」
「辞書管理用のツール群」
を統合したシステムをインプリメントした。
このあたりから、アスキーの VJE-Pen の
開発チームおよび出版技術部の TEX 維持チーム、
それにアップルコンピュータ・ジャパンの
「ことえり」開発チームとのコラボレーションが
始まった。
こっから先は、商売がらみのすったもんだの
話になるので、本スレの趣旨に合わない。
そんなわけで、この件はここで終わり。
辞書管理の労苦とか、形態素解析システムと
構文解析システムとの統合、みたいな技術的な
話は、興味があったら随時質問してくれ。 要らない
個人ブログでやって
産廃みたいな話しかできないみたいだから ここで、自然言語処理における
形態素解析システムについて、
あらためて考えよう。
「日本語の（構文文法未満の）文法は
｛始点属性、マッチング文字列、終点属性｝という
三つ組みデータで記述できて、チャート法によって
処理できる」ということが謂える。
で、ここから「日本語でなくても、同じことができる」
が謂える。
つまり、「同じシステムで、ローマ字かな変換も
できてしまう」。数学者の島内 剛一先生による
ローマ字かな変換は、そのまんま記述可能で、
あっさり動いた。 つぎに、「経路探索ができる」というのも指摘しておこう。
共立出版のコンピュータ・サイエンス専門誌『bit』の
『ナノピコ教室』に「十三階段への道」という問題が出た。
十三階段を上るのに、「一歩で一段」「一段抜かしをして、
一歩で二段」「二段抜かしをして、一歩で三段」の三通りの
やりかたがある場合に、「十三段を上がるのに、何通りの
やりかたがあるか、という問題である。
この問題は、要するに、“*”、“**”、“***” という単語が
あったとして、"*************" は何通りの表し方が
あるか、という問題に帰着する。「すもももももももものうち」
を「李（すもも）」「桃（もも）」「酢（す）」「藻（も）」
「も（助詞）」「の（助詞）」「内（うち）」で表すやりかたの
候補を全部挙げろ、と言ってるのと同じことなのだから。 「かな漢字変換システムは間に合っているし、
パズルにも興味がない」という人は多いだろう。
とはいえ、このスレは自然言語処理スレッドなのである。
そうすると、当然のように辞書は使ってるよな？
で、その辞書は たいていテキストの形で持ってるよな？
（中には「ＤＢに入れてる」という人もいるだろうが、
出力することくらいあるだろうから同じだ）
そのとき、順番はどうなるか。単語とえば読みがなの順で
出力したいときに、どうやって整列させたらいいのか。 このとき、読みがなをキーにして単純に整列してしまうと、
うまくない。文字コードの大小で整列すると、普通の
紙の辞書の見出し語順にならない。
「蚊」「蛾」「梶田」「鹿島」が「か」「かしま」
「が」「かじた」の順になる。こうなると、データと
紙の辞書を突き合わせるのが非常にめんどくさい。
そうなると、「辞書順にソートするのに必要な比較関数」
（要するにコンパレータ）を書きゃあいいじゃねぇか、
という話になりそうだが、実際にやると大抵失敗する。
順序関係が循環して、整列が終わらなくなる。
じゃあ、どうするか、だ。 >>755
今は形態素解析って
ライブラリで済ませちゃうからな
その先が知りたい 辞書を出版している出版社や、ビジネスソフト
（顧客名とかでソートすることだってあるだろう）を
開発している会社ではどうやっているのか、といえば、
「読みがなから、整列用のキー文字列を生成する」
という手法を用いている。このキー文字列で辞書順
整列ができてしまう。
このとき、生成する文字列はふたつ。ＡとＢを
生成したとして、Ａのあとに読み仮名のコードよりも
小さい文字をくっつけて、Ｂにくっつける。なお、
Shift-JIS と UNICODE では、かなと記号の
位置関係が違うので、注意すること。
で、この「整列用のキー」の生成に、やっぱり
先の形態素解析エンジンが使えてしまう。
JUMANだの茶筅だのといった
形態素解析システムを使っていても、この手の汎用の
ツールはひとつ持っておくと便利だ。 >>760
「その先」っていうと、
形態素解析の応用面（論文の内容の比較とか
著者の推定とか）とか実際の成果（今までに
どんな結果を出したか）とか？
でなかったら、そのベースになるシソーラスの
構築のしかたとか？
それとも構文解析とか意味表現とか？
いろいろあるけど、どっから始める？
「他のアプリケーションとの連携はどうする？」
とか言われると、「そこいらは相手先との関係を
どうするか」とかいった生臭い話も絡んできて
このスレの趣旨と外れちゃいそうだから
どこまで書けるかわからんが (^_^!)。 >>762
釈迦に説法かもしれないけど大きく分けると解析は
形態素解析、構文解析、意味解析、文脈解析が四つで
そのうち形態素と構文は方法論が固まって来てるけど
意味と文脈の解析が難しいとよく言われているよね
そこで意味解析と文脈解析の方向性が知りたいな
あと解析の話は多いけど文生成の話が少ないので
単に逆の処理するだけでもないだろうし生成の話も >>763
> 意味解析と文脈解析の方向性が知りたいな
了解した。たしかにそのあたりは急所だ。
まず、「文章」の基本要素は「文」だ、というのを
納得してもらおうと思う。
英語（英文法）だと「単文」「複文」という区別があって、
「動詞」が文の中核にある、というのが常識として
通用しているけれど、日本語（日本の国語教育）の場合、
その部分が強調されることって、あんまりないでしょ？
おそらく、それが英作文や英文和訳のときの大きな
壁になっていると思うんだ。
だけど、日本語においても（というか、おそらくは
世界中の言語で）、言語表現・意味における中核は
「文」あるいは「述語（動詞、形容詞、コピュラ）」
なんだと思う。 ちょっと余談になるけど、「カタストロフィ理論」で
有名な数学者のルネ・トムという人は、この「述語（verb）」
のことを「原始文章」と呼んでいて、そこからさらに踏み込んで
「初等カタストロフィ集合に “切断” という操作を行なうことで、
原始文章のタイプ分けができる」とまで言ってる。で、日本の
自然言語処理の草分けである長尾真先生が、論文のタイトルの
構文構造を型分けしていったら、やっぱり十いくつかの型に
分類できちゃった、ということを仰っている。 で、「文」というのは、化学における「原子」に
相当するものと考えると都合がいい（「文法」は
形のあるもんじゃないから、脳味噌を引っ搔き
まわしても出てこないので、「（実用的な意味で）
都合がいい」としか謂えない）。
この「文」の中には「述語」が一個だけあって、
この述語から見た「体言（「もの」というか「存在」というか）
の関係」というのが、「格（文法格）」だと考える。
たとえば、述語「食べる」は少なくとも「誰が」と「何を」と
いう格を “要求” する。 この、「述語が要求する格」は複数あるわけだが、
それぞれの格の対象は、それぞれ１つしかない。
難しくいうと、「述語は格を一意に要求する」。
「私はラーメンを餃子を食べた」は「何を」が二個あるから
文法的に正しくなくて、「私は “ラーメンと餃子” を食べた」は
「何を≡｛ラーメン＆餃子｝」だから文法的に正しい、とかいった
話になる。 複数の文が、格を付与された体言を共有することで、
結合することがある。これは化学でいう共有結合
みたいなもので、その結果として「分子」にあたる
「複文」ができる。
「俺が頼んだラーメンを食った奴は誰だ？」は、
「俺」が主語である述語「頼む」と「誰か」が主語である
述語「食う」が、体言「ラーメン」を介して結合したものと
考えられる。 こうしてできた文（単文あるいは複文）を
接続詞によって繋げてできたものが「文章」で
あり、「文がどのように繋げられているか」
が「文脈」になる。
「ラーメンは食べるが、餃子は食べない」は
「ラーメンは食べる。しかし餃子は食べない」と
同義であり、その関連を示すのが「が」「しかし」
であるという解釈である。
日本語には「のに」「ので」「にもかかわらず」
「けれども」など、いろいろな「接続助詞」「接続語」
があるが、文単位の形態素解析ができれば、与えられた
コーパスデータから、自動的に抽出できる。
同時に、接続助詞や接続語が出てきたら、そこで文が
区切られているので、述語と格の関係はそこで切れて
いるとみなせる。
ただし、この場合後の文には省略がある場合が多いので、
その部分を補う必要がある。
「僕はタケノコは食べられるが、シイタケは食べられない」は
「僕はタケノコは食べられるが、（僕は）シイタケは
食べられない」の省略表現だと考えないと、構文解析処理が
と文脈解析処理がこんがらかって、ややこしい話になる。 >>763
> 文生成の話
文生成の場合は、
「〔引き続く動詞が要求する格を持った体言列（助詞つき）〕
＋〔動詞（連体形）〕〔まだ使ってない格を持った体言〕」
の形で接続してゆけば文（単文または複文）が生成できて、
〔前置詞〕＋〔文〕＋〔終助詞〕とするか、
〔前置詞〕＋〔文〕＋〔接続助詞〕＋〔文〕…… と
するとかして（同時に前置詞のかわりに接続詞を
使うとかして）、文を生成してゆくと、一応の文生成はできる。
ただし、時刻とか場所とか方法とかといった「格を持たない体言」
（これを、個人的に「相」と呼んでいる）とか、「さっぱり」「めっきり」
のような連用修飾詞（動詞・形容詞の連用形もここに含めちゃっていい）
とかも適宜織り交ぜると、より「それっぽい」文章が生成できる。 >>770
日暮しマシンに向かい、頭に思いつく文生成プログラムを
夢中になって書き作り動作させれば、怪しうこそ もの
狂おしくなって、「馬鹿だ。こいつ馬鹿だ」とマシンを指さして
ゲラゲラ笑うプログラマこそ哀れなり。
橋田浩一さんとか松原仁さんとか筒井康隆さんとかは、
こういうの好きなんだよな。 これは自然言語処理というより国語学や
言語学に類する話題なのでスレチなのだが、
日本語処理の応用に関わってくるのでコメ
しておく。
たとえば「激しい雨」と「激しく降る雨」と
「豪雨」は同義だが、「降る」という述語が
出てくる場合と出てこない場合があるということを
どう解釈するか、という話がある。述語があると
ないでは、データ構造のレベルで違う、という
話になるからだ。
また「両国橋を渡る」「隅田川を渡る」「広小路から
向こう両国に渡る」は物理的な解釈としては同一
なので同義であるとみなせる（こういう立場を
外延主義という）が、「それって本当に“意味”って
謂えるのか？」という指摘が坂井寿秀先生などに
よって指摘されている。つまり、「明けの明星」も
「宵の明星」も実体（外延）としては「金星」なの
だから、「明けの明星は金星である」と「金星は明けの
明星である」と同義（単なるトートロジー）という話に
なるわけだが、そうすると「明けの明星は宵の明星
である」もまた同義ということになり、「それって
変じゃねぇか？」ってな話になる。 坂井先生は、「外延的な形容詞」というものが
あるのではないか、という指摘もなさっている。
「その馬は白い」「馬は哺乳動物である」から
「その哺乳動物は白い」を推論するのは妥当である。
ところが「その鼠は大きい」から「その鼠は
大きい哺乳動物である」を推論するのは妥当ではないし、
「その象は小さい」から「その象は小さい哺乳動物である」を
推論するのも妥当ではない。
したがって、「白い」と「大きい」は、別種類の形容詞と
考えざるをえない、という指摘である。 で、こういう基本的な部分をうっちゃったまま、
適当なコーパスをありもののライブラリで
形態素解析し、その結果を
ありものの統計処理パッケージでいじくって、
自然言語処理がどうのこうのとか
日本語処理がどうのこうのとか
偉そうに言っている自称・研究者を見ると
顔面を二三発張ってやるのも功徳では
ないだろうかと思う、と所長に言ったら、
「手が汚れるし、怪我をされても面倒だから、
尻でも蹴飛ばしてやったほうがいい」と
真顔で言われた。 鬱憤が溜まっているので剣呑な話になってしまった。すまんm(_ _)m
>>773 の形容詞の区分についてだが、おそらく形容詞
のみならず連体修飾詞全般にいえるのは、連体修飾詞には
「集合から部分集合を切り取る」という作用があるのでは
ないか、ということだ。すなわち、「大きい」は、いま目の前に
ある対象としての集合から、「大きいものの集合」を切り取る作用が
あるのではないか、ということだ。
鼠集合から切り取られた集合と、哺乳動物から切り取られた集合は
異なっているので、「大きい鼠は、必ずしも大きい哺乳動物だとは
謂えない」。
また、その「切り取る」操作が、「切り取られる対象」によって
規定されるということも指摘しておきたい。
「赤いミカンは赤い」し「赤いリンゴは赤い」のだが、
赤いミカンは蜜柑色だし、赤いリンゴは普通に赤い。
この場合、「未熟な⇔完熟した」という評価の軸との
関連において評価する必要がある。 「もの」という言葉が出たついでに言っておくと、
ここでいう「もの」は“individual”、すなわち「不可分なもの。
個人、個体、個物」を意味する。れっきとした哲学用語だ。
ただし、これは「物理的な存在」ではなく、「概念」を
指していて、しかも「具体的な意味」「内包的な意味」を
持たない。その意味で、individual は「意味を引っ掛ける釘」の
ようなもので、「こっちの釘とあっちの釘は、どこがどう違うと
言われても説明できない。ただ、引っかかっている意味が違うし、
比較によって区別できる」ものである。
同じような性質をもった存在として、Codd のデータベース理論における
データベース・キーというものがある。 individual の訳語としては、「もの」が使われることが
ままある。馬場あき子『鬼の研究』によれば、「鬼」
には「もの」の訓があるという。意味としては「物
狂おしい」「もののけ」の「もの」に相当する。
そんなわけで、自然言語処理の研究者の間では、「仮にこっちの
“もの”を『白うるり』とします。で、こっちの“もの”を
『ももんがぁ』とします」「その場合、二つの存在の関係と
『ひょうすべ』と『ぬらりひょん』の関係が相同であるとすると、
その意味の差を求めるためには、どの程度の計算量が見込まれるか、
という話になりますよね？」みたいな議論が真顔で行われる、
ということになる。 >>777
このあたりの議論は、すでにルイス・キャロルが
『論理ゲーム』（『不思議の国の論理学』に収録）の
中でおこなっている。「念を押すが、筆者は前提が
“事実”であると保証してはいない。だいいち、
筆者はドラゴンを見たことはない。（中略）われわれの
義務はただ、前提が“論理的に結論につながるかどうか”を
理解することのみであり、したがって、かりに前提が真
ならば結論もまた真だということになるだろう」。 日本語の細かい文法ルールにお詳しいみたいだけど、「そもそも日本語に文法などあるのか?」と思わざるを得ない
10〜20代の若い連中がTwitterで書き散らしてるような文章はそれ自体「新しい言語現象(文法)」であって、仮に「これが正しい日本語文法でござい」とルールベースのエンジンを作り上げたところで、どんどん出てくる新しい文法には無力だと思うわけだが。
そこについてどう考えているの? 日がな一日Twitterを監視して新しいルールを追加し続けるのか? それってあんたが >>753 で書いた「こんなんやっとれるかぁ！」的な作業と何が違うんだ?
それがわかったからこそ、個別のルールに固執することはやめて、みんな「形態素解析の結果をありものの統計処理パッケージでいじく」るようになったんでしょ。
そのほうが精度も高いし。 >>779
> どんどん出てくる新しい文法には無力だと思うわけだが。
日本語は、古事記・日本書紀の時代から千年以上使われており、
しかも南北に長いので、沖縄首里方言と標準語の間には、
英語とドイツ語くらいの差（だいたい千五百年くらい）の
距離がある。薩摩弁と津軽弁もそのくらいの差があり、
平安時代の文芸と、現在の東京弁もそのくらいの距離がある。
だけど、それは全部ひっくるめて「日本語」なんだよ。
で、日本語を日本語たらしめているのは、「日本語の文法」なんだ。
だから、「およそ日本語であるならば、時代だろうが地域だろうが、
全部ひっくるめて処理してやろーじゃねぇか！」っつーんで開発
されたのが JAI-Parser なんだ。
千年ちょっとの些末なバリエーションなんぞは、
スクリプトと辞書で吸収できるんだよ。ふん。 コンピュータ・サイエンス誌『bit』（共立出版）、
一九九二年十二月号、p.52
『汎用日本語解析系の試作 ― 形態素解析コンパイラ・コンパイラの
試作をめぐって』を読んでくれたまえ。
「よろしい、何とかしましょう。それも、個別にではなく全部まとめて
面倒をみましょう。かな漢字変換も、漢字かな交じり文の解析も、
現代文も文語も方言も、ひっくるめて処理してみせようではありませんか。」
と、大見得を切っちゃった（つーか、実装しちゃった）んで、現在の
ようなコトになっとるわけだ。
当時のシステムはフツーの C 言語で実装されていたので、
メモリリークやらワイルドポインタの都合で動作が不安定
だった（Mac の C は、文字列がハンドル表現だったので、
なんとか実アプリとして安定動作してた）のだが、
二十一世紀に入ってから（山之内製薬と藤沢薬品工業が
合併して、アステラス製薬になるちょっと前ごろ） Java に
移植したらサーバ上で安定動作するところまで持ってゆけた。 なお、日本語の文法には、三回ほど大激震が走って
いるのが確認されています。
一回めは、上代特殊仮名遣が用いられなくなって、
母音の数が減っちゃったこと。
二回めは、動詞の末尾音として使われていた h 音が
消失して、新たに a・o・u 音が採用されたために、
動詞の活用と指標音の対応が崩れちゃったこと。
三回めは、動詞・形容詞の終止形が廃れてしまって、
「連体形の終止用法」が定着しちゃったこと。
一回めの変化は、大野 晋先生のお師匠さんである
橋本進吉先生によって発見されました。
で、JAI-Parser を使って二回めと三回めの変化を発見・
検証したのは、うちらだょ〜ん。 >>779
今カラデモ遲クナイカラ原隊ヘ歸レ
オ前達ノ父母兄弟ハ國賊トナルノデ皆泣イテオルゾ >>484
> 八重山
そっちは 5.15
こっちは 2.26 >>769
御説拝聴したので私の所見も述べるよ
＞「文がどのように繋げられているか」が「文脈」になる
自然言語（日本語）の「文脈」には
引用のように言語処理の文脈で使われる
「文の組み合わせ」の意味のほかに
「文章外の情報」がある
＞構文解析処理がと文脈解析処理がこんがらかって、ややこしい話になる
ただ本当は、この文章外の情報も取り込んだ上で
解析する必要があるのだと私は思う
人間は自然にそうしてるから
しかしソレをやり出すと人間の常識には際限がないので
フレーム問題のようなものに突き当たって
頓挫してしまったのが昔のAIブーム（の挫折）だと捉えている
そしてそれを打開するには新しい流行の機械学習と結びつけて
自動的に人間の知識を学習させて
人間が自然に持っている常識を身につけさせる必要があると私は考える >>770
＞文を生成してゆくと、一応の文生成はできる
＞適宜織り交ぜると、より「それっぽい」文章が生成できる
文章解析の意味解析と文脈解析の難しさは
文章生成にも必ず出てくるはず
文法通りに生成するだけで
意味は「それっぽい」だけの文章というのに
私はすごく不満を抱いている
>>771
つまるところ現在の大半の文生成とは
意味が分からないままランダムに言葉を組み合わせる
人工無能のレベルにあって
それを人間があえて意味を解釈する面白さはあるにせよ
やはり人工知能としてはもの足りない
人工知能としての自然言語処理を目指すのであれば
まず表現すべき意味や文脈もしくは意図を持っていて
それに沿った表現を組み立てていくべきだと私は考える
しかし意味や文脈にはさっきと同じフレーム問題のような
袋小路が待ち受けているのでやはり機械学習の
ブレイクスルーなど何か画期的な解決の糸口は必要だろう 構文解析をやっていると、「やっぱり文法や形態素解析の知識は
必要だな」と思う。
「なぜ」が連用修飾詞であるとか、「ません」が連体修飾詞で
あるとかいった視点がないと、構文解析の結果が交差してしまって、
支離滅裂になる。 >>787
すまん (^_^!) そういう意味での「文脈」に
ついては、その処理に至る以前に
超えなきゃいけない壁があって前に進めない。
言語はそもそも時系列の発話なり表記なりが
ベースになっているので、「通信」としての
性格がある。したがって、「速度」と「信頼性」の
両方に配慮する必要がある。
大野晋先生が『日本語の文法を考える』で述べて
いらっしゃるように「未知のことだけを伝えれば足りる」
ので、そこに「省略」が生まれる。ただ、その前提として
「相手にとって何が既知で、何が未知か」ということを
「理解」していなくてはいけない。そのため「省略」と
「理解」は不可分なので、扱いが難しい。 それに対して、「精度」を上げることはそれほど難しくなく、
語彙的な対応によって対処できる。
看護師が「清拭（せいしょく）」を「せいしき」と言うのは
生理的食塩水（生食：ナマショクではなくセイショク）と
間違えないためだ、という。
また、早稲田大学の竹本先生は能の作者推定に取り組んで
いらっしゃったが、「枕詞」の選び方に作者の個性が
出るとおっしゃっていた。「あしびきの」⇒「長い」、
「たらちねの」⇒「母」のように、「前振りをすることで、
意味を取りちがえないようにする」というのが枕詞の
機能だ。
ただ、「速度」と「精度」の間にはトレードオフの
関係があるので、そこにも困難がある。 これとは別に、「制禦」「意図」という
視点がある。なぜシステム間で通信が
行なわれるのかというと、話者システムが
聞き手システムを、情報を伝えることで
制禦したいという意図があるからだ。
その制禦のための通信プロトコルが
文法だということになる。
この意図のありかたも、「学ぶ」
「命令する」「交渉する」といろいろ
あるので、それをどう扱うか、という
課題もある。 そんなわけで、
>>788
> 意味や文脈にはさっきと同じフレーム問題のような
> 袋小路が待ち受けているのでやはり機械学習の
> ブレイクスルーなど何か画期的な解決の糸口は必要だろう
に関しては、意味表現が整備されてから、意味データベースを
構築する際には重要になると思う。
ただ、それ以前に「人間のモデル化」が壁として立ちふさがって
いると考えている。
当面の目標は、「漫才ができるシステム」だな。
『アンドロイドは電子漫才のオチで笑えるか？』 >>789 でも述べられていますが、
形態素解析から構文解析に至る過程で、
「語順と省略」に関する問題があります。
ただ、この点に関して、自然言語処理
（日本語処理）の研究者は、ほとんど注意を
払っていません。たとえば、
「象は鼻が長い」は、「象は長い鼻の動物だ」と
同義である、とわれわれは考えていますが、「鼻」
強調された結果として語順が変わり、「動物だ」が
省略され、「象は動物の一種である」という「常識」が
要求されています。
にもかかわらず、形態素レベルの「象は」「鼻が」「長い」に
関してしか議論されていないのが、自然言語処理の停滞の
大きな原因だとわれわれは考えています。 >>793
「ゾウムシの鼻が長いのに、コクゾウムシの鼻が
長くないのはなぜか？」
「ゾウムシは『象虫』ですが、コクゾウムシは
『穀蔵虫』だからです」
「なるほど」
「なお、ゾウムシは『ゾウのように鼻が長い』のではなく、
『長い口吻が象の鼻のようだ』から、ゾウムシと呼ばれます。
熱帯魚のエレファントノーズも同様です」
「ありがとう。」
これくらいのシステムであれば、現在の技術で充分に
可能だと思うんだが。
ついでながら、文語文は記述精度が高いので、いわゆる
標準語よりも生成が楽だ。その意味では、コンピュータとの
インタフェースには、「けいはんな方言」（京都弁でも
大阪弁でも奈良弁でもない、中途半端なエセ関西弁）が
向いていそうに思う。 ■ このスレッドは過去ログ倉庫に格納されています
