NLP2011, 本会議2日目終了（セッションB2: Twitterと言語処理）

B2:テーマセッション4: Twitterと言語処理
B2-1 Wikipediaのカテゴリ階層を利用したTwitterユーザのカテゴライズ手法 (pp.448-451)

○放地宏佳, 鶴田雅信, 酒井浩之, 増山繁 (豊橋技科大)
ユーザ推薦のために公式用意されたカテゴリ数は8種類。
母数と比較してあまりにも少ない→客観的な判断に基づいたユーザ分類
発現内容に基づくカテゴライズ
　新語が多く形態素解析困難
　既存シソーラスでもカテゴライズ困難
　→Wikipedia利用してカテゴライズ
特徴誤抽出のための前処理
　ユーザ名除去
　RT,QT以降の文除去
　ハッシュタグ除去
　文字表記法法の統一「は”」→「ば」

Q: 違和感を感じたのはツイート分類かユーザ分類かが混ざっているのか。
　人自体が多面性持ってるし、移り変わるものでもあるし。ツイート分類
　して時系列的にユーザ分類するのが良いのかしら。


会場Q: カテゴリを辿って近いパスといったが、共通カテゴリへの最小パス？
A: 特徴語から近い方。
会場Q: 閾値から2以上というのは2未満の誤り？
A: 最上位カテゴリと特徴語があり、数式では最上位カテゴリからの値。

会場Q: Wikipedia中リンクのアンカー名とタイトルとの関係を使うと
　より頑健な抽出ができると思う。
会場Q: ユーザ20名はどうやって選んだ？
A: Streaming API から取得した日本人からランダム抽出。
会場Q: ユーザによってカテゴリのしやすさもあると思う。
会場Q: 複数のことに興味があってまたがったツイートをしている人も
　いると思う。特徴語から共通カテゴリを取るとかなり上位のカテゴリ
　が取られてしまい変なことにならないか。
A: 1ユーザについて全部をまとめて共通カテゴリを作るわけではなく、
　複数カテゴリが付与される。閾値調整であまり上位過ぎないように調整する。



B2-2	マイクロブログの分析に基づくユーザの嗜好とタイミングを考慮した情報推薦手法の提案 (pp.452-455)

○向井友宏, 黒澤義明, 目良和也, 竹澤寿幸 (広島市立大)
Twitter「リスト」の名前からユーザの属性を判別＆特徴誤抽出。
必ずしも嗜好情報を表しているとは言えない。
「お気に入り」は嗜好情報含むが、あまり利用されていない。
→「リツイート」を利用。
　全ツイート使うよりもクラスタリング結果は良質に見える。
リツイート中の名詞を利用。
　表記揺れ→Wikipediaカテゴリ情報
　意外性のある推薦
バースト＋極性評価（ネガティブ時は推薦しない）
　仮定：推薦が受け入れられやすいタイミング

Q: favtterとかある程度整理されたのを後から見るケースも増えてきてる
　ので、リアルタイム性が必ずしも高いとはいえないのかも。
Q: （そもそもツイートに反応するボット的な推薦は受け入れられるのだ
　ろうか。ボット的な推薦なのかは分からないけど）


会場Q: ネガポジ判定に「ヒット」といった言葉で決まってしまうとのこと
　だが、野球でも攻守によって異なる。その対応はできるのか。
A: ツイートの流れを追う事によって判別できると思う。

会場Q: (1)リツイートを対象にした時と全ツイートを対象にしたときとで
　どのような差が見られたのか。リツイートは情報が高かったものを広める
　役割で、嗜好を表しているというのも何となく分かるが、クラスタリング
　されているか否かと嗜好を表しているか否かは一致していないように思う。
　(2)タイミングで高揚している時に出すというのは面白いともうが、
　実際やってみてどうだったのか。
A: (1)ユーザ毎にプロファイリングした結果、全ツイートを用いると特徴的
　な語が取得し難い。
　(2)タイミングについては、評価実験はまだ行えていない。
会場Q: クラスタリングの評価について、直感的にやったのか、
　客観的にやられたのか。
A: 成功している／いないについては直感。具体的な尺度は無い。
会場Q: クラスタリングすることで意外性のある情報推薦ができると考えた理由は？
A: 異なるユーザの特徴語に共通点が多く、異なる特徴語があり、
　カテゴリ的に上位で共通していれば意外性があると考えた。



B2-3 Twitterからの個人の行動に起因するトラブル予測システムの試作 (pp.456-459)

