ホームページ > 記事 > テクノロジー周辺機器 > Meituan の包括的なビジネス推奨システムの品質モデルと実践

Meituan の包括的なビジネス推奨システムの品質モデルと実践

王林転載: 2023-04-14 12:43:021344ブラウズ

著者: Yong Haogengen、Wang Xin 他

1 はじめに

美団の店舗内総合事業 (以下、総合事業といいます) ) は Meituan の店内総合ビジネスです。店舗内ビジネスの重要な分野の 1 つであり、入浴、KTV、美容産業、医療美容、親子、結婚、スポーツとフィットネス、エンターテイメントなどの数十の主要な下位産業をカバーしています。、教育とトレーニング、家具、ペット、バー、生活サービスなど、数億人のユーザーの多様な地域生活のニーズに応えます。

レコメンドシステムは、効率的な需要と供給のマッチングを実現するための重要なリンクであり、データの価値を伝達する出口であり、レコメンドシステムの品質がマッチング効果の損失を決定します。以下の図 1 に示すように、データはデータウェアハウスとアルゴリズムによって処理され、データサービスを通じてさまざまなビジネスシステムに送信され、最後にクライアントを通じてデータウェアハウスに戻され、「フライホイール効果」が形成されます。リンクにおける歯車の噛み合いのキーポイントは、効率を向上させ有効性を確保するための重要な前提条件です。

品質保証は測定を「見える化」「明確化」「正確に補正」するために行われなければなりません。ただし、従来のバックエンドサービスの品質指標では、現在の「データフライホイール」の品質を十分に説明できません。私たちは、包括的なビジネス推奨システムの品質モデルの構築を通じて、同様の複数のビジネスライン、効果指向のシステム品質測定に対する新しい思考の視点と実践的な参考を提供できることを願っています。

Meituan の包括的なビジネス推奨システムの品質モデルと実践

図1 レコメンドシステムの「データフライホイール」

2 現状分析

レコメンドシステムは効果ベースのシステムであり、機能別システムとは品質特性が異なります。一般に、機能系システムはダウングレード後のユーザーエクスペリエンスに大きな影響を与えますが、レコメンド結果がAやA'となった場合、ユーザーはそれを明確に認識することが困難です。しかし実際には、マッチング効果が悪化すると、ユーザーの暗黙のエクスペリエンスに直接影響するため、それを特定する必要があります。一般に機能系システムでは、ユーザビリティを核とした品質指標システムを構築しますが、総合的なビジネス推奨システムの実務においては、ユーザビリティなどの指標には次のような限界があることが分かりました。可用性は一部の欠陥には影響されません

