軽量で大規模な機械学習アルゴリズムライブラリ Fregata オープンソース: 高速、パラメータ調整不要

1. 大規模機械学習の課題

インターネットとモバイルインターネットの普及により、利用可能なデータの量はますます豊富になっています。データリソースの豊富さにより、機械学習が価値を生み出す機会がますます増えています。機械学習は、計算広告や推奨システムなど、数千億ドル規模のアプリケーションにおいてますます重要な役割を果たしており、それが生み出す価値も増大しています。しかし、データの規模の拡大は機械学習に多くの課題をもたらします。

[[178537]]

最大の課題は、膨大な量のデータによってコンピューティングリソースの需要が急増していることです。まず、古典的な機械学習アルゴリズムの計算の複雑さは、一般的にトレーニングデータや特徴の数の2乗、あるいは3乗になります[1]。つまり、データ量や特徴量が倍増するたびに、計算量は元の量の 4 倍、さらには 8 倍にまで増加します。このような計算能力の増加は困難であり、スケーラブルなコンピュータクラスターを使用しても、このような計算能力の増加に対応することは困難です。幸いなことに、凸最適化手法に依存する多くのアルゴリズムでは、確率的勾配降下法を使用して、計算の複雑さの増加を、データ量と特徴の数に基本的に比例するレベルまで減らすことができます。しかし、大規模な機械学習では、依然として 3 つの大きな計算上の困難に直面しています。

まず、ほぼすべての機械学習アルゴリズムは、データを複数回スキャンする必要があります。大規模なデータの場合、どのプラットフォームであっても、メモリ内に完全に保存できない場合は、ディスクストレージシステムからデータを繰り返し読み取る必要があり、IO オーバーヘッドが膨大になります。多くの場合、IO オーバーヘッドはトレーニング時間全体の 90% 以上を占めます。

第二に、分散コンピューティングシステムの場合、メモリ内のすべてのデータを処理するのに十分なリソースがあっても、モデルのトレーニング中にモデルを更新すると、大量のネットワーク通信オーバーヘッドが必要になります。同期更新でも非同期更新でも、膨大なデータ量と特徴量数により通信量が爆発的に増加し、大規模機械学習のボトルネックの一つとなります。

3つ目に、大規模モデルではモデル全体を単一のノードに保存することは不可能であり、モデルを分散的に管理する方法も大きな課題です。

図1

現在主流のビッグデータ処理技術はすべて、Map Reduce コンピューティングモデル (Hadoop や Spark を含む) に基づいています。 Map Reduce コンピューティングモードでは、最初の問題はメモリと SSD ストレージを増やすことによってのみ解決または軽減できますが、これにも高いコストがかかります。 2 番目と 3 番目の問題については、Map Reduce モデルの制限を克服することが困難です。

パラメータサーバー[2]は、大規模機械学習システムの最新の設計パターンであり、主に3番目の問題を解決し、パラメータサーバーとモデルパラメータの分散管理を通じて超大規模モデルをサポートします。同時に、モデル更新プロセス中の通信モードは、非同期更新モードを採用して、データ同期のオーバーヘッドを削減し、通信効率を向上させることができます。ただし、パラメータサーバーモードでは、モデル更新量の計算とモデル更新が分離されており、原理的に膨大な通信オーバーヘッドが避けられません。幸いなことに、一般的な大規模機械学習の問題はすべて高次元スパース問題であるため、通信オーバーヘッドの問題は大幅に軽減されます。モデル規模の制限を突破するパラメータサーバーの利点は、Map Reduceモデルでは代替できないため、パラメータサーバーは大規模機械学習の最も先進的で最も認知されているモデルとなっています。

図2

パラメータサーバーはモデルの分散管理のボトルネックを解決しますが、非同期通信モードと問題自体のスパース性により、通信のプレッシャーが大幅に軽減されます。しかし、機械学習アルゴリズム自体によるデータの複数回のスキャンによって生じる計算および通信のオーバーヘッドは、依然として大規模機械学習の効率性に対する大きなボトルネックとなっています。

