読者です 読者をやめる 読者になる 読者になる

Machine Learning Casual Talksに行ってきた

勉強会・ハッカソン データ解析・可視化

もう1ヶ月くらい経ってしまうのですが、Machine Learning Casual Talksに行ってきました。 内容は機械学習のテストの自動化について。

感想としては、

  • ランダム性のあるものをテストするとか、テストデータを生成するとか、そのあたりで苦労するのは皆同じなんだなーということと、それにどうやって対処しているのか聞けてよかった。
  • リコメンドシステムのチューニングについて、他のところではどうやっているのかという話を聞けて、非常に参考になった。

という感じです。

いろいろとメモをとったので、それを整理してまとめました。

オープニングトーク・諸注意 (@chezouさん)

資料:http://www.slideshare.net/slideshow/embed_code/35249532

  • 会の目的
    • 現場での地道な知見の共有をしたい。特にテスト部分。
  • クックパッドでの機械学習の活用事例
    • ご意見フォーム
      • スパムフィルタリングに利用
      • テストが不足していた部分
        • 削除エラーが出たという連絡
          • ライブラリのバージョンアップで内部モデルの変更があったが、0から学習させるテストしかしていなかったので気付かなかった。

機械学習のテスト自動化コトハジメ (@komiya_atushiさん)

資料:https://speakerdeck.com/player/ce31fb10cf970131ae261e02cdc90b71

  • xUnit xSpec系のテストについて
  • 機械学習のテスト自動化の難しさ。
    • 期待する結果の定義が難しい・・・
    • 精度100%ではないし・・・
    • ランダムな振る舞い・・・
    • テストデータ作成つらい・・・
    • NGになったとき何が悪いのか・・・
  • 基本はBlackbox Testをベースにする。
  • アプリケーションレベル・・・得られる精度を検証
    • 行うのは難しい
      • ABテストとか?
  • ビジネスロジック・・・使い方の正しさを検証
    • ログの処理や出力の使い方など。
    • 機械学習部分のモック化。
    • 乱数シードを固定する。
    • 例外値をテストする。
  • 機械学習アルゴリズム・・・実装の正しさを検証する

    • 既存のライブラリならいらない。
    • 手動で計算できる小規模なデータを使い、手で計算して出力データを作る。
    • 既存の枯れた実装を利用してデータを生成する。
  • Q&A

    • そもそも事故ってることをどうやって検出する?
      • 難しい・・・エラー検出機構を予め仕込んでくことくらいしか・・・
    • アルゴリズムを差し替えたときのテスト
      • それはむしろ精度のテスト。ABテストとかやって試すとか。
    • 解析的に解けない問題はどうやってテストする?
      • 半導体とかランダム性多い。そのときは信頼区間とかでだいたい範囲内に入っていればOKにする。
      • 極端に良いデータと悪いデータを与えてその結果を比較する。

Jubatusにおける機械学習のテスト(@unnonounoさん)

資料: http://www.slideshare.net/slideshow/embed_code/35564179

  • 機械学習のライブラリを作る側のテスト
  • コア層のテスト
    • 「ちゃんと」問題がとけるのか。
      • どう考えても解けるだろうという擬似問題をとかせる。
      • 特定の手法だけ判別精度が異常に低いことが発覚・・・
        • 一箇所だけ+-の記号を間違えてたが、何回も見ないと発見できなかった・・・
          • たいていは発散するかランダムになるかだが、今回はそういうケースに当てはまらなかった。
    • 「ちゃんと」論文通りに実装されているか。
      • 精度が出ているからといって正しいては限らない。
        • なぜか間違った実装のほうが精度良かったし・・・
    • 「ちゃんと」利用者に使い方がわかるか。
      • パラメータの意味が伝わるか。
      • 論文で示された挙動と違いがある・・・
        • 使い勝手・一貫性は必要。
      • パラメータ多すぎると調整が困難(3つ以上)。
      • パラメータの影響範囲が広くならないように設計していく・・・が元のアルゴリズムからして難しそう。
  • 機械学習の論文の精度ってどうやって示す?
    • 実験的に試す。
    • 理論的に示す。

「パーソナライズニュースを支えるML業務のまわしかた@Yahoo! JAPAN」(@muraokazさん, @qlutoさん)