: 可用性は中断の頻度と期間の関数であり、サービスを提供し続けるシステムの能力を反映します。システムの欠陥は、外部サービスに影響を与えない限り、ユーザビリティには影響しませんが、実際にユーザーエクスペリエンスに影響を与えるものもあります。ここでの欠陥は予期されたもの (

) または予期せぬもの (モデル更新の遅延 ) の可能性があり、品質の測定に含める必要があります。 データのリンク全体を可用性でカバーすることは困難です。: レコメンデーションシステムのリンクは、データの生成、処理、アプリケーション、分析、その他のリンクをカバーします。 1 つは、ユーザビリティにはデータテーブルの品質が関係していないということ、もう 1 つは、パフォーマンス測定が利用可能な場合でも、データ品質の全体像を反映できないということです。データ品質では、可用性の範囲を超えた、完全性、正確性、適時性、セキュリティなどの特性を考慮する必要があります。国際的に著名な学者であるアンドリュー・ン氏は、人工知能の価値の 80% はデータと、レコメンデーションシステムが提供するレコメンデーション効果の質 (
ビジネスの違いをユーザビリティに反映するのは難しい: Meituan Zhizong は数百の業界と数十のチャネルページをカバーしています。レコメンデーションシステムは効率とコストの考慮に基づいています。を完全に分離することはできず、可用性の直並列計算方法により、事業間を区別して個別に評価することが困難になります。ネットワーク上のサービスは、アクセス頻度、トラフィックのピーク時間帯、ビジネス戦略などによって大きく異なり、その結果、品質特性や問題の分布も異なります。現在の可用性インジケーターにはビジネスディメンションの情報が欠けており、洗練された品質の運用を導くのには役立ちません。
品質構築においては、従来は故障レベルを目標としており、検証サイクルが長く、偶発性があり、目標と論理導出の関係が問題視されていました。アクションは強くなかった。さらに、障害自体は後から考えられたものであり、この問題主導のアプローチは運用の継続には役に立ちません。一般に、ユーザビリティを目標としながらも、実際に計算を実施するにはさまざまな問題があるため、ユーザビリティをベースとしたレコメンドシステムの品質モデルを構築し、計算方法を調整することで、より洗練された品質運用を導くことを検討しています。
3 構築のアイデア

3.1 ビジネスの文脈における品質

品質モデルを構築するには、まず品質の本質の理解に立ち返ります。国際標準化機構 (ISO) の定義によれば、品質とは、明示的または暗黙的な「ニーズ」を満たす企業の能力を反映する特性の合計です。もう 1 つの一般的に使用される品質概念は安定性であり、安定性の核心は、システムを「期待された」状態で長期間実行できるようにすることです。品質であれ、安定性であれ、システムが誰のニーズや期待に応える必要があるかを理解することが重要です。レコメンデーションシナリオでは、このオブジェクトは製品とアルゴリズムです。ビジネス製品は、ユーザーのシナリオを理解し、ユーザーのニーズを抽象化し、製品要件をレコメンデーションチームに提案し、それが外部の製品のイテレーションに反映されます。同時に、レコメンデーションシステムチームは内部で互いに協力して、最適な最適化モデル戦略を学習します。データチーム内のアルゴリズムの反復に反映されます。

#以下の図 2 に示すように、可用性の計算式では長時間が強調され、「必要性」と「期待」は外部サービスの提供にのみ反映されます。ここには一定の合理性があります。第一に、可用性は業界で一般的な指標であり、その定義を一般化する必要があります。次に、共通性と品質の最終ラインは外部サービスの提供です。第二に、ほとんどのバックエンドシステムは機能を提供し、また、ほとんどの外部サービスは「ある」「ない」の状態で提供されるため、サービスが低下する余地もあります。ただし、効果を中核目標とするレコメンデーションシステムの場合、機能が「ある」場合と「ない」場合では、「良い」効果と「悪い」効果の広範囲が存在します。レコメンデーションシステムの品質について考える繰り返しにおいて、中心的な変化は、外部サービスの「はい」と「いいえ」から、外部サービスの「良い」と「悪い」への変化であり、これは変革の出発点でもあります。ユーザビリティの計算方法です。

#図 2 品質指標に対する欠陥の認知的影響
3.2 欠陥の考慮と選択

「ニーズ」や「期待」を満たさないと不良が発生し、不良は品質低下の原因となります。 ISO/IEC 25010 ソフトウェア品質モデル (2011) ソフトウェア品質モデルはソフトウェアの欠陥を定義し、機能の適合性、パフォーマンス効率、互換性、可用性、信頼性、セキュリティ、保守性を含む欠陥の完全なセットとみなすことができます。移植性に関する 31 のサブ機能。バックエンドサービスではカバーされていない品質機能がいくつかあり (
ユーザーインターフェイスの美しさ、学習の容易さなど。)、また、現在の認識では C エンドの品質を構成しない優れた要素がいくつかあります (モジュール性、共存、否認防止、再利用可能性など。)。ビジネス特性と推奨システムの高頻度の品質問題を組み合わせて、この段階では、以下の図 3 に示すような品質特性を欠陥の原因として考慮することに重点を置きます。

図 3 レコメンデーションシステムの品質特性
従来のユーザビリティ対策がほとんど集中していることがわかりました。信頼性、機能の完全性、正確性については評価されていますが、推奨事項の品質と有効性に密接に関係する機能の正確性、適切性、安全性のほとんどについては測定が不足しています。精度と適切さが効果に及ぼす影響は比較的直感的ですが、その他の影響はより間接的です。例えば、セキュリティにおけるクローラアクセスを例に挙げると、クローラのアクセス挙動は実際の人間の行動習慣に従わないため、UVCTRなどのコア指標のリサイクルに影響を及ぼし、効果の判断を誤ることになります。同時に、クローラーデータを識別して除去できない場合、ノイズはモデルトレーニングの精度にさらに影響を与えます。データ品質の問題は、データの「フライホイール効果」における「毒薬」であり、ポジティブなフィードバックを生成し、欠陥を継続的に増幅させます。第 4 章の計算ルールでは、上記の欠点を定量化し、利用範囲を拡大します。
3.3 測定と計算の選択

可用性は測定方法と計算方法に分けることができます。測定はよく N ナインと呼ばれるもので、計算には平均故障率が使用されます。インターバル時間と平均回復時間の関数として。測定方法に関して、業界で一般的に使用されている品質測定方法を以下の図 4 に示します。

#図 4 測定方法
#

測定方法の数点スケールの選択は、現段階では品質スコアの焦点ではありません。ユーザビリティ自体に使用される N 9 は十分に単純で比較可能なものであるため、計算方法に焦点を当てます。。統合された業務ラインが多く、レコメンドシステムはプラットフォーム製品であるため、システムとビジネスの関係はN:Nであり、業界、プロジェクト、業務ごとに現行システムの可用性を計算することは困難です。トラフィック位置は、レジャーおよびエンターテイメントビジネス、スクリプトキリングプロジェクト、コアディスプレイメインパスの一部、またはコンテンツ推奨の種類に属することができます。この種の柔軟な属性を使用できます。集計のリクエストは次のとおりです。最適な。以下の図 5 に示すように、可用性がリクエストの関数である場合、可用性には、前のセクションで注目した品質機能だけでなく、ビジネスに意味のある品質統計も複数の側面で含めることができます。

#図 5 リクエストの観点から品質を測定する
4 計算方法

# # 前章の構築の考え方をもとに、欠点から欠陥まで、「はい」「いいえ」の推奨結果から「良い」「悪い」の推奨効果まで、全体から各事業まで、良質な特性を記述します。そのポイントはあるはずです。この章では、指標の計算ロジックに焦点を当て、主要な欠陥を選択し、「成功した要求応答」を定義し、品質スコアのビジネス集計次元を追加します。
4.1 計算式

3.2 章で説明した品質特性と組み合わせて、要求成功率の観点からシステム品質を評価します。、各レベルで次の 4 つの欠陥に分類できます。
- システムレベル : リクエストは、欠陥応答であるシステム例外をトリガーします。。一般的なものには、リコールタイムアウト、リコール失敗、リコール空の結果などが含まれます。
- データレベル: このリクエストで使用されるデータが異常な場合、それは欠陥レスポンスです。一般的なものには、異常な供給量、異常なラベル配布などが含まれます。ユーザーのリクエストに対するデータの実際の影響は、データ系統の確立と影響評価によって異なります。
- アルゴリズムレベル : リコールおよび並べ替えプロセス中にこのリクエストで使用された機能、モデル、および戦略が異常な場合、それは欠陥応答です。よくあるものとしては、モデル更新の遅れや機能の欠落などがあり、レコメンド効果の発現に影響を与えます。
- ビジネスレベル : リクエストはビジネス適合性またはセキュリティコンプライアンス要件をトリガーし、上記の結果を含むリクエストはすべて欠陥のあるレスポンスです。一般的な運用上のフィードバックには、供給品質やコンテンツのセキュリティなどの重大な悪いケースが含まれます。
リクエストのライフサイクルのいずれかの部分で欠陥が発生した場合、その結果は欠陥応答として定義されます。特定の欠陥リンクは分析とドリルの次元です。下。 3.2 章の品質特性と上記の欠陥の 4 つの側面から、典型的な問題 (ビジネス上の課題、高頻度の品質問題 ) を選択して計算します。例として、以下の図 6 を取り上げます。

図 6 品質スコアの計算方法
4.2 ビジネスの一般化

包括的な推奨システムは複数の事業ラインにまたがっており、業界の違いは大きく、推奨される資材の場所も多数あります。これは品質測定に反映されています。以下の図 7 に示すように、洗練された運用を導くために、すべてのレベルでの集計分析が必要です。

#図 7 各ビジネスレベルの集計分析

ビジネスレベルには中頻度および低頻度のサービスが多数あります。このとき、比率の変動はリクエストの絶対値に大きく影響されます。これらのシナリオでは、いくつかの小さなトラフィックビットを集約し、業界またはプロジェクトレベルで分単位でのみ監視できます。

4.3 指標システム

以下の図 8 に示すように、レコメンデーションシステムによって応答されたリクエストを製品配送動作として扱います。これらのリクエストのうち欠陥のないリクエストの割合は、レコメンデーションシステムの品質スコア。は、トップレベルの品質出力指標です。リクエストのライフサイクルに基づいて、リコール不良率、仕分け不良率など、コアプロセスの品質ステータスを測定するための第 1 レベルの入力指標を確立できます。また、第 1 レベルの指標をさらに分解して第 2 レベルの入力指標を取得することもでき、たとえば、リコール欠陥率が比較的高い場合、リコールヌル率、リコールタイムアウト率などを測定できます。また、ユーザーのリクエストをビジネスに基づいて垂直方向、水平方向、時間軸で集約して、よりターゲットを絞った、ビジネス属性を伴う品質スコアを取得することもできます。

#図 8 品質インデックスシステム

この改善された品質スコアのセットは、要件に基づいています。このユニットは、元の可用性計算方法の限界をある程度解決します。欠陥に敏感で、データリンクの影響を含めることができ、複数のビジネス側面の集計分析を容易にします。
4.4 ブラッドラインの拡張

品質はリクエストの粒度に基づいて計算されます。データアプリケーションサービスでは、リクエストは外部データの形式の 1 つにすぎません。出力。基本的な品質スコアが完了したら、品質の測定を完了するために、リクエストのライフサイクルをデータリンク全体に拡張する必要があります。現時点では、以下の図 9 に示すように、データの血縁関係に基づいてデータテーブル、ビジネスシステム、C 側のトラフィックを関連付け、パノラマ品質のポートレートを構築します。
##図9 推奨システムデータ血縁関係

血縁とは、人間社会における結婚や出産などによって生じる対人関係のことであり、人間関係などです。データは、親子関係、兄弟関係、その他そこから派生する親族関係を融合・変換することでデータの親族関係を生成することもできます。データの血縁関係は、さまざまなレベルのデータベース、データテーブル、フィールドに分割されており、通常、データ資産 (引用人気度の計算、データコンテキストの理解 )、データ開発 (
影響分析) に使用されます。、アトリビューション分析
)、データガバナンス (リンクステータスの追跡、データウェアハウス管理 )、およびデータセキュリティ (セキュリティコンプライアンス検査、ラベルの伝播 )。システム品質スコアを推奨するという現在の考え方では、影響分析は主に品質スコアを拡大するために使用され、障害のあるノードからのすべてのリクエストがマークされ、対応するスコアが差し引かれます。レコメンデーションシステムのビジネスセマンティクスでは、スナップショット、スキーム、コンポーネント、インデックス、モデル、フィーチャーの 6 種類のビジネスメタデータを定義し、メタデータに基づいてリネージュを構築します。これは、タスクへのアクセスの提供、血統分析、データのエクスポートに分類できます。タスクアクセスは収集モジュールと倉庫モジュールに分かれており、タスクアクセスが完了すると、ノードとその関係がグラフデータベースに保存され、グラフアルゴリズムを使用して血縁関係が確立されます。血縁関係が確立された後は、ノード自体の異常によりシステムの検出と手動マーキングがサポートされ、影響分析は自動的に完了できます。ノードに異常が発生するとメッセージが通知され、異常情報が血統に伝わり、下流リンクの品質スコア計算に影響を与えます。