さらに、もう 1 つの大きな課題は、アルゴリズムパラメータの調整です。一般に、機械学習アルゴリズムは 1 つ以上のパラメータに依存します。同じ問題でも、異なるパラメータ設定はモデルの精度に大きな影響を与え、同じパラメータ設定でも問題によって影響が大きく異なります。機械学習に携わる人にとって、パラメータの調整は常に頭痛の種です。知乎には「パラメータを調整すればするほど、患者を治療する医者になったような気分になるのはなぜか？」という質問があり[3]、そこには機械学習のパラメータ調整に関する多くの経験、洞察、不満、ジョークが含まれています。

大規模な機械学習の問題の場合、パラメータの調整は明らかに難しくなります。

まず、トレーニングとテストのプロセスにかかる時間とコンピューティングリソースの消費量は膨大です。どのようなパラメータ調整方法を使用しても、複数の実験を行うと、膨大な時間とコンピューティングリソースの消費量が発生します。

第二に、大規模な機械学習の問題は、計算広告や推奨システムなど、データが急速に変化する問題であることが多いです。以前に決定されたパラメータも、データが変化すると劣化するリスクがあります。

現在、大規模機械学習には 2 つの主な課題があります。1 つ目はコンピューティングリソースの消費量が多く、トレーニング時間が長いこと、2 つ目はパラメータの調整が難しく、効率が低いことです。 TalkingData社も、大規模な機械学習の実践において、この2つの問題に悩まされていました。特に、ハードウェアリソースが非常に限られていた同社の開発初期段階では、この2つの問題が特に顕著でした。私たちはこの問題を解決するために多くの努力と試みを行ってきました。 TalkingDataによって最近オープンソース化されたFregataプロジェクト[4]は、この点に関する私たちの成果をまとめたものです。

2. Fregataの利点

Fregata は、Spark をベースにした TalkingData のオープンソースの大規模機械学習アルゴリズムライブラリです。現在は Spark 1.6.x をサポートしており、まもなく Spark 2.0 もサポートされる予定です。現在、Fregata には、ロジスティック回帰、ソフトマックス、ランダム決定木の 3 つのアルゴリズムが含まれています。

3 つのアルゴリズムのうち、ロジスティック回帰とソフトマックスは一般化線形パラメータ法の一種とみなすことができ、そのトレーニングプロセスは凸最適化法に依存します。我々はSGD最適化手法に基づいて学習率の自動調整を実現し、パラメータ調整の手間を省くGreedy Step Averaging[5]最適化手法を提案した。多数の実験により、GSA最適化手法を用いたロジスティック回帰とソフトマックスアルゴリズムの収束速度と安定性は非常に良好であり、異なるデータスケール、異なる次元スケール、異なるスパース性を持つ問題に対して良好な精度と収束速度を達成できることが示された。

GSA 最適化手法に基づいて、Spark に並列ロジスティック回帰と Softmax アルゴリズムを実装しました。多くの公開データセットと独自のデータをテストした結果、ほとんどのデータでは、データを一度スキャンするだけで収束できることがわかりました。これにより、IO オーバーヘッドと通信オーバーヘッドが大幅に削減されます。

ロジスティック回帰アルゴリズムには、複数の特徴セットの交差をサポートするバリアントバージョンもあります。違いは、次元の交差がトレーニングプロセス中に完了するため、データ準備中に複数の特徴次元セットを事前に準備する必要がないことです。通常、これはデータ量の点でデータ量が拡大することを意味し、データストレージとIOに大きな負担がかかります。計算広告や推奨システムでは、複数のグループのクロスフィーチャーが必要になることが非常に多いため、これに対して特別なサポートを提供しています。

ランダム決定木[6][7]アルゴリズムは、分類、マルチラベル分類、回帰、マルチターゲット回帰の問題を処理できる効率的なノンパラメトリック学習方法です。パラメータの調整も比較的簡単です。しかし、ツリー構造自体が複雑かつ大規模であるため、並列処理は困難です。バイナリ特徴データのトレーニングは一度のスキャンで完了し、トレーニングプロセス中に消費されるメモリが非常に少なくなるように、いくつかのハッシュトリックを採用しました。

まとめると、Fregata には 2 つの利点があります。1 つ目は速度が速いこと、2 つ目はアルゴリズムがパラメータ調整を必要としないこと、またはパラメータ調整が比較的簡単であることです。これら 2 つの利点により、コンピューティングリソースの消費が削減され、効率が向上するとともに、機械学習エンジニアに対する要件も軽減され、作業効率が向上します。

3. GSAアルゴリズムの紹介

