自然言語処理スレッド その４
■ このスレッドは過去ログ倉庫に格納されています
前前スレ 自然言語処理スレッド その２
http://mimizun.com/log/2ch/tech/1173105287/
前スレ 自然言語処理スレッド その３
http://mimizun.com/log/2ch/tech/1235129481/
このスレッドでは、日本語の構文解析、談話理解、情報検索、
文章生成などの技術に関する理論と(おもに)実装を扱います。
あくまでアプリケーションプログラミングの技術的な面に重点をおきたいので、
学術的な話はアリですが、いわゆる人工無能や哲学的AI話、
言語学の話題などは他のスレッドでお願いします。 数学では，ある問題を解くために，その問題を別の問題に翻訳して，もとの問題ではなく
て翻訳された問題の方を解く，という方法がとられることがよくあります．A という問
題を解くために，B という問題が解ければ，その解から A の解も得られることが判って
いるような問題 B をうまく設定して，A を解くかわりに B を解くのです．このような
問題 B を見つけることを，「問題 A を問題 B に帰着させる」と表現します．B は以下の
例でのように単に A の言い替えにすぎない場合もありますが，面白いことには，B は A
よりむしろ難しい問題になっていることも多いのです．これは，問題がやさしいか難しい
かは必ずしも問題が解きやすいかどうかということと一致しない，ということでしょう．
多くの場合，解きたい本来の問題 A を帰着させる先の問題 B は A よりずっと抽象的
な問題になっています．これは，前の節でも述べた，抽象的な設定の方が数学的には扱い
やすい，という現象の現われと言えるでしょう．
もとの問題 A が一般的な（必ずしも数学で扱えそうには見えないような）問題で，そ
れを数学的な問題 B に帰着させているときには，A の数学化(mathem atization)が B で
ある，というような言い方をすることもあります．
一般的な問題を数学的な問題に帰着させる，つまりこの一般的な問題の数学化を行う
例として「ケーニヒスベルクの橋の問題」という名前で知られている問題について考察し
てみることにしましょう．
http://kurt.scitec.kobe-u.ac.jp/~fuchino/chubu/method-math-WS06.pdf コーパス開発はオープンにした方がよい、という提言で、全てのやり取りを公開しましょう、
という話なのだが、オープンソースソフトウェア開発のようにソースコードから開発のやり取り
まで全てをオープンにできる場合もあるが、コーパス作成は元のテキストを書いた人がいるわけで、
全てをオープンにできないという性格がどうしてもつきまとう。もちろん再利用可能なテキスト
にアノテーションをすればいいし、テキストを作るところからオープンにもできるわけだが、
それで見えなくなってしまう言語現象も少なくないと思われるし（実際講演の中でも「少数の
事例をどうするか」という問題提起があった）、個人的にはセミクローズド（特定のグループ内で共有）
程度が現実的なところではないかと思う。
それより大事だと思われるのは、そういったコーパス開発に参加する、あるいは門前の小僧状態で聞
くだけでも人が育つことであって、結局ここがボトルネックになり、特定の研究室の出身者しかノウハウがない、
という状況になっているのだと思う。特に個人的にポイントだと思っているのは、先日も書いたような新人
に対して優しいコミュニティになっているかどうかで、自然言語処理自体はかなり新人が入りやすい
コミュニティだと思うのだが、ことコーパスや辞書のようなリソース作成系はかなりハードルが高いと感じる。
コーパス分析やそれを用いた自動解析に関しても、簡単にできるところはすでにやり尽くされていて、
残っているのは難しいところばかりで、簡単なところから練習してウォーミングアップし、
助走期間を設けて本丸に突撃する、というようになっていないのである。もちろん最先端を走る研究者
たちで議論するのはもっとも難しい事例でよいし、むしろそうでないと意味がないのだが、簡単な事例
から始める（あるいは既存のものの分析からではなく、新しいタグ付与にメンターつきで最初から関わる）、
というトレーニングもあってよいと思う。
http://d.hatena.ne.jp/mamoruk/20140902/p1 コーパス作成について一からやり直したほうがいいかどうかは、悩ましい問題なので一概にどうだ
ということは言いにくいのですが、アノテーション・コーパス作成自体が大きな研究テーマであり、
ベストプラクティス的なものもなければ、少しだけ蓄積されているノウハウ的なものすらチーム
レベルでしか共有できていない（共有するのが難しい）、という状況です。また、やり直したら
すぐコーパスができるかというと、質の高いコーパスを作るには時間が何年もかかるものなので
（自分の携わった NAIST テキストコーパスは5年以上かかっています）、すぐ利用可能にはならないでしょう。
http://d.hatena.ne.jp/mamoruk/20140902/p1 国や自治体は、地球儀で表現できる。物体・流体とその運動は、シミュレーターで表現できる。
人物とその行動はオブジェクトで表現できる。けれども「民主主義」とかの抽象概念は表現できず、
せいぜい共起関係を調べるのみ。例えば朝鮮民主主義人民共和国だって「民主主義」ということで、
北朝鮮＝民主主義国家なんて理屈も成り立つ。しかしこれは一般的なイメージとはかけ離れている。
従って抽象概念を一般的なイメージに帰着させるためには、いくつかの具体物を結びつけるしかない。
「世間」とは何か
http://www.pat.hi-ho.ne.jp/nobu-nisi/kokugo/seken.htm
「世間」とは・・・近所のおばさん、警察、新聞、学校、勤め先の会社、知り合い・・・・ 英語の論文読むのが苦痛でたまらない
はやく翻訳装置つくってくれ 第二に，3 次元オブジェクトの中には複数の物体から構成されるオブジェクトがある（たとえば，図 6 は「花」と「鉢」
から成る一つのオブジェクトである）．今後，画像解析技術が進み，機械が複数の物体から構成されるオブジェクト
を一つ一つの物体に分解できたとしても，機械にとって，それが常識に基づいた構成であるか，常識から外れた
構成であるかを区別することは困難であると推測される．
http://minamigaki.cs.inf.shizuoka.ac.jp/work/2014/SCIS2014fujita.pdf 東ロボくん センター模試2014
英語………95
国語………69
世界史Ｂ… 52
日本史Ｂ… 44
数学ⅠＡ… 40
数学ⅡＢ… 55
物理………31
７科目合計…386/900
漢文は全問ノーマーク
世界史Ｂは２問ノーマーク
日本史Ｂは４問ノーマーク
数学じゃないんだから
分からない問題はランダムにマークしろよ… 漢文・世界史Ｂ・日本史Ｂ
ノーマークの問題をすべてランダムにマークしてたら
49.6％の確率で14点以上アップ
つまり49.6％の確率で７科目合計が400点に届いたことになる 東ロボくん 英語 センター模試2014
発音・アクセント問題…パーフェクト（配点14）
未知語-語意推測問題…パーフェクト（配点8）
グラフ・図表問題…得点率75％（配点20）
語句整序完成問題…得点率67％（配点12）
意見要旨把握問題…得点率67％（配点18）
文法・語法・語彙問題…得点率60％（配点20）
会話文完成問題…得点率33％（配点12）
文脈に合わない文-指摘問題…得点率33％（配点15）
実用文書読解問題…得点率33％（配点15）
読解問題（論説文）…得点率33％（配点36）
読解問題（情報理解）…全滅（配点30） 東ロボくん 国語（現代文） センター模試2014
漢字…パーフェクト（配点10）
語句の意味…得点率67％（配点9）
評論読解…得点率50％（配点40）
小説読解…得点率32％（配点41） >>255
お前実は、自分で長文コピペ貼っておいて、自作自演してる張本人だろ？ >>253
未知語の推測問題、推測するまでもなく意味を知ってたんじゃないのこれ 文章が入力されたら、隠れマルコフモデルがたくさん存在する集合に射影するようなことできないかなぁ NAISTの自動音声翻訳
2013年、初級通訳者レベルに到達
ドコモが機械翻訳の会社「みらい翻訳」を設立
機械翻訳の精度は現在TOEIC 600点レベル
2016年までにTOEIC 700点レベル、2019年までにTOEIC 800点レベルを目指す
TOEIC 600点レベルなら、センター英語はもっと点とれるんじゃないの？
東ロボ英語チームはみらい翻訳と組めばいいかもね word2vecはギリギリまで次元を減らして意味ありげな指標を作っただけという可能性 翻訳はしょせん入出力が一対一レベルじゃろ 文脈をどこまで見てるかもあやしい 東ロボくん 東大模試2014
理系数学…36/120（偏差値55.7）
文系数学…32/80（偏差値54.1） 「理論上は」東ロボくんがほぼ全ての入試問題（数学）を解ける「目処」が立ったらしいが
まだ課題があるみたい
http://blog.livedoor.jp/dg_law/archives/52234923.html 東ロボくん専用スレ立ててこのスレでは禁止していいかな？ 公務員試験だけの先生が東ロボの話をコピペしているの？ 東ロボにRubyは使えないのか？
力学シミュレーションと可視化
これまでRubyで軽くシミュレーションを書くのはかなり困難なことでした。
微分方程式はRuby-GSLで解けますがインストールは非常に煩雑でした。
可視化に関しては決定的な方法がなかったように思います。 (私がよく知らないだけかもしれませんが…)
今ではFortranをラップしたODE gem (gem install odeだけでインストール可能)で常微分方程式
を解くことができます。 また、IRubyに新しく加わったCustomWidgetを使うことで、Rubyとネイティブ
拡張の出した結果をリアルタイムにブラウザ上に表示できます。この場合JavaScriptの有名なdom操作ライブラリ、
jQueryやd3.jsを使って可視化部分を簡単に書くことができます。
http://domitry.hatenablog.jp/entry/science_with_ruby >>245
＞自分の携わった NAIST テキストコーパスは5年以上かかっています
人海戦術で何とかならんのか？ >>245
＞自分の携わった NAIST テキストコーパスは5年以上かかっています
それでもアノテーションコーパスの充実は、今後ますます必要になってくると思う。
□現象?多様性?カバーできているのか?
SNS文書，論文など別?種類?文書へアノテーションが必要
□学習アルゴリズム・解析アルゴリズム・特徴抽出?さらなる改善
現象?多様性を捉えるには? 今まで?延長線上でうまくいくか? 問題?観点を効果的に捉えるには?
□情報共有
アノテーション時?経験則，問題?評価指標
□ジレンマ
学術的に?問題を安定させなけれ?共有が難しい /
今後想定される応用に向けて問題?改編が必要
□アノテーションしたデータだけ対象にしていていいのか?
アノテーション学 vs ポスト経験主義
述語項構造と照応関係?アノテーション：
NAISTテキストコーパス構築?経験から
飯田龍(NICT), 小町守(首都大),井之上直也(デンソー・東北大),
乾健太郎(東北大), 松本裕治(NAIST)
http://www.anlp.jp/anniversary/20th_sympo/slide_iida.pdf 長文を箇条書きにするというのは恐らく文書要約の範疇で、盛んに研究されているところだと思いますが、
重要文抽出以外はまだ実用的には難しいでしょう（文抽出以上のことをしようとすると、意味を理解しないといけなくなる）。
最近はニュースの配信アプリケーション・サービスが盛んに開発されていて、ざっくりまとめたりする機能がありますが、
自然言語処理の最先端の技術が使われているというよりは、かなりルールを書いたり、人手を入れたりしている、と聞いたことがあります。
http://d.hatena.ne.jp/mamoruk/20140902
コーパスのアノテーションは、ものによりますが人海戦術でなんとかなるものではなく、人を増やしても質が確保できない
（むしろ悪化する）ため、少数の人数で長期間作成する、というのが典型的な方法です。最近はクラウドソーシングによって、
多数の人間にアノテーションをさせる、という試みがなされていますが、自然言語処理は画像認識ほどには一般的ではありません。
見てすぐ分かる、というタスクならいいのですが、少し考えないといけないようなタスクが多いからでしょう。
画像認識については、リンク先を拝見しましたが、これは画像認識だけの問題ではなく、かなり難しい類の問題であると思います。
何が「余計」かというのを分かるためには、答えを推測できないと分からないように思いますし、いまの東ロボプロジェクトの数学
を公理系（数式）に落とし込んで推論（というか証明で）解くアプローチでは、このような問題は苦しいのではないでしょうか（
予測して探索するようなアプローチをする必要があり、どちらかというと証明系というよりはゲームAIの推論のような感じ？
要は大規模なデータからのパターンマッチにする、というパラダイムにする、とうことです）。これを幾何の問題のまま解こうと
するのは数学の解答エンジンを一から作り直すことに相当すると思われますし、このプロジェクトのフォーカスからは離れそうです。
http://d.hatena.ne.jp/mamoruk/20140822 自然言語処理のエラー分析は、これまた困難らしい。
Project Next NLP という、いろいろなタスクでエラー分析をする日本の自然言語処理コミュニティの一大実験プロジェクト
があるのだが、予想通り大変そうである（自分は今年度子育ての負荷が高いことが分かっていたので、結局メインでは
参加していない）。こういう機会が必要なことは恐らくこの業界のほとんどの人が賛同すると思うのだが、実際にエラーを
分析しようとすると、アノテーションの経験がありかつ言語学にも詳しい人がプロジェクト内に複数人いないと、
そもそもエラー分析自体がまともに回らないと思うし、もしそういう人たちが中核にいたとしても、議論が白熱して
毎回侃侃諤諤の議論になることうけあいなのである。
http://d.hatena.ne.jp/mamoruk/20141112/p1 アノテーションに関しては、自然言語処理におけるアノテーションに特化したような和書はありませんね。需要はあると思うので、
出版社の方が見えたとき、そのような本を企画されては、と提案したことはあります。ただし、体系化することが難しいので、
書くには骨が折れると思います。ほとんどの場合、仕様を解説されても意味が分からないので、読む人が言語現象自身に詳しく
（つまり言語学の知識があり）、かつ自然言語処理にも明るい（つまりプログラムを書いて機械学習を行う処理がイメージできる）
必要がありますので、入門書とはならないでしょうし、個人的にも入門書ではなく専門書としてちゃんと書いたほうがいいと思っています。
http://d.hatena.ne.jp/mamoruk/20140902 RDF等に関しては自然言語処理よりはウェブマイニング（広義の人工知能研究）で盛んに
研究されていますが、ほとんどの研究は英語が対象で、日本語でちゃんとしたリソースは
作られていないというのが現状だと思います。だからどう（日本語でも作るべき）だとい
うわけではないですが、少なくとも東ロボのプロジェクト期間内にどうこうできるという話ではないでしょう。
個人的には、ここは確かに研究の余地があるところだと思っているのですが、英語で書かれた
リソースと比べると日本語で書かれたリソースが少ない（かつ分野が偏っている）という問題と、
日本語が英語と比べると処理しにくいという問題のため、英語のように精度の高いリソースを
作るのはそんなに簡単ではないと思っています。（たとえば、英語だと2つの名詞句の間の文字列
を取ってくれば、だいたい述語が取れるので、構文解析によらない頑健な処理ができますが、
日本語では述語は文の末尾に出現するので、係り受け解析をしないと述語が分からず、なかなか頑健にはできなさそう）
http://d.hatena.ne.jp/mamoruk/20140902 コピペが無くても誰も書き込まないスレッドをコピペのせいにするなよ コピペが無くても誰も書き込まないスレッドをコピペのせいにして申し訳なく思います ＲＤＦトリプルセットは「連想・推論」に利用できるので、人力でＲＤＦ辞典を作成しておきたい。
自然言語の多義性・曖昧性は、これである程度解消できるはず。
提案手法では，開世界仮説に基づき，RDF グラフからそれより高い表現力をもつ SROIQ概念の極小モデルを推論できる．
さらに，ある概念の極小モデルが一意に決まることを利用し，与えられたRDF グラフから記述できるすべての概念を生成
する停止性をもつアルゴリズムを提案した．
http://sigswo.org/papers/SIG-SWO-A1402/SIG-SWO-A1402-10.pdf
（x,y,z）＝(主語,述語,目的語)で、出現頻度の多い順に並べる、あるいは少ない順に並べる。高頻度のトリプルがやたら多いということは、
逆に言えば他と似たり寄ったりでつまらないコンテンツである可能性が高い。出現頻度の少ない組み合わせは、オリジナル表現か
あるいはナンセンス文かのどちらか。例えば「女性は子供を産む機械」。こういうのは普通に「女性 子供」で検索しても出ない。
コーパス作成について一からやり直したほうがいいかどうかは、悩ましい問題なので一概にどうだということは言いにくいのですが、
アノテーション・コーパス作成自体が大きな研究テーマであり、ベストプラクティス的なものもなければ、少しだけ蓄積されている
ノウハウ的なものすらチームレベルでしか共有できていない（共有するのが難しい）、という状況です。また、やり直したらすぐコーパス
ができるかというと、質の高いコーパスを作るには時間が何年もかかるものなので（自分の携わった NAIST テキストコーパスは
5年以上かかっています）、すぐ利用可能にはならないでしょう。
http://d.hatena.ne.jp/mamoruk/20140822
今後，画像解析技術が進み，機械が複数の物体から構成されるオブジェクトを一つ一つの物体に分解できたとしても，機械にとって，
それが常識に基づいた構成であるか，常識から外れた構成であるかを区別することは困難であると推測される．
http://minamigaki.cs.inf.shizuoka.ac.jp/work/2014/SCIS2014fujita.pdf
『常識』なるものは、専ら人力で登録するしかない。コンピューターなんていくら高性能でもただの計算機に過ぎないのだから。 >>282
＞機械にとって，それが常識に基づいた構成であるか，常識から外れた構成であるかを区別することは困難であると推測される．
自動作成が困難な「違和感CAPTCHA」は、試験問題作成委員と東ロボとイラスト作成支援ツールや
過去問改題支援ツールを併用し、人力と機械力のハイブリッドで効率的に作成する。イラスト理解は
コンピューターには困難だが人間には易しい。難しい東大の過去問も、懇切丁寧な誘導付きで易しい問題
に改題すればいい。センター数学は人間には易しいが東ロボには困難だ。またそれ専門のセキュリティ
企業を設立して、効率よく大量生産できるようにしたい。できれば一日あたり一万通りくらいは作りたい。
三回間違えたら３０分間はアクセス禁止にするとか。そうすれば２ｃｈのアラシ投稿も激減するはずだ。
「ぐにゃぐにゃ文字CAPTCHA」にはもうウンザリ。 あと、２ちゃんねるでの板違いスレ立て乱立防止のために、「資格試験CAPTCHA」を導入するとか。
例えばプログラマー板なら、基本情報技術者試験の午前問題で、７割正解しないと投稿できないようにするとか。 人間は完璧を求める。物体に穴が開いていると、物体の一部が欠けていると、そのギャップを埋めようとする。
次の画像を見ると、実際には存在しないものの、円と長方形に見えてくる。
閉合の法則が存在しない状態では、長さの異なる線にしか見えないが、閉合の法則により、線を組み合わせて、形として見る。
http://livedoor.blogimg.jp/mikamikanmikamikan/imgs/1/8/186ef42f.jpg
http://www.seojapan.com/blog/8-web-design-rules
82. 1. 記述範囲として20sの領域を選択 2. 領域を4 4(=16)ブロックに分割 3.
記述範囲をオリエンテーション方向に回転 方向の正規化 20s 20s 82
http://livedoor.blogimg.jp/mikamikanmikamikan/imgs/e/1/e1a13d79.jpg
http://www.slideshare.net/MPRG_Chubu_University/sift-32258833
我々人間は、無意識のうちに膨大な量のコモンセンス知識を、日常生活の中で自然と会得し共有している。
人間に近い思考をする人工知能を実現するためには、コンピュータ上にコモンセンス知識の巨大なデータベース
を構築する必要がある。ビッグデータを扱う技術と組み合わせれば、人工知能の思考精度を向上させる土台となる。
http://livedoor.blogimg.jp/mikamikanmikamikan/imgs/2/9/2989d626.jpg
http://business.nikkeibp.co.jp/art…/bigdata/20140722/268973/ 全角カンマが論文で多く見られ、一般には余り用いられないことから
，(.|\n)+https?://
をNGにすると結構良いんじゃないだろうか。
あと驚いたのが
る。(.|\n)+https?://
が思ったより誤認識しないこと。これも論文に特徴的な、「である調」を意識したものだが、このスレで引っかかった中で少しでも意見が含まれると思われる投稿は9件に留まった。
リンク先との内容の重複を検出するのが一番なんだろうけどね。 研究者ワナビーのオッサンがコピペしてそうだよな
学歴は高くなさそうなオッサンが ふつうに入門書から読めば、学歴がどうあれそれなりに理解はできるだろうにねえ。
わけもわからずそれっぽいweb上の記事を漁って仮にそれを丸ごと暗記できたとしても
何の意味もないのに。 Wikipediaのdumpって
いつの日付のが良くベンチマークとして使われてるとかあるのですか？
むしろlatestを使うのが普通なんですか？ 学歴高いオッサンでポストがあっても話にならんクズは多いけどな あれっ？
CRFって最大エントロピー法の特殊な場合なんだっけ？ 入力や解析の途中の状態をすべて保存しておけば、
入力・解析が途中で止まっても再開できるぞ。
俺スゲー https://radimrehurek.com/gensim/wiki.html
に書いてある通りにwikipediaのデータを読み込ませているのだけど
セグメンテーションフォルトで落ちる
メモリー8GのマシンではWikipediaを全部読むのは無理ってことでしょうか？
このドキュメントにはwikipediaのダンプは8Gのファイルサイズって
書いてあるのだけど先月のダンプが１２Gあるので
そこも疑ってるのだけど https://sites.google.com/site/projectnextnlp/ws2015
12:30-13:00 言い換え 「言い換え認識技術の評価に適した言い換えコーパスの構築指針」(論文，スライド)
藤田篤（NICT），柴田知秀（京大），松吉俊（山梨大），
渡邉陽太郎（NEC），梶原智之（長岡技科大）
13:00-13:30 「情報検索のエラー分析」（論文，スライド）
難波英嗣（広島市立大），酒井哲也（早稲田大）
13:30-14:00 「『ロボットは東大に入れるか』プロジェクト 代ゼミセンター模試タスクにおけるエラーの分析」 すみません、どなたかお力をお貸しください！
英語版Wikipediaのタグ除去済みの生データが欲しいのですが、
どうしても今日中に手に入れたく、、うちのコンピュータだと各種コンバータを借用しても間に合いません。
古めでも問題ないので、どこか公開されてたりしないでしょうか？ まぁ、地味にうちのi5マシンでも
英語版Wikipediaデータのコンバータ使ったら、5日かかったからな。
SQLのINSERT外して、タグ除去ってやり方なら一瞬だけど、
XMLに変換して、綺麗に構造的に展開していくタイプのツールだと、とんでもない時間かかる。 Wikipedia のdumpをapache solrに入れて検索してるんだけど
遅すぎる
どうやったらgoogleの半分の速度でいいから高速検索できるんだ 東ロボが「図とグラフの把握」をクリアするころには、連想型アニメイラスト作成支援ツールが普及して、
漫画家はアシスタントを雇う必要が無くなっているに違いない。イラストの大半は既存のオブジェクト
の組み合わせで、それとこれとはどんな繋がりがあるのかが理解できればいい。 自然言語理解＝単語と助詞の連想ゲーム。例えば「象はバナナを食べる」はOKだ が、
「バナナは象を食べる」は×。こ のように現実に有り得ない組合せ は、予め削除しておく。
嘉門達夫の 「あったら怖いセレナーデ」を、一 億通り作成しておきたい。 ボトムアップな言い換え事例収集
ある範囲のテキストをとことん言い換える (内省)
l 仮説: 100人集めればある程度の網羅性を担保できる
l パイロット作業
n BCCWJから言い換え元の文をサンプル
n ひたすら言い換え →150事例/5時間(ペースはほぼ一定)
l trivial なものも結構含む
l minimal pair となる負例は別途要作成
l 宮尾さん「人間の限界はたかがしれている」
http://paraphrasing.org/~fujita/publications/fujita-NLP2015WS-slides.pdf 2.1 述語項構造に基づく共起関係のモデル化
述語項構造は, 述語とその任意個の項の関係を記述するものである. 例えば,
HPSG に基づく構文解析器 Enju によると, 以下の文
An importer might be able to make payment in his own domestic currency.
に関して表 1 のような述語と項の関係が得られる.Enju における述語項構造では,
動詞だけでなく任意の単語が述語として扱われる. 表 1 では, 主語と目的語に対応する
名詞句を項とする他動詞 make に加え,動詞句の付加部を構成する前置詞 in も述語
として扱われている. これにより, 様々な種類の述語を介して句と句の関係が記述される.
http://www.logos.t.u-tokyo.ac.jp/~hassy/publications/nlp2015/paper.pdf 3.1 よく知られている単語の抽出
スクリーニング検査の被験者は，一般的に高齢者が多く，「三単語復唱」で用いる単語には新造語や流行語
は適切ではない．これに対し，童話や童謡は，対象が幼児，児童である故に，そこに出現する単語の多くは，
あらゆる年代の人間に親しみ深く，非常に認知度が高い．そこで，本研究では童話や童謡歌詞を題材とし，
それらに出現頻度の高い名詞を抽出して，「三単語」の候補とすることにした．
本研究では，日本の童話 210 編，童謡 90 曲1をコーパスとして用い，そこから，出現頻度の高い名詞を自
動抽出した．抽出された名詞を日本語語彙大系2の一般名詞意味属性体系に準拠させて「食べ物」，「乗り物」，
「植物」，「動物」，「建築物」，「日用品」，「スポーツ」，「空想物」の 8 つのカテゴリに分類して格納する．
これら 8 つのカテゴリは，互いに意味属性体系上の包含関係が生じないように定めた．この作業の終了後，
「三単語」に適さないと思われる名詞を手動で削除し，さらに，各カテゴリに，適切と思われる名詞を適量ずつ追加した．
http://www.anlp.jp/proceedings/annual_meeting/2015/pdf_dir/B4-4.pdf 言語処理部とシミュレータ部を組み合わせることで、「場合の数・確率」の文章題に自動で解答する
システムを開発中であるが、現状では正答率は低い。シミュレータ部では、多くの問題タイプに対応
できるようにして、より汎用的なプログラムにする必要がある。言語処理部では、問題文を変換する
パターンを増やしていき、変換可能率をあげるとともに、オブジェクトが玉でないものにも対応する必要がある。
数学確率文章題の自動解答システムの開発
http://www.anlp.jp/proceedings/annual_meeting/2015/pdf_dir/B2-3.pdf
これができるようになれば、東ロボは東大理３入ってるだろう。 文章中の数箇所をワイルドカードで置き換えることによって
表現されるいわゆる文章テンプレートは, 自然言語生成の分野
で使われ, また, ワイルドカードに入る語を見ることで関係抽
出にも使われる. 次々に新しいテンプレートを増やす必要があ
る場合, 人手でテンプレートを作る作業は高コストであり自動
的にテンプレートを抽出する必要がある.
http://www.anlp.jp/proceedings/annual_meeting/2015/pdf_dir/D1-2.pdf >>302
Apache solarより
Indriというデータベースの方が良いと聞いた 本稿では，マンガ作品において重要な要素である登場人物の顔領域検出について，
学習サンプルの違いによる検出率の変化を検討する．マンガの登場人物の顔領域は
現実の顔画像と比較して，個々の特徴変化が大きい傾向にある．
そこで，顔検出器の学習に，特定の登場人物の顔画像のみを使用した場合と，
複数の登場人物の顔画像を使用した場合について，検出率の比較を行った．
http://www.ams.giti.waseda.ac.jp/pdf-files/2015IEICE_D_12_31_yanagisawa.pdf 4. アノテーション作業と問題点
「たら」「れば」「なら（ば）」の３つの条件表現アノテーション作業はガイドライン設計
者 2 名で行った。それぞれの表現について、多くの文章の中から該当の表現が出現
する部分を抜き出し、その用法がどのカテゴリに属するかを、テストをもとに判断した。
アノテーションの件数は「たら」「れば」「なら（ば）」それぞれ 200 件ずつ、計 600 件行った
アノテーションを行う中で、以下のような例に対するアノテーションが問題となった。
https://www.ninjal.ac.jp/event/specialists/project-meeting/files/JCLWorkshop_no7_papers/JCLWorkshop_No.7_10.pdf
実験の結果から, 全体的に「対象」の役割をもつヲ格名詞句に焦点が置かれる傾向があるが,
段階的に「対象」から「到達点」あるいは「道具」へ焦点が移っているということがわかった. 焦点
が置かれるところが類似している動詞は, 意味内容も似通っていることが明らかになったといえる.
日本語の使役空間移動動詞には, 「－が－に－を 動詞」の型と「－が－で－を 動詞」型があるが,
どちらの型もとれる動詞もある. その場合,対象がヲ格で示され, ニ格で到達点が示された動詞は,
そのニ格がヲ格となって中身よりも容器のほうに焦点が置かれ, ヲ格の対象物はデ格で表されることになる.
これらの動詞について, 対象物・到達点・容器・道具を示すと考えられる名詞句のどこに焦点が置かれ,
それを話題として取り上げるか, その傾向を調べたのであるが, 全体的にはヲ格名詞句に焦点が置か
れる傾向があることが明らかになった.
http://www.jcss.gr.jp/themes/jcss2014/meetings/JCSS2014/proceedings/pdf/JCSS2014_P1-27.pdf
辞典類にあって、 「し」の用法としては、 〈並列〉と〈原因理由〉とは立項されるが、 〈果〉は立てられていない。
たしかに、、〈34）の例は〈果〉を示しているが注意しておくべきは「だから」の語が直前にあるように、
そうした接続語の支えが必要であるように思うが、このことは、 「し」が何を列挙するのかということを
考える上でも興味深いように思う。
http://www.lib.shimane-u.ac.jp/kiyo/a014/035/004.pdf 従来の係り受けアノテーションは、専門家がそれぞれの文節に対して一つの係り先をタグ付けしている。
この手法だと、例 (2) のように、意味的にはどちらにもとれるような係り受けに対して、係り先をどちらか
に決める必要があり問題となる。
本タスクでは、クラウドソーシングによる係り受けのアノテーションを試行した。一つのタスクは、一つ
の文節の係り先を判定するタスクとした。ワーカーへのインストラクションを図 1 に示す。係り先の候補と
しては、KNP が出力する係り先候補とタグ付きコーパスの正解係り先とした。タグ付きコーパスとしては、
京都大学 Web 文書リードコーパス 2 を用いた。このコーパスは京大コーパスと同じ基準で係り受けがタグ
付けされている。
Yahoo!クラウドソーシング 3 を用いて、一つの文節の係り先につき 10 人のワーカーに判定を依頼した。
https://kaigi.org/jsai/webprogram/2015/pdf/2L3-4.pdf
項省略型は，動詞などの述語の項が省略されているケースで，いわゆるゼロ照応として知られている
問題である．ゼロ照応解析は述語項構造解析の範囲であるが，ゼロ照応解析には自動解析が困難な
例が多数存在しており，すべての問題を対象に自動解析を試みた場合に解析精度が極端に低くなる
ことが報告されている [飯田 12]．特に，今回は省略された項が述語と異なる文に出現する文間ゼロ照応
の問題となっているが，文間ゼロ照応の自動解析は文内ゼロ照応と比較して精度が極端に低く
（例えば [今村 15]）依然大きな課題である．
https://kaigi.org/jsai/webprogram/2015/pdf/2L3-4.pdf Apache solarはsenを組み込めるけど
他でmecab組み込めたりするのあるのかな アノテーションは、人手でやるしかない。コンピュータはただの計算機で自然言語はただの文字列にすぎず、
人間が教えていかないとどうにもならない。
自分は NAIST 松本研にいたからこそこういうタグ付けの方法論を教わったが、自然言語処理の研究室でも
ほとんどの研究室ではこういうノウハウがなく、卒論や修論で闇雲にタグ付けして再利用できないデータが
再生産されているのではないか、と懸念する（先輩から引き継いだ、というか教員から渡されたデータを使っ
て実験したりしても、元々のデータがあやしいのでちゃんとした研究にならない、みたいな）。
コロナ社の言語処理シリーズでもアノテーションの方法論について誰か書いてくれるといいのに、と編集の方
にときどきお話ししているのだが、想定読者が少なすぎるのか（確かにマニアックなテーマで、ほとんどの人
はデータを作る側ではなく使う側）、引き受け手がいないのか、まだ動きが見えないようである。
http://d.hatena.ne.jp/mamoruk/20150529/p1
2 つ目は，4.4.2 項で述べたエラー要因に対する対策を実現することである．対応策の
中には，否定表現や時制表現の処理など，比較的容易に実現できるものもあるが，特にエ
ラーの要因の中で大きな割合を占める人物抽出やパターンに関する問題の解決策は時間
をかけて深く探求する必要がある．M人手 においては完全に人手でパターンの構築を行っ
ているため，パターンが少ないことが大きな問題である．そのため，人物間の関係を表す
典型的な言い回しを数多く発見する手法を検討する必要がある．
https://dspace.jaist.ac.jp/dspace/bitstream/10119/12702/5/paper.pdf
もっと沢山の、人手によるアノテーションコーパスが必要。 JavaだとMavenにmecabあるので自動でインストールできるけど
Cabochaがないみたい
みんな手動でインストールしてるの？ 野良レポジトリでcabochaらしきものあったけど mavenに
mecab
kuromoji
go
形態素解析ばかり３つもあるのか
どれが一番いいんだろ
cabochaも誰かつくればいいのに http://www.lemurproject.org/indri/
IndriにMeCab組み込んで日本語検索してる研究らしき発表はあるのに
公式のホームページにMeCabの組み込み方が書いてない
ワイルドカード検索できるっぽいからSolrより良い感じなんだけど
日本語検索の方法がわからない 以前に使った時はSolrのワイルドカード検索はかなり機能が限定的だった
*が一ヶ所しか使えなくて複数がダメだった 機能表現解析の結果を表 1，2 に示す．これらの結果より，CRF を用いることでベースラインよりも
高い性能での機能表現解析が可能であることが分かった．CRFの結果から，範囲同定は比較的高
い性能で行えるが，曖昧性解消は難しいことが分かった．
https://www.ipsj.or.jp/award/9faeag0000004ej9-att/5Q-02.pdf
本稿では，数学入試問題自動解法の概要を示した後，その技術課題について述べる。
http://img.jp.fujitsu.com/downloads/jp/jmag/vol66-4/paper03.pdf ■ このスレッドは過去ログ倉庫に格納されています