例外がユーザー側に影響を与える場合、私たちは損失をビジネス言語で再説明しようとします。包括的な収益モデルに基づいて、各ビジネスラインの各インテンション UV の値を計算できます (ユーザーのマーチャント詳細ページおよびグループ注文詳細ページへの訪問はインテンション訪問と呼ばれます)。そして、このトラフィックを使用します。前年比の結果を生成するためにステータスを訪問し、ビジネス上の損失を自動的に推定します。

5 指標の運用

5.1 システム実装

品質スコアのシステム実装方法は、ポイントの埋め込みと診断に依存します。完全なリンクには、パラメータ入力、リコール前処理、リコール、リコール後処理、大まかな並べ替え、詳細な並べ替え、再配置などを含めることをお勧めします。各リンクは失敗する可能性があるため、データ収集は実行時の例外をカバーする必要があります。各リンクの情報などを出力します。以下の図 10 に示すように、Kafka を通じて非同期データを収集し、シナリオに従ってデータ処理を実行します。運用環境では、ほぼリアルタイムの ES が過去 4 日間の高速クエリサービスを提供するインデックスを構築します。 4日前のログはHiveにアーカイブされますさらに、埋め込まれたポイントデータはFlinkエンジンで解析されます必要な診断後、リアルタイムでスコアが計算され、アラーム情報がプッシュされますテスト環境ではログがMySQLに振り分けられますリアルタイムでテストとトラブルシューティングを容易にします。最後に、さまざまな段階での推奨事項の品質を構造化して表示することで、結果の読みやすさが向上します。