GSA アルゴリズムは、私たちが最近提案した勾配ベースの確率的最適化アルゴリズムであり、Fregata が使用する中核的な最適化手法です。これは確率的勾配降下法 (SGD) に基づいた改良であり、実装の容易さ、メモリオーバーヘッドの低さ、大規模なトレーニングサンプルの処理の容易さなど、SGD の利点を維持しながら、SGD の学習率パラメータを手動で調整する手間を省きます。

実際、近年では、Adagrad、Adadelta、Adam など、SGD アルゴリズムのステップサイズ選択問題に関するいくつかの関連研究が行われています。しかし、これらの方法で主張されている適応ステップサイズ戦略は、実際にはアルゴリズムの学習率に対する感度を他のパラメーターに転送し、パラメーター調整の問題を根本的に解決せず、追加のストレージオーバーヘッドも導入します。これらのアルゴリズムと比較すると、GSA は軽量で、実装が簡単で、並列化も簡単です。SGD と比較して追加のメモリオーバーヘッドがなく、あらゆるパラメータから完全に独立しています。

GSA アルゴリズムをロジスティック回帰とソフトマックス回帰に適用し、libsvm 上の異なるタイプとサイズの 16 のデータセットで比較実験を行い、SGD、Adadelta、SCSG (SVRG のバリアント) などの現在一般的なランダム最適化アルゴリズムと比較しました。結果は、GSA アルゴリズムが、パラメータを調整せずに、パラメータ調整後の他のアルゴリズムの最高のパフォーマンスに匹敵することを示しています。さらに、GSA は、計算速度とメモリオーバーヘッドの点でも、これらの一般的な方法に比べていくつかの利点があります。

GSA アルゴリズムの基本原理は非常に単純です。反復の各ステップで、単一サンプルの損失関数に対して直線検索を実行します。具体的には、現在のサンプルポイントの勾配情報のみを使用して正確な直線探索ステップサイズを計算する、ロジスティック回帰とソフトマックス回帰のクロスエントロピー損失関数の近似式を導出します。この近似式を使用して得られたステップ長の時間平均を取って、現在の反復ステップの学習率を計算します。これには 2 つの利点があります。正確な直線探索に基づいて取得されたステップサイズには、現在の反復ポイントからグローバル最小値までの距離情報が含まれます。ステップサイズは、収束に近い場合は比較的小さく、収束していない場合は大きくなるため、収束速度が保証されます。一方、平均化戦略により、アルゴリズムは外れ値に対してより堅牢になり、損失減少曲線が激しく揺れることがないため、アルゴリズムの安定性がさらに高まります。

4. Spark上でのGSAアルゴリズムの並列実装

GSA アルゴリズムは基本的な最適化手法です。Spark では、アルゴリズムの並列化の問題も考慮する必要があります。機械学習アルゴリズムを並列化する方法には、データ並列化とモデル並列化の 2 つがあります。ただし、Spark はデータ並列処理のみをサポートできます。これは、モデル並列処理によって大量のきめ細かいノード間通信オーバーヘッドが発生し、Spark が採用している BSP 同期モードでは効率的に処理できないためです。

データ並列モードで機械学習アルゴリズムを並列化する方法には、勾配平均化、モデル平均化、結果平均化の 3 つがあります。勾配平均化では、各データシャードの現在の勾配更新を計算し、各シャードの勾配更新を集計して平均化し、モデル全体を更新します。モデルの平均化は、各シャードが独自のモデルをトレーニングし、それらのモデルを集約して平均化し、全体的なモデルを取得するプロセスです。結果の平均は実際にはアンサンブル学習ですが、モデルのサイズが大きいため、大規模な問題には適していません。

実際、最もよく使われる方法は勾配平均化です。現在、この方法をサポートするために、パラメータサーバーのさまざまな実装が主に使用されています。Spark MLLib のアルゴリズム実装もこの方法を採用しています。しかし、Spark での勾配平均化の使用は、現在の最新モデルに基づいて現在の勾配更新量を計算するため、データシャード間で頻繁にモデル同期のオーバーヘッドが発生し、MapReuce コンピューティングモデルに大きな負担がかかるため、効率の面で比較的大きなボトルネックがあります。

