「Deep Learningをサービスに導入したい！」人に周囲が泣かされないために：機械学習活用プロジェクト大解剖（2）（3/3 ページ）

機械学習を実際に活用する人が意識すること

　ここまでは、Deep Learningを活用させるための、チーム外での連携の話を中心に書きました。いわば、データサイエンティストを外側からの目線で見た話です。次は内側の目線、つまりDeep Learningを実際に使う側が意識する内容について書きます。

　Deep Learningを含む機械学習を活用するためには、以下の要素をしっかりと準備・開発する必要があります。

　この番号は優先順位です。ひっくり返ることはまずありません。

　1.の「学習したモデルの良しあしの定義や測定」が決まっていなければ、学習したモデルをリリースしても無価値どころか、サービスを悪化させた可能性もあるので大変危険です。

　2の「学習したモデルをリリースする方法」がなければ、学習に必要なデータがいくらあってもサービスに何の影響も与えません。

　3の「学習に必要なデータ」がなければ、いくらマシンパワーがあっても無意味です。

　4の「必要なマシンパワー」がなければ、機械学習を実施することができず、どんなに理論的に素晴らしい手法だとしても計画しただけで終わってしまいます。

　本プロジェクトでは、一番優先度が低い、5の「機械学習の手法」を先に決めてしまいました。このまま、機械学習の手法から始まって、上記の優先順位とは逆の方向で進めていたら、プロジェクトはおそらく失敗していたことでしょう。しかし今回は、「機械学習の手法」は決めたものの、上記の優先順位順に進めていくことにし、Deep Learningの扱いはずっと検証程度にとどめており、プロジェクトの後半でようやくサービスリリースのための実装に移りました。

【1】学習したモデルの良しあしの定義や測定

　「学習したモデルの良しあしの定義や測定」には、前述の通りA/Bテストベースで進め、効果測定は「別のチームに依頼する」といった形を採りました。

【2】学習したモデルをリリースする方法

　「学習したモデルをリリースする方法」では、再コンパイルの必要なく高速かつ手軽にリリースするため、アルゴリズムのコア部分は外に出し、基本的にはそのコア部分を変更する仕組みを作りました。そのコア部分は以下の3種類に分類できます。

　これらの情報を統合することで、ランキングアルゴリズム改善のA/Bテストを実施しています。

・ロジックテンプレート

　「ロジックテンプレート」は、ほとんどSolrのファンクションクエリであるDSLでの設定ファイルの形で実現しています。こちらには、例えば、「価格が1000円未満の商品ならばx点をランキングアルゴリズムのスコアに加点する」といった処理が書かれています。

・条件ごとの具体的な値

　この「x」に該当する箇所は、カスタマー属性や検索条件によって動的に切り替えられるようにしています。このxに該当する「条件ごとの具体的な値」の参照方法は、csvのような設定ファイル形式をメモリに読み込む形式の他、別途KVSを作りそこから値を獲得する形式も採っています。

　このような方法を採ることで、例えば「飲料水で検索した場合のx」は100、「タブレットPCで検索した場合のx」は-50のようにして、検索ランキングアルゴリズムを管理しやすい状態で複雑なロジックを実現しています。

・A/Bテスト条件とロジックの対応表

　「A/Bテスト条件とロジックの対応表」も別の設定ファイルにすることで、各ロジックの配信比率をコントロールしやすくしています。ロジックの配信比率変更はA/Bテストを実施していく中で結構な頻度で発生するので、こちらも変更しやすい状態を意識して作っています。

switch (abTest){
// 「A/B テスト条件とロジックの対応表」の処理内容
case A: 
//「条件ごとの具体的な値」の処理内容
    if(searchCondition=="飲料水"){
        x = 100;
    }else if(searchCondtion=="タブレットPC"){
        x = -50;
    }else{
        x = 0;
    }
// 「ロジックテンプレート」の処理内容
    if(price<1000){
        score += score + x;
    }
}

【3】学習に必要なデータ

　今回はクリックスルーログを用いました。これは「検索結果一覧画面の、どのアイテムがクリックされたか」についてのログです。クリックではなくコンバージョンされたアイテムのログの方がデータの質は高まるはずですが、今回はデータの量を重視したため、クリックスルーログを用いました。

