言語処理学会第19回年次大会(NLP2013) チュートリアル終了
NLP2013の前夜祭的なイベントという認識ですが、チュートリアルが終了しました。大会場はテーブル付いてて割と電源も豊富で無線LAN完備。地下鉄の駅出口から徒歩1分。名古屋は地下鉄移動が便利すぎて地図的な位置関係が全く脳内構築されませんｗ
午前中に参加した「言語処理研究におけるソフトウェアの開発と公開」は3部構成。
最初の「研究を進める上で有用なコーディング極意」では、大学というか研究室で繰り返されているであろう負の連鎖（〆切直前に結果の誤りを発見、コード複雑すぎて解読不能、結果が残っていない、etc.）に対してどう取り組んでいるかという話。言語処理100本ノックではUnix的な極意（小さく分解して、細かい部品毎に正しく動くようにし、様々な組み合わせで問題に取り組み、簡単に再現できるようにする）のを自然と学べるように構成を工夫しているらしい。研究室で取り組んでいるだけあって、論文化することを最優先することで「最終的に何をどう用意したら良いか」を一通りこなして初めて振り返られる気づきを得られるという話も。個人的には学部3年次向けの実験としてどう設計しようかと悩んでいるところですが、100本ノックを真似るところからやるのもありかなぁ。
2番目の「研究で開発したコードの公開」では、（検証しているところのみに重点を置いているという意味で）一点突破型の実験コードというレベルと、一般的なソフトウェアというレベルに分けて考え、実験コードでもどしどし公開しようという話。そうしないと再現困難だったりするし、（公開を前提としたレベルでドキュメント化してないと）研究室内でも引き継ぎにくいから財産となりにくく埋もれてしまうよね、と。公開するからには最低でも「結果を再現できる」だけの情報は付けよう。知財の絡みで公開困難なケースでは、バイナリ提供やデモサーバ公開とかいう形もあるよねという話も。
3番目の「企業における自然言語処理と開発手法」では、企業だからこそ求められる（求めていく必要がある）品質を改善・可視化するためにもテストが必須で、結果として「正しく動いているか（ソフトウェアとしての品質）」というテストと「解析結果が正しいか（自然言語としての品質）」を明確に区別し、自然言語の質を高めることに注力することにも役立つという話。今回は「単体テスト」レベルの話で、言語処理の品質、例えば「東京都」という文字を形態素解析させた結果が「東、京都」になるのか「東京、都」になるのかどちらかが正しいかというのはソフトウェア・テストとしては設計不十分で、スタブによる仮モジュール（この例では辞書を設定するとか）の導入や、モックにより関数／メソッドが正しく呼ばれているかを検証することで「ソフトウェア的な意味での品質」をテストしやすくなるよ（その分本当にやりたい言語処理の品質改善に注力できるよ）、と。個人的にはスタブ＆モックするようなレベルでのテストはやったことないのですが、「テストのテスト」が必要そうになりそう点を懸念してしまったり。
午後のチュートリアルは「言語処理の後先（あとさき）」に参加。従来の多くの言語研究（主に心理実験を用いた語彙獲得や認知に関する事例）では元々曖昧な概念である「語彙」が分かりきっている前提で進められているが、そこをあやふやなまま進めてしまって良いのかという問題意識があり、言語だけに特化せず身体を含めたり、そもそも一人だけをモデル化するのではなく二人をモデル化してみないと見えて来ないものがあるよね等、多岐に渡る事例を交えながらの「意味はどこから来てどこえ行くのか」という話。個人的にも賛同している視点で、語彙がそもそもあやふやだという話は
- 認知科学の今井先生が言う所の「連続的に推移する世界はことばによって離散的に分節され、カテゴリーを発見・想像・修正を繰り返すことで多層的かつ重層的に捉える」
- 医学・認知神経学の大槻先生が言う所の「視覚情報では認知できなくとも非視覚情報では認知できたりすることから、入力モダリティ毎に意味システムを構築していると考えざるを得ない」
- 場の言語学で言う所の「身体を通した自己の二重性と即興劇モデルに基づく共存在の深化（身体と身体、身体と環境との相互作用）が主体的な意識を形成し、コミュニケーションが産まれて言語へと発達した」
に共通している話かなと思いながら聞いていました。ジェスチャーに「話をする負担を減らしている側面がありそう」という解釈（できなくもない結果）も面白かった。
終了後は学内にあるスタバで学生の発表資料チェック。晩ご飯はホテル近くで適当に探した手打ちうどん 五城で食べてきました。味噌煮込みうどん美味しかったんだけど、ひょっとして煮込みうどんだと「手打ち」じゃない専用のうどん麺なんだろうか。普通のもちもち触感のうどん麺で煮込みうどん食べたいんだけどな。
以下、参加したチュートリアルのメモです。
目次
- チュートリアル T-a, 言語処理研究におけるソフトウェアの開発と公開
チュートリアル T-a, 司会：ニュービッグ グラム (NAIST), 言語処理研究におけるソフトウェアの開発と公開, 岡崎 直観 氏（東北大学）, 吉永 直樹 氏（東京大学）, 工藤 拓 氏（グーグル株式会社）
研究を進める上で有用なコーディングの極意（岡崎）
研究を進める上でのコーディング作法は教えてくれない
（自然言語において）研究の成果物は知見（論文）であって、作ったソフトウェアそのものではない ソフトウェアエンジニアの仕事とはかなり違う
対象：仕様が決まっている vs 解かれていない問題
目的：利益を得る vs アイデア（実験結果）を検証
言語処理100本ノック
小さい処理に分解し結合せよ
道具を使え
自分を過信せず検証せよ
常に検証に備えよ
研究成果を可視化せよ
最適化・整理は完成してから
論文を書いたらコードを整理せよ
naltoma: 学部3年次向け（プログラミング導入は済んでいいるがまだ研究室に配属していない、
専門が決まっていないという段階）でも、
普遍的な能力を養うという点では同じ方針でやれそうかしら？
Q: 100本ノックについて、具体的にどうやって演習する？
A: 1週間に1回2時間問題を解いてきて皆でレビューする。
先輩をチューターにつけて、討論。
研究で開発したコードの公開（吉永）
研究者がコードを公開する意義
実験結果の再現性を保証
公開しないと実質的に再現困難
ツールとしての共有資産化／研究成果の社会への還元
2種類のレベルでの公開：実験コードとソフトウェア
実験コード
一点突破
公開するコードをまとめる／README（再現方法）／使用条件／研究手法と対応付けて公開
公開できない場合
コード・READMEを引き継ぐ
バイナリ形式での公開／デモ・実験サーバの提供／代理実行
公開をためらう場合
そのコードで削減される時間があることを意識する
ソフトウェア
ソフトウェア化に値する手法はごく一部
多様な価値観に晒される
naltoma: うちの学生にも公開前提でやらせてみよう〜。
Q: 論文書き上がる頃にはコードがごちゃごちゃしてて出すのは忍びない。
A: 実験コードレベルで終わるのか、ソフトウェアまでを想定しているのかを
意識してコーディングしていくことも重要かと思う。
実験コードについては割り切って出すのが良いのでは。
Q: 仕様固めてから研究しても、研究している間に仕様が変わっていくことは良くある。
A: あまり綺麗なコードといってると研究が進まない。
時間のある範囲で綺麗なコードで十分では。
まずは1,2回公開してみると掴めることもある。
Q: プログラムの公開について、言語やインストール方法とか様々あるが。
A: 重要なことだとは思うが、個人的にはC++で書いている。
できる限りプラットフォーム・フリーにしたいと考えている。
ダウンロード数を見る限りでは圧倒的に Windows 版が多い。
企業における言語処理研究・開発（工藤）
2種類の品質
ソフトウェアとしての品質
自然言語処理としての品質
テストの役割
予期せぬ動作と解析誤りの明確な分類
コミュニケーションの道具
人材・プログラムの流動性が活発（弄りやすい／引き継ぎしやすい）
ソフトウェアテスト
リファクタリング
テスト駆動開発：失敗するテストをコーディング前に作成
YAGNI (You ain’t gonna need it)
必要になるまで機能追加しない原則
コードの不必要な複雑性を排除
適度なコードの抽象性はテストによって担保される
解析誤りと正しい動作を混同しない
テストダブル (Test Double)
あるシステムが依存しているコンポーネントを置き換える代用品
依存先が常にあるとは限らない
スタブとモック
スタブ：決められた動作だけを行う代役（e.g., 必ず false を返す）
モック：メソッド呼び出しの検証を行うための代役（e.g., メソッド呼び出し回数を記録するカウンタ）
stub を inject して mock しながら検証
依存性の注入 (Dependency Injection)
コンポーネント間の依存性を外部から動的に注入できる設計
何に依存するかは実行時まで分からない
DIコンテナ
十分なテスト（正しい動作）をすることで、真の解析誤りに注力
評価
機械的・平均的評価
回帰テスト：「絶対変換・解析で気無いとまずい」例によるテスト
ユーザビリティテスト
見える化
naltoma: テストのテストが必要になったりしそう。
テストの自動生成でなくても良いけど、テスト作成のコストを下げられないか？
Q: テストについて。大学レベルではそこまで使われるのか。
A: 多分、大学ではやる必要は無い。
ただし、形態素解析作ってたりすると「当たり前のことを間違える」というケースが多い。
回帰テスト用意しとくだけでもいろんな応用が効くと思う。
チュートリアル T-c, 司会：丸山 岳彦 (国語研), 言語処理の後先（あとさき）：意味はどこから来てどこへ行くのか．, 齋藤 洋典 氏（名古屋大学）
言語活動／心的活動／意味処理活動／心理実験／脳イメージング／言語と行為の関係
はじめに
言語と身体（言語処理と非言語処理）
身体運動を含む多様な処理を認め、意味を創出し理解する仕組みは「どこから来てどこへ行くのか」。
e.g., ジェスチャー：必ずしも意味を特定する訳には使われないが、未だに使われ続けている。
意識と脳（意識処理と非意識処理）
自己と他者（一人の脳と二人の脳）
言語は本質的に他人との関わりの中で発展してきた。
語彙と語彙接近モデル
そもそも語彙／語は曖昧
心理学での語彙研究：語の連想記憶／語と知能／単語の読み
単語優位効果：学習＝概念と概念の結びつき。単語の中にその力が含まれている（？）。
問い「意味（こころ）は脳のどこにあるのか？」という問いは適切か？
そもそもどこか1カ所に貯蔵されているもの？
従来の語彙接近（lexical access: 単語検索）：限りなく近づくが、到達はしていない。語彙性判断。
問いかけ：言語だけが浮き上がってくるのは何故か？
問いかけ：手（ジェスチャー）での処理が先に終わってて、後から言葉が修正することもある。
残された課題
多感覚入力／複数出力の処理統合。非言語処理、身体運動、意図理解等。
話者/聴取に閉じないモデルの構築。一人の脳から二人の脳へ。
漢字の読み処理
見える「もの」と見えない「こと」
漢字「で」研究
講義の意味理解：少ない情報でより確実な未来を予測する
読み間違いは目の誤りではなく脳の誤り
漢字の形態要素の配置と音韻の両方で起きる。
部首の位置と音の確率的な結びつきの知識を持っており、それらの影響を受ける。
発話と身振り
発話に伴う自発的な身振りは、だれのどのような役に立っているのか？
半分は自分のため？
表象的身振り（発話と関連する意味的な内容を描く身振り）
ビート（意味的な内容を含まず、単純でリズムに乗った身振り）
聞き手指向／話して指向 vs 対面パラダイム [Alibali et al., 2001]
話し手は、聞き手が見えない状況でも身振りを算出するか？
減りはするが、無くならない
カメラを通した想像条件でも無くならない
盲人同士（見たことも無い）がジェスチャーをする
ジェスチャーが発話者本人にとってどういう意味があるか？
スピーチの負担が減る（？）
e.g., 第2言語ではジェスチャーが増える≒フレーミング（枠組み構築）に使っているのでは
行為と言語化
ボールを投げる動作／投げるシミュレーション／観察／言語化が同一の機能なのか？
10分前にやったことは後続観察課題で想起されるが、それを言語化するとdischargeされる
一人の脳から二人の脳へ（脳機能の連携による意図と共感の算出と理解）
行為も言語化もせずただ認めるだけで、脳の特定領域が活性化される
naltoma: ヒトと同等のセンサを有するロボット（≒身体を有する何か）を作り得たとして、
そのロボットが「ヒトと同様に感じ、語彙を獲得し、学んでいく」ためには何が必要だろう？
Q: 漢字の例で、似ている意味、似ている音が間違いに寄与しているのではないか。
A: 漢字に関するデータを見る限り、まず形の類似性が間違いを大きく引き起こす。
音も引き起こすケースはあるが、音単独では起こらない。そのぐらい、脳は賢い。
脳はあってるがそれを報告するヒトが（気づかずに）間違うこともある。
脳は知っているが、explicit にはヒトが知っていないことがある。