始めたら絶対にハマると分かってたので、これまで約２年間確信犯的に（←誤用）近づかないでいたtwitterだけど、長期で海外にいる今こそアウトプットの必要性をひしひしと感じているのではじめてみました。ブログにするまでもない、くだらないネタや日記的なものを更新していこうと思う。

http://twitter.com/mhagiwara

そうしたら自分が書く内容のほとんどがブログにするまでもないものであることに気づいたので、しばらくはそっち中心に更新していくかも。たぶん中国語の話が多いです。

しかし twitter がほとんどのブロガーの執筆欲を奪ってるっていうのは本当かもなー。twitter がなかったらブログ界はもっと良記事であふれるに違いない。（だらだらと雑談 or 独り言　を書きながらそれがアウトプットになってるっていうのは確かに良いかも）

バイドゥ(百度)の上海研究開発センターにリロケーションして３週間経った。日本ではＧＷ真っ盛りの週末、中国でも３．５連休（なぜ３．５連休かは後述）が取れてやっと少しゆっくりできたので、そろそろ上海でのエンジニア生活について書いてみる。

仕事について

中国側の社員は総じてみんな若い。上で３．５連休と書いたけど、実は中国の５月４日は青年節といって、２８歳以下の社員はみんな半休がもらえる。上海オフィスで該当するのはマネージャ職２人を除く全員（自分も含む）らしいということで、その平均年齢の低さが分かる。でもみんなすごく優秀なのが、一緒に仕事をしているとすぐ分かる。

インターンが社員に混ざってバリバリ仕事をしているのは自分が行ったGoogleやMicrosoftと同じで、しばらく社員だと思ってたぐらい。インターンから正社員になる条件付き確率はここでもけっこう高い一方で、インターンの選考はかなり熾烈らしい。この時期、面接も随時行われていて、受付で待っている緊張した面持ちのインターン達とすれ違うと、少し応援したくなってくる。

雰囲気は、ベンチャーっぽい雰囲気の日本法人よりもさらにGoogleに近い。特に会議の雰囲気とか（でもこの辺はどっちかっていうとマネジメントの上手さによるものかも） Google（本社）の雰囲気は、どのベンチャーとも大企業とも一線を画していると思う。

言語について

英語・中国語・日本語が飛び交う社内は、自他ともに認める言語オタクとしてタマラナイ環境である。今、関わっているプロジェクトの共通言語は英語で、マネージャー級はもちろん、社内のエンジニアの英語力は総じて高いので、とても快適に仕事をさせてもらっている。下手したら、去年アメリカでインターンしていた時（上司が日本人）よりも英語しゃべってる割合はずっと高い。

でも、中国人同士で議論が白熱した時はやっぱり中国語に切り替わって自分はついて行けないし、このままでは快適に仕事が出来すぎて中国語が全然上達しないままリロケーション期間が終わって帰国する可能性がある。それじゃあなんかもったいないし、仕事以外の生活もあるので、とりあえずプライベートでは意地でも英語話さないようにしている（というか、そもそも街では英語がほとんど通じないのだけど）

日本でとりあえず中国語検定３級までは取っていって、中学卒業レベルの英語程度なら話せるのだけど、やっぱりそれじゃあ全然足りないので、語学学校や家庭教師等を同僚の助けで色々と探しているところ。上海で有名な巨大書店の上海書城や上海外文書店に行ってみたのだけど、中国語学習関連の書籍がこれでもか！というほど揃っていて、勉強するモチベーション的にも最高。これは英語圏で生活するよりも全然楽しいなー。

宿について

リロケーションして最初の２週間はホテル住まいをしながら仕事＋アパートを探しつつ、その後引っ越しというスケジュールだった。来て数週間で、言葉も不十分なままアパート探しは大変だなぁと思っていたら、日本で言うマンスリーマンション的なものを会社側が手配してくれたのでその心配は無かったのだった。

実は近年の上海の不動産価格の上がり様は異常のようで、家賃も下手したら東京に肩を並べるぐらいなんじゃないかと思う（実際、東京の自分のアパートより高い）。去年のインターン時のMSRもそうだったが、なんだか待遇が良くてこっちが申し訳ないぐらい。

あと、上海で、宿について気をつけたいのが「騒音」の問題だと思う。上海万博に向けて（かどうか知らないが）上海は建設ラッシュで、町中のいたるところで道や建物を、夜中・休日構わず工事していて、出来るならなるべく上の階の部屋を借りたほうが良い。たとえるなら、市全体からずっと「ゴォー」という地鳴りがしている感じ。あと、同じ階でも高架道路の方に面しているかどうかでも全然違う。

食事について