モデル平均化の収束は理論的には保証されていないと常に信じられてきましたが、最近Rosenblattら[8]はモデル平均化の収束を証明しました。多数のテストで、モデルの平均化によって通常非常に優れたモデル精度が達成できることもわかりました。モデル平均化計算モードが Map Reduce 計算モデルに適していることを考慮して、Fregata では GSA アルゴリズムの並列方式にモデル平均化方式を使用します。モデル平均化の並列方式では、各データシャードは Map フェーズで独自のモデルをトレーニングし、最後に Reduce 操作を通じて各シャードのモデルを平均化します。データを 1 回スキャンするには、モデル同期が 1 回だけ必要です。さらに、多数の実験において、この方法はデータを一度スキャンするだけで非常に高いレベルのモデル精度を達成することができ、基本的にはより多くの反復後の最良の結果に近くなります。

5. FregataとMLLibの比較

Fregata は Spark をベースにした機械学習アルゴリズムライブラリなので、Spark の組み込みアルゴリズムライブラリ MLLib と非常によく似ています。ここでは、3 つのデータセットを簡単に紹介し、2 つのアルゴリズム (ロジスティック回帰と Softmax) の精度とトレーニング時間を比較します。私たちが使用する精度指標は、テストセットの AUC です。精度とトレーニング時間を考慮して、アルゴリズムはスキャンごとにデータを 1 回記録します。

Fregata のアルゴリズムではパラメータ調整は必要ないため、実験は 1 回のみ実施しました。 MLLib のアルゴリズムについては、さまざまなパラメータの組み合わせ (最適化方法の選択を含む) の間でグリッド検索を実行し、テストセットで最高の AUC を達成したパラメータセットを比較結果として選択しました。

Lookalike は Fregata プラットフォームをベースにした成熟したサービスであり、シード人口に基づいて人口を拡大し、潜在顧客を見つけることを目的としています。 Lookalike はバイナリ分類問題として扱われるため、ロジスティック回帰アルゴリズムを使用して処理できます。モデルをトレーニングする際、シード集団は正のサンプルとして使用され、その他は負のサンプルとして使用されます。通常、シード集団の数は多くないため、Lookalike は通常、正のサンプルの割合が非常に小さいクラス不均衡の問題です。大規模データセット (4 億サンプル、2,000 万特徴) での Lookalike 問題のモデルトレーニングにおける Fregata LR と MLLib LR のパフォーマンスを比較しました。

図 4 から、Fregata の LR アルゴリズムは、データを 1 回スキャンした後、AUC の最高値 0.93 (テストセット上) に収束していることがわかります。このデータサンプルでは、パラメータを調整して最適な AUC 結果を選択した場合でも、MLLib の LR アルゴリズムの AUC は約 0.55 にすぎません。モデルの予測精度は大きく異なります。さらに、MLLib のトレーニング時間 (最高精度に到達するまでの時間) も Fregata の 6 倍以上です。

公開データセットeplison[9]（400,000のトレーニングセット、2,000の特徴）では、Fregata LRは収束速度とモデルパフォーマンスの点でMLLib LRよりも大きな利点を持っています。図 5 からわかるように、このデータセットでは、Fregata LR は 1 回の反復でテストセットの最良の結果に非常に近い値を示していますが、MLLib LR は 5 回の反復を必要とし、その最高精度は Fregata LR よりもはるかに低くなっています。MLLib LR のトレーニング時間も Fregata LR の 5 倍以上です。

さらに、図 6 は、6 つの異なる問題に対する Fregata LR と MLLib LR のテストセット AUC 曲線を示しています。さまざまな問題に対する Fregata LR アルゴリズムの収束速度と安定性は、MLLib LR よりも大幅に優れていることがわかります。最初の反復後、Fregata LR の AUC は基本的に収束しました。最高値とはまだ若干のギャップがありますが、非常に近い値です。

また、公開データセット MNIST で Softmax アルゴリズムをテストしました。図 7 からわかるように、テストセットでの Fregata Softmax の AUC は、データを 1 回スキャンした後、最良の結果に非常に近い値になります。一方、MLLib Softmax では、データを 1 回スキャンした Fregata Softmax の結果に近づくまでに、データを 40 回以上スキャンする必要があります。 2 つのアルゴリズムがそれぞれの最適な結果に到達するまでにかかる時間を比較すると、MLLib Softmax は Fregata Softmax の 50 倍以上になります。

