淘宝網の情報フローの統合とハイブリッドサービスのアップグレード

レコメンドシステムは、ユーザーの好みを予測し、大量の情報からユーザーが興味を持つ可能性のあるコンテンツをフィルタリングして、パーソナライズされた推奨を行うために使用される情報フィルタリングシステムです。完全なレコメンデーションシステムプロセスには、主に、マルチチャネルリコール -> マテリアルの完成 -> 細かい並べ替えとフィルタリング -> 混合並べ替え -> 適応出力などの処理ノードが含まれます。結果出力前の最後の処理層として、シャッフルは主にさまざまなソースからのレコメンド結果を正規化して並べ替えるために使用され、一方ではユーザーにとって最適なレコメンド効果を持つ並べ替え順序を取得するため、他方では他方で、多様性、パーソナライゼーション、レコメンデーションの到達範囲も改善できます。

テクノロジーリンクの現状

▐既存のリンク

タオバオの情報フローは典型的なレコメンデーションシステムです。情報フローには、製品、広告、クラウドテーマ、ショートビデオ、ライブブロードキャストなど、さまざまな種類の名刺が存在します。名刺を広告結果と自然推薦結果の 2 つのカテゴリに分けます。ソート段階では、2 つのシリアル処理モジュールが 2 つの異なるタイプの結果に分割され、混合してソートされます。

購入後の情報フローの混合プロセスの模式図

広告成果：広告は主に動的ピット表示戦略を採用しており、広告が提供する動的表示サービスを呼び出して、どのピットに広告を表示するか、具体的にどの広告結果を表示するか、およびそれに対応する広告請求を決定します。意思決定の目標は最適な商品化です。。価値。決定を行う際、すべての推奨候補セットが文脈特徴として入力されますが、自然な結果の順序は決定されません。
自然な結果: 自然な結果を再配置するプロセスでは、意思決定を行うためのコンテキスト特徴として広告候補セットを使用しません。同様に、広告候補セットのランキングについて追加の決定は行いません。自然な結果内で再配置するだけです。最適なユーザー値のソート順序。

最終的な結果出力順序では、動的表示サービスで決められた枠に広告結果が優先的に表示され、残りの空き枠にはその他の自然な推薦結果が表示されます。

▐問題があります

アルゴリズム戦略には一貫性のない目標があり、全体的に最適な結果を得ることができません。広告表示戦略は商業的価値に基づいており、自然な結果であるユーザー価値はあまり考慮されていません。ただし、指標の置き換えはトレードオフを調整することで達成できます。しかし、明らかに全体的に最適なシーケンス結果を得ることができません。
アルゴリズム戦略の反復とビジネスロジックの反復の間には高い結合があります: 現在のリンクでは、アルゴリズムの学生は工学の学生と同じコードセットを共同開発する必要があります。同時に、関連するさまざまなポリシーモジュールがシステムのさまざまな段階に分散しています。広告ダイナミックターゲティングサービスが依存する広告 ECPM 値サービスなどのパイプラインは完了フェーズで呼び出されますが、実際のダイナミックターゲティングの結果は混合スケジューリング中に処理されるため、システム全体の複雑さが増し、安定性が高まります。維持費。

▐ソリューション_

上記の課題を踏まえ、現在の混合配置戦略サービスを統一的にバージョンアップし、以下のような特徴をもったサービスを実現したいと考えています。

シャッフル戦略の目標の調整：シャッフルサービスは、ユーザー価値と商業的価値を総合的に考慮し、ページ全体の価値を最大化することをシャッフル戦略の目標とする必要があります。
戦略とビジネスの分離: サーバー側のビジネスリンクからミキシング戦略ロジックを抽出し、独立したサービスとして接続します。その後の反復アップグレードは新しいサービスのアルゴリズムの同僚によって維持され、アルゴリズムの戦略は反復されます。エンジニアリングリンクのビジネス反復により、開発の分業がより明確になり、それに伴うメンテナンスコストが削減されます。

具体的な実施計画

▐技術選定

この新しいハイブリッドフュージョンサービスは、コードフレームワークとして xrec を選択します。 xrec は tpp グラフィカルエンジンをベースにしたビジネスフレームワークで、主に次の利点があります。