普段は昼からさっそく同僚達とぐーるぐーる回る式の中華レストランに行っているのだけど、一人あたり２０元（＝約３００円）も出せば美味しい中華がお腹いっぱい食べられる。上海の料理は中国各地の料理と比べても日本人の口にも合うようで（辛すぎず、油っこすぎず）、食事については文句の付けようがない。住んでるアパートのキッチンが、中国らしからぬショボさ（ただの電熱プレートに、１００均で買ったかのようなフライパン）なのも、自炊するモチベーションを急激に下げている一因である。

もちろん、「地球の歩き方」系のガイドブックに載っている店に適当に行ってみてもそれなりに旨い。ただしこの場合、必ずしも安いとは限らないのでちょっと注意かも。

一人の時は、街角で、日本で言う肉まん（肉包）系を１個０．５元で買ったり、街角の拉麺屋（日本式ではない）に入ったりもするけど、これも１０元（＝約１５０円）以下でお腹いっぱい食べられる。味は店やメニューによりけりだけど、今のところボラれたり、変な病気になったりした事はないので大丈夫だとおもう。

あと、朝早くバイドゥのオフィスに行くと軽い朝食が無料で出る。あと、同じビルにある施設で卓球やビリヤードで遊べたり。この辺もなんだかGoogleっぽい。（どうでも良いが、中国語で「卓球」と言うとビリヤードのことである。自分も含めて、みんなビリヤードを英語で何と言うかよく分からないので、ここだけ中国語だったり。）

生活について

アパートは地下鉄２号線の静安寺駅から歩いてすぐのところにあって、ちょっとうるさいけど、同僚いわく「上海の新宿」と言うだけあって住むには超便利なスポットである。「久光」という日系デパート＋スーパーもあって、ちょっと高いが何でも揃う。一駅行くと南京西路駅（こっちは雰囲気的に「上海の銀座」にちかい）、もう一駅行くと市の中心である人民公園駅で、他の主要な場所も乗り換えてどこでも行ける。

上海は下手したら東京よりも都会で何でもあって便利だし、車が無いと基本的に生活できないアメリカと違って、自転車と地下鉄、そして、タクシー（初乗りが約１５０円程度と、これがまた安い）でどこでも行けるのでずっとこっちのほうが好きだな。

他にも、自転車買った話、携帯無くしてまた買った話、観光行った話、「上海の秋葉原」徐家汇の話などいろいろあるけど、よく考えたら「ソフトウェアエンジニア」全く関係ないのでこの辺で。上海においでの際はぜひご一報ください～

（写真：香港大学から見た高層アパート群と、ヴィクトリア・ピークからの夜景）

週末から今日にかけて、研究室で参加している

日本法令翻訳プロジェクト
http://www.kl.i.is.nagoya-u.ac.jp/told/

の関係で香港大学を訪問していました。

自分は法律文に統計的自然言語処理を適用する話について研究紹介。基本的には、去年の夏に参加した、法律情報学の国際ワークショップJURISIN 2008で発表した内容と同じ。前にも書いたけど、日本の法律文というのは定型性が高いので、自然言語処理の分野で提案された統計的手法などを適用したら嬉しいよね、という話。

もう一つの研究紹介は、小川先生のBilingual KWICで、単語のアラインメントをさせながらパラレルコーパスをKWIC形式で検索できるツールである。KWICとアラインメントという、どちらもそれ単体では既に枯れた技術だが、それを組み合わせるとものすごく便利になるよ、という話の好例だと思う。

この「対応単語がわかるパラレルコーパス検索エンジン」、shimaさんのブログのエントリ：

外国語学習に役立つ、対応単語がわかるパラレルコーパス検索エンジン「LINEAR B」
http://w-it.jp/shima/2009/03/linear_b.html

には、「どなたか英語<–>日本語あたりで似たようなシステムを作ってみてはいかがでしょう？」とあるが、既にここにあるよ～！ということで紹介してみました。

この「Bilingual KWIC」、今コーパスとしては法律文が入っているが、一般のパラレルコーパスを入れて英語学習者向けに公開したらウケるのは間違いない。法律関係の用語にはめっぽう強く、例えば「証券会社」と入れるとちゃんと「securities corporation」「securities company」といった訳語を推定してくれて賢い。

香港について

今回、香港に行ったのは初めてだったけど、歴史的経緯のせいで、英語、広東語、標準中国語（普通話）が街中に飛び交う、なかなかマルチリンガルな地域である。それだけで自他ともに認める自分のような「語学マニア」にはたまらない。たとえば、地下鉄のアナウンスは、広東語、普通話、英語の順に３言語で同じ内容を言うのでなんだか長ったらしくて騒がしいが、聞いてみると単に「列車とホームの隙間にご注意ください」ぐらいしか言っていなかったりする。

そのためあって、法律の言語関係は色々大変とのことで、カナダ（英語＋フランス語）と同様に中国語と英語で、最初からパラレルに法律が書かれるそうな。

