SIGIR Paper Writing TIps: 超意訳してみた
最早旧聞に属しますが、
"SIGIR Paper Writing Tips"
SIGIR Paper Writing Tips - Microsoft Research
自分はIRの人ではないですが、CV(PR), NLP, MLな人にも役立ちそうな事が多いので超意訳してみます。超意訳なので、正しいことは保証しません。「あれ？」と思った方はご自身でちゃんと英和辞書引いてください・・・
Tip 17は本当に秀逸ですよねぇ～～～
ライセンスから
このTipsはPeter Baileyによるもので、
Creative Commons Attribution-NonCommercial
Creative Commons — Attribution-NonCommercial 3.0 Unported — CC BY-NC 3.0
に従って頒布されますよっと。
もし何か問題があることにお気づきの方がいらっしゃればご指摘いただけると幸いです。即座に削除などの対応をいたします。
I wrote this article based on SIGIR Paper Writing Tips - Microsoft Research ,written by Peter Bailey, distributed under the license of Creative Commons — Attribution-NonCommercial 3.0 Unported — CC BY-NC 3.0 . I believe and hope that this (terrible) translation does not violate any rights of the original author; but if you find any suspicous thing, please let me know. I'm happy to respond your notices, including total deletion of this article.
前置きは省略して有難いTipsの数々
Tip 1. Titles describe the paper; don't mislead, overpromise, or be unduly punny. Less is more. A tweet's length is too long.
Tip 1. 「名は体を表す」：タイトルは論文を表す！ミスリードとか、盛りすぎとか、シャレ効かせすぎて狙いすぎ*1もダメ。Less is more. １４０字は長すぎる。
ありますよねー痛々しいタイトル。でも、まずはタイトルで引っかからないと読んでもらえませんからね・・・
Tip 2. Abstracts summarize the paper. In 1 short paragraph. Subject. Motivation. Goal. Method. Achievement. Make me want to read.
Tip 2. 「名は体を表す２」：アブストは論文の中身の要約です！１段落で収まる短さがグッド。対象-->動機-->ゴール-->手法-->結果。「本文を読みたくなるように書いてくれよ」
最後のポイントが全てですねぇ。でもこんなアブスト、めったに出会わないですよねぇ・・・。このところだと、これ(http://books.nips.cc/papers/files/nips24/NIPS2011_0668.pdf)の"easily be implemented in a few lines of MATLAB code"とか？
Tip 3. Intro: What are you doing? Why is it interesting and novel? Will I learn something in the next hour? 1/2 to 3/4 page max.
Tip 3. イントロでは以下のことについて0.5~~0.75ページで応える。 何の話をするか？なんで面白いか？どこが新しいの？で、これから１時間使って論文読んだら、俺は何か新しいことを知れるわけ？
Tip 4. Related Work. 30-40 citations is sweet spot; less means you don't know the area. Don't omit key works from other people.
Tip 4. 関連研究。30-40くらい引用しているといい感じ。少なすぎると勉強不足って感じ。（自分たちのチームじゃない人の）重要な研究は省いたらアカン。
数についてはCV, MLでは違うかも知れませんね。CVはテーマによっては関連研究が膨大すぎて、reviewを引用するしかなくなるケースもままありますからねぇ（特徴量とか）
Tip 5. Report experimental results with appropriate statistical info like error bars, confidence intervals, effect size. Please.
An increase in scores is not necessarily an improvement, it's just some probability of improvement, which may be near zero.
Tip 5. 実験結果は統計的な裏付けとともに報告しましょう。標準偏差エラーバーとか、信頼区間とか、効果量とか。というか報告しろほんと頼むから。
スコア上がったからって進歩とは限らないんだぜ。ただ、進歩した可能性が（ほぼゼロかもしれないけど）あるってだけだぜ・・・
CVやMLではスコアを競う分野だとベンチマークデータセットがしっかり整備されていて*2、そこなら数字だけでもＯＫって感じありますがね。
IRはそういう感じじゃないんでしょうか？ＮＬＰは難しいと思いますが
でも統計的な裏付けは本当に重要ですよね。"We condut a statistical t-test (p = 0.05)." の一言だけで査読の時の信頼度全然違いますからねぇ・・・*3
Tip 6. ML is a means to an end, not the main meal. Feature engineering is only interesting if it gives insights on user behavior.
SIGIR is not ICML. ML helps us accomplish things, but the goal of IR is not better ML.
Tip 6. 機械学習は目的のための「手段」であって、IRのメインディッシュじゃありません。特徴量をゴリゴリ探すのが許されるのは、その結果がユーザ行動の解析に新しい洞察を与えてくれる時だけです。
SIGIR はICMLじゃありません。機械学習は目的を達成するお手伝いをしてくれますが、IRが目指すのは良い機械学習技術を作ることではないです。
うーん。IR/CV/PRのために役立つMLを投稿・発表することは許してもらってもいいと思いますがね。というか、そこまで分野をぶった切って区別する意義ってあるんでしょうか？そこまで不可分じゃないと思うんですが・・・
上記の↑↑意見についてはお便りをいただきまして、
別にIRにおけるML paperを否定しているわけじゃないんやで、と。でも、ちゃんと「今回のこの素晴らしいprposed ML技術の開発によって、おやぁ？『IR技術に』以下のような新しい知見と洞察を得ることができましたぁ！」っていうのが(SIGIRとしては)嬉しいんだよ！というのがもともとの意図ではないかと。
ふーむ。そうなのかもしれません。CV/PR/NLPな方はMLの"invasion"をどのように思っているのでしょうか、ちょっと気になります。
Tip 7. Use Greek letters and maths/stats for precision and brevity. Explain intuitions in English. Don't assume familiarity.
Maths and stats is complex at the best of times, so make it easy to follow both what you're doing and why.
Tip 7. ギリシャ文字と数式と統計は、精密さと簡潔さのためだけに使うものです。直観はちゃんと自然言語（えーご）で説明してください。「これだけ書けばまあわかるよね」-->死亡フラグ。
どんなに頑張っても、数学と統計は複雑なのです・・・だから普通の英語で「何を」「何のために」やっているのか説明してくれると助かるのです・・・
はい（真顔）*4
Tip 8. Unless space-constrained, put lead author's name before citation cross-ref, so I don't have to flip back and forth always.
Tip 8. よっぽどスペースが足りない場合以外は、引用時には著者名を一緒に乗せてくれると引用文献の章と本文を行ったり来たりしないで済むので助かるなぁ。Sato [13]みたいにね。
natbibを使って、どうぞ。
まあ、スタイルファイルががっつり固められている場合もありますからね。そういう場合は頑張って手で何とかするしかないですね。
一方、指定されたスタイルファイル使ってTexコンパイルしたのにエラーする某国内 -----censored-----
Tip 9. Citations. Run cross-ref update in Latex or Word before final submission. Check author names' spelling; they might review!
Tip 9. 引用大事。最後の提出前にはちゃんと[?]がないか確認しましょうね。あと、著者の名前のスペルは本当に気をつけて・・・その人、レビュアーかもよ！
引用するってことは関係分野の研究ってことなので、まあ引用した御本人ではなくても、部下のＰＤが査読するってのは普通ですからね。「ボス(or先輩)の名前間違えてる・・・」ってなったら、その時点でペナルティってことですね。
でもギリシャ人とかインド人の方って、難しいんですよね・・・名前のつづり・・・・・・向こうから見たら日本人の名前は短いし簡単なんじゃないでしょうか？
Tip 10. If evaluating with a test collection, use more than 1. Don't use pre 2000 exclusively. There's more to life than ad hoc.
Ad hoc IR is great! It's really foundational for many things. It's not typical web search behavior however, nor is it micro-blog use behavior, nor .... A really interesting result is something that will generalize, like BM25 (which came from ad hoc IR research). Almost any test collection will have some peculiarities; make sure your findings are not overly limited.
Tip 10. テストデータで評価するときは、テストデータは２つ以上用意しましょう。20世紀の某データだけ使うとはＮＧですよ！Ad hoc検索だけがIR人生じゃないさ。
別にAd hocなＩＲシステムがダメってわけじゃないですよ。IRは全てAd hoc検索から始まったのだ・・・。しかし！ でもそれは典型的な検索行動じゃないし、典型的なツイッタラーでもないし、・・・・。 今、本当に興味深いことは「一般化」できるはずなんです。たとえばもともとAd hoc IRで数字出すために作られた(偏見)BM25とか。どんなテストデータもそれ特有の特徴があるわけで、あなたの研究の成果がその特徴に引きずられないようにしましょう、ってことです。
この部分、IRな人以外は意図を汲むのが難しいです。ということで、ここで代打の神様、sleepy_yoshi(http://d.hatena.ne.jp/sleepy_yoshi/)さんに調べていただいた内容を報告いたします*5。
IR業界の地下闘技場的 (?!) コンペ TREC (Text REtrieval Conference) の王道タスクのひとつであるAd hoc task [1] を意識した発言だと思います。Ad hoc taskではTREC2001時点でトピック数 [2] が全部合わせても550程度です。検索対象の評価済み文書数はたくさんあるのでデータセットとしてはそこそこの規模があるのですが、多様なクエリに対して検索結果上位10件を当てることが重視されるウェブ検索エンジンの評価とは本当に適切かと考えてしまいますよね。また、数多くの研究でTRECデータセットが用いられているので、古いデータセット(≒タスク) から得られる知見はもう十分にしゃぶりつくしたんじゃ1ない？これが2000年以前のデータを使うのは避けようという発言の意図かと思っています。つまり「いつまでもTREC Ad hocタスクだけを見てないで、それ以外にもいろんな世界があるんやで。」ということを言いたのかな、と思います。
[1] Ad hoc 検索が何かということについてはウェブ検索してくださいネ。はい、その行為がAd hoc 検索です (ドヤァ
[2] トピック≒クエリですが、TRECではトピックとしてキーワード (TITLE) 以外にdescription，narrativeといった追加情報が与えられます。それらをどのように使うかも検索システム側に裁量があります。
つまり、"pre 2000"の時代のデータセットで性能を競っても、それは今一般に課題となるIRシステムの対象ドメイン("典型的な検索行動", "典型的なツイッタラー")における主要タスク("検索結果上位10件を当てる", average precision @ K的なやつですかね) とは全く異なる特徴を持っているということです。そこだけで性能を主張されても、SIGIRガチ勢としては認められない、ってことですね。
基本的に科学ってのは一般化に向かう淘汰圧が働くものです。少なくとも、物理(Physics)に支配されていると、数少ない原理で全て表現する方向に向かっていきますね。そして細かい隅をつついて例外を溜めていって、また新しい原理が生まれるみたいな。
パタレコが統計的機械学習、ひいてはBayes Riskにどんどん刈り取られて行くように、アドホック検索から始まったIRも一般化の方向にどんどんシフトしていっているのでしょうか。
実ビジネスの応用では、その場では特殊化ガンガンかけてもＯＫですが、「学問」としてのIR/ML/CV/PRはそれは許されないのでしょうか？
Tip 11. Working with big log data doesn't make it interesting. Insights make it interesting. Especially ones which generalize.
This tip is a cousin of Tip 6; understanding matters more than just being able to run some experiments with lots of data.
Tip 11. 別に大きいログデータで実験したからって面白いわけじゃない。大事なのは実験結果からの洞察でしょ。特に一般化できる知見ね。
これはTips 6の親戚みたいなものです。何かを発見して理解すること、それはでかいデータでプログラム走らせらて実験できるようになりました！よりずっと重要ですから。
そうそう、データがビッグ（）じゃなくても別にいいんです。大事なのは役に立つ知見を得られるかどうかなのです。
Tip 12. Building real IR systems involves much compromise. Don't overclaim for your new algorithm unless you've already tried it.
As an industrial researcher myself, it's frustrating to read lines like "it should be easy to incorporate new algorithm and improve current systems". Unless the algorithm is making a 10% improvement in some (existing, industrial state-of-the-art) metric, it's hard to justify the investment.
Tip 12. 実IRシステムを作るってのは妥協と努力の産物なんだ！簡単に「提案法は既存のシステムに容易に組み込める」とか、実際に組み込んでないなら書くんじゃない！！
企業研究者の１人として*6、提案法は既存のシステムに容易に組み込めて、性能を向上するはずだ」とか書いてるのを見ると怒りを覚える。たとえば、現実に稼働してる現システム（それが現実の「最先端」だ）の性能を何かの指標で10%とか更新しない限り、システム更改の予算はつけられないものなのです。
すみません・・・なんちゃって企業研究者ですみません・・・
Tip 13. What's product interesting is not always research interesting, and vice versa. What's both is not always publishable.
Industrial researchers in particular can fall prey to this trap - Nick Craswell articulated this crisply for me a few years ago, and understanding the line between them is a regular point of discussion internally for us within Microsoft. Sometimes it's challenging to publish or otherwise share work about what's interesting and commercially sensitive. Similarly, an algorithm that obviously won't scale can still be useful if it provides insights into thinking differently about a problem.
Tip 13. 実プロダクトやってる人が興味を持つ部分と研究者が興味を持つ部分ってのは違うものです。両方とも満たすような話は必ずしも論文にならいんやで。
企業研究者は特にこの罠にはまりやすい・・ある意味で過剰に。Nick Craswell*7が数年前にこのことを生々しく話してくれたんだが。この二者の境界線はいったいどこにあるのかってのは何度も何度も弊社*8の中でも内々に議論されています。本当に面白くて、でも商業的にセンシティブなところを論文にしたり何らかの形でソサイエティで共有するってのいうのは時々凄く難しい。一方で、明らかにスケールしないようなアルゴリズム*9だって、ある実問題に新しい観点を与えてくれるのであれば非常に有用なのです。
Tip 14. Graphics. Make legends readable when printed on paper. If color essential to interpret output, make note in fig caption.
Tip 14. 絵と図。凡例は印刷したときに読めるような大きさじゃないとダメですよ。色分けがないと判読不能な図の場合には、ちゃんと"Best viewed in color"と書いておきましょう。
これはCVの論文だと常識ですが、そうじゃない分野もまだまだあるってことですね。
あと、万が一色がなくても読めるように、線のスタイルを変える*10ってのも常套手段ですよね。
Tip 15. When selecting data to exclude, describe what you did and why. Otherwise it's not clear what the bias in dataset will be.
From a reproducability standpoint, which is increasingly a part of the SIGIR reviewing guidelines, it's essential to describe what you did (and did not) do.
Tip 15. 実験から事前に除外するデータがあるときは、どうやって除外したのか、あとその理由を書きましょう。そうじゃないと、このデータのもつバイアスは一体どういうものなんかがわからなくなります。
（近年のSIGIRのレビュー時の注意点にいつも、そしてますます強調して書いてある）実験の再現性の観点からいっても、論文には「何をして、何はしなかったのか」が明確に書かれている必要があります。
Tip 16. Negative results can be interesting. What didn't work, and why not? Surely not all expts led directly to success? #dreamon
Tip 16. 「良くない実験結果」だって大事なことがあります。何がうまくいかなくて、それはなぜなのか？あらゆる実験がいつも直接成功につながるなんて、そんなわけあるわけないじゃないですかやだー！！
うまくいくためには、素早く何度も試行重ねるスキームが必要なのは分かっているんですけどね・・・だから一流になれない・・・（ため息）
Tip 17. Your first audience is overworked, on a deadline, tired, had a glass of wine and put the kids to bed. That is your prior.
This tip is just "know your audience", and the environment under which they're likely to read your paper. Make them happy to be reviewing, and make them work as little as possible. Reviewers want to accept papers, and are more likely to give useful feedback if it is clear you put in the maximum amount of work you could to get it accepted, not the minimum.
Tip 17. あなたの論文の最初の読者（＝査読者）はいつだって働き過ぎで、締め切りギリギリで、疲れ果てて、一杯酒を引っかけて、子供をベッドに押し込んでから「さて・・・」とおもむろにあなたのＰＤＦを取り出します。これが査読者に対する正しい事前分布です。
このTipsは、単に「敵（査読者）を知れ」ということです。大体あなたの論文はこんな状態の査読者にレビューされるってことです。なので、お疲れの査読者がレビュー引き受けて良かったと思えるように、そしてさくっとレビューを終えられるように論文を書きましょう。査読者だって論文はアクセプトしてあげたいのです。そして、できれば価値のあるレビューコメントをつけてあげたいのです・・・全力でアクセプトされるようにあなたが最大限（最小限じゃなくて）の労力をつぎ込んでいることが読みとれれば。
ほんまこれ（査読者の事前分布*11 ＆査読者の気持ち）
Tip 18. Two words: Strunk and White. Read then follow: Rules of usage. Principles of composition. Matters of form. Misused words.
Tip 18. ソースはwiki つ http://en.wikipedia.org/wiki/The_Elements_of_Style 結論：author guidelineはちゃんと読んで、従いましょうね！
でも読むの面倒なんですよね・・・。最後はちゃんと読むんだけども。
Tip 19. Don't pad out with lower quality work. >4:5 papers are rejected. Many great 8 page papers in past. Make it all shine.
SIGIR papers are often rejected due to their weakest part, not accepted due to their strongest. You can't afford weak parts.
Tip 19. 内容の薄い論文を水増ししてページ数を増やすな。４～５ページの内容で済む論文なら落とされます。今までどれだけ素晴らしい８ページの論文があったと思っているんですか。隅から隅まで磨き上げてフルにページを使いなさい。
SIGIRの論文は一番弱い鎖を切られて落とされます。一番強いところを拾ってはもらえないことが多いです。なので、弱い部分があってはダメです。
これはCVもMLも同様ですね。基本、めっちゃ内容を増やして、一番面白いところだけを生かすように煮詰めて行かないとダメですね。*12
Tip 20. Make your contributions clear. Both at the start and end of the paper. Also, Conclusions are not a summary. What changes?
Restating the paper's contributions does not make a conclusion - I already read it. I want to know how the future may be different due to your work.
Tip 20. この論文の貢献(contribution)を明確にしましょう。論文の最初と最後に繰り返して書くくらいでちょうどいい。あと、結論は「要約」じゃないですからね。この論文を通じて、どんな違いを人類の知の体系に加えたのですか？（ニッコリ）
論文の貢献をもう一回コピペするだけでは結論足り得ない。もうそれは読んでるんだから。この結論を得たことで、どんな新しい未来が開けるのか、それが読みたいんだよね。
Contributionを明確に書くのは、個人的にも最近お気にいりです*13。あと、Future workってのは本当に大事ってことですよね。この論文を読んで、読者が次の研究ネタを思いつくくらいじゃないと、その業界に大きな寄与は残せないってことでしょうか。
Tip 21. Acknowledge those who helped you out. Thanks cost little, while forgetting may offend. If big help, make them a co-author.
Tip 21. 謝辞には助けてもらった人を書ききりましょう。感謝するのはちょっとのtypeで済みますが、忘れるとすごく恨まれるかも知れません。すごく助けてもらったなら、共著者に加えるといいかも。
いままで恨みを買ったことはない・・・・・・と信じたい。
End of Tips: Thanks for all the feedback from the Twitter audience, hope you enjoyed them. What did I miss? What do you most love/hate in reading or writing or reviewing SIGIR papers?
最後のTips: ツイッターでリプくれた人たち、ありがとう。楽しんでもらえましたか？何か言い逃したことあるでしょうか？SIGIRの論文書いたり査読しているときに一番良いこと、やなことってなんでしょう？
NIPSで一番良かったこと：通してくれたこと。一番いやだったこと：落とされたこと（多数）。
Tips – Thanks: A big shout out to many colleagues over years, especially to Dave Hawking, Nick Craswell, Ryen White & Susan Dumais.
エンドクレジット。
・・・読むだけなら一瞬ですが、訳して文書に起こそうとすると結構時間かかるもんなんですね・・・。
謝辞
お手伝いいただいたsleepy_yoshiさん
http://d.hatena.ne.jp/sleepy_yoshi/
に全力感謝。
*1:シャレ効かせるような英語力があれば素敵なんですけどね・・・
*2:というか、整備されないと競えないことを良く知っている
*3:と、査読で「検定せーよ！」といわれてから検定しだした青二才が申しております
*4:私も全てテイラー近似と変分法で線形計算に落とし込む機械系出身ですので、このTipsには全面同意です
*5:なお、ここで掲載した内容については私Dr_KayAiが全責任を負います
*6:原著者の方はMicrosoft Researchですね
*7:Bingの研究開発者としても有名ですね。
*8:MS researchでしょうね
*10:線の太さは予想以上に判別が困難
*11:子供ができる予定は今のところないですねぇ・・・
*12:え、それでどれだけ通しているんだって？・・・やだなぁ、聞かないでくださいよ(泣)
*13:で、採択は・・・
