確かな情報です! AIテクノロジーアーキテクチャソリューションの実現可能性を判断するのに役立つ3つの重要な要素

近年、人工知能は急速に発展しており、コンピュータービジョンや自然言語処理の分野で画期的な変化をもたらしただけでなく、他の分野でも技術革新の波を引き起こしています。新規事業の試みであれ、既存事業のアップグレードであれ、60年以上にわたり押し寄せてきた「新しい波」であるAIは、私たちの伝統的な技術アーキテクチャの概念に微妙な影響を与えています。

[[329873]]

AI アーキテクチャ (特に機械学習やディープラーニングに代表されるアーキテクチャ ソリューション) は、当社の技術アーキテクチャ選択における新たな選択肢となっています。

AI アーキテクチャ ソリューションが必要ですか? AI アーキテクチャを選択するための主な基準は何ですか? これが今日議論する主な問題です。

まず、典型的な AI アーキテクチャを見てみましょう。

• まず、モデルのトレーニングに必要なデータを収集する必要があります。このデータは、CTR 推定タスクにおけるユーザーのクリック データやユーザーの注文データなど、ビジネス システム自体から取得される場合があります。また、画像分類タスクにおける画像や NLP タスクにおけるコーパスなど、システム外部から取得されたり、公的に購入されたり、独自にクロールされたりする場合があります。
• これらのデータは収集された後、一度だけ使用されるわけではないため、クリーニング、処理、保存されます。一般的には、分散ストレージデバイス（HDFS など）またはクラウドに保存されます。ほとんどの企業は独自のデータ プラットフォームを構築し、長期蓄積のためにデータ ウェアハウスに保存します。
• 必要な場合は、まずデータをスクリーニングし、適切な特徴データを選択してから、データを前処理してからアルゴリズム モデルに送信します。モデルを構築するためのオプションの技術フレームワークは多数あり、Spark mllib、sklearn、tensorflow、pytorch などをベースにすることができます。その後、トレーニング、評価、パラメータ調整を経て、モデル構築が完了します。
• 最後に、モデルを特定のオンライン ビジネスに適用して、分類と回帰の特定のタスクを完了する必要があります。展開プロセス中に、モデルをパッケージ化し、予測モデルをビジネス システム (クライアント) に直接展開することができます。また、言語間の呼び出しを容易にするためにオンライン RESTful インターフェイスを直接提供することも可能です。

まとめると、データの収集、処理、特徴選択、データの前処理、モデルのトレーニング、モデルの評価、モデルの適用を経て、データはビジネスシステム、データプラットフォーム、アルゴリズムモデルの 3 つのシステムを通過して閉ループを形成し、最終的に AI アーキテクチャ全体の中核となるビジネスシステムに適用されます。

AI アーキテクチャは必要ですか? この技術アーキテクチャ ソリューションの実現可能性をどのように測定しますか? それは主に次の 3 つの要素に依存すると思います。

1. シナリオ

アーキテクチャの実現可能性を議論する場合、それがビジネスやビジネス開発に適しているかどうかが第一の基準であり、AI アーキテクチャも例外ではありません。

推奨、検索、広告など、古典的で広く使用されている機械学習のシナリオを振り返ると、これらのシナリオはすべて、シナリオが比較的閉じられており、目標が単一であり、制御可能であるという特徴があります。

その理由は、アルゴリズム モデルがいかに複雑であっても、最終的には損失関数に基づいて実装され、後者は一般に単一の目的と単一の最適化タスクだからです。あるいは極端な値（損失の最小化）を追求したり、一定の対立バランスを実現したりします（GAN など）。この場合、ビジネスがどのようにモデル化されるかに関係なく、アルゴリズム モデルと損失関数に基づいて実装する必要があり、最終的にはシナリオと目標の単一性が制限されます。

したがって、ビジネスが AI アーキテクチャに適しているかどうかを判断するには、まずビジネス シナリオの目標が単一かつ制御可能であるかどうかを確認する必要があります。または、ビジネス モデリングとアーキテクチャの分解後、各リンクのシナリオが単一であるかどうか。

例えば、同城魯龍のホテルシステムは、ホテル業者にホテルの写真をアップロードする機能を提供しています。このシナリオでは、写真の合法性を確認するだけでなく、写真に「ロビー」、「フロント」、「客室」、「周辺」などの分類ラベルを付ける必要もあります。 AIアーキテクチャを正常に使用するには、シーン内のターゲットを分割し、異なる分類器をトレーニングする必要があります。具体的なプロセスは以下のとおりです。

このうち、ステップ 2、3、4 には複数の画像分類器が関与し、それぞれに異なる目標があり、異なるトレーニング データが必要です。同じサンプル画像入力に対して、各分類器は独自の機能を実行し、目標は単一かつ制御可能です。失敗したサンプルの中には、手動による介入が必要になるものもあります。最後に、法的写真はシステムに保存されます。