英語の通用範囲はかなり広いし、標準中国語もけっこう通じるようだし（拙いフレーズを買い物するときに少し使ってみたが、こっちのほうが地元の店の人には通用するみたい）、何より書いてあるのが繁体字なので、標準中国語で使われる簡体字よりも日本人に優しいというのが良い。アジアの典型的な（カオスな）町並みと近代的なビル群が混ざったような風景は面白いし、言葉の関係もあって海外旅行初心者には良い目的地だと思う（あと料理がホントおいしい！）。そのためあって、空港まで迎えに来てくれた弟夫婦に激しくオススメしておいた。

週末から今日にかけて、研究室で参加している

日本法令翻訳プロジェクト
http://www.kl.i.is.nagoya-u.ac.jp/told/

の関係で香港大学を訪問していました。自分は法律文に統計的自然言語処理を適用する話について研究紹介。

また詳細はあとで書きます。（溜まったメールも返信します。。。）

引き続き、先週鳥取で行われた自然言語処理年次大会(NLP2009)の本会議3日目について書きます。

まずは、個人的に興味のあった発表について。

超大規模ウェブコーパスを用いた分布類似度計算
（京大 柴田さん他）

超大規模ウェブコーパスとして、検索エンジンTSUBAKIの1億ページを使って分布類似度を計算し、類義語を求めました、というお話。

「超大規模」と銘うってある割には、高速化や近似処理などの「超大規模ならでは」の話があまり無かったように思える点は残念である。一点、ふんだんなコーパスサイズを利用して、「コーパスサイズを変えると分布類似度の性能はどう変化するか」が詳細に調査されてて、この研究で扱った1.6G文ほどあれば十分のようだ、という結果である。

個人的な経験としては、分布類似度の計算には、文脈の量も大事だが、それよりも「多様さ」（異なり数）がけっこう利くので、ある程度量を確保したら、それ以上コーパスサイズを増やしても多様性は少ししか（コーパスサイズのlogを下回るペースでしか）増えないので性能が飽和するのだろう。直感的に。

これに関連して、超大規模コーパスから文脈類似度を計算する話としては、

James Gorman and James R. Curran
Scaling Distributional Similarity to Large Corpora
In Proc. of COLING/ACL 2006

が詳しくてオススメ。ここでは、大規模コーパスからの分布類似度の計算のために、

- RI; Random Indexing
- LSH; Locality Sensitive Hashing
- VPT; Vantage Point Tree
- PLEB; Point Location in Equal Balls
- SASH; Spatial Approximation Sample Hierarchy

などの、ベクトルモデルでk近傍を高速に求めるための近似手法がいくつか比較されている。結果的には、速度ではRandom Indexingが、近似精度ではSASHが良かったという話である。ベクトル間の類似度を求める処理は自然言語処理に限らず色んなところに出てきて、どれがうまく行くか、というのはある程度タスク依存なところも有ると思うが、こういった手法をカタログ的に知っておくのは有用である。

グラフカーネルに基づく非分かち書き文からの意味的語彙カテゴリの抽出
（自分の発表） 発表スライド

自分の発表したD4:マイニング(1)のセッションに面白そうな話が集まっていたのが理由だと思うけど、とてもたくさんの人に見に来て頂いて圧倒されそうだった。質問・コメント等に関しても、セッション中およびセッションの後にまで及んで本当に数え切れないぐらいの人から有用なフィードバックを頂いて、ただただ感謝するばかりである。こういう点に関して、自分は他人の研究に質問・コメントしたりするのが全然まだまだだなぁと感じるので、微力ながらこうやってブログで紹介等を書くのがせめてもの罪滅ぼしである。

実は今回の話、NAISTの小町さんらのグループの話にかなりの部分が依存していて、論文等も引用しまくっている。それもあって、原稿を投稿した直後に「論文引用したので、ちゃんと引用できてるか、よかったら読んでください」といって本人に直接、原稿を送ったのだった。結局、引用をチェックしてもらえただけではなく、脚注中のタイポまで指摘してもらい（！）とても有用な経験だったので、今後もできるだけ続けていきたい。（参考文献がほとんど英語なので、これを実行しようとすると自動的に論文は英語でしか書けなくなるけど）

この「論文を引用したら著者に見せる」メソッド、実は前コメントでshimaさんに紹介してもらった、MSRのSimon Peyton JonesのHow to write a great research paperの中にあった、

A good plan: when you think you are done, send the　draft to the competition saying “could you help me ensure that I describe your work fairly?”
（「関連研究」を書き終えた時点で、論文のドラフトを引用した競合相手に送り、「あなたの研究をちゃんと引用できているか確認してもらえますか？」と言うと良い）

