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

[大杉直也，リクルートテクノロジーズ]

【失敗パターン2】精度に課題がありサービス改善にならなかった

　機械学習を導入したところで、必ずサービス改善につながるとは限りません。

　今回のような検索ランキングアルゴリズム改善の場合、機械学習導入による改善失敗には「既存のアルゴリズムで十分だった」「ランキング改善がそもそも重要じゃなかった」「機械学習の使い方が悪かった」という3つのケースがあります。これらのケースをいかに回避するかを考えます。

【回避方法1】そもそも改善プロジェクトを開始しない

　まず、「既存のアルゴリズムで十分だった」ケースの回避方法を考えます。

　実際にそのサービスで検索をしてみて心の底から満足できる結果が得られた場合は、そもそも改善プロジェクトを開始しません。

　しかし筆者個人の実感としては、「検索に求められる欲求は日に日に高まっており、まだこの世界には人を本当に満足させる検索エンジンは存在していない」と思っています。実際、このケースには出会ったことがありません。

【回避方法2】改善によって、今より悪い状態にはならないという前提に立つ

　次に、ランキング改善がそもそも重要じゃなかったケースの回避方法を考えます。

　例えば、検索のレスポンスに最大で3件しかアイテムが含まれない場合は、検索のランキングはさほど重要ではありません。一方、レスポンスに含まれるアイテムが多い場合、ランキングアルゴリズムは重要な意味を持ってきます。

　筆者個人は、多くても検索結果を上位10件くらいしか見ないため、「レスポンスに含まれるアイテム数が20程度あれば、ランキングアルゴリズムは重要ではない」と思っています。

　検索結果ページにページング機能があると、ランキングアルゴリズムはもっと重要になってきます。大体のサービスでカスタマーはあまり2ページ目以降を見にいかない傾向があります。もちろん、サービスの利用状況によってランキングアルゴリズム改善の効果量は大きく異なります。

　筆者のように検索結果の上位数件しか見ないカスタマーが多いサービスの方が、そうでないサービスよりもランキングアルゴリズム改善の効果が大きいはずです。ただ、そうではないサービスでも、ランキングアルゴリズムを改善することで、今よりも悪くなることはないはずです。

【回避方法3】インプットとアウトプットの関係性を見る

　最後に、機械学習の使い方が悪かったケースを考えます。

　機械学習の活用には、その手法の数学的な背景や、もろもろのデータエンジニアリングの技法や、ビジネス観点でのゴール設定やら必要なものが多く、なかなか難しいです。機械学習の活用方法は本連載の最後に簡単に触れます。ただ、機械学習の中身の理解は難しくても良しあしの評価はさほど難しくありません。機械学習関連箇所をブラックボックスだと見なし、単にインプットとアウトプットの関係性を見ればよいだけです。

図4　ブラックボックスは分からなくても、アウトプットの良しあしは分かる（QueryRewriterではインプットがクエリで、アウトプットが検索結果とその並び順）

　確かに機械学習は専門性が高いかもしれませんが、その良しあしの判定を、機械学習を導入した人やチームに任せ過ぎるのは、「自分の仕事を自分だけで評価する」状態になり、非常に不健全です。最悪、不正が起きやすくなってしまいます。そこで、「良しあしの判定を解釈の余地がないほどに厳密に定義する」「成果と直接の利害関係のない組織が良しあしの判定を行う」、どちらかの状態にしておくべきです。

・良しあしの判定を厳密に定義する場合の留意点

　検索ランキング改善のようなプロジェクトでは、可能ならばA/Bテストなどの無作為標本化によるオンラインテストを行うべきです。なぜなら、カスタマーの行動といった要因を全て書き出すのが不可能なほどに複雑な事象を扱わなくてはならず、無作為標本化以外の手法で実験をコントロールすることが極めて困難だからです。

　A/Bテストを実施する場合、どの指標で良しあしを判定するかが一意に決まれば、良しあしの判定を厳密に定義できます。この指標の最有力候補はKGI（重要目標達成指数）です。

　仮に、新施策を導入することによりKGIが悪化した場合は、その施策は無条件で駄目です。逆にKGIが向上した場合、その施策は無条件で良いかというと、そんなことは決してありません。

　検索ランキングアルゴリズムの例では、マイクロソフトのBingが「クエリのシェア率」「売上」といった中長期的な指標でオンラインテストを行った結果、サービスの質が悪化し、短期的には指標は改善したものの、中長期的には悪化した報告があります（参考：『Trustworthy online controlled experiments: Five puzzling outcomes explained』2012年、ACM）。この示唆に富む例から分かるように、どの指標で判断すべきかは、実際に改善施策を導入し、各指標がどのように影響し合うかを確認してからでないとなかなか決めづらいです。

・成果と直接の利害関係のない組織が良しあしの判定を行う（当プロジェクトの成果の評価方法）

　今回の検索改善プロジェクトはリクルートグループ内でサービス横断的に活動しているため、さまざまなWebサービスでの検索ランキングアルゴリズムを日々改善しています。そのため、改善におけるA/Bテストの効果測定は他のチームに依頼する形で行っています。

　リクルートグループ内のサービスの多くは、データドリブンに継続的な改善をし続ける体制が整っているため、既にA/Bテストの効果測定を行っているチームが存在し、そのチームに依頼する場合が多いです。どうしても、われわれのチームで効果測定を行わなくてはならない場合は、その効果測定の方法を透明化し、他のチームでも同じ結果が再現できるような体制を作っています。

　また、A/Bテストなどの定量的な評価方法の他に、検索結果比較ツール（前回参照）を用いた定性的な評価も重要視しています。「自分がカスタマーだったら、この条件での検索なら、こっちの検索結果の方が良い気がする」といったカスタマーと同じ目線を意識し続けることで、機械学習に一任したことに起因する迷走が抑止され、検索改善のための新たなアイデアが浮かぶようになります。