ビジネス上の必要性の観点から見ると、すべてのビジネス シナリオで AI アーキテクチャが必要なわけではありません。アルゴリズムモデルは物事の正確なシミュレーションと抽象化であり、その複雑性は比較的高いです。しかし、私たちのビジネスでは、このような細かい制御が必要ない場合もあります。たとえば、単純な if...else... ステートメントで問題を解決できる場合もあります。より複雑なケースでは、複数の「戦略」を設計し、ビジネス エキスパートがそれぞれの状況に合わせて戦略を構成する場合があります。さらに複雑なケースでは、BI ソリューションが検討される場合もあります。つまり、データを収集し、多次元分析を実行し、最後にアナリストとビジネス エキスパートがいくつかの一般的な結論を導き出してシステムに組み込むという方法です。これも非常に効果的です。

ホテルの流通価格調整を例に挙げてみましょう。ホテルを販売代理店に流通させる前に、商品の販売価格をベース価格に基づいて介入し、一定のポイント数（パーセンテージ）を調整して、利益を最大化しながら販売を確保します。

最初は、固定レート（6% の値上げなど）になる場合があります。事業が発展するにつれ、ホテルを「高級かどうか」と「人気があるかどうか」という2つの軸で4象限に分け、「高級・人気」のホテルには高い価格調整率を、「非高級・不人気」のホテルには低い価格調整率を施行するなど、一連の戦略が立てられました。その結果、利益が大幅に増加し、効果は良好でした。

その後、ビジネス担当者はより正確な管理をしたいと考え、ホテルの星評価、地域、ビジネス地区、独占性、客室タイプなどの要素をより細かく分類し、過去のデータを組み合わせて統計分析を行い、さまざまな結果に異なる価格調整率を適用しました。生産量と利益がさらに増加し​​ました。

現時点では、すべてのビジネス関係者が比較的満足しており、コストが高くなく、システムの複雑さも高くない場合は、より洗練されたインテリジェントな AI アーキテクチャを検討する必要はありません。 AI の導入の本質は、コストと利益のバランスを取り、システムの複雑さを制御しながら、効率、エクスペリエンス、精度の向上をもたらすことです。これらを達成できない場合は、計画を再検討する必要があります。

もちろん、アーキテクチャとビジネス開発のスケーラビリティを考慮し、設計に「オープンとクローズ」のスペースを確保することもあります。現時点では「戦略モード」がよい選択かもしれません。システムのデフォルト戦略については、戦略拡張インターフェースを維持しながら、手動構成ベースのソリューションを採用しています。今後、ビジネス要件が増加すると、「AIベースの戦略」が導入されます。これにより、現在のコストが制御されるだけでなく、システムのスケーラビリティのバランスも保たれます。

2. データ

データによって機械学習の上限が決まりますが、アルゴリズムとモデルはこの上限に近似するだけです。

データの収集と取得には通常長い時間がかかり、十分で包括的なデータ ウェアハウスの構築にはさらに長い蓄積と磨き上げが必要です。したがって、データはどの企業にとっても貴重な資産であり、簡単に譲渡されるものではありません。アルゴリズム モデルの成功はデータと機能に依存します。したがって、AI アーキテクチャ ソリューションが最終的に良好な結果を達成できるかどうかは、十分かつ適切なデータが収集されているかどうかによって決まります。

これらのデータ ソースには通常、独自のシステムからの収集、インターネット上の公開データの収集 (またはクロール)、外部からの購入が含まれます。

独自のシステムからの収集が最も一般的なソリューションであり、ビジネス システム自体によって生成されたデータは、通常、ビジネス シナリオでの適用に適しています。しかし、このようなデータは貴重で希少であるため、企業の意思決定者は事前に計画を立て、ビジネスデータの収集と整理を早期に開始し、データプラットフォームを構築し、データウェアハウスを充実させる必要があることがよくあります。このようにして、数か月後、あるいは数年後にAIアーキテクチャが実際に使用されるときには、弾薬庫にはすでに十分な「弾薬」があることになります。

インターネット上の公開データをクローリングするのも高速かつ無料の方法ですが、広大な海の中から自分に合ったデータを探すのは簡単ではありません。また、自分が入手できるからといって他社も入手できるわけでもなく、競合他社との差別化が難しいという問題もあります。

アウトソーシングは通常、莫大な費用がかかり、品質もまちまちなので、インターネット企業にとっては最後の手段となることが多いです。

データの取得にはコストがかかり、困難で、蓄積に長い時間がかかり、シナリオが AI アーキテクチャの使用に適しているという前提の下では、データ不足に直面した場合、解決策はないのでしょうか? 必ずしもそうではありません。まだいくつかの代替ソリューションがあります。

（１）浅いモデルは通常、深いモデルよりも少ないデータを必要とします。したがって、データの量が不十分な場合は、通常、データの需要を減らすために、深いモデルの代わりに浅いモデルが使用されます。もちろん、モデルの表現力も低下しますが、特に複雑ではないビジネスシナリオであれば、浅いモデルでも良い結果を得ることができます。もちろん、これには特徴マイニングに対するより高い要件と、モデル選択に関するより厳しい要件が伴います。分類タスクを例に挙げてみましょう。SVM、ロジスティック回帰、ランダムフォレスト、ナイーブベイズ...各モデルには独自の特性と適用性があります。すべてのデータを有効に活用するには、それらを十分に考慮して比較検討する必要があります。いわゆるデータが不十分でモデルを使用するのも最後の手段です。

