解き方の答えはプログラムではなくデータにある

午前中、雑誌の取材。こちらから自然言語処理機械学習に関する情報提供をするが、量子コンピューティングに関して最新の話題を提供してくださり、勉強になる。あと、慶應商学部線形代数の単位を取らないと卒業できないらしく、線形分類器であれば理解できるらしい。すばらしい(と、気をよくして少しノイジーチャネルモデルについてお話したら、さすがに細かすぎた気がする)。

昼は共同研究のミーティング。スクレイピングの続きであるが、データを見てみたら、HTML処理とか正規表現とか使うまでもなく、テキストファイルとして行数指定で抽出できるようだった。脱力……(何行目が所望のデータかは、手で調べておく必要があるが)。まあ、データを見てそれを思いついた彼も機転が利いたということである。目標に対して、難しすぎる問題にして解いてはいけない、という好例であった(Vapnik の原理「ある問題を解くとき、その問題より難しい問題を途中段階で解いてはならない」)。

午後に Skype でつないで言語教育勉強会。今日は PACLIC のため松本先生と hiromi-o さんがいないのだが、ippei-y くんが進捗報告を、[twitter:@mitsuse_t] くんが論文紹介をしてくれる。2人とも M2 なので当然といえば当然だが、ちゃんと研究やっていて偉いなぁ。@mitsuse_t くんが紹介してくれたのは

  • Mohammad Sadegh Rosooli and Joel Tetreault. Joint Parsing and Disfluency Detection in Linear Time. EMNLP 2013.

で、やりたいことはタイトルに書かれている通りで、手法もまあ妥当な話だし、EMNLP 向きの研究かなと思った。

夕方に研究室に戻ってきてスクレイピングの結果を確認すると、ちゃんと抽出できていた。プログラミング面接でよくあるように、コードを書く前に、どういうコードを書くつもりか口頭で説明してもらって、細かく実装方法を聞いて理解度を確認して(必要なら使うべき関数や文法を補足して)から、書いてもらうようにしたのだが、ほとんどステップバイステップで何をするか確認してから書いてもらったほうが、1行書けないために全部を書かない、というリスクを減少させることができるように思った。

ただ、このやり方だと、ほとんど確認する側が想定する範囲でのコードしか書けない(自分が手法を思いつく範囲でのタスクしか解けない)気がするので、プログラミング面接のように「相手の能力を確認する」のはよい(個人的にはあまり楽しい作業ではない)が、研究的にはこれではまずいかな……。