というアドバイスを愚直に実行してみたものである。思えば、引用される側からしても、自分の論文が引用されていれば嫌な気はしないし（というかけっこう嬉しいし）、それを元にどんな研究がなされたのか、論文中でどのように言及されているかは気になるところであるので、両者ともハッピーなのではないだろうか。

ちなみに上の「How to write a great research paper」、これ以外にも

- 研究をやる前に論文を書け
- 論文の目的はシステムの紹介ではない
- 本論文の構成は、以下の通りである・・・はやめれ
- 例を使え
- 従来研究を高く評価しても、自分の研究の評価を下げることにならない

等々、有用なコメントがたくさんあるので、論文書く前に何度でも読み返したい。

先週鳥取で行われた自然言語処理年次大会(NLP2009)の本会議2日目について書きます。

意味的類似度を利用した日本語クエリ書き換え

この日のポスター発表では、去年の夏にMicrosoft Researchで取り組んだ「意味的類似度を利用した日本語クエリ書き換え」のプロジェクトについて話してきた。この話については、去年の９月に熱海で行われたNLP若手の会(YANS)の第３回シンポジウムで一度話しているが、実験で若干の修正（改善）があったことと、全国大会での初のお披露目、という意味でもう一度あらためて発表したものだった。

クエリ書き換えは、実はちゃんとやろうとするとけっこう難しいタスクであり、しかも自然言語処理の様々な要素技術を使う。今回のプロジェクトも実はかなり大規模で、雑音のある通信路モデル、nグラム言語モデル、翻字、一般化編集距離、分布類似度、ブートストラップ、グラフカーネル、最大エントロピー法、etc. etc.と、これはもはや「自然言語処理のデパート」だ、と自分で勝手に呼んでいるぐらい色々な話が入っているので、それを全部説明すると聞く方も話す方も退屈してしまう。

そのため、前回の反省を踏まえて「いかに多くの人にプロジェクトのことを知ってもらうか」に注力して話してみた。他の研究室の学生さんと話していて、そもそもMSRでインターンができることを知らなかった、という話もあったので、インターンの宣伝も兼ねている。詳細はばっさり切ってシステムの概要だけ説明して、必要に応じて詳細に踏み込む、幅優先探索的な戦略。この成果もあって、共著のhisamiさんと手分けして並列に説明したのでかなり多くの人にプロジェクト自体を知ってもらえたように思う。多数の質問コメントありがとうございました。

ここで話した内容のポスター（及びブースターセッションのパワポ）はNLP若手の会のサイトから見られるので、よかったらどうぞ～

そういえば、クエリ書き換えと言えば、NY大関根先生の株式会社ランゲージ・クラフト研究所のページに面白いスペルミスを集めたミススペル １０９例というページがある。一見どこが間違っているかよく分からない例もあって見てるだけでも面白いが、どれもこれも検索エンジンのクエリ誤りとしてはありがちだと思うので、これからスペル訂正システムを作ってみる場合には、「とりあえずこの１０９例が正しく直せるか？」というのをベースラインにしても良さそうである。CoNLL shared taskにしろ、同義語獲得でよく使われるTOEFLの同義語判定50問にしろ、こういった手軽に使える共通のベンチマークがあると研究も俄然盛り上がるような気がする。

ちなみに、今回のプロジェクトでクエリログをけっこうな量眺めたのだが、面白かったスペルミスは「You Tube」のスペルミスで「Юチューブ」というもの。この「Ю」はハングルではなく実はキリル文字で/ju/の音を表すものらしく、おそらく「ユーチューブ」を入力しようとした時にロシア語のIMEがONになっていたため入力されてしまったと想像される。発表では「You Tube」のスペルミスだけをたくさん集めたものをばーんと見せて「クエリ訂正がいかに重要か」ということを理解してもらえるよう努めたのだが、しかしまあ検索エンジンのユーザーというのは（自分も含めて）色々な間違いをするものだなぁと感心する。

頭語構造の特長を利用した上位下位関係辞書の拡張
(NICT 山田さん他)

他に１件だけ、面白かった発表を紹介（ほかにも面白かったものはたくさんあった）。

この発表では、Wikipediaから収集して構築した語の上位下位関係辞書に対して、Webテキストから収集した語を追加して拡張していくというタスクを扱っている。上位下位関係辞書は、関係を繋げていくと「語彙体系」とよばれる木構造になるが、Webから獲得した語をその語彙体系のどこに追加していけば良いかを求める、というのが手法の本質部分。

簡単に言うと、Webから収集した文脈に基づく「分布文脈類似度」から求めた潜在クラス分布を用いて最も似ている節点を求めて、その上位語にくっつける感じ。この上位語の求め方も、単純に一番似ているものを取ってくる方法から、似ているものを複数取ってきて、その全てを総合してスコアリングして尤もらしいものを取ってくる方法まで試されていて、広範囲を見て総合的にスコアリングして求めた方が性能が高いそうだ。

