【ビッグネーム登場、第2話】快溝タクシーの知能進化への道

インテリジェントな注文発送システムをゼロから構築するように依頼され、1 日の注文数が 40 万件だとしたら、その注文を引き受けますか?あなたは何をしますか？やったことがある人は簡単だと言うでしょうが、やったことがない人は考えることすらできません。実は、技術に大した違いはありません。違いは「一度やってみる」という経験にあります。他の人の経験談を聞くのも、経験を積む良い方法です。私たちはかつて快溝タクシーのシニアマネージャーである胡先波氏を招き、彼の経歴について語ってもらいました。彼は快溝タクシーの配車システムがゼロからインテリジェントへと進化した経緯を語ってくれました。

以下は私が整理したテキストバージョンです。皆さんの参考になれば幸いです。 (リプレイリンク: http://aix..com/activity/10010.html?dk=wz)

石器時代

単一の分割データベース、ビジネス分離

快溝タクシーは当時58.comが育成したN事業ラインの1つであり、わずか3週間で立ち上げられたため、初期バージョンにはユーザー側アプリ、マーチャントアプリ、管理バックエンドの3つのモジュールが含まれていました。

上図は、ビジネスインキュベーション期間中の全体的なシステムアーキテクチャを示しています。単一のデータベースモデルを採用し、他のビジネスとデータベースを共有することでコストを節約します。これは、ビジネスが市場で受け入れられるかどうかを迅速に検証するために行われます。

上図は事業育成期間における受注発送体制を示したもので、単位業務として捉えることができます。システムの中核部分は OrderPushJar であり、ここで注文の作成、プッシュ、およびその他の注文ディスパッチ ロジックが処理されます。

この段階での注文スケジュールの原理は非常に単純です。プッシュフレームワークMQTTは、設定された範囲内のすべてのドライバーに注文をプッシュします。ドライバーは手の速さに基づいて注文を受け入れ、市場を迅速に掌握することを目的とした補助金があります。これはプラットフォームにとって大きな無駄です。

快溝タクシーの導入後、市場の反応は非常に良く、わずか3か月で注文数が1万件増加しました。しかし、この時点でデータベースはボトルネックに達しており、フィールドの冗長性やデータベースのインデックスの有効性などの問題が顕著になっています。複数のビジネスの展開をサポートすることは不可能です。サブビジネスがオンラインまたはオフラインで開始されると、「同一ソース」ビジネスにも影響が及ぶことになります。

上の図は、Kuaigou Taxi データベースを結合されたビジネス データベースから分離する、データベースのボトルネックに対するソリューションです。このソリューションは双方向同期モードを使用して、業務を中断することなくデータを移行します。

全面的な移行後、快溝タクシーの全体システムは、注文、決済、構成、トラックなどのモジュールに大まかに分割されます。各モジュールには対応する個別のデータベースがあり、業務間の結合を効果的に回避します。トラックサービスデータベースの例外は、他の業務プロセスに影響を与えません。

鉄器時代のデュアルプッシュチャネル、クアドラントプッシュ

2015年、快溝タクシーは急速な発展段階に入り、ブルーライノ、No.1カーゴ、雲鳥など、多くの類似の競合企業が市場に登場しました。市場競争は白熱した段階に入っており、快溝タクシーは市場シェアを拡大​​するために大量の受注補助金を導入し、市場チャンスを掴むために時間との競争を繰り広げている。

上の図は、ビジネスが急速に発展した時期のシステムアーキテクチャを示しています。アプリ、PC、その他のサードパーティチャネルは、オーダーセンターサーバー（オーダーセンター）に入ります。オーダーセンターサーバーは、特定の責任に応じて業務をモジュール化し、決済、支払い、プッシュ、ドライバータスクなどのモジュールに分割されます。

ドライバーができるだけ早く注文を受け取れるようにし、メッセージのプッシュ到着率を確保するために、Kuaigou Taxi は、GeTui や MiPush などのサードパーティ チャネルと組み合わせて、独自に開発した TCP チャネルを使用しています。ドライバーの携帯電話のブランドに基づいて GeTui または MiPush チャネルを選択し、独自に開発した TCP チャネルを追加して、メッセージの到着率を確保します。

この段階では、注文スケジュールはもともと異なる象限に従ってプッシュされます。注文が生成されると、需要を満たすドライバーが近くのXキロメートル内で見つかり、注文がプッシュされます。誰も注文を受けない場合は、運転手の注文意欲を刺激するためにいくらかの補助金が追加されるだろう。

上図に示すように、象限プッシュモデルが採用されます。注文をつかむ人がいない場合は、一部の補助金を増やして、拡張象限に注文をプッシュします。注文をつかむ人の数が一定の上限に達した場合は、一部の補助金を減らします。

ドライバーを割り当てる際には、注文を受けたドライバーの距離、賞賛率、過去の注文完了率などのコア評価指標に基づいて最適なドライバーを選択します。このシンプルな方法は、プラットフォームによって配布される効果のない補助金の無駄を減らすだけでなく、速度に基づく悪質な競争を効果的に回避し、プラットフォーム全体の注文完了率を向上させます。

インテリジェンスの時代には、ビッグデータプラットフォームがインテリジェンスに導入される

2016年、快溝タクシーは業界のリーダーとなり、安定期に入りました。このとき、プラットフォーム補助金をいかに効率的にし、いかにして補助金として機能させるか、ユーザーのニーズを最大限に満たすにはどうすればよいか、ドライバーの収入をどのように分配するかなどについて、より深く考えるようになりました。

そのため、効率性の向上が今年の全体的な目標となり、ビッグデータ プラットフォーム、インテリジェント ディスパッチ アルゴリズム、インテリジェント ダイバージョン フレームワークの導入が主な作業となりました。

ステップ1データ収集

上図に示すように、アプリユーザーの使用状況データ、H5 エンドログ操作、サーバーエンドユーザーリクエストログなどのデータがログセンターグループを通じて収集および報告され、ログセンターに集約され、Flume と Kafka を使用してビッグデータプラットフォームに同期されます。 DB は、DTS と Canal を通じてビッグデータ プラットフォームにも導入されます。

Ste.2 インテリジェントモデルトレーニング

上の図に示すように、これがインテリジェント モデルのトレーニング ロジックです。最下層は情報を収集するためのものです:

l 発送元、発送先、価格などの注文情報。

l ユーザーの所在地や価格感度などのユーザー情報。

l 注文の受諾意思などを含むドライバーの情報。

l 顧客とドライバーの関係情報（両者をマッチングするための基準を含む）。

l 全体的な注文プッシュや注文受諾のシナリオなどの情報。

正規化とバケット化、XGBoost、特徴量の組み合わせ、エンコードなどのビッグデータ手法を活用して、モデルのトレーニングを実施しています。現在、ビジネスプロセス全体で使用されているデータモデルは約80万個あります。

次に、ビッグデータに基づくインテリジェントな注文発送システムの応用について、主に価格設定、注文プッシュ、注文処理などの具体的なシナリオを通じて説明します。

シナリオ 1: 価格設定

タクシーの利用者も運転手も価格に非常に敏感なので、まずは価格設定のシナリオを共有します。

具体的には、まずユーザーが料金を問い合わせ、問い合わせ情報に基づいてユーザーにA元の割引が与えられ、ドライバーにもそれに応じてB元の補助金が支給されます。また、C元の価格設定に基づいて、快溝タクシーはプラットフォームの運営を確保するためにD元の手数料も徴収する必要があります。

では、ABCD の関係をどのように計算するのでしょうか?当然のことながら、全体的な注文獲得率を確保しながら、A と B をできるだけ小さくする必要があります。

つまり、プラットフォーム補助金を最小限に抑えるという前提の下、与えられた補助金の予算に応じて受注獲得率を高めることができるのです。

上記の 2 つの価格設定モデルに基づくと、注文の完了率を確保するには、少なくとも 2 人のドライバーが注文を競い合うようにする必要があることがわかります。ドライバーとユーザーの行動を分析することで、ドライバーが注文に対しておおよそ受け入れる価格を把握する必要があります。同時に、注文を受け入れるドライバーの総数を通じて、モデルの有効性を順番に検証します。

上記の割引モデルは、ユーザー離脱率を分析するための手段です。ユーザーの日々の活動、注文額の貢献度などに基づいて、特定の理由によりユーザーが離脱するリスクがあることがわかり、プラットフォーム上でクーポンを発行してユーザーの復帰を促す必要があります。

シナリオ2: 注文のプッシュ

上の写真は注文を受ける場面です。注文を受け入れる意思のあるドライバーに注文をプッシュすると、ユーザーの待ち時間が短縮され満足度が向上するだけでなく、注文の成功率が向上してドライバーの関心も高まります。

では、ドライバーが注文を受け入れる意欲はどこから来るのでしょうか?これらには、注文とドライバー間の距離、注文の価格、チップと補助金、出発地と到着地が含まれます。

大規模なロジスティック回帰を通じて、プラットフォームは近くのドライバーが注文を受け入れる意思を計算し、対応するドライバーに注文をプッシュすることができます。

シナリオ3: 中期

中間順位のシナリオでは、50 人のドライバーが順位を競い合っている場合、賞賛度、距離、サービス態度、車両を無料で移動する意欲などの戦略が最も適したドライバーが「宝くじに当たる」ドライバーになります。

ここでのサービス モデルは比較的単純で、主に距離、レベル、スコア、結合度などの指標が含まれます。

偽の運転手がプラットフォームの秩序を乱すことを防ぐために、快溝タクシーはデバイスの相互接続、注文追跡、顧客と運転手の金額配分、仮想識別などの方法を使用して、注文の不正の可能性を特定します。不正な注文が見つかった場合、プラットフォームはユーザーとドライバーの両方を処罰します。

シナリオ4: 全体的な操作

上図に示す通り、全体的なアプリケーションシナリオです。

l ユーザーが注文すると、Kuaigou Taxi は注文価格設定モデルを使用して、ユーザーに価格調整、割引、または補助金が必要かどうかを判断します。

システムが注文をプッシュすると、Kuaigou Taxi はドライバーの注文受け入れ意欲と注文がプッシュされる順序を予測します。

ドライバー同士が受注競争をする際、快溝タクシーは受注予定人数を予測し、その人数が上限に達したら受注補助金の削減など動的な微調整を行います。

快溝タクシーは注文を割り当てる際に、ドライバーの完了確率も予測し、ドライバーの質を把握します。

l 注文が完了すると、Kuaigou Taxi はユーザーが解約するかどうかを予測し、ユーザーの維持価値に基づいてさらに割引を提供するかどうかを決定します。

上の図は、全体的なシングルサイドアーキテクチャを示しています。核となるのは、戦略アプリケーションサービス側、一般ロジックサービス層、そして基礎となるデータサービス側の分割です。

上の図は、インテリジェントディスパッチのコアプロセスを示しています。左側のコアモジュールは特徴データであり、データ収集とトレーニングを通じて対応する特徴データ値を取得します。特徴マッチングシステムを通じて、データはビジネスシステム全体に適用されます。同時に、注文キュー エンジンとドライバー キュー エンジンは、注文ステータスのリアルタイムの変更に基づいて、注文をドライバーにプッシュします。

さらに、ビジネス監視プラットフォームは、新しいモデルやアルゴリズムがオンラインになったときに適切に転用され、監視されるようにするために使用されます。具体的には、ユーザーのデバイスの特性に基づいてトラフィック分布をシミュレートし、データをリアルタイムにレポートします。

たとえば、問い合わせフェーズが完了した後にのみユーザーが解約するかどうかなどです。解約率が高い場合、リアルタイムレポートを通じて新しいオンライン転送設定がオフになります。

次に、Kuaigou Taxiの監視プラットフォームを共有します。具体的な定義は次のとおりです。

l アルゴリズムには安定したシステムサポートが必要

l ビジネスの変動を素早く把握

トラブルシューティングの効率を向上させることは損失を回復することです

上図は、キーワード監視、インターフェース監視、トラフィック、ポート、JVM、CPU、スレッド、キャッシュ、DB などの監視を含む、Kuaigou Taxi の 3 次元監視部分のスクリーンショットです。

事業指標のモニタリングには、受注や補助金の全体的な変動が含まれます。注文の変動は、近くのドライバーの平均数と注文の変動を監視するためのものです。補助金の変動は、ユーザーとドライバーへの補助金支給に関するリアルタイム データを監視した結果です。これらのコアビジネス指標を監視するには、変動があった場合にリアルタイムのフィードバックと迅速なアラートが必要です。

クーポン注文数が急増しているのはなぜですか?なぜ補助金対象の注文数が急に減ったのでしょうか？これらのコアビジネス指標を監視することで、リアルタイムのフィードバックを提供する必要があります。

要約する

2014年以来、快溝タクシーチームは成長を続け、ビジネスは継続的に反復され、最適化されてきました。要約すると、次のようになります。

l ビジネスの急速な変化に対応してサービスの継続的な進化を維持するために、チームとビジネスに合わせてアーキテクチャを調整します。

l プッシュの到着率を確保するために、デュアルプッシュチャネルを使用することをお勧めします。

l 問題を迅速に特定し、影響を軽減するためには監視が非常に重要です。l 継続的な改善、チームの能力はビジネスのペースに追いつく必要があります。