○隅田飛鳥, 服部元, 小野智弘 (KDDI)
ユーザのログから特定トラブルが発生する可能性が高いか否かを判定したい。
例：健康管理システム（肥満）
個人の行為・状態の積み重ねを原因とするトラブルに限定
　地震とかサーバダウンは対象外
　因果関係を用いた予測
　時間関係も加味して要因を認識する必要がある
原因候補の抽出＋グルーピング
　名詞の上位下位関係、動詞の含意関係
時間情報を考慮してトラブル発生しやすさを機械学習してスコア付け
　素性:単語そのもの+周期性+原因候補の書き込み時刻+周期の変化

Q: メタボとか複数要因（食事、運動等）が絡むようなのは、
　今の所考慮しないということか。


会場Q: 評価について。「風邪」から「風邪」は分かりやすいが、
　「風邪引きそう」はトラブルとしては除外？
A: 除外。
会場Q: ニーズについて。ユーザが使う時に嬉しいのかどうか。
　どう説明するのか、役に立つと示すのか。
A: 実証実験を行いたいと思うが、まだそこに至っていない。
　精度高くしないと実用には厳しい。

会場Q: 表現語の選択はどうやっている？
A: 「風邪」を必ず含む後にしているので、限定し過ぎているかもしれない。
会場Q: 「太った」というのが「トラブル表現」とのことだが、
　太るというのは急激に発生するわけではなく徐々になる。
　トラブルとしてはどう書くのか。
A: 例としては「体重計のったら太っちゃった」とか書かれる。
　それを「太る→太った」と表現した。
会場Q: 警告をすると言ったことを考えている？　この時に太ることを
　覚悟していることもあると思うが、どう考えているか。
A: トラブルの選択については考える必要があると思う。



B2-4 マイクロブログサービスの返信行動に着目した投稿及びユーザの分類 (pp.460-463)

○黒澤義明, 竹澤寿幸 (広島市立大)
フォローしやすい→増え過ぎて大変→要選択
　親密度（？）を返信行動「投稿の繋がり」で分類
　名詞だけでは無関係→Wikipedia辞書でカテゴリ同一
カテゴリ化
　Wikipediaでカテゴリ情報抽出（2段階）
双方への配分
　ペット：3×α　（3倍して重み調整）
　ツイッター文長自体が短いので、複合して情報量upを期待
クラスタリング
　pLSA, SOM

Q: ツイート文長が短くて情報量少ないという点を「カテゴリ名」を
　「3倍＋重み調整」するというのが相対的のどのぐらい効果が出そう
　なのか良く分からない
Q: TL検索して垣根を越えて人を見つけやすくなってるだけでも十分
　だとも思うけど、コミュニティ単位での検出という意味ではそれが
　嬉しい場面もありそう。ハッシュタグもそうだし。


会場Q: クラスタリングで、学部が一致すべきかどうかが良く分からない。
A: 課題でも述べたが、学年の進行に伴い変わるものだし、学部の中でも
　仲が良いとは限らない。もう少し細かいクラスタでやりたいが、
　細かい情報が載せられてないためアンバランスな面がある。

会場Q: セレンディピティという話もあるようだが、最終的な目的は？
A: 全ツイートを見るわけにはいかないので、興味のあるツイートを提示
　したい。興味通りの所を提案するだけだと飽きるので、新たな友達を
　発見するツール等を考えている。
会場Q: 返信内容に含まれる単語を使ってクラスタリングしているよう
　だが、単純に考えると返信し合っている人は同じくラスタに入りやすい。
　それだけだとフォロー関係使っても同じものを得られそう。それ以上の
　ものが取れているのかどうか。
A: 直接比較はできていないが、フォロー関係については別途やっており
　合体／比較していきたい。
会場Q: 評価の方法として、ツイッターで作られるコミュニティと
　現実生活コミュニティが同じであると仮定していると考えている？
A: その通り。
会場Q: それをネットで発見する意義は？
A: 友達作りが下手という話も良くきくようになった。
　実際あるコミュニティを知らない場合に、チャンスが広がると考えている。



B2-5 Twitterユーザの属性判別によるスポーツ映像の自動要約 (pp.464-467)

○小林尊志, 野田雅文, 出口大輔 (名大), 高橋友和 (岐阜聖徳学園大), 井手一郎, 村瀬洋 (名大)
膨大な放送映像を効率的に閲覧する技術が必要
視聴者の視点による重要なシーン検出
　盛り上がり（歓声／実況チャット）を利用
実況書き込み
　属性評価辞書で投稿者の属性判別
　　「どちらのチームを応援する文脈に現れやすいか」
　　チームを応援するハッシュタグ
　要約映像の生成
　　同一チームを応援する投稿者の書き込みかr亜盛り上がり度を算出