#図 10 品質スコアのシステム実装

スコアシステムは段階的に改善する必要があります。推奨システムの場合、推奨結果の失敗は最も深刻な品質問題です。最初に収集して計算するのは、推奨ヌル結果です。これは、第 1 レベルの指標の結果不良率とリコール不良率、および第 2 レベルの指標の結果ヌル率とリコールヌル率に対応します。同時に、総合ビジネスのビジネス特性により、多くの業界が存在し、供給が時間的および空間的に不均等に分散されているため、多数の横断的なフィルタリング条件も空の結果となり、計算に影響を与えます。品質スコア。

ビジネスの期待を満たす空の結果を排除し、品質上のノイズを排除する方法、隠れたポイントの認識に基づいた診断が非常に重要になります。空の結果を例に挙げると、主にパラメータ診断、データ診断、リンク診断の 3 つの側面からそれらを特定します。データ診断とは、オンラインフィルタリング条件によって空の結果が生成された場合に、ソースに戻って基になるデータをもう一度検証し、一番下のテーブルデータが空かどうかをクエリすることを指します。下の表に実際に関連する供給がない場合は、アラームなしルールが適用され、アラームなしの有効期間が設定されます。一定期間内に、現在の都市の現在の産業には関連する供給が不足し、空の結果は品質スコアの計算に含まれません。