　ログ収集環境については記事「Hadoop＋Embulk＋Kibanaのデータ集計基盤によるデータ可視化と集計データを活用したキーワードサジェストの仕組み」が詳しいので、そちらをご参照ください。

　今回、機械学習活用のためのログ収集要件変更の内で特筆すべきものは「検索結果一覧画面内のクリックされていないアイテムの情報」も取得するようにしたことです。今回の機械学習活用では、「教師付き学習」と呼ばれる手法を用いるため、正例（クリックアイテム）と負例（非クリックアイテム）の両方のデータ取得が重要だったためです。

【4】学習に必要なマシンパワー

　マシンパワーの確保は、最近ではAWS（Amazon Web Services）やGCP（Google Cloud Platform）といったクラウドサービスのおかげで確保自体は難しくなくなりました。問題となりやすいのは「ログデータを用いるための情報セキュリティ」「金銭的コスト」の2つです。

　この中でも、情報セキュリティの方はクリックスルーログに個人情報は一切含まれていないことと、既にわれわれのチームでは「AWSを利用した環境を構築していた」ため、問題ありませんでした。

　残るは金銭的コストの問題です。実は、機械学習導入以前に「検索結果比較ツールを用いたハンドチューニングで作った検索ランキングアルゴリズムのA/Bテスト」をこの時点で実施済みでした。そこで非常に大きな改善効果が確認できたため、追加コストの調達は非常にやりやすかったです。

　この意味でも、優先度が高い順から進めていき、未完成の状態でもリリースしてテストしてみることの重要性がよく分かります。

【5】機械学習の手法

　機械学習を使うための上記【1】〜【4】の準備を進めていたら、「Chainer」という使いやすいDeep LearningフレームワークがPreferred Researchから発表されました。

　Chainerの発表は、プロジェクトのタイミング的にもちょうど良く、すぐに検証作業に入りました。この検証の成果物の1つはブログにも書きました（ただし、これは Chainer が1.5から大幅に変更されたため現在の最新バージョンでは使えなくなってしまいました）。

　アルゴリズムの基本方針は、「ニューラルネットワークの最終層はファンクションクエリで表現される部分」「下層は“条件ごとの具体的な値”を計算する部分にそれぞれ対応させたネットワーク構造」といったものでした。

結局、Deep Learningで本当にサービスが改善したのか

　最後に、「Deep Learningで本当にサービスが改善したか」の結論に触れます。

　結果としては、以前リクルートテクノロジーズのブログで書いた通り、KGI改善効果が認められました。

　この改善施策のランキングアルゴリズムは、検索の絞り込み条件やカスタマーの属性に応じてスコアに加算する値を変更（「学習したモデルをリリースする方法」のxに該当）する方法で、具体的な値はChainerでクリックスルーログから計算したものです。このアルゴリズムをサービスの主要検索導線ほとんどに導入したため、改善効果は非常に大きかったです。

　しかし、その改善効果の割合は、最初に自作のランキングアルゴリズムを導入したときの改善効果の3分の1程度でした。この最初のアルゴリズムの設計方針は、「ないよりかは絶対にあった方が良い特徴量の線形和でアイテムを評価する」といった単純なものでした。これはログを見ずに思考実験だけで作りました。例えば、あくまで一例ですですが、「同じ商品が仮に2つ以上あった場合、送料や価格が安い方が良い。レビューの点数や評価数が高い方が良い」といったような具合です。

　それら特徴量の各重み付けは、検索結果比較ツールを使って定性的なハンドチューニングだけで決めました。後でちゃんとログを分析してみると、そのハンドチューニングはかなり筋の良い結果になっていたことが分かりました

　この「勘で作った」といっても過言ではないアルゴリズムと、苦労して導入したDeep Learningベースのアルゴリズムの工数対効果比は24対1くらいでした。

　この結果は、検索改善プロジェクトから見ると大成功でしたが、データサイエンティストとしては敗北でした。この結果は、Deep Learningの費用対効果比が悪いというよりも、「今回の学習に使える特徴量が貧弱な状態だったこと」「最初の改善効果が大き過ぎたこと」が原因だったと考えています。次回、この反省も踏まえて「検索改善に本当に必要だったものは何だったのか」について考察します。