質疑応答でも質問があったが、この方法を聞いて思い出すのがRion SnowのCOLING/ACL 2006の論文で、こちらでは、文脈類似度と上位・下位関係分類器の出力など、「複数の情報源からの手がかりに基づいた語彙体系自体の確率」を最大化するように新たな節点を追加している。まず上位下位の語彙体系を構築してそこに追加していくという２段階ではなく、その両者を考慮して語彙体系を（ゼロから、もしくは核から）むくむくと成長させてく感じで、よりスマートに思える。両者の比較もぜひ見てみたい。

あとは、文脈類似度を求める時に使っている潜在意味モデルがどう見てもPLSIと本質的に同じなのだが、そこへの言及が無かったのは残念だった。この部分は、ぶっちゃけ単純なBoW＋ベクトル空間モデルでも類似度が出せるので、今回の話の本質ではないのだけど・・・。

ちなみに発表者の山田さんは、自分の研究室のＯＢということで少しお話させていただいたのだが、同じ系統の研究をやっている身としてもっとゆっくりと時間をとって議論できたら良かった。

先週参加した自然言語処理年次大会(NLP2009)について引き続き書きます。本会議１日目は発表は無し。個人的に面白かった発表を２件ほど紹介します。

Character-based Thai Named Entity Recognition（文字ベースのタイ語固有表現認識）
（東工大のWanvarieさんら）

今回の自分の発表が非分かち書き文からの知識獲得に関するものなので、こういう「文字ベース」系の手法にどうしても目が行ってしまう。

日本語と同様に、タイ語も単語分かち書きをしないのはけっこう知られていると思うけど、さらに全て表音文字なので、日本語のひらがなで文が全て書いてあるようなもので、固有名詞抽出などのタスクが大変だという問題がある。

形態素解析器などもあまり整備されていないため、それならば文字nグラムの単位でやってしまえば良いのでは？というお話。

手法としては、まずタイ語固有の前処理（特定の文字は単語の最初には来ない、などなど）をして文字を「疑似形態素」にまとめておいてから、CRFの系列ラベリングでIOB（固有名詞の頭か、内側か、外側か）のラベルを付けていくという手順で、特に目新しいものはない。

興味深かった知見は、これを２段階に分けて、単語境界検出をしてからそれを素性にして固有名詞抽出をすると、単語境界検出に足を引っ張られてかなり性能が落ちてしまうところ。それならば最初から文字nグラムを直接素性にしたほうがいい、という結論で、これは自分の研究のそもそもの動機である「固有表現認識に形態素解析は使えない」に通じるものがある。日本語でも、文字種などのヒューリスティックである程度まとめてから文字nグラム単位で解析したらもう少しうまく行くかもしれない。

専門用語の内部構造解析
(NAIST, 東大の山田さんら)

一日目にしてこんなに面白い研究発表に出会えたのは幸運かもしれない。「問題→解決」のストーリーが分かりやすい素晴らしいプレゼンで、例もふんだんに使ってあって聞いててどんどんとのめり込んだ。今回の大会のオレ的最優秀発表賞。

ここでは医学系の専門用語を扱っていて、たとえば「急性骨髄性白血病」は「（急性）の（骨髄性白血病）」で、「骨髄性白血病」は「（骨髄性）の（白血病）」というように、内部構造（要素とその間の関係）を持つ。この関係をどのように定義してやればいいか？という話なのだけど、例えば「大腿骨折」は「（大腿骨）の（骨折）」というように「骨」が縮退してしまっていてちょっと複雑なのでなかなか一筋縄ではいかない。

そのために、この発表では文字単位で係り受けを定義することによって、縮退や依存関係などを統一的に定義している。

質疑応答の中にもあったけど、自分も「縮退を前処理的に処理しておいて、係り受けはあくまで要素間で定義できないのかな？」とも思った。でもよく考えてみると、文字単位でやったほうがすっきりするし、要素の区切りと依存関係を、同じ枠組みで表現できるので解析器も学習させやすいのは良い。

漢字の文字単位での係り受けの定義・解析って、これだけ聞いていると、これはもはや「中国語の構文解析」の特殊な場合に近いのでは？と思った。実際、中国語には「兼語文」といって、前の文の客語（目的語）と後ろの文の主語が同じ時に一つにまとまっている（＝縮退している）構文がある。中国語の構文解析ではこういう文をどう定義しているのか調べてみると参考になるかもしれない。