下の表に供給がある場合は、データ処理またはサービスプロセスに異常があり、リコールできないことを意味し、エラーリンクが特定されます。リンク診断を通じて、対応する品質スコアの計算に含まれます。ルール照合メカニズム ( はルールエンジン ) を確立する方法が診断エンジンの鍵となります。現在、EasyRule、Drools、Zools、Aviator など、ルールエンジンには多くの選択肢があります。上記の分析によると、診断エンジンはリクエストパラメーター、推奨リンク、および基礎となるデータに対してルール診断を実行できる必要があります。リクエストパラメータと推奨リンクの診断はメモリパラメータを通じて実行できますが、データ診断にはサードパーティストレージからの情報が必要なため、一部をカスタマイズして開発する必要があります。人間のツールの成熟度と利便性を考慮すると、Aviator 表現エンジンの方が適しています。診断が必要な内容に適合するように、設計された表現診断プリミティブは次のとおりです。
```
//参数诊断-原语表达 //是否符合一定参数的诊断原语 global:check=aviator[cityId !=nil && include(string.split('1,2,3,4,5,6,7,8,9,10,16,17',','),str(cityId))] //链路诊断-原语表达 //1、召回异常诊断原语 global:recallException=param[${recall#exception#}], global:check=aviator[recallException!=nil && recallException !='' ] //2、召回空无异常的诊断原语 global:recallEmpty=param[${recall#after#}], global:check=aviator[recallEmpty!=nil && recallEmpty !='' ] //3、召回不为空，过滤规则执行后为空的诊断原语 global:recallEmptyCode=param[${recall#after#}], global:predictFiltersEmptyCode=param[${predict#after#filters#}], global:check=aviator[(recallEmptyCode ==nil || recallEmptyCode =='')&& predictFiltersEmptyCode !=nil] //4、执行某一具体过滤规则后，导致无结果的匹配 global:filterEmptyCode=param[${PredictStage#filter#after#_compSkRef#}], global:check=aviator[filterEmptyCode !=nil&& filterEmptyCode =='deleteItemByConditionalFilter' ] //数据诊断-原语表达（判断底层是否有数据，若没有则为true，否则为false） global:keys=keySpread[@prefix 138_ymtags_][@crossOrder city_${cityId}_platform_${platformNo}_surgery_prj_${genericLvlIds}], global:cnt=cellar@cellar[@count ${keys}], global:check=aviator[cnt !=nil && cnt !='' && long(cnt) 0 ]
```
5.2 アラームのフォローアップ

品質スコアを使用できます。リアルタイムの監視と運用レビューのために、チームメンバーは変更をタイムリーにフォローアップする必要があります。一般に、企業に共通のアラームシステムは、サービス名の粒度に基づいてアラーム受信者を構成します。レコメンデーションシステムなどのプラットフォームサービスは、統一されたインターフェイスを通じてサービスを提供しますが、モデル戦略はさまざまな学生によって維持され、企業間では業界の知識と理解に一定のしきい値が存在します。デフォルトのブロードキャストタイプのアラームは、アラームストームを簡単に引き起こす可能性があるため、誰もが自分のモジュールの問題に集中できず、アラームを見逃すこともあります。フォローアップ率を向上させるため（図 11 に示すように）、既存のアラームをベースに、特定のトラフィックレベルのアラームを専任の担当者にルーティングするフォローアップ機能を開発しました。フォローアップのステータスフローを記録すると、タイムリーな通知とその後のレビューが容易になります。運用面では、データレポートを通じて品質ダッシュボードを構築し、さまざまな事業の品質変動を定期的にレビューしています。