6. フレガータの紹介

Fregata アルゴリズムライブラリに含まれるいくつかの技術的原理とパフォーマンス比較について簡単に紹介しました。次に、Fregata の使い方を見てみましょう。 Fregata は 3 つの異なる方法で入手できます。Maven を使用してプロジェクトを管理する場合は、次のコードを追加して pom.xml に導入できます。

 <依存関係>
     <groupId>com.talkingdata.fregata</groupId>
      <artifactId>コア</artifactId>
      <バージョン>0.0.1</バージョン>
  </依存関係>
  <依存関係>
      <groupId>com.talkingdata.fregata</groupId>
      <artifactId>スパーク</artifactId>
      <バージョン>0.0.1</バージョン>
  </依存関係>

SBT を使用してプロジェクトを管理する場合は、次のコードを使用して build.sbt に導入できます。

 // ローカルのMavenリポジトリに手動でデプロイする場合は、次の行のコメントを解除してください
    // リゾルバー += Resolver.mavenLocal
    ライブラリ依存関係 += "com.talkingdata.fregata" % "core" % "0.0.1"  
    ライブラリ依存関係 += "com.talkingdata.fregata" % "spark" % "0.0.1"

ローカル Maven リポジトリに手動でデプロイする場合は、コマンドラインで次のコマンドを実行します。

 git クローン https://github.com/TalkingData/Fregata.git
 cd フレガータ
mvn クリーンパッケージのインストール

次に、ロジスティック回帰を例に、Fregata を使用して分類タスクをすばやく完了する方法を見てみましょう。

1. 必要なパッケージをインポートする

fregata.spark.data.LibSvmReader をインポートします
fregata.spark.metrics.classification.{AreaUnderRoc, Accuracy} をインポートします。
 fregata.spark.model.classification.LogisticRegression をインポートします。
 org.apache.spark.{SparkConf, SparkContext} をインポートします。

2. FregataのLibSvmReaderインターフェースを介してトレーニングデータセットとテストデータセットをロードします。トレーニングデータセットとテストデータセットは標準のLibSvm形式です。[10]を参照してください。

 val(_, trainData) = LibSvmReader.read (sc, trainPath , numFeatures.toInt)です。
 val (_, testData) = LibSvmReader.read (sc, testPath , numFeatures.toInt)です。

3. トレーニングサンプルのロジスティック回帰モデルをトレーニングする

val モデル = LogisticRegression.run(trainData)

4. トレーニングされたモデルに基づいてテストサンプルを予測する

val pd = model.classPredict(テストデータ)

5. Fregataの組み込み指標を通じてモデルのパフォーマンスを評価する

val auc = AreaUnderRoc.of ( pd.map{
ケース((x,l),(p,c)) =>
      p -> l
  })

Fregata では、breeze.linalg.Vector[Double] を使用してサンプルの特徴を保存します。データ形式がすでに LibSvm である場合は、Fregata の内部インターフェイス LibSvmReader.read(…) を介してロードするだけで済みます。それ以外の場合は、次のメソッドを使用して、インスタンスを表すデータセットを breeze.linalg.Vector[Double] にカプセル化し、トレーニングとテストのためにモデルに組み込むことができます。

 // インデックス配列型、添え字は0から始まり、0ではないデータの添え字を保存します
//値配列型、対応するインデックスに対応するデータ値をインデックスに保存します
// 長さInt型、サンプル特徴の総数
// label Double型、サンプルのラベル。テストデータの場合、このフィールドは必須ではありません。
 sc.textFile(入力).map{
 val インデックス = ...
 val値= ...
 val ラベル = ...
 ...
 (新しいSparseVector(インデックス、値、長さ).asInstanceOf[Vector], asNum(ラベル))
 }

7. Freagataの開発目標

Fregata は現在、多くのアルゴリズムを統合していませんが、今後、より効率的な大規模機械学習アルゴリズムを拡張していきます。 Fregata プロジェクトは、軽量、高性能、使いやすさという 3 つの目標を追求しています。