推奨される業務プロセスのコンポーネント化：xrecフレームワークはリンクの業務ノードをコンポーネントに抽象化することができ、開発者はフレームワークで合意されたコンポーネント実装仕様に従って各ノードの業務を実装し、配置時に固定形式のjsonファイルを渡すだけで済みますプロセスの場合、コードレベルでビジネスプロセスのオーケストレーションを考慮する必要はありません。
完全非同期同時実行パフォーマンスの最適化: 元のエンジニアリングリンクで使用されていた TPE フレームワークの合理化された実行プロセスとは異なり、xrec フレームワークは、マルチチャネル同時実行を自動化し、データ操作をカプセル化することでシーンのパフォーマンスを向上させ、グラフィカル構造を使用してビジネスプロセスを記述します。並行プログラミングを学習することで、大規模かつ安全な並行性を実現できると同時に、データのシリアル化/逆シリアル化、データ変換、一般的な外部サービスの呼び出しをオペレーターの操作にカプセル化して利用できるようになります。パフォーマンスが最適化されたプラットフォームモジュールは、パフォーマンスが磨かれた未使用のユーザーコードを置き換えるために使用されます。

xrec フレームワークはアルゴリズム開発者の作業を大幅に節約しますが、コーディングルールに多くの制約を課すため、開発プロセスはフレームワークのルールに厳密に従って実行する必要があります。

▐リンクスキーム

混合サービスリンクソリューション

xrec フレームワークに基づいて、すべての広告と自然な結果の統合シャッフル戦略ロジックを実行するための独立した TPP サービス (xhuffle) を構築しました。サービス全体のリンクは以下の通りです。 xhuffle サービスは、広告と自然な結果の価値情報を取得するために、広告の ecpm 価値推定サービスと推奨される統一価値モデルを内部で並行して呼び出します。融合ミキシングメカニズムモジュールは、広告と自然な結果の価値情報を要約し、並べ替えに関する決定を行います。すべてのカードの結果、カードのピット位置を指定するか、カードの順序を変更し、最後に広告請求サービスを呼び出して、広告結果に対する広告請求情報を取得します。

元のエンジニアリングリンクでは、混在して依存するサービスモジュールがパイプラインのさまざまな段階に分散されています。新しいサービスを作成した後、混合と並べ替えの関連ロジックは独立したサービスに統合され、新しいサービス内で個別に反復できるため、開発コストとメンテナンスコストが大幅に削減されます。
レコメンド統一価値モデルと広告ecpm推定サービスは、それぞれレコメンドと広告によって維持され、それぞれが推奨値ポイントと広告価値ポイントの取得を担当します。
統合された混合メカニズムモジュールは、広告側と推奨側によって共同で維持され、反復されます。
広告課金サービスは広告側で保守されており、広告EADSサービスを呼び出すことで、広告課金文字列の生成が広告サービス内に集約され、情報セキュリティが確保されます。

xhuffleサービス全体のリンク図

また、買収後の情報フローには、クラウドテーマやショートビデオのターゲティングなど、ビジネスターゲティング戦略がまだいくつかあるため、この部分の戦略は、当初の混合配置戦略では考慮されていませんでした。シャッフル戦略によってピットの位置が決定される可能性があり、これによりこれらのビジネスピットカードがシャッフル結果に干渉し、ビジネスデータインジケーターに直接影響を与える可能性があります。 xhuffle サービスでは、ビジネスピット情報のこの部分をシャッフルモジュールへのサービス入力として提供し、ピットのこの部分を積極的に回避して、混合結果とビジネスピットの結果が相互に干渉しないようにします。

エンジニアリングリンクサービス通話プラン

xhuffle サービスの導入後、サービス呼び出しのタイミングが上流のエンジニアリングリンクの重要な懸念事項になります。基本的な考え方は、並べ替え段階での事前フィルタリングが完了した後、xhuffle サービスを呼び出して事前フィルタリングされた広告と自然な結果の候補セットを決定し、シャッフルに基づいて最終的な出力カードのシーケンスが決定されるというものです。結果。これにより、フィルタリングされたカードでの決定が回避され、ピットの使用率が向上する一方で、候補セットの数が減り、サービスへのプレッシャーがある程度軽減されます。

ここでは、2 つのリンク呼び出しスキームを提案します。

オプション 1: 並べ替えフェーズを分割し、サービスを並行して呼び出す

既存のリンクは並べ替えフェーズで連続して実行されるため、新しい外部サービス呼び出しの追加を考慮して、解決策 1 では並べ替えフェーズを 2 つのフェーズに分割します。

事前ソートステージ: このステージでは主に、いくつかの事前ソートカードフィルタリングを実行します。事前にフィルタリングされたカードシーケンスを取得した後、シャッフルサービスおよびエンジニアリングリンクの他の外部サービスへの並列呼び出しを開始します。
ポストソートステージ: このステージでは、シャッフル結果に基づいてカードシーケンスがソートおよび切り捨てられ、出力に適合させる必要がある最終的なカードシーケンスが決定されます。

スキーム 1 エンジニアリングリンク図