ちなみに、自分の研究室では、構文情報付きの法律文コーパスを作っているが、ここでも「法律文中の並列関係や同格関係、括弧書き間の係り受け関係をどのようにして定義するか？」という問題が出てきて、ミーティングで毎回、侃々諤々の議論をしていた。日本の法律文というのは、少なくとも近年においては非常にシステマティックに、高い定型性を持って書かれていて、ここではかなり綺麗に定義できた記憶がある。その結果は去年のNLP2008で発表している（山田将之ら「構文情報付き法律文コーパスの設計と構築」）ので、興味がある方は参照していただきたい。

先週まで、鳥取で開かれた言語処理学会年次大会(NLP2009)に参加していました。自分は、発表２件をひっさげてチュートリアルから本大会まで、とフル出場でした。帰ってきて少し落ち着いたので、取ったメモを元にして少しまとめてみたいと思います。

—

チュートリアルの中で自分の興味のあった講演は、

Yahoo!の山下たつをさんの「ウェブサービスを利用した自然言語処理研究」

と

NY大関根先生の「自然言語処理のための知識獲得」

の２件。

ウェブサービスを利用した自然言語処理研究

前者は、Web APIを自然言語処理に活用する際のレシピ、と銘打っていて、Yahoo!の提供するWeb APIの紹介と、それを使った自然言語処理のアイデアなどを浅く広く紹介してもらえた感じ。最近流行のライフハック本シリーズに倣って一言でタイトルを付けると「Web API＋NLP Hacks！」という感じになるかな。

Web APIを適用していたタスクには、「関連語検索」「関係抽出」などの語彙知識や固有名詞獲得系のものが多かった。この系のタスクは、関係を取ってくるために、大規模データ中の文脈パターン（一次の共起）や文脈の類似度（二次の共起）、もしくはその両方を使うものが多いので、Web上での統計を求めるためにWeb検索APIは絶好のツールである。

この辺りの話は、「枯れた技術」が中心で、ほとんどがたつをさんのブログに載っているので、それを「Web API＋NLP」という軸でまとめたというところ以外、特にいつもブログを拝読している身としてはどこかで聞いた話は多かった。一方、小粒なテクニックでは面白いアイデアがちょこちょこあって（例えばYahoo!カテゴリを利用した簡易文書分類、など）、ベースラインとして使うにはちょうどよいネタが満載だった。

自然言語処理のための知識獲得

後者は、「知識獲得」と銘打っているが、講演の最初に紹介があったように、ここで言う「知識」とは「モノ・コト・名前とその間の関係」なので、語彙知識獲得とかなりの部分が重複しており、こちらもどこかで聞いた話がほとんどであった。

印象としては、知識発見手法についてこちらも広く浅くまとめてあって、知識獲得系のことを包括的に知るためのポインターとしては有用だと思った。（スライド最後に膨大な参考文献のリストがあって、これだけでも価値がある）

この講演で初めて聞いた話でとても面白かったものの一つに、「Amazon Mechanical Turk」がある。これは、オンラインで出来る軽い作業（タスク）を安価に人に頼めるWebサービスで、これを使うとたとえば「この画像によく当てはまる単語を選んでください」とか「この中から反義語を選んでください」みたいなアノテーション（タグ付け）の作業を簡単に外注できる。このサービスを使ったアノテーションについては、EMNLP 2008のRion Snowの論文に詳しいが、多数決を取ったり工夫することで専門家と同等以上の質のアノテーションが実現できるみたいだ。

チュートリアルの説明を聞く限り、アノテーションの外注サービスのような印象を受けたけど、よくよく見てみれば別に外注する作業はアノテーションに限ったものでは無い。簡単に思いつく面白い（実用的な）使い方は「英文添削」で、英語のWebサイトとかを作ってみたら、「このサイト読んで英語の変なところを教えてね！」的な作業を投げてみれば良い。驚くべきはそのコストで、１０文のアノテーションを頼んで2セントとか、そういうレベルらしい。論文とかだと守秘義務の問題とかがあって難しいかもしれないけど、どうせ公開するWebサイトとかなら、専門の業者に頼むのがバカらしくなりそう。

この話を聞いて真っ先に浮かんだのが、前に友人に教えてもらった、IT系のプロジェクトを簡単に外注できる仕事マッチングサービスの「oDesk」。この両者、似ているようでだいぶ方向性が異なっていて、Amazon Mechanical Turkのほうは「人力作業外注サービス」である一方、「oDesk」のほうは「プロジェクト外注マッチングサービス」という感じかな。「oDesk」で英語の先生を激安で雇う、ということもできるし、どちらも使い方次第では可能性が広がる。

総括