資料:http://www.slideshare.net/slideshow/embed_code/35821441

  • Yahooパーソナライズニュースでの活用事例
    • スマホWebのトップページの下のほうとスマホアプリに表示されている
    • ニュース閲覧履歴、検索履歴、他のサービスの情報からニュースをリコメンド
  • サービスの規模
    • ニュースをクリックしている人をカウントすると 230万ユニークブラウザ/day
    • 解析対象2000万Cookie/day
    • リコメンド対象記事 6000本/day
  • リコメンドのロジックなど
    • 10E5次元の特徴量
    • コンテンツのメタデータが有効
    • ロジスティクス回帰でやってる
    • 入稿時刻とアクセス時間で減算処理している
    • ピークタイム前にバッチ処理でモデル更新
    • 直近のログと過去の学習結果に興味減衰率をかけてリコメンド
    • 短期的興味と長期的な興味を混ぜてリコメンド
  • 精度評価
    • オフライン評価
      • フィードバックログを使ってモデルを評価。
      • チューニングにつかうデータと評価につかうログは日付が違うほうがいい。ニュースは日付に影響されるものが多い。
    • オンライン評価
      • ABテストによる評価
      • KPIを定めて、その指標が改善されているのか。
        • CTRは釣り記事とかもあるので、訪問率のほうが満足度を表していると考えている。
    • 問題設定→モデリング→オフライン評価→オンライン評価→リリース→はじめに戻る
    • オフライン評価から先に進むのは
      • 精度が明らかに上がった時
      • 下がっても定性的には良いと思われる場合
        • ABテストで再度判定。

ディスカッション

  • オフライン評価するとき、過去のデータからだと過去のモデルの影響受けるよね?
    • その課題認識はある。
      • ランダムに記事を出すものも混ぜたり、機械学習を使わない郡を用意するなど。
      • もっといい方法があるかもしれないけど難しい・・・
  • モデルを更新するアイデアはログから、それともドメイン知識的なものから?
    • 両方ある。
      • ニュース編成の人に聞きにいったりとか。
      • 特徴量増やしたり、減らしたり、良いと思うものをひたすらトライアンドエラー
  • モデルのテスト期間は1週間くらいだけど、その後変わったりするのでは?
    • だいたい1週間でえいやと決める。
    • 過去のモデルのほうが良かったとかは検証しずらい・・・コンテンツ入稿の量も異なってくる。
      • ベース・ラインの施策を超えられるかどうか。
    • 過去のデータも時事性のあるニュース記事では使いづらい点はある。
    • 長期的な視野でモデル改善は行っていきたい。
  • 特徴量を改善するかアルゴリズムを改善するか?
    • 学習データの精査 → 特徴量 → 手法 の順
      • 学習データの精査:ツィッターのデータでブログのデータを解析できるのかという話。
      • データがたくさんあるなら、データのクレンジング。
      • データが少ないなら特徴量から手を付ける。
      • その後にアルゴリズムの改善。
  • KPIを訪問率にすると難度の高い記事を休日にだけ読む人とかターゲットにできない?
    • その解決策は今はまだ思いついていない。
  • オーバーフィッティング。もう見たやつが出てしまう。
    • ランダム性を入れるなど。
    • 機械学習としてはすでに見たものが出るのは正しい感じもする。
      • 他の部分のロジックでカバーすべき。

LT

pythonでカジュアルにディープラーニング(@yamakatuさん)

資料:http://www.slideshare.net/slideshow/embed_code/35566045

グノシーを支える機械学習業務プロセス(Gunosy 関さん)

資料:https://speakerdeck.com/player/bebe4b70cf8b0131ae261e02cdc90b71

  • 過去データはユーザの体験を表さない。
    • すべてユーザーに出して決めてもらう。
  • 仮説をたてる。「こうしたら最新の記事が出るようになるとか」
    • KPIもその時点でできる。
  • 既存のものと精度比較はしない。
    • KPIが達成できたか。
    • 問題点が多そうなら、少ないユーザーから適用する。
  • 新しいアルゴリズムは新しいユーザーをメインに試す。
    • これまでの経験という比較がないので。

「scikit-learn入門とお願い」(@showyouさん)

資料:http://www.slideshare.net/showyou/scikit-learn-and-favor

  • scikit-learn

「レシピの自動分類」(Cookpad 原島さん)

資料:https://speakerdeck.com/junharashima/resipifalsezi-dong-fen-lei

  • レシピを何料理(肉料理、魚料理・・・etc.)かどうか自動で分類したい
    • すでにユーザーが分類してくれたデータがある
      • それを使って学習させた
    • SVMつかった
    • GNU parallelで並列化して高速化