Q: バイアスを気にするというよりそれが気にならないぐらいに
　高バイアスしちゃうよ！というように見える。
Q: ツイートタイミングと映像タイミングとでの時間差は
　何かしら一意にアライメントできるのかしら。


会場Q: 中日ファンの例を見たが、ロッテファンではどうなるのか、違いは？
A: 試合内容と展開によって大きく異なる。この例では大差で負ける。
　この場合、買ってる方は「相手の得点」でも盛り上がる。

会場Q: 巨人／横浜だった場合、巨人ファンが多すぎるといったことがある
　と思うが、問題にならないか。
A: 単語数を一致するように設定していることで調整できた。
会場Q: 2chの実況版とかあるが、それを利用することはできないか。
A: 匿名性があり、どのユーザがどの書き込みをしたかというのが得難い。
　Twitterに特価した手法。
会場Q: (1)ユーザの立場が分かるというのは面白い。偏りがあるというのは
　良いが、日本と別の国となると片方の立場で映像出さないといけない、
　majorityになるような場合にどうなるのか。(2)評価について、立場を
　評価せずにTwitter盛り上がりだけを見た時にどうだったか。
A: (1)明らかに偏りがありすぎる場合には、基本的には属性判別困難。
　単語に隔たりが出てくると可能性はあると思う。
　(2)実際の書き込み件数だけでいくのと比較すると、2シーンはとれた。
　他は立場を考慮しないと取れなかった。



B2-6 Twitterにおけるつぶやきの関連性を考慮した改良相関ルール抽出による話題抽出 (pp.468-471)

○鈴木啓太, 新美礼彦 (未来大)
最新の話題を収集し続けるのは困難→話題抽出
Googleトレンド／kizasi.jp
　何故話題になっているのか、どう使われているのかは分からない。
　→話題を類推できる情報を提示したい
類推ワード
　トピックワード：相関ルール抽出で生成
　　結論部にトピックワードを持つルール
　関連文書：類推ワードと集めた文書から生成

Q: 昨日のポスターセッションであった「ページに何が書かれているかを
　示す記述用語」みたいな話かしら。


会場Q: 相関ルール抽出で語彙を増やしたとのことだが、類義語とか
　他の方法とは違う効果が得られるのか。この方法に着目した理由は。
A: 相関ルール抽出しか知らなかったというのが大きく、
　他の手法と比べてというのは無い。

会場Q: 具体的にどういう目的でやっている？
A: 類推ワードと関連文書を抽出し、Twitter呟きを使うことで日々
　生まれている単語／略語を類推できるような文書を抽出すること。
会場Q: kizasiみたいなもの？
A: その通り。



B2: テーマセッション4: Twitterと言語処理: パネル討論
最新情報や開発ノウハウについて。
ハッシュタグ: #twitterconf
　togetter: 言語処理学会第17回年次大会-パネル討論[B2-6]Twitter情報を活用したサービスの現状と課題
Twitter研究会
　Twitter, Ust, ATND
以下、
　・パネリストによる数分プレゼン
　・討論お題
　・会場質疑応答
の3部構成。


＞横田 真俊（Twitter解説書著者） @Wslash
Twitter連携サービスの変遷
　BOTの時代
　　今日は何の日？
　　並の人間よりもBOTの方がフォローされる
　ランキングの時代
　　ふぁぼったー、トゥギャッター、バズッター
　Daily meの時代
　　デイリー enews
　　paper.li、Flipboardなど


＞辻村 浩（沖電気工業株式会社） @tsupo
TwitterのStreaming APIを使ってネタ集め
　public_timeline, private_timeline 取り扱いに注意が必要
　　原則として public 使おう
　ログ保存機能のあるTwitterクライアントでひたすら収集
　　Tween, Shiro, Chirrup,,,
　　Twitter IRC gateway(TIG)経由でIRCクライアントの利用も
　REST APIには時間当りの発行回数制限あり
　　ホワイトリスト登録申請はなくなる方向
　Streaming API
　　firehose: Twitter社と契約必要（法人のみ）
　　sample: 契約不要（10~15%に間引きされたもの）
　　filter: 契約次第。検索条件に合致するもののみ取得したいとき。
　参考: FaceBookの場合
　　public_timeline に相当するものは無い
　　基本公開された情報でもないので取り扱い注意