久しぶりにチュートリアルなるものに出てみたけど、わざわざ日曜に鳥取入りして出た価値があった。一点だけ残念なのは、「チュートリアル」というからには研究分野に飛び込んだばかりの修士課程の学生が聞いても面白い（もしくは分からない内容については適切なポインターを提示する）内容であるべきだと思っていて、その点でスライドが英語なのはどうかな・・・というところ。英語がネックになって研究が思うように進まない学生はけっこう多いように思う。もちろん、最新のトピックには日本語にできないものが多数あるのがあるのは分かるが、むしろこういう機会に「標準訳」を提示してやるぐらいの勢いがあったらよかった。

その点で、関根先生が最初に

Distributional Similarityは、『分布類似度』ではなくてむしろ『文脈類似度』と言うべき

という趣旨のことを仰ってたのにははっとした。これは最初の英語の用語がそもそも適切では無い例だが、これまで自分も違和感を持ちながら使っていたので、これからチャンスがあれば「文脈類似度」という言葉のほうをちょっと使ってみたくもなった。

２人のプログラマが同じ画面を見て、色々と議論しながら同時にプログラミングを進める「ペアプログラミング」もすっかり市民権を得た感がある。

最近、共同で研究をするときに、２人で研究の各フェーズ（議論、実装、検討）を同時に進めていく「ペア・リサ－チング」的な事をやったら思いのほか良かったのでちょっと書いてみます。

プロセスはこんな感じ：

1. タスクを決めて、関連研究を調べて、だいたいこういう手法で行こう、というのをまず決める。

2. ベースラインでも提案手法でも良いけど、「まずこれをやってみよう」というのを、少なくとも数式レベルではフィックスする。ここまでは相談して行う。

3. 同じ手法を２人で別々に実装する。

4. 入力データを共通にして、動かした中間結果もしくは最終結果を付き合わせる。

5. 結果に食い違いが出たら、食い違いの無い中間結果までフォールバック。実装を直す。これをバグが取れるまでやる。

ポイントは、二人でわざわざ同じ実装を作るというところ。普通の共同研究（共同開発）では、モジュール分けして実装を分担すると思うけど、ここではあえてこの車輪の再発明をしよう、というわけ。これには以下のようなメリットがある：

メリット１：バグがすぐ取れる　—　モジュールごとに分担するとお互いの出力を無条件に信頼してしまい、最終的にうまく行かなかった時に、お互いに「俺のほうに間違いは無いはず・・」的な状況になってしまうことも。同じものを実装して結果を比べれば、どっちが、どこで、どのぐらい間違ってるのかが分かりやすい。

メリット２：手法に関する理解が深まる　—　モジュール分割してると、自分の担当外のところは話が分からなくても進んでいってしまうが、これはけっこう危険。論文では分かったつもりでも、いざ実装してみると「あれ？？」となることがあるし、実装してみて初めて分かる直感的な理解、っていうのは計り知れない。このメリットが大きいかも。

メリット３：実験のスループットが上がる　—　論文の締め切りに追われている時なんかは特に、実験のスループットが重要になってくる。この時に、手法の微調整などの「手戻り」が発生すると、モジュール分担している場合、修正の必要なモジュールの担当者がボトルネックになってしまう。同じ実装を別々にやる場合、自分の実装に対しては完全に主導権があるので、独立に修正を進めることが可能。

研究のプロセスはプログラミングよりも時間スパンが長いので、IMとかでゆるーくつながりながらやるのが良いかも。同じ実装してデータを見ながらあーだこーだ言い合うのはけっこう楽しい。新しいアイデアというのはこういう時に生まれてくることも多い。

もちろん、ペアプログラミングと同じで、ペアを組む２人の実力が同じぐらいで無いと、実力の高いほうが一人でやったほうが早い（比較優位の原則が働く）ことになってしまうので、共同研究は良いパートナーを見つけることが何よりも大事である（と、どちらかと言うと足を引っ張る側の自分が言ってみる）

人がたくさん居る研究室や研究所では当たり前のことかもしれないけど、自分にとっては新鮮だったので紹介してみました。

昔、個人の翻訳アシスタントをやっていたことがあって、医学・歯学系の論文を翻訳（日英・英日両方）したり、まとめたり、特許翻訳したり、あと外国からの電話・メール対応などをやらせてもらっていた。最近でも、翻訳は主にボランティアベースでちょくちょくやるので、そのために整えたツール群があるのだけど、実はこのツール群、英語で論文書いたりメール書いたりする機会が異様に増えた今になってもけっこう役に立っている。

辞書引き

辞書を引くのは基本的に Jamming という辞書ツールを使ってる。対応してる辞書形式が幅広いので、英辞郎、Collins COBUILD、LDOCE、WordNet、Roget’s Thesaurus、ステッドマン医学大辞典など、持ってる辞書を片っ端から登録してる。英辞郎とか、シソーラスとか、今だとたいがいオンラインで引けるけど、遅いし（Webアクセスのオーバーヘッドは速度が要求される翻訳にとって致命的）、そもそもオフラインで使えないのでアウト。