軽量とは、Fregata が別個のコンピューティングシステムを構築せずに、可能な限り標準の Spark バージョンでアルゴリズムを実装し、標準の Spark バージョンで Fregata を非常に簡単に使用できるようにすることを意味します。 Spark には、ビッグデータ処理の基本ツールとして、モデルサイズの制限など、いくつかの固有の制限がありますが、Fregata のサポートにより、大規模な機械学習の適用の敷居を大幅に下げることができます。結局のところ、専用の大規模機械学習コンピューティングプラットフォームを構築し、それをビッグデータ処理プラットフォームとプロセス全体に統合するためのコストと複雑さは無視できません。

高性能とは、高精度と高効率を同時に追求し、アルゴリズムとエンジニアリングの実装の面でアルゴリズムの精度と効率を極限まで押し上げ、大規模な機械学習アルゴリズムをかさばる肉切り包丁から軽い短剣に変えることを意味します。現在、Fregata の主な制限は、Spark の固有の欠点に基づくモデル規模の問題です。将来的には、この問題を軽減するためにいくつかのモデル圧縮方法が使用される予定です。

使いやすさも Fregata が追求する目標であり、最も重要な点はパラメータ調整の難しさを軽減することです。現在の 3 つのアルゴリズムのうち、2 つはパラメータ不要で、もう 1 つは比較的パラメータ調整が容易です。パラメータ調整の難しさを軽減したり、パラメータ調整の問題をなくしたりすると、モデル適用の難しさやコストが大幅に削減され、作業効率が向上します。

一方、LR アルゴリズムの特徴的な相互反応要件など、いくつかの一般的なシナリオにおける特別な要件も考慮します。一般的な LR アルゴリズムは非常に効率的ですが、特徴の交差などの一般的な要件に対して、特徴の交差プロセスがアルゴリズムに結合されていない場合は、特徴を事前に交差する必要があり、膨大な IO オーバーヘッドが発生します。このアルゴリズムは機能のクロストークのサポートを実装しており、この効率のボトルネックを回避します。今後は、より多くのアルゴリズムを統合しながら、さまざまな一般的なシナリオで特別な処理が必要になるかどうかも検討していきます。

Fregata プロジェクトの中国語名は「Frigate Bird」です。TalkingData のオープンソースプロジェクトはすべて鳥にちなんで名付けられています。Frigate Bird は世界最速の鳥で、最高時速は 418 km/h、最大重量は 1.5 kg、翼幅は 2.3 メートルです。世界中に広く分布しています。 Fregata プロジェクトは、グンカンドリのように軽量でありながら、大規模で効率的な機械学習をサポートし、強力な適用性を持つものになることを期待しています。現在、フレガータはまだ幼鳥ですが、将来は飛べる猛禽類に成長することを期待しています。

参考文献

[1] Cheng T. Chu、Sang K. Kim、Yi A. Lin、Yuanyuan Yu、Gary R. Bradski、Andrew Y. Ng、Kunle Olukotun、「マルチコアでの機械学習のためのMap-Reduce」、NIPS、2006年。

[2]

[3] https://www.zhihu.com/question/48282030

[4] https://github.com/TalkingData/Fregata

[5] http://arxiv.org/abs/1611.03608

[6] http://www.ibm.com/developerworks/cn/analytics/library/ba-1603-random-decisiontree-algorithm-1/index.html

[7] http://www.ibm.com/developerworks/cn/analytics/library/ba-1603-random-decisiontree-algorithm-2/index.html

[8] Rosenblatt JD、Nadler B. 分散統計学習における平均化の最適性について[J]。情報と推論、2016：iaw013 MLA

[9] https://www.csie.ntu.edu.tw/~cjlin/libsvmtools/datasets/binary.html#epsilon

[10] https://www.csie.ntu.edu.tw/~cjlin/libsvmtools/datasets/

著者について

Zhang Xiatian: TalkingData の主任データサイエンティスト。大規模機械学習とデータマイニングの分野で 12 年の経験があり、推奨システム、計算広告、大規模機械学習アルゴリズムの並列化、ストリーミング機械学習アルゴリズムで深い業績を上げています。トップの国際会議やジャーナルで 12 本の論文を発表し、9 件の特許を申請しています。IBM CRL、Tencent、Huawei Noah's Ark Lab の元データサイエンティストであり、KDD2015 および DSS2016 国際会議で基調講演を行いました。また、オープンソースの機械学習プロジェクト Dice の創設者でもあります。

<<: オタクのためのオープンソースドローンプロジェクト4つ

>>: YouTube 動画推奨アルゴリズムを破る方法