著者: Xianyu Technology - Xu Wei
序章
インターネットの情報が爆発的に増加する現代において、レコメンドシステムは私たちの身の回りになくてはならない存在です。Taobao で商品をブラウジングしたり、Douyin で動画をスワイプしたり、どこにでもある広告などを閲覧したりできます。Xianyu 製品レコメンデーション システムについて説明しながら、このホワイト ペーパーでは、マルチ レコメンデーション シナリオ エンジニアリング メンテナンス タスクの問題点と、複数のシナリオを自動的に放射するためのアルゴリズム モデル最適化の難しさを考慮して、一般的なレコメンデーション ミドルエンド プラットフォームを構築する方法を紹介します。
バックグラウンド
推奨システム
ユーザーがインターネットを閲覧するとき、自分のニーズを正確に説明できれば、必要な情報を見つけるために積極的に検索できます。しかし、多くの場合、ユーザーは自分のニーズを正確に説明できないか、ユーザーが買い物に来るだけで、製品が興味のある情報を積極的に直接プッシュしてくれることを望んでいます。この時点で、レコメンダー システムは、ユーザーと情報をつなぐ仲介役を果たします。
今日、インターネット情報の活発な発展により、大量の情報やコンテンツが刻一刻と生み出されています。したがって、レコメンドシステムが解決しなければならない問題は、膨大な候補情報の中からユーザーが最も興味を持っている情報を選択することです。
この最適な選択プロセスを完了するために、典型的な Xianyu 製品レコメンデーション システムには、下の図に示すようなモジュールが含まれます。
- データ
レコメンデーション システムの本質はデータに基づいており、ここでのデータには、ユーザー自身の年齢、性別、地域、ユーザーが公開した製品、コンテンツの構造化データ、露出、クリック、インタラクション、その他の行動中に生成された行動が含まれます。ユーザーのブラウジング プロセス データ。大量のユーザー＆商品＆行動データの分析と計算を通じて、ユーザーのトリガー情報が生成され、アルゴリズムモデルのトレーニングを支援するサンプルデータが生成され、生成エンジンインデックスデータテーブルが構築されます。
- ユーザー情報
ユーザー要求が届いたら、ユーザーが誰であるかを識別し、その後のパーソナライズされたレコメンデーションを実装する必要があります。ここでは通常、ユーザーの一意の ID に基づいてユーザー センター サービス システムにクエリを実行し、ユーザー ディメンションの基本情報を取得します。
- 引き金
トリガーは、トリガー ステージとして、レコメンデーションのソースです。これは一般に、ユーザーの過去のブラウジング、クリック、インタラクティブな動作、およびユーザーの好みの結果です。データ処理段階では、これらのトリガー情報を調整します。データリターンリンクを通じて、トリガー情報は最終的にオンラインシステムに保存され、サービスがオンラインで要求されると、データはユーザーの一意の ID に従ってリアルタイムでクエリされ、後続のプロセスに参加します。
- 想起
上文有提到，全量的推荐候选集，数据量级往往突破千万，甚至级别。如果每一次的用户请求，我们均采用全局排序的思路，遍历整个推荐候选集，进行模式算分后，再找出topK个最佳预测的商品。这样的推荐效果可能很不错，但是对计算资源与性能要求过于苛刻，在生产环境中难以实现。因此，我们通过召回，来解决在候选集上进行全量排序的资源&性能问题。 在召回阶段，基于用户的特征与trigger信息，从全量的亿级别候选集中，挑选出万级别的商品，送入后续的算分排序阶段。而在召回手段上，主要有规则定义、协同过滤、向量召回等。
- 粗/精排
算分一般也分为粗排+精排两阶段。粗排针对召回的万级别商品进行模型算分，由于打分候选量级较大，这里模型网络结构上一般采用双塔结构，而不做复杂的交叉网络。有了粗排分，我们再挑选排在前面的千级别候选集，进行一轮精排模型算分。此时待打分的商品量级可控，因此这一环节通常采用更多的用户&商品&交叉特征与较为复杂的网络模型。
- 重排
前面的排序主要通过算法网络模型决定，而重排阶段，则会体现场景的业务诉求，做一下打散干预，比如类目打散、价格打散等。
- 结果返回
经过上面的链路后，推荐系统最终将topK个（一般为10~20个）最佳预测的商品，填充元信息后，返回给用户进行展示。
- 日志&埋点
对展现给用户的商品做日志记录与埋点，便于回收用户行为数据。
基于上面的分析，一条完整的推荐链路开发维护成本并不低，其中涉及离线数据分析处理、采集样本、算法模型训练、模型&内容表索引构建、在线查询&召回&算分引擎部署、在线推荐服务开发、日志&埋点回收等。
面临的问题
闲鱼目前推荐场景数10+，在过去四个月新增了4个新的场景（闲鱼币，新品推荐，购后推荐，新发tab），同时更多推荐场景正在规划中（省心卖，首页tab feeds流等），这么多的tpp场景背后是闲鱼对个性化推荐的大量需求。 从工程角度来看每个新业务接入都需要从0到1搭建完整的推荐链路，除了大量重复的工作之外还伴随着不小的维护成本，如何才能降低如此众多场景的边际成本提升边际效益。 从算法视角来看，这些推荐场的算法模型都需要case by case迭代优化，如何实现模型迭代优化自动辐射到更多的场景。
设计方案
设计目标
基于上文分析，如何在有限的成本之下快速从算法获取更多的红利是我们核心要解决的问题。因此我们期望构建这样一个推荐中台，通过一套推荐底坐支撑所有的中小推荐场，实现收敛推荐链路的同时让算法模型迭代形成规模效应。 显然，针对不同的业务场景，其对推荐策略存在不同的诉求。即使同一个场景内，也存在不同策略实验的述求。因此我们将推荐链路中的各个环节，进行了抽象，沉淀出内容池策略、特征策略、召回策略、粗排&精排&重排策略等，每一个推荐场景便可以认为是各环节策略的组合。
同时，我们将策略以配置化+插件的方式对外输出。这样，当我们有新的场景接入时，不再需要去搭建完整的推荐链路，而是通过少量的配置化工作完成。最终将新场景上线的周期，由周级别降低至天级别，同时算法模型的迭代优化也能更加专注，接入流程如下图所示。
整体架构
如下图，是推荐中台的整体架构。整体上，我们依赖特征中心，根据用户与商品维度的特征信息灵活组合，计算产出各个场景的推荐候选池，并构建底池索引至引擎中。算法结合数据样本与底池，进行模型训练与召回数据训练，并产出模型与内容表，也回流至引擎供在线部分使用。在引擎部分，我们针对召回与排序，提供了通用召回与算分模型的同时，也定义了标准的输入输出协议，以满足业务场景定制化接入的诉求。场景的所有策略抽象，都收敛至实验平台进行管理。
用户在线请求pv到来后，我们首先根据场景id路由，拉取到相关配置后，根据具体的策略内容，逐步执行推荐各环节，如下示意。
推荐候选池
推荐候选池作为推荐业务场景最大的区别之一，其直接决定了推荐中台的复用/通用能力。因此支持高效灵活的定义推荐候选池，是首先需要解决的问题， 而从实际来看，结合闲鱼众多推荐场景，推荐商品候选池可以看做是用户与商品维度特征的组合，如下示例。
因此，我们使用特征来定义推荐候选池，通过特征的自由组合与实时计算，实现推荐候选池的大规模定义与计算，生产链路如下图所示。 这里面，闲鱼特征中心收敛了用户维度与商品维度特征（包括离线统计计算与实时产生的特征），以如下格式对外输出。
有了基础特征信息，再搭配推荐候选池定义的特征表达式组合，使用数据ETL工具，将原始商品与用户特征、商品信息维表、推荐池定义维表等数据源，经过多层merge、join的操作，最终在商品维度打上场景唯一标识（这个标识是一个以逗号分隔的复合字段，便于单个商品同时满足多个候选池规则时打标），生成各场景的推荐候选池。
召回引擎
召回策略上，我们提供了三种索引方式，分别是i2i索引，x2i索引，深度召回，并标准化掉召回的输入与输出。对于输入，有两种通用的格式，第一种为trigger格式，引擎将以传入的trigger作为key，从i2i与x2i索引中执行kv检索与倒排检索。第二种则是针对深度召回，上游传入模型预测出的embedding向量，再经由向量引擎完成检索。输出则是召回检索得到的商品item_id与对应的召回recall_score。 目前三种方式共计10+路召回通道可供业务场景选择，每一路召回通道都枚举了一个标识。接入业务只需要配置选择用哪些召回通道即可。
- i2i：根据商品积累的用户点击行为，计算item-item的用户共现点击得分，作为i2i的相似度。
- x2i：这里的x可以是商品的tag、class、brand、query、pool_ids等，根据用户全域的行为构建用户偏好，对商品标题信息进行分词，以及用户的tag，class，品牌，搜索场景下对应query等，最终构建倒排索引进行检索。
- 深度召回：主要通过深度网络模型，来预测用户与商品的相似性。模型分别计算出用户侧向量与商品侧向量，在线检索时，根据用户侧向量，通过向量引擎完成ANN检索出topK个商品。
算分引擎
算分引擎的作用，是将输入的待打分候选商品集，关联上商品特征，并结合用户的特征，通过深度网络模型的计算执行，完成候选商品集中每一个商品对该用户的个性化预测得分。这里我们提供了一个包含ctr、cvr与互动的多目标算分模型，满足了大多数场景的个性化需求。 此外，我们将算分排序模型的输入输出进行标准化，也提供了模型定制化的能力。有些场景不太适应通用的多目标模型，可遵循协议将模型接入，每一个模型具备一个唯一的标识biz_name，场景配置上选择该biz_name即可。
模型存在多个目标得分，比如ctr_score、cvr_score、car_score等。而最终的得分如何计算，场景内也支持配置运算表达式与加权&降权（有些场景倾向转化，有些场景则重成交，或者满足交易抵扣的商品需要提权），来满足不同的场景要求。
实验体系
推荐系统迭代极快，算法工程师通常会展开很多AB实验，需要能够灵活的支持实验策略与流量调整。此外，全量用户基本比较固定，用户在不同场景，以及场景内不同实验，均需要做到互不干扰，保证实验的独立性。 在实现上，每次注册场景时，我们会同步创建实验与流量模型，并跟场景id进行绑定，确保场景之间的流量模型独立。场景内部多实验的诉求，则通过在流量模型内进一步动态分层的方式。这样场景A对应流量模型A，场景B对应流量模型B。而场景A里面，实验1按照50% vs 50%运行在流量模型A的分层1，实验2也可以按照50% vs 50%运行在流量模型A的分层2。
稳定性
推奨されるミドル プラットフォームは、Xianyu 10+ の推奨されるフィールド トラフィックを伝送するため、システムの安定性とサービスの高可用性に対する要件が非常に高くなります。システム展開に関しては、中央コンピューター室（張北）とユニットコンピューター室（南通）にリモートマルチコンピュータールーム展開を実施し、1 つのオンラインコンピュータールームに異常が発生した場合、トラフィックを次の場所に転送できるようにしました。通常のコンピュータ ルームから緊急フロー スイッチングを通じてサービスを提供します。さらに、アクセス ビジネス シナリオを論理的に分離しました。シナリオごとに電流制限と融合を構成する特定のシナリオに異常なトラフィックやバースト トラフィックがある場合、他のシナリオへの影響を防ぎ、全体的な高可用性を確保するために、迅速に機能を低下させて切断することができます。
エピローグ
レコメンデーションは体系的なプロジェクトであり、近年では、コンピューティング アーキテクチャ、モデル ネットワーク構造などの面でも進化しています。Xianyu 製品レコメンデーション アーキテクチャの導入に基づいて、このホワイト ペーパーでは、制限されたコストでアルゴリズムからより多くの配当を迅速に取得する方法の中心的な問題を中心に、一般的なレコメンデーションの中間段階のソリューションを提案します。中間プラットフォームの構築は、エンジニアリングとアルゴリズムが独自の機能を蓄積するための効果的な試みであることが推奨されます. 新しいシーンはスカイレベルに接続するだけでよく、エンジニアリングとアルゴリズムのメンテナンスの反復もより集中されます.そして集中。現在、10以上のシナリオが接続されており、シナリオ接続前と接続後の効率指標を比較すると、クリック変換率は8%以上、一人当たりのipvは10%以上増加しています。同時に、アクセス シナリオの増加に伴い、貴重なデータ ラベルもプラットフォームに預けられます。さらに、現在の全体的なリンクにはまだいくつかの欠陥があります。ランク付けモデルでは、モデルの精度がまだ不足しており、マルチシナリオのジョイント モデリングは実行されていません。エンジニアリングに関しては、学生が介入するためにシーン アクセスを開発する必要があり、自動化の程度を改善する必要があります。将来的には、高品質のエンジニアリングとアルゴリズム機能を反復し続けます。