＞榊 剛史（東京大学） @tksakaki
ソーシャルセンサーとしてのTwitter
　Twitterにおける「今」と「どこ」の重要性
　実社会を観測するソーシャルセンサー
　　トレンド・ニュース分析
　　　ツイちぇき！、Buzztter、、
　　評判分析
　　　クチコミ係長、TweetFeel、、、　　　
　情報伝搬分析
　ユーザー影響力分析
　自然現象等の観測
　　カゼミル
　　（終了）みんなの花粉症なう！β
　自然現象の抽出
　　地震検出、虹検出、渋滞・交通情報抽出
　イベント検出の仕組み
　　地震の場合：特定キーワードを含むツイート収集分析＋位置情報
　　ただし位置情報付きツイートは日本全体で5%ぐらい。
　　ユーザプロフィールや、ツイート中の位置情報単語も使う。
　既存ツールでは十分な解析が難しい
　　交互的なツイート、省略表現、略語表現
　実用可能な情報抽出を行っているプロジェクトは少ない
　新しい研究・ビジネスとしての可能性


＞岡野原 大輔（PFI） @hillbig
自然言語処理屋から見たTwitter
　Twitterをコーパスとして活用
　　対話、談話情報が抽出できる
　　周辺情報が豊富
　　量が豊富
　高精度な固有表現抽出が必須
　　その後の精度問題は大抵キーワード抽出の精度が影響
　　tweet特有の表現を真面目に処理
　スケーラブルな処理速度が必要
　自然言語処理の基本的な処理が重要
　　文が短く、省略が多い
　　BOWがうまく動かない場合も多く、真面目な解析が重要！
　　ゼロ照応解析（「俺は良いと思う @RT:….）
　　共参照解析（「AとBなら私は後者」）
　　tweetをまたがるトピック抽出（談話解析）


＞大角 知孝（(NTTコミュニケーションズ株式会社) @elrana
「ツイちぇき！」開発における取り組みと課題
　今、この瞬間に注目されている話題をリアルタイムに分かりやすくお知らせするサイト。
　課題：ツイート取得
　　安定して大量のツイートが必要
　　Search API：断続的に取れないことがあったりする
　　　APIは動いているが更新されない
　　APIが不安定になることを想定した実装
　　並列して異なるAPIを利用
　　　Streaming API  (gardenhose)  + Search API (search.twitter.com)
　　バイアス
　　　場所指定 Search APIとStreaming APIでのツイート文字数比較
　　　場所付きの人はしっかり書いてる傾向
　　Buzz Finder Next(仮称)


＞お題1：Twitterは他の言語処理と比べて何が違うのか。
・ネット特有の言葉が多い（wwwとかも）
・Twitterは一旦投稿したものを削除することはできるが、編集はできない。
　揚げ足取り等に発展しやすい要因の一つ。
・即時性。極めてリアルタイムに近い。
　電車が止まった時にTwitter検索した人挙手→結構いる
・日本語と英語とでも使い方が大きく異なる。
　英語だと単文。日本語だと議論にもなりやすい。
・現実世界との繋がり、コメントしやすさ。
　世の中で起きていることに対してコメントしている。これを取得しやすい。


＞お題2：Twitter情報活用したサービスは色々ある。それらにおける課題や注意点。
・安定したクローラーを書くのが大変。
　普通にAPIで集めるのだと量が足りない。
・Twitterや検索の仕様が結構変わる。
　言語指定の有無で結果が異なるとか。
・データの量が多い。後ろ側で解析する処理が結構しんどい。
　裏側の作りをしっかりしないとサービス提供上の課題。
・Twitter流れてる情報はpublicだけではないので扱いに注意。
・Twitterを認証に使ったサービスが増えてきているが、今後トラブルが出てくるのでは。


＞お題3：今後期待されるようなサービス／技術。どういうアプローチが面白そうか。
・自分の個人情報に着目して補助するサービスが増えると思う。
　Facebookとの使い分けにも興味あり。
・発表にあったトラブル予測のようなものに期待。
　もっと面白いBOTを！
・作ったサービスが期待されるように。
　APIがどんどん更新されて、メタ情報が増えてきている。それを使おう。
・Twitterだけでなく4sqもあるが、空間を有効に利用するサービス。
・ユーザがどういう属性持っていて、どういう話題が受けているかを分かると
　ビジネス的に有効。どう仕掛けたらどう情報が伝搬するかというモデルは
　あるが、それを使った実サービスが出てくるのでは。

Q: Twitterに限らず「情報膨大→要約→嗜好加味した要約」という目的や
　手段の推移は分かるが、これらを「アンケート評価」よりももう少し
　ベンチマーク的な評価をする場をセッティングすることはできないか。
　GroupLensみたいに。


会場質疑応答