この中でもオススメはCollins COBUILDに入ってるThesaurus（類義語辞書）。論文とか書いてて同じ言い回ししか浮かばない時や、自分の選んだ言葉にどうもしっくり来ない時に類義語で置き換えてやるとちょっと英文がカッコよくなる。例えば use → utilize, employ, make the most of, みたいな置き換えってけっこうみんな無意識のうちにやってるのでは。

ちなみに最近、Emacsから直接辞書引きができるステキなツールを見つけたので、そのうち使ってみたい。詳細は以下：

Emacsで快適な翻訳環境を
http://ubulog.blogspot.com/2007/08/emacs.html

論文の表現

（注意！　このくだりについて、論文で受動態を使うのは論文の作文スタイル的に良くないというご指摘をコメントにて頂きました。元々の趣旨は、「たまには受動態を使って文が単調になるのを避ける」というぐらいのものですが、事実と意見を分けるのが重要な論文では十分注意しないといけません・・・。ご指摘ありがとうございました。）

余談だけど、論文を書く際に英文をカッコよくする一つのコツは、無理矢理にでも「人」を主語に使わないようにする、というテクニック。こうすると、モノが主語になって受動態を使わざるを得ないというのがその理由。例えば、”We analyzed the corpus XXX” という代わりに “The corpus XXX was analyzed” とするとちょっとカッコイイですよね。英語だとけっこう自然に書けてしまうから不思議。

いつも自然言語処理とか、情報系の論文ばっかり読んでると表現とか偏ってしまうので、一度医学とかバイオ系の論文を読んでみることをオススメする。実験の節なんか、”(物質の名前) was prepared” “(物質の名前) was synthesized” とかばっかりで、冷徹なほど淡々としていて視野が広がること間違いなし。

ちょっとのぞき見するのなら、例えばこの辺の論文はどうでしょう？この論文、全長2ナノの「NanoPutians」という人間の形に見える分子を合成します、っていうオチャメで怪しい、でもれっきとした論文。PDFの１ページ目から吹くこと間違い無しｗ

Synthesis of Anthropomorphic Molecules: The NanoPutians
http://pubs.acs.org/doi/pdf/10.1021/jo0349227

例文検索

ちゃんと翻訳したいなら、特に日→英の場合、例文検索が欠かせない。Googleとか検索エンジンで調べてもいいのだけど、「例文」としての適切さと、Web検索結果としての適切さって違うので、検索エンジンの結果上位が例文として使えるとは限らない。それよりは汎用のコーパスを用意してその上で全文検索したほうがいい。（ただしたつをさん作EReKはそれ用なので使える。）

自分が使ってるのは英辞郎収録の「例辞郎」と、朝日出版のE-DIC。汎用の英語例文集ならこれだけでけっこういける。

全文検索エンジン

上の例文検索について、例辞郎は英辞郎のCD買うとテキストファイルで入ってくる（ただし最新の第４版にはPDIC用の専用形式しか入ってないので注意！）ので、あとはそれを全文検索してやるだけ。自分はスクリプト使ってファイル分割してから、全文検索エンジンHyper Estraierにインデックス化させて自分用WebにBasic認証かけて置いてる。

E-DICも、一応検索ツールが付いてくるのだけど、なんとなく使い勝手とかが気に入らないので、

EdicConv.rb - 『E-DIC』JIS X4081変換スクリプト(ruby版)

を使って読めるHTMLに変換して、Hyper Estraierに登録。Hyper Estraierの検索は異様に速いので、オンラインアクセスするオーバーヘッドを入れてもE-DICの専用ツール使うよりこっちのほうが速いかもしれない。

翻訳メモリ

翻訳メモリソフトの類は一切使わない。ひたすらEmacsでゴリゴリと対訳を書く。Emacsだとdabbrevが使えるので、どんなに長い単語でも１回でも訳したことがあればすぐ補完できる。昔Tradosを体験版で使ったのだけど、なんだか性に合わなかったのでそれ以来使ってない。もっと使いこなせば変わるかもしれないけど、なんだか巷に出回ってる翻訳メモリエンジンって、なんとなく「いいもの使ってる感」が無い感じがするんだけどぁ。

その代わり、自分の過去の翻訳を参照する可能性はどうしてもあるので、これまた過去に訳したファイル（対訳になってる）をひたすらHyper Estraierに登録。こうすると過去の翻訳と、上に書いた例文が串刺し検索できてハンパ無く便利。

ということで、翻訳メモリを使わない点なんてとくに時代錯誤のローテクな翻訳環境でした。自然言語処理研究してる人なら自分用翻訳メモリソフトぐらい数時間あれば作れるものだと思うので、必要にかられたらちょっと作ってみたい。