最近、社内勉強会で機械学習についてエンジニアに説明する機会があり、その際にKaggleについても説明しました。一方で うーん、「Kaggler はパラメータチューニングやアンサンブル等の自明でインクリメンタルな改善『しか』できない」というような誤解はどうやって解いていけばいいんだろう。— im132nd (@im132nd) 2018年4月4日 という話もあり、(特にデータサイエンティスト以外の職種の人が)Kaggleをやる意義/メリットについてまとめてみました。ガッと勢いで書いたので、項目に結構被りがあります。なお、書いている本人はKaggleほぼ初心者であまり説得力がないです。Kaggle Masterの人がもっといいエントリを書いてくれるのを期待しています、議論の叩き台エントリです!! Kaggleをやる意義/メリット 様々なデータセットを触ることができる kernelでデータ分析の

週末KagglerとしてavazuのCTR予測コンペに参加しました。Kaggleは機械学習版のISUCONだと思ってもらえばよいです。コンペ自体は終わっているので、late submiteであまり意味はないかもしれません、練習です。leaderboard上で上位10%以内に行けたので、そこまでの試行錯誤をメモしておきます。謎ノウハウ(?)を持っているガチ勢じゃないと上位に行けないものかと思っていましたが、基本に忠実にやればこれくらいの順位(上位7.6%)に行けましたし、他の人の工夫を垣間見えるという意味でも現場の機械学習やり始めたエンジニアにお薦めできそうでした。 参加の動機 目標感: 頑張りすぎずに上位10%以内に入る 試行錯誤 AthenaとRedashによる探索的データ解析 ベンチマークをまず超える 線形分類器でシンプルな特徴量 時系列要素を忘れていて過学習発生 特徴量エンジニアリン

サービスに機械学習技術(例えばSVM)を入れる際に、「この機械学習技術は本番サービスに投入しても大丈夫なものか?」を考える基準がまとまっていると人に説明するときに便利だなとふと思ったのでまとめてみました。散々言われ尽くされている話だとは思います。 前提 考慮に入る採用基準 予測精度 (コードの)メンテナンスの容易性 計算オーダー 学習時 予測時 挙動のコントロールのしやすさ/予測説明性の容易さ チューニングの必要性 その他 まとめ 前提 機械学習がプロダクトの主要な武器になる(例えば最近話題になっているGoogle翻訳におけるNMT)ものではなく、サービスにデータがまずあり、機械学習でデータを活用することにより、そのサービスを支えていくようなものを前提に考えています(例えばCGMサービスのスパム判定)。また、投稿内容は私個人の意見であり、所属組織を代表するものではありませんとお断りしておき

先週末、はてな社内の勉強会で構造学習、特に実装が簡単な構造化パーセプトロンについて発表しました。発表資料と説明用にサンプルで書いたPerlの品詞タグ付けのコードへのリンクを張っておきます。 今日からできる構造学習(主に構造化パーセプトロンについて) from syou6162 structured_perceptron/structured_perceptron.pl at master · syou6162/structured_perceptron 「えっ、Perlかよ」という人がいるといけないので、Clojureで構造化パーセプトロンを使った係り受け解析のサンプルコードへのリンクも張っておきます(2種類あります)。PerlもClojureもあれば8割くらいの人はカバーできそうなので、安心ですね。 syou6162/simple_shift_reduce_parsing syou616