会場Q: サービス設計する上でリアルタイムに処理するのか、バッチタイムに
　するのか。システム設計時点でどちらかにすると、もう片方を考慮
　できない。両方を上手くサービス化するための設計は無いものか。
A: リアルタイムの場合でもそのサービスが要求されるのは数分とか10分等、
　サービス次第で異なる。小さいバッチシステムと大きいバッチシステムを
　分けて用意するといったことが考えられる。
A: リアルタイム／バッチ処理かといっても、取りあえず取りこぼしがあると
　クローリング問題。そこをしっかり作って、足りない部分をバッチで対応。

会場Q: 公式報道前にTwitterに流れる情報について。利用にあたり気をつけている
　点があれば。
A: 一番良いのは、上司をフォローしてフォローされること。ある程度見られ
　ているという意識があれば良いのでは。
A: 自分のツイートについては自分の責任。他人のことについてのツイートに
　ついては慎重に投稿するようにしている。
A: いろんな人が見ているので、見られ方次第でネガティブに取られることも
　ある。できるだけポジティブに取られるよう書いている。
会場Q: private/publicがあるとのことだが、tweetには著作権があるのか。分析して
　辞書を作った場合、販売可能か。コーパス公開する際に「やめろ」といった
　ことが無いか。今後どう考えているか。
A: 一応publicになっているので検索エンジンと同じ立場。グレーゾーン。
　Twitterからアクセス止められたら終わりなので、上手くやる必要はあると思う。
A: Ustreamで流した時にそのツイートを表示したら大きな問題になった。
　ユーザ名はぼかして表示するようにしている。
A: グレーゾーン。それがいろんなAPI公開として広がっている部分もある。
　ある程度の許容がもたれているという状況では。



招待講演2: 「実務翻訳の現状と未来」講演者　田中千鶴香 氏（日本翻訳連盟理事・日本語標準スタイルガイド検討委員長）
課題
　コスト削減（プロセス自動化等）
　グローバル化（関連データの標準化）
　ベンダーロックインの回避（Tradosの時代、オープンソース）

支援技術
　Computer Aided Translation: 翻訳メモリーソフトウェア、用語管理ツール等
　Contents Management System: トピック単位で構造化管理、DITA。
　Translation Management System: プロセス自動化、言語資源一元化。
翻訳プロセス全体の自動化
　機械翻訳は自動化された翻訳プロセスの一部
　対象ファイル→準備→XLIFF等→翻訳支援ツール→XIFF等→後処理→出力
　　用語データTBX、翻訳メモリーTMX
　　機械翻訳は翻訳支援ツールの一つ。
実務翻訳関連オープンスタンダード
　翻訳メモリー
　　TMX(LISAの規格), XLIFF(OASIS), SRX(LISA), ITS(W3C)
　用語データ
　　TBX(LISA), UTX(AAMT)
言語資源の活用
　TAUS(Translation Automation User Society)
　TDA(TAUS Data Association)
　　2011年3月より会員以外も翻訳メモリーのup/download可能に。
　　＊uploadは著作権クリアしたもののみ許可。
　　関連URL: TAUS Search
　　　入力文「翻訳機能」→「翻訳 機能」じゃないとうまくいかない。
　　　何かあればTAUSへ。
機械翻訳＋ポストエディット
　MTと人手による後編集
　　機械翻訳の品質に応じてではなく、
　　目標品質に応じてエディット作業を選択。
　　目標品質毎のガイドラインはTAUSが提示している。
　MTのみ／MT+社内ポストエディット／MT+社外ポストエディット（ライト/フル）
実務翻訳は目的・機能を重視
　コストとスピードに応じて設定
　　正しい表記／自然な言葉遣い／読みやすさ／良い翻訳
和訳時の日本語表記の問題
　文字種が多い
　「どのように訳すか」と同時に「どのように表記するか」が問題
　発注者毎に用語や表記仕様が異なり標準化されていない（特にIT業界）
　　コンピューター？コンピュータ？
　　ローカルエリアネットワーク？
　　ローカル・エリア・ネットワーク？ローカル エリア ネットワーク？
　　グラフィカル？グラフィック？
日本語表記への取り組み
　SINAPS Forum
　　日本語表記スタイルガイドを整理
　　　e.g, 半角英数字の前後にスペースの有無、長音の有無、、
表記使用の不統一：まとめ
　百害あって一利無し
　　ガイドラインは機密文書
　　翻訳品質基準の一つ
　　優良企業ほど企業文化を尊重
提案
　表記統一ツールの提案
　　対象ファイルから用語を抽出
　　抽出した用語の標準表記を定義ファイルに従って生成
　　抽出した用語を生成した標準表記の用語に置換
　　元のファイルに書き戻す
　　ファイル形式対応
　問題点
　　辞書登録時のミスが永続化
　　新語はどんどん増えていく
翻訳の本質は不変
　言葉・質に対するこだわり
　「間」の翻訳