这种并行调用的方式看似减轻了链路RT的压力，实际上引入了一个新的问题。排序阶段输入的候选集序列大小一般是数倍于最终排序输出的序列大小，例如在购物车场景，每次请求最终返回的卡片序列数量为20，而排序阶段输入的卡片序列数量一般可达到100。在原有链路中，工程链路其他处理过程只会承接最终确认好顺序的20张卡片。如果将这部分处理前置，即使经过了前置过滤，这部分的服务实际承接的卡片序列数量还是将增长三至四倍，无形中加重了下游服务的压力。

在这部分外部服务中，UMP导购券后价接口的问题比较突出，这主要是因为UMP接口限制了接口一次调用承接的卡片数量不能超过15个，超出数量限制就需要分批发起多次调用，原本承接20张卡片就需要发起两次调用。如果承接的卡片数量增多，那么会直接增加对下游服务的请求量。

在前期小流量验证阶段，我们发现在实验流量上，对UMP服务接口的调用QPS增长了约3倍左右，这一现象也符合我们上述对该方案的分析。在小流量实验上并不能暴露出QPS增长带来的具体问题，但是如果采用这种方案进行推全，全量后下游的UMP接口将承载入口流量六至八倍的流量，压力实在太大，并且最终输出的卡片序列数量并没有增多，这部分新增的资源消耗并不是有效消耗，而是冗余消耗。

方案二：串行调用服务

考虑到上述方案带来的冗余资源消耗问题，我们提出了第二种链路调用方案，将xhuffle服务作为整体排序阶段的一个串行模块，在前置过滤完成后，直接串行执行服务调用。

方案二工程链路示意

这种调用方式对链路的RT压力会更大，由于是串行执行，服务调用的耗时会直接体现到整体链路耗时上。为了缓解RT的压力，我们采取了以下两个方面的措施：

xhuffle服务本身的链路优化。混排服务中耗时占比最大的是推荐统一价值模型的调用，在最初的方案中是通过调用外部tpp服务进行处理，目前已优化为在服务中直接进行RTP调用来处理，同时调用所需的qinfo数据直接使用商品召回的缓存数据，不用重新生成。
购后工程链路在不影响用户体验的前提下，适当放宽超时限制，以此降低端上的超时率。目前，各场景均将场景超时限制放宽50ms。

两种方案对比

优点	缺点
并行调用对链路整体的RT影响较小	将工程链路其他处理前置，会带来下游服务承接的卡片数量增长三至四倍，带来冗余的资源消耗
链路改造成本小，无冗余资源消耗	服务耗时会直接体现在链路整体耗时上，对系统稳定性的压力更大

经过综合考虑后，我们认为方案一带来的冗余资源消耗是不可接受的，最终选择了方案二作为正式的链路改造方案。

总结与展望

在进行上述的链路改造后，xhuffle服务已在购中后信息流推全，好价版信息流正在逐步接入中。经过一系列优化迭代，目前的xhuffle服务在保证了系统稳定性前提下，取得了自然&广告双涨的结果。

▐ 链路稳定性结果

混排服务场景指标：入口场景的服务调用平均RT保持在30ms以内，P99保持在70ms以内。服务调用超时率稳定在0.5%以内。
入口场景整体的系统稳定性指标：链路整体耗时可控，整体超时率保持在0.3%以内。
端上用户体验指标：由于各场景均扩了超时RT限制，我们通过端上接口的耗时变化来反映对用户体感上的影响。从扩RT前后分端接口耗时来看，用户体感上没有明显的变化。

▐ 未来展望

短视频、直播等业务的混排策略升级，减少业务定坑对混排的约束。
类目打散等规则化策略的融入。
建设通用化的混排服务链路接入方案，以同一套方案为更多场景提供混排策略服务。

网络包传输

淘天集团首页&信息流技术-首页团队，目前负责集团电商平台的首页和信息流推荐，其中手机淘宝首页、信息流、NewDetail等场景每天服务数亿用户，大促核心系统峰值QPS千万计，工作涉及全链路端到端性能优化，流量效率提升、用户体验、提高商家及达人参与淘宝的积极性，优化商业生态运行机制。在过去的几年时间，我们一直专注手机淘宝首页、推荐信息流核心链路业务支持和业务平台抽象，与业界领先的算法团队紧密协作，不断拓展业务边界并将核心业务指标一次次踩在脚下。
这里有巨大的流量，可以满足你对高并发大规模分布式系统练手的畅想；
这里有前沿的算法应用场景，可以玩转各种智能创新；
这里有严苛的系统指标要求，可以让你感受到优化复杂系统化的快感~

¤ 拓展阅读 ¤

3DXR技术 | 终端技术 | 音视频技术

服务端技术 | 技术质量 | 数据算法

本文分享自微信公众号 - 大淘宝技术（AlibabaMTT）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。