図 11 警報フォローアッププロセス
5.3 ガバナンス効果

品質スコア結果ヌル率から実装を開始し、プロセスに従って再現ヌル率、モデル予測ヌル率、再配置演算子ヌル率を分解して収集し、プラットフォーム、ビジネス、フォーム、プロジェクト、トラフィック位置に集計します。ビジネス、多次元。ガバナンスのアクションと結果は次の側面に分類されます:
- 追跡と診断を通じて、現在の空の結果が供給の問題なのか品質の問題なのかを判断し、誤報を避けるために空の結果の 98% を品質スコアの計算から除外することができます。空の結果アラームの 1 日あたりの平均数が 40 件から 5 件に減りました。
- リンクプロセスにおける各リンクのヌル率の分析に基づいて、データ仕様（データ階層化の標準化、ラベリング仕様）、サービスアーキテクチャを含むガバナンス対策を講じます。 (ビジネスの分離、基盤となるデータのデュアルメディア、ダウングレード)、仕様の変更 (オンラインパイプライン検査の構成、トラフィックの再生) により、空の結果のシステム検出率が 60% 以上に維持されます。
- アラームブロードキャストを回避し、フォローアップステータスのマーキングをサポートするためのアラームルーティングのカスタマイズされた開発空の結果アラームのフォローアップ率は、統計不可能な値からコアトラフィックの 100% のフォローアップまでの範囲です。
#null 結果の管理と識別後の現在のコアトラフィックの null 率は 0.01% であり、これは、コアトラフィックリクエストの 99.99% で結果が得られることが保証されていることを意味します。施工品質分析と同時に、システム発見率と警報追跡率も確保します。
5.4 資産の沈殿物

レコメンデーションシステムはデータの価値を提供します。データが資産化されて初めて、この価値は持続可能となり、付加価値が得られます。レコメンデーションシステムの品質モデルを構築するプロセスは、実際にはデータ資産の蓄積にも関係します。データは収集後資産となるため、一般に流動性、測定性、制御性、付加価値の 4 つの条件を満たす必要があり、これらについては第 4 章の計算方法で説明します。インジケーターの運用プロセスは、質の高い知識資産を蓄積するプロセスでもあります。ソフトウェア欠陥モデルは最終製品の納品品質にどのような影響を及ぼしますか?それらの間に相関関係や因果関係はありますか?この影響はスコア計算に明示的に関与していますか、それとも間接的ですか?品質サブオペレーションのプロセスでは、頭の中で品質マップを徐々に埋めていき、指標と欠陥、指標と欠陥の間のトポロジカルな関係を形成することができ、これは品質を資産化するプロセスです。例えば、レコメンドシステムの実務を通じて、オンライン障害の80％はリリースが原因であり、リリース障害の80％はデータリリースが原因であることが分かり、データリリースのガバナンスを通じてオンライン障害を削減することができます。
6 今後の予定

ユーザビリティをベースに計算方法を調整し、多段階のレコメンドシステムの品質スコアを確立し、さまざまな推奨素材やさまざまなコンテンツに拡張しました。ビジネスモジュールの中核は、外部サービスの「可用性」から外部サービスの「良し悪し」までの認知的反復を完了したことであり、これは品質と洗練された運用の基礎でもあります。フォローアップ計画では、一方では品質モデルの計算とリンクカバレッジを強化し続けることですが、他方では品質モデルに基づいて品質ガバナンスの取り組みをさらに強化することです。
- 埋め込みポイントと診断を改善することで、品質サブシステムのすべてのレベルで指標を段階的に実装し、含意を強化します。品質サブシステムを強化し、より多くの品質問題に対応します。
- マルチレベル推奨の柔軟なダウングレードを構築することで、品質スコアの理解を繰り返し、さまざまなダウングレードがシステムに及ぼす影響を定量化します。
- データリネージの精度、対象範囲、適時性を最適化し、特定のリンクにおける品質問題の影響をより正確かつ迅速に評価します。
7 この記事の著者

Yong Hao、Gengen、Wang Xin、He He、Li Cong などすべて Meituan 店内プラットフォーム技術部門/店内総合ビジネスデータチームの出身です。