Q: 同じ文であったとしても、文脈によって訳仕方が不適切な翻訳結果が
　あると思うが、どのように選択／支援されるべきか？


会場Q: 表記揺れを無くしていくという提案があったが、全世界に強制する
　というものではないという認識で良いか。言葉の表記揺れにも
　コントロール・ランゲージに通じる部分がありそうだが、どう考えているか。
A: 表記ガイドラインに従って翻訳せざるを得ないのが現状で、大変なストレス。
　これを何年も続けているとタマラナイ。自分は自由に書いて、後はツールを
　使うことで企業毎のガイドラインに従う形に変換できるようになれば、
　とても嬉しい。

会場Q: それぞれが自由に書いた文を機械で変換するという話について、
　語だけじゃなく、構文的な部分もできるんじゃないかと思う。
A: そこまでできるのであれば、ニーズもあるはずなので嬉しいです。
会場Q: 開発する場合お金は出るのか。
A: 検討させて頂きます。大きなビジネスチャンスでもあると思う。
会場Q: 翻訳以外にも社内文書スタイルに統一したいというのが恐らく企業ニーズ。
　そういう企業の蓄積したデータが大量にあれば、ここに参加している人は
　そこに統一するというツールはできると思う。ただし精度の問題はあって、
　100％は困難で、いくら貰えるならどこまで精度を高める努力をする、
　という話に落ち着くと思う。ある程度できたらリファインするというのが
　現実的だと思う。
A: 実務翻訳の世界では、扱ってるファイル形式が沢山。こういったものも
　扱えるようになると嬉しい。逆に言うとそこが条件でもある。そこが使えないと
　使い物にならない。抜き出汁と書き出しを人間がやらざるを得ないと、
　物足りず、値段を付け難い。
会場Q: (1)日本語と英語のペアを見ると機械翻訳でも難しいペア。翻訳のコスト
　として違いがあるのか。(2)日本人は言葉に対する思い入れがあるという話が
　あったが、表記の揺れは重要かもしれないが読む側にとってはどうでも良い。
　そこまで求めているかというのはオーバースペックではないか。スペックを
　下げて行く運動があれば、無駄なお金を減らせるのではないか。
A: (1)コストについては、求める品質との兼ね合いによる。言語の違い、
　場所の違いによっても異なり、簡単には言えない。(2)オーバースペックでは
　ないかという点については、その通りだと思う。ユーザは特に考えていない。
　ただし、社内スタイルを変更するためのコスト、揺らぎを許容するための
　コストが大変。
企業Q: ツールを利用する際に、翻訳のように100%マッチしたら問題無いと
　思うが、そうじゃないケースについて。マッチ度合いが少し減る場合、
　自分が訳した方が早いのか。
A: コストの問題でもあるが、がっかり感。



