|
オタクトーク 01 検索ディープラーニングモデルビジネスとアーキテクチャの進化 下の画像に示すように、川の長さを尋ねると、検索結果は川の正確な長さを返します。ユーザーが順番に検索するウェブページへのリンクを返すのではなく、答えが返されます。これはディープラーニングの重要な役割によって可能になっています。ディープラーニングモデルはコーパスから正確な回答を検索、判断、抽出し、ユーザーに提示します。さらに、ユーザーは画像を入力して、その画像に何が含まれているかを尋ねることもできます。 1.1 セマンティック検索パスの検索 検索の発展を振り返ると、初期の手動機能から浅い機械学習モデル、そしてますます洗練された深層学習モデルへと進化を遂げ、ユーザーのニーズと候補コンテンツを理解する能力は継続的に向上してきました。この能力の向上は、ある程度、アーキテクチャの変化に影響を与えています。近年、最も大きなアーキテクチャの変化の一つは、大規模な深層学習モデルとシステムの実装です。 従来の検索手法では、転置インデックスが使用されます。通常、インデックス作成とは、テキストを起点として、そのテキスト内のキーワードの出現頻度を数えること、つまり順方向インデックス作成と理解されています。では、転置インデックス作成とは何でしょうか?これは、ユーザーが単語を検索し、その単語がどのテキストに出現するかを確認することです。しかし、中国語の文脈では、たった1つか2つの文字や単語を変えるだけで、文の意味が大きく変わってしまうことがあります。例えば、「山桃红了」(山桃は赤い)と「山桃花红了」(山桃の花は赤い)は、前者は山桃の実の色を表し、後者は山桃の花の色を表します。 転置インデックスではこれらの変更を捕捉するのが困難ですが、セマンティック インデックスはそのような問題の解決に優れています。 では、セマンティックインデックスとは何でしょうか? ユーザーのクエリをベクトル(128/256次元)に埋め込み、ウェブコンテンツ全体を検索し、埋め込みをベクトル空間にマッピングします。このベクトル空間をセマンティック空間と考えることができます。検索結果がベクトル空間内で近いほど、セマンティクスが類似していることになり、ユーザーにとってより満足度の高い結果が得られます。 1.2 ディープラーニングモデルの探索 検索と推奨には共通点が多いですが、違いも多くあるため、ここで比較しながら説明します。 検索用の意味理解モデルでは、変換型構造が広く使用されており、特徴としてテキスト、通常 200,000 語未満の語彙、深いモデル、および大量の計算が必要です。 推奨モデルには、多数のユーザー機能とマテリアル機能、およびインタラクション機能が含まれ、語彙のサイズは TB レベルに達し、広範囲だが比較的浅いという特徴があります。 検索モデルの特徴: 1. 元のテキスト/画像 -> 埋め込み 2. クエリURL/タイトル/コンテンツ 3. ディープモデル 4. オフライン事前学習とオンライン多段階予測 5. 計算集約型 -> 異機種ハードウェア △ 画像出典:Vaswani A, Shazeer N, Parmar N, et al. Attention is all you need[J]. Advances in neural information processing systems, 2017, 30.CTR/推奨モデルの特性: 1. 高次元離散特徴量 -> 埋め込み 2. 特徴エンジニアリングサンプルのアセンブリと特徴抽出 3. 浅いDNN 4. タイムリーさ -> オンライン学習 5. 高スループット -> CPU + PS △ 古典的なCTRモデルWide & Deepの模式図(画像出典:Cheng HT、Koc L、Harmsen J、et al. Wide & deep learning for recommender systems[C])1.3 意味検索パスウェイにおけるディープラーニング検索モデルの応用セマンティック検索パスウェイは、主にオフラインパスウェイ(下図の左側)とオンラインパスウェイ(下図の右側)に分類されます。オフラインとオンラインの両方の手法で、深層学習モデルERNIEが利用されていることがわかります。 △ 画像出典: Liu Y, Lu W, Cheng S, et al. 百度検索におけるウェブスケール検索のための事前学習済み言語モデル[C] オフライン側では、ネットワーク全体に膨大な量のテキストが存在し、それらすべてをデータベースに取得して埋め込みを行う必要があります。このタスクでは、オフラインパスを事前に計算し、データベースに保存する必要があります。 02 2.1 オンラインシステムとニアライン/オフラインシステム オンライン検索推論システムは、ユーザーのクエリに基づいてリアルタイムで計算を行い、結果を返します。このモデルは、主に要件分析/クエリ書き換え、関連性/ランキング、分類の3つの部分に分かれています。 (1)要件分析・クエリ書き換えとは、ディープラーニングモデルを通じて意味的に類似したクエリを返すことです。 ユーザーが「『サーキットブレーカー』とはどういう意味ですか?」と質問し、その質問に口語表現が含まれている場合、ディープモデルは意味的に類似したクエリ「『サーキットブレーカー』とはどういう意味ですか?」を返すため、取得される回答はより豊富で正確になります。 (2) 関連性/ランキングには、粗いランキング/細かいランキングモデルが必要です。ユーザークエリとタイトルに関連するウェブページ情報を連結し、モデルが関連性を計算します。その結果得られたスコアによって、ユーザーに結果を返す際のランキングが決まります。 ユーザーが「西安の観光名所 必見ガイド」と質問した場合、モデルによって与えられたスコアが高いほど、Web ページがユーザーのニーズに近くなり、結果は「float: 0.876」になります。 (3)分類、つまりモデルを通して型を識別し、その型を返す。 ユーザーが「ジェイ・チョウのライスフレグランス」と尋ねると、モデルはこれが音楽のリクエストであることを認識し、ユーザーに音楽タイプのカードを表示できます。 オフライン検索システムは、時間的制約の少ないタスクの処理に使用されます。検索の利用状況は、特に深夜のユーザートラフィックが非常に少ない時間帯に、明確なピークと谷のパターンを示します。冗長リソースはオフライン計算に使用でき、結果はコーパスに保存されます。例えば、冒頭で述べたエベレストの標高に関する質問では、ディープラーニングモデルによってコーパスから直接回答を抽出できます。その他の完全にオフラインのタスクには、バッチデータベースの作成と、インデックスを取得してデータベースに保存する処理が含まれます。 2.2 ディープモデル推論システム ディープモデルは検索システムの多くのタスクで利用されています。私たちは、すべてのユーザーとビジネス関係者が同じAPIを使用してディープモデルを呼び出せるようにすることを目指しており、それが私たちの取り組みの一部です。 ディープ推論システムの後は、モデルのタイプ、サイズ、次元、異機種コンピューティング能力がそれぞれ異なるため、バックエンドでディープモデル推論サービスを展開する必要があります。 では、同時実行性が増加した場合、どのようにすれば均一なスケジュールを実現し、システムの安定性と信頼性を確保できるのでしょうか? まず、均一なスケジューリングです。 下の図は、企業内モデルの典型的なデプロイメントスキームを示しています。各自が受け取るコンピューターはスタンドアロンマシンと呼ばれますが、スタンドアロンマシンは粒度が細かすぎるため、サービス提供やスケールアップ・スケールダウンなどのために、より細分化された仮想化が必要です。これをインスタンスと呼びます。 さらに、安定性と信頼性も不可欠です。 アーキテクチャ分野では、「アーキテクチャとは、不安定なハードウェア上に安定したシステムを構築することである」という有名な格言があります。インスタンスやマシンの数が増えるにつれて、ハードウェア障害は避けられなくなります。私たちの責任は、タイムリーな障害検出と軽減を実現し、良好なユーザーエクスペリエンスを保証することです。 さらに、リソースコストを最小限に抑えながら、十分に高速で高スループットな推論システムを目指しています。 図に示すように、推論システムへのリクエストはbrpcを介して入力されます。brpcは社内モジュール間のネットワーク呼び出しを容易にし、ユーザーはローカル関数呼び出しと同様に他のサービスを呼び出すことができます。リクエストを受信すると、システムは推論リクエストからアクセスするモデル、アクセスするバージョン、入力などの情報を識別し、処理パイプラインに進みます。 処理パイプラインは 4 つの部分で構成されます。 (1)キャッシュ:一定時間内に同じリクエストが計算された場合、GPUを呼び出すのではなく、キャッシュを通じて結果を直接ユーザーに返します。 (2) 動的バッチ:多くのオンラインモジュールはバッチサイズ1でモデル計算を開始しますが、バッチサイズ1ではハードウェアを最大限に活用できず、一部の計算ユニットはバッチサイズが小さいため帯域幅のボトルネックになる可能性があります。ハードウェアを最大限に活用するために、レイテンシが許す限りバッチサイズを可能な限り大きくします。そのため、一定の時間枠などのルールを用いて推論リクエストをバッチにまとめ、その後、それらを分割してユーザーに返します。 (3) 自然言語処理モデルに対応するユーザー定義の前処理は、平文をIDに変換します。なぜユーザー定義の前処理が必要なのでしょうか?これは、検索統合の多様なビジネス方向性に関係しています。各ビジネスには異なるデータ前処理方法があるため、ユーザーが定義できるようにすることがより適切です。 (4) 予測キュー:前処理後、リクエストはキューに入ります。このキューは、バックエンドの予測エンジンに順番に入ります。予測エンジンが計算を実行した後、ユーザーがカスタマイズした後処理に入ります。後処理によって出力結果が最適化され、上流に返されます。 以上が超大規模オンライン推論システムの概要です。 オタクトーク 03 ディープモデル最適化の実践 3.1 モデル最適化におけるボトルネック 私たちのディープラーニングモデルの最適化は、特定のボトルネックをターゲットにしています。GPUモデルは通常、I/Oボトルネック、CPUボトルネック、GPUボトルネックの3種類のボトルネックに直面します。下の図に示すように、学習プロセス全体は、データの読み取り、順方向推論、バックプロパゲーションで構成されます。私たちの推論プロセスは、データの読み取りと順方向推論の2つの部分に分けられます。 (1)IOボトルネックとは、バッチ1とバッチ2のデータ処理間の間隔を指し、データの読み取り速度を高速化する必要があります。 (2) CPUボトルネックとは、CPUがGPUに割り当てるワークロードが少なすぎるためにGPUの利用が不十分になる状況を指します。これは、複数の演算を含むディープラーニングモデルが、GPU上で複数の演算シーケンスに分解されて計算されるという状況を指します。その前にCPUが処理を実行する必要があり、GPUは演算を完了しますが、CPUはまだ次のタスクを送信していません。 (3) GPUボトルネック。GPUボトルネックが発生した場合、GPUの使用率がすでに十分であることを意味し、これは良好な状態です。 3.2 モデル最適化作業 モデルの最適化作業は、トレーニング、推論、小型化の 3 つの側面に分かれています。 3.2.1 トレーニングの最適化(1)データの読み取り 特定のシナリオに合わせてデータ読み取りを最適化しました。これは、モデルが大きくなるにつれて、モデルを分割し、複数のGPUを搭載した単一のマシン、あるいは複数のマシンで学習させようと試みてきたためです。異なる分割方法を用いると、データ処理がシナリオに深く適応できないことがよくありました。 PaddlePaddleフレームワークを使用するか他のフレームワークを使用するかに関わらず、多くの操作(OP)が提供されています。これにより、ユーザーは同じ機能を異なるOPで実現できるため、高い自由度が得られます。しかし、異なるOPは実際の実行において非効率的または効率的になる可能性があります。そのため、私たちの作業の一部は、それらのOPを特定し、より効率的な実装に置き換えることです。 3.2.2 推論の最適化カーネルの融合/開発と同等の置き換えに加えて、推論の最適化には GPU/CPU 負荷分散とモデル構造のプルーニングも含まれます。 (1)GPU/CPU負荷分散 推論シナリオでは、前処理、カーネルランチ、後処理など、CPUのワークロードはそれほど重くありません。メモリアクセスは多いものの計算負荷は低い処理など、GPUが苦手とするタスクをCPUに任せることで、CPUで実行した方が合理的です。 (2)モデル構造のトリミング 3.2.3 モデルの小型化小型化は、蒸留、定量化、剪定という 3 つの方向に分けられます。 (1)サービス指向の蒸留 蒸留とは、複雑で大規模なモデル(教師)の知識をより小さく単純なモデル(生徒)に転送するモデル圧縮技術です。これにより、小規模なモデルでも大規模モデルと同様の学習結果を維持できます。 実際のビジネスシナリオでは、教師の数が増え続けると、蒸留プロセスを並列化できなくなります。教師モデルの順方向推論は逐次実行され、その時間消費が増大し、大きなボトルネックとなります。そのため、エンジニアの観点からは、教師を異機種コンピューティングパワー上に配置して推論を実行させます。これにより、逐次実行されている教師の順方向推論が並列化される一方で、アイドル状態のリソースも活用されます(下図参照)。これにより、蒸留プロセス全体の効率が向上します。 (2)定量化 (3)剪定 オタクトーク 04 要約 |