（２）事前学習済みモデルの使用も、データ要件を削減する良い方法です。転移学習は画像分類問題で広く使用されており、BERTモデルは事前学習済みモデルを自然言語処理にも導入しました。特定の問題の場合、適切な事前トレーニング済みモデルを見つけて、それを少量の独自のデータで微調整することができれば、データの需要が減るだけでなく、トレーニング時間も大幅に短縮され、一石二鳥になります。ただ、適切な事前トレーニング済みモデルを見つけるのは難しいのです。

（３）データ要件を削減するためのもう一つの回避策は、少量のデータから始めて、継続的にデータを取得し、モデルの更新頻度を増やして「オンライン学習」アプローチを採用することです。ここで実際に行っているのは、総データ需要を時間次元に拡張して解決することです。もちろん、ビジネスでは、初期モデルの精度がそれほど高くなくても許容する必要があります。データの増加とモデルの継続的な更新により、期待される効果が徐々に達成されます。

たとえば、ホテル ショッパー製品の表示を高速化するために、ホテル ショッパー製品の販売は通常、サプライヤー データを事前に取得することによって実装されます。ただし、サプライヤーが提供する QPS は非常に限られており、一度にキャプチャできるホテルは 1 つだけです。高頻度のキャプチャにより、ホテル データの鮮度が確保され、ゲストに優れたエクスペリエンスを提供できます。低頻度のキャプチャでは、在庫や価格情報の適時性が保証されず、予約の失敗や損失につながることがよくあります。したがって、ホテル間で QPS を合理的に分配する方法は、典型的な機械学習の問題です。

ホテルの人気度、予約サイクル、休日など、複数の次元から特徴マイニングを実施しましたが、データ ウェアハウスには 3 か月分のデータ、つまり現在の季節のデータしかなかったため、「季節」という重要な要素に対して有効な特徴を抽出できないことが最終的に判明しました。

この問題を解決するために、モデルを再設計し、アーキテクチャを調整し、「オンライン学習」アプローチを採用して、モデル更新問題をソリューションに組み込みました。元のデータは、初期モデルのトレーニングにのみ使用されます。オンラインになった後、モデルは新しく生成されたデータを継続的に取得して繰り返し更新し、季節要因の追跡を確実にするために、より近いタイムラインを持つデータに高いサンプル重みを割り当てます。システムが運用開始されてから、非常に良い結果が得られました。

（４）初期データが不足している場合、強化学習が代替手段として用いられることが多い。強化学習では「試行錯誤」のアプローチを採用し、継続的に進化して最終的にルールを学習します。もちろん、これにはビジネスモデルへの対応する調整が必要です。同時に、進化のサイクルが長すぎると、モデルが初期段階でかなりの期間、より良い決定を下すことができない可能性があるため、より高いビジネス許容度が求められます。

3. 計算能力

周知のとおり、トレーニング プロセスは典型的な「計算集約型タスク」です。強力な計算能力がなければ、アルゴリズム モデルのトレーニングと研究をサポートすることは困難です。 GPU は機械学習のほぼ標準的なコンピューティング プラットフォームであり、トレーニング時間は CPU に比べて 5 倍以上短縮されます。

現在、それを取得する主な方法は、自社構築のクラウド プラットフォームとリースのクラウド プラットフォームの 2 つです。お金があれば、もちろん自分で作ることもできますが、最近の GPU は急速にアップグレードされているため、基本的に 1 年に 1 回交換することになります。機械学習に使われるGPUは計算速度が重要であり、多額の費用をかけて構築したGPUクラスターは数年後には「古い車」になってしまう可能性が高い。

クラウド プラットフォームをリースすると、最新の GPU コンピューティング速度がもたらす「快感」をいつでも享受できますが、多くのエネルギーも必要になります。各クラウド プラットフォームが提供するサービスとコストを詳細に比較するだけでなく、リソースの使用率を最大化するために CPU と GPU を合理的に一致させる必要があります。

ここまで述べてきましたが、最も頻繁に言及される 2 つの単語はおそらく「コスト」と「利益」であり、これらは企業が最も懸念している問題でもあります。コンピューティング リソースであれ、システム アーキテクチャであれ、AI アーキテクチャのソリューションには相当のコストの投資が必要です。適切なシナリオで適切に選択すれば、AI はかなりの利益をもたらすことができます。ただし、収益が費用を賄うのに十分でない場合は、AI アーキテクチャ ソリューションの選択には注意が必要です。

最後に、技術者の確保と法的要因も、AIアーキテクチャを実装する前に考慮する必要がある問題です。少し前に、工業情報化部はAIの顔を変えるアプリケーション企業を召集しました。

AIは、新しいテクノロジーや産業をもたらすだけでなく、古いシステムに新たな命を吹き込む機会も与える波です。技術者として、私たちは新しいテクノロジーがもたらす課題を受け入れるだけでなく、テクノロジーの選択における主な要因とその背後にあるリスクを明確に理解して、波の頂点に立つ必要があります。では、AI アーキテクチャ ソリューションは必要ですか?