特別講演: 「表現から意味へ：言語処理技術と言語の科学」講演者　辻井潤一 氏（東京大学大学院，マンチェスター大学教授，英国・国立テキストマイニングセンター 研究担当ディレクター）
計算言語学と言語処理
正しいアプローチ？
　テキストに対して野心的な目標
　　T-H pairs／Frameの認識／意味役割の付与
　　特徴抽出器
　　→うまくいかない場合にはここを改善したり、テキスト増やしたり。
　　　チューニングした結果はドメインが変わると知見が活かせない。
　　　→分野適応／モジュラリティ
考えたいこと
　・テキスト表象と「意味」や「解釈」との間には大きなギャップがある。
　　目標が恣意的あるいは過度に野心的に設定されていないか。
　・人間の言語処理アーキテクチャは複雑。
　　単一の機械学習器だけでは不十分では？
　・巨大データへと向かう方向とは別の研究方向もあるのでは？
工学と科学
　SRL, Textual Entailment
　　句構造、依存構造、意味ラベル
　　　観測不可なものがアノテートされる。NLP応用上嬉しいから付けているだけ。
　　　理論的正当化なく試行錯誤的に行われる。
　　　疑似科学的な定量的評価。
　　　→理論的により設定＋理論からの吟味＋正当化が必要では。
　　言語的な表現レベル
　　　深層と表層
　　　多層的な理論 vs. 炭層的な理論
　　説明すべきデータと説明すべきでないデータ
　　生得説と連合説
　　　言語処理に特化した計算アーキテクチャ？
　　量には還元できない特異な構造
　　質／効率／モジュラリティ／適応可能性への寄与
The modularity of Mind/精神のモジュール形式
　批判されるべき箇所は多分にあるが、分かりやすい形を提示。
　　言語処理のある部分は周辺系にあり、情報遮断性がある。
　　中央系は非限定的な情報参照があり、科学の対象としては研究できない。
　　→強すぎる主張ではあるが、ごった混ぜにしない点は有益では。
文法理論に基づく深い文解析
　制約文法の研究CL：可能な解の集合（句構造木＋述語-項構造）
　文解析器の研究NLP：可能な解の確率分布
　　両者を切り離して見つけることを研究し過ぎていて、
　　どういう解があり得るか、どういう制約を満たしているか、
　　といった側面がお座なりでは。統合されるべきだろう。
　意味に基づく知的な文検索システム MEDIE
何が計算できるかをきちんと定義する必要があるだろう。
どういう構造を計算したら良いのかを決める。
文法理論
　初期の変形生成文法：深層構造で表層の違いを解消したい。（表現と計算の混同）
　生成意味論：深層過ぎる。（野心的過ぎて奇妙な規則／雑多な系）
　解釈意味論：あまり表層と変わっていない。（宣言的な関係記述）
　　→表層／深層を宣言的に記述する
HPSG（主辞駆動句構造文法）
　辞書として記述
　　e.g, love: 動詞、主語1つ、目的語1つ
　文法規則
　　テンプレートとして記述
　　　ユニフィケーション
　　　情報伝搬
　　　→辞書項目に、統語構造と意味構造の写像関係が規定される
　複雑な統語構造から意味への写像
深い解析器に関する二つの見方
　(1)入力→機械学習器→出力
　　入力は様々な特徴抽出により雑多に生成
　　出力に、フレーム／フレーム要素の認識（FrameNet）は野心的すぎる。
　　出力に、意味ラベル（PropBank）もまあだ野心的。
　(2)文→深い文解析器→HPSGによる派生過程→述語-項構造(深い統語構造)
　各々タスク設定が異なる。
　(2)では比較的浅い所に「述語-項構造」が来る。
広いカバーレッジの文法
　文法開発と評価のための木構造バンク
　　派生構造にある確率分布も計算できるので、最も適切な構造を選択する問題に。
　文解析の難しさ
　　カタラン数
　　優先解釈の選択
　　　比較的もっともらしい解釈をうまく選んでくれる確率モデルが必要
　　　確率HPSG
高い効率の文解析
実用上は速くないと使えない
　ユニフィケーションを速くするだけではダメで、
　ユニフィケーションしない（ユニフィケーションする回数を減らす）、
　まで考える必要あり。
　→探索問題
　　CFGフィルタリング、高効率な探索手法、スーパータギング
　　ビームサーチ
　　　ビーム幅を狭くしても大抵は上手くいく。
　　　失敗した時だけビーム幅を広げてやり直す。
スーパータギングによる文解析器
局所処理と周辺文脈
意味の構成性(Compositionally)
　フレーゲの原理：全体の意味は、部分の意味から決定される
　ボトムアップに意味は計算できる
　周辺文脈からの優先解釈の決定
　　辞書項目を選ぶ場合に、周辺を見て選ぶ→スーパータギング
優先探索を木構造作る過程でやるより、
木構造は作ってしまった後で項目選択時にやる。
スーパータギングのモデルにフィードフォワードする等でより高度に発展させると、
ユニフィケーションせずに探索問題として解けて、効率も良いシステムが作れる可能性。
統合的なモデルから段階的なモデル、
初期の段階で豊かな情報を参照するモデルが高効率な処理モデルになり得る。
述語-項構造は、より深い構造へと情報を写像するためのインタフェース表現となる。
巨大な学習データがあっても良いと思うが、
人間は、巨大な学習データを必要としないように見える。

Q: 安易に機械学習で何かをまとめて学習するというアプローチはそもそも
　無理筋じゃないかというのは全く持ってその通りだと思う。そこを人間が
　試行錯誤的にデザインしている部分そのものを機械化してしまえば、
　と思うが、それでも計算リソース的には厳し過ぎるのだろうな。
　そもそもそこを定式化（≒システム化）できていないわけだし。


会場Q: 生命科学の分野に特化されてイベントへのマッピング等をやる場合、
　一般の場合にはどう手をつけたら良いかがまた悩ましい。どうアプローチ
　したら良いか。
A: ドメイン特化知識と一般言語を繋げる所に、もう少し意味が寄与している
　ように思う。言語だけでも知識だけでもないような部分を捉える必要がある。
　ただし直接的にやろうとすると非常に粗い研究テーマになるので、
　今はドメインでやってみたい。ワトソンも、かなりドメインを絞った特殊化
　されたシステム。事象は何か、関係とは何かというのはまだ早いかなという印象。

会場Q: 巨大なデータを必要としないという点について、確かに巨大データを
　食わせるのはどちらかというと嫌。ただ食わせるだけではなく、裏にある
　何かについてもデータを必要としない考え方や枠組みが必要ではないか。
　スーパータガーのモデルをどう作るか。
A: 巨大データの是非については議論の余地がある所。巨大データは知性とは
　全く違うので、人間には無いような何かを持つ可能性もあり得る。
　何かヒントが見えるところは否定できない。何をストラテジーに研究するか
　ということ考えると、ドメイン・アダプテーションについて、比較的早く
　適用するというタイプの研究もあり得ると思う。個人の話としては、
　巨大データを食わせてドメイン特化モデルを別分野に適用する際に、
　なるべくかかるコストを少なくしたい。ある種パラメタライズされた
　ようなモデルかもしれない。パラメタさえ分かれば調整できる、
　そういう感じのことをやりたい。



P3: ポスター(3)
P3-3 英語論文表現データベースを用いた分野横断的ムーブ分析 (pp.591-594)

○金丸敏幸, マスワナ紗矢子 (京大), 笹尾洋介 (ヴィクトリア大), 田地野彰 (京大)
論文の構造が「背景→目的→、、、」とかIMRDという順番になっているかを
大量文献＆人海戦術で調査してみたという話。アノテーション自体に揺らぎが
多く含まれているっぽいけど、こういうのが積み重なると、
「こういうストーリー構成の物語を読みたい」みたいな検索ができたりするんだろうか。
P3-4 語の共起を効率的に検索できる日本語作文支援システム「なつめ」の紹介 (pp.595-598)

○阿辺川武 (NII), ホドシチェク・ボル, 仁科喜久子 (東工大)
当初は留学生向けの作文支援ということだったようだけど、
特に留学生に限定する必要ないよねということで表記のタイトルになってるらしい。
限定する必要が本当に無いのかが気がかりで質問してみたのだけど、
本当の所はどうなんだろう。
P3-8 短答式記述答案の採点支援ツールの開発と評価 (pp.611-614)

○中島功滋 (ベネッセ/CRET)
比較的単文（1文とか2文？）を想定した採点支援のため、
クラスタリングすることで似たような回答群としての提示と、
参考回答とのBLUE距離で参考採点付けてみたらしい。
問題文も利用できそうなんだけど、そこは手つかずっぽい。
P3-10 汎用アノテーションツールSlate (pp.619-622)

○Dain Kaplan, 飯田龍, 徳永健伸 (東工大)
多分、嬉しいツールなんだと思うけど、
「こういうアノテーションにはこういう属性名付けると良いですよ」
みたいな推薦までサポートしないと使い難そう（アノテーション結果を
利用するユーザにとって使い難そう）な予感（勝手な想像）。
クラウド的にアノテーションされたデータ蓄積しまくって、
傾向抽出すると面白そうなんだけど、どうなんだろう。
P3-11 『日本語話し言葉コーパス』における話題導入表現の形態統語論的特徴と談話構造の分析 (pp.623-626)

○高梨克也 (JST/京大)
面白そうなんだけど客多数で話聞くタイミングが合わず。後で読もう。
P3-12	複数の客観的手法を用いたテキスト含意認識評価セットの構築 (pp.627-630)

○宇高邦弘, 山本和英 (長岡技科大)
逆説的なのか自分自身で良く分かってないですが、
主文から推察できる事象を、その確度と共に生成できると便利そうなんだけど、
同じ話なんだろうか、違う話なんだろうか。
P3-21 長単位に基づく『現代日本語書き言葉均衡コーパス』の品詞比率に関する分析 (pp.663-666)

○冨士池優美, 小西光, 小椋秀樹, 小木曽智信, 小磯花絵 (国語研)
素性に「形態素、句、節」といった単位とは別（？）に、
「短単位、長単位」という言語単位があるっぽい。
P3-29 筆跡とパーソナリティの多面的対比 (pp.691-694)

○高野孔司, 久野雅樹 (電通大)
心理学？だかである程度の傾向はあるものと解釈するのが正しいのだと
思ってましたが、そうでもないのかしら。問題設定（テスト環境の設定）
次第でどうにでも解釈が変わりそうでもあるので、そこら辺の話が気になります。