美団総合ビジネス推奨システムの品質モデルと実践

著者: Yong Hao Gen Gen、Wang Xin など

1 はじめに

美団の総合店内事業（以下、「店内総合事業」という）は、美団の店内事業の重要な部門の一つであり、入浴、カラオケ、美容産業、医療美容、親子、結婚、スポーツ・フィットネス、娯楽、教育・トレーニング、住宅、ペット、バー、生活サービスなど数十の重要なサブ産業をカバーし、数億人のユーザーの多様な地域生活ニーズを満たしています。

推奨システムは、需要と供給の効率的なマッチングを実現するための重要なリンクであり、データの価値を提供する出口です。推奨システムの品質が、マッチング効果の損失を決定します。下の図 1 に示すように、データはデータウェアハウスとアルゴリズムによって処理され、データサービスを通じてさまざまな業務システムに提供され、最終的にクライアント埋め込みポイントを通じてデータウェアハウスに流れ戻り、データの「フライホイール効果」を形成します。品質はまさにこのリンクにおける歯車のかみ合いの重要なポイントであり、効率を向上させ、結果を確保するための重要な前提条件です。

品質保証は、測定が「目に見える」、「明確」、「正確に」なるように測定を中心に実行する必要があります。しかし、従来のバックエンドサービスの品質指標では、現在の「データフライホイール」の品質を十分に説明することはできません。総合的な業務推奨システムの品質モデルの構築を通じて、同様の多業務ラインおよび効果指向のシステム品質測定に新たな視点と実用的な参考資料を提供したいと考えています。

図1 推奨システムの「データフライホイール」

2 現状分析

推薦システムは効果ベースのシステムであり、その品質特性は機能ベースのシステムとは異なります。機能的なシステムは、一般的に、ダウングレードされた後にユーザーエクスペリエンスにより明らかな影響を与えますが、推奨結果が A または A' を返す場合、ユーザーが明確な認識を持つことは困難です。しかし実際には、マッチング効果が悪化すると、ユーザーの暗黙的な体験に直接影響するため、特定する必要があります。機能システムでは、一般的にユーザビリティを中核とした品質指標システムを構築します。総合ビジネスレコメンデーションシステムのビジネス実践において、ユーザビリティなどの指標には次のような限界があることがわかりました。

可用性は部分的な欠陥の影響を受けません。可用性は停止の頻度と期間の関数であり、システムがサービスを継続的に提供できる能力を反映します。システムの欠陥が外部サービスの提供に影響を与えない限り、可用性には影響しませんが、実際にユーザーエクスペリエンスに影響を与えるものもあります。ここでの欠陥は、予想されるもの（アクティブな劣化など）または予期しないもの（モデル更新の遅延）である可能性があり、品質測定に含める必要があります。
可用性はデータチェーン全体をカバーすることが困難です。推奨システムチェーンは、データの生成、処理、適用、分析、およびその他のリンクをカバーします。まず、可用性はデータテーブルの品質とは関係ありません。また、パフォーマンスメトリックが利用可能な場合でも、データ品質の全体像を反映することはできません。データ品質では、可用性の範囲を超えて、完全性、正確性、適時性、セキュリティなどの特性を考慮する必要があります。国際的に著名な学者アンドリュー・ン氏はかつて、人工知能の価値の80%はデータに依存しており、推奨システムの推奨効果（クリックスルー変換率、トランザクション変換率、ユーザー滞在時間など）の提供品質も主にデータの質に依存すると述べました。
可用性はビジネスの違いを反映するのが難しい：Meituan は数百の業界と数十のチャネルページをカバーしています。効率とコストを考慮すると、推奨システムはビジネスを完全に分離することはできません。可用性の直列および並列計算方法では、ビジネスを区別して個別に評価することが困難です。ビジネスはそれぞれアクセス頻度、トラフィックのピーク期間、ビジネス戦略が異なるため、品質特性や問題の分布も大きく異なります。現在の可用性指標にはビジネスディメンション情報が欠けており、洗練された品質操作のガイドには役立ちません。

これまで、品質構築の目標は、障害レベルをターゲットとして使用することでしたが、その結果、検証サイクルが長くなり、ランダム性が生じ、ターゲットとアクションの論理的推論との関係が弱くなりました。さらに、障害自体は事後に発生するため、この問題主導型のアプローチは継続的な運用には役立ちません。一般的に、可用性を目標とした場合、実際の計算実装にはさまざまな問題があるため、可用性に基づいてレコメンデーションシステムの品質モデルを構築し、計算方法を調整して洗練された品質操作を導くことを検討します。

3 建設アイデア

3.1 ビジネスにおける品質

品質モデルを構築するには、まず品質の本質についての理解に戻る必要があります。国際標準化機構 ( ISO ) の定義によれば、品質とは、明示的または暗黙的な「ニーズ」を満たすエンティティの能力を反映する特性の合計です。よく使われるもう 1 つの品質概念は安定性です。安定性の中核は、システムが「期待される」状態で長期間にわたって実行できるようにすることです。品質であれ安定性であれ、システムが誰のニーズと期待を満たす必要があるのかを把握する必要があります。推奨シナリオでは、このオブジェクトは製品とアルゴリズムです。ビジネス製品は、ユーザーシナリオを理解し、ユーザーニーズを抽象化し、製品要件を推奨チームに提案し、外部の製品反復に反映されます。同時に、推奨システムチームは相互に連携して最適な最適化モデル戦略を学習し、データチーム内のアルゴリズム反復に反映されます。

下の図 2 に示すように、可用性の計算式では長時間性が重視され、「必要性」と「期待」は外部サービスの提供にのみ反映されます。ここに一定の合理性があります。第一に、可用性は業界で共通の指標であり、その定義は一般化する必要があります。したがって、品質の共通性と最終目標は、外部にサービスを提供することです。第二に、ほとんどのバックエンドシステムは機能を提供し、外部に提供するサービスは主に「はい」と「いいえ」の間であるため、サービスの低下にも一定の余地があります。しかし、効果を主な目標とする推奨システムの場合、機能の「存在」と「非存在」の間には「良い」効果と「悪い」効果の長いスペクトルが存在します。推奨システムの品質に関する私たちの反復的な考え方における中核的な変化は、外部サービスの「存在」または「非存在」から、外部に提供されるサービスの「良し悪し」への変化です。これは、可用性の計算方法を変える出発点でもあります。

図2: 欠陥が品質指標に与える影響

3.2 欠陥の考慮と選択

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

図3 推薦システムの品質特性

従来のユーザビリティメトリックは主に信頼性、機能の完全性、正確性に重点を置いているものの、推奨事項の品質と有効性に密接に関連する機能の正確性、適切性、セキュリティのほとんどのメトリックが欠けていることがわかりました。正確性と適切性が結果に与える影響はより直接的ですが、その他はより間接的です。例えば、セキュリティでは、クローラーのアクセスを例に挙げます。クローラーのアクセス動作は実際の人間の行動習慣に適合していないため、UVCTRなどのコア指標の回復に影響を与え、効果の誤判断を引き起こします。同時に、クローラーデータを識別して除去できない場合、ノイズはモデルトレーニングの精度にさらに影響を及ぼします。データ品質の問題は、データの「フライホイール効果」における「ポイズンピル」であり、正のフィードバックを生成し、継続的に欠陥を増幅します。第4章では、上記の欠陥を定量化し、計算ルールにおける可用性の範囲を拡大します。

3.3 指標と計算の選択

可用性は、測定方法と計算方法に分けられます。測定は、よく N9 と呼ばれるもので、計算は平均故障間隔と平均回復時間の関数によって測定されます。測定方法に関しては、業界で一般的に使用されている品質測定方法を以下の図 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 レベルの入力指標を取得できます。たとえば、リコール欠陥率が比較的高い場合、リコール NULL 値率、リコールタイムアウト率などを測定できます。ユーザーリクエストは、ビジネスに応じて垂直、水平、時間ベースで集計され、ビジネス属性による品質スコアを取得できるため、よりターゲットを絞った集中的な処理が可能になります。

図8 品質指標システム

この改善された品質スコアは、リクエストを基本単位として使用します。元の可用性計算方法と比較すると、欠陥に敏感であり、データリンクの影響を含めることができ、複数のビジネスディメンションの集計分析を容易にするなど、ある程度の制限が解決されています。

4.4 血統の拡大

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

図9 推薦システムのデータ系統

血縁関係とは、親子関係、兄弟姉妹関係、その他そこから派生する親族関係など、人間社会における結婚や出産などにより生じる人間関係のことです。また、データは融合や変換によって血縁関係を生成することもできます。データの血縁関係は、データベース、データテーブル、フィールドの異なるレベルに分かれており、一般的にはデータ資産（引用人気度計算、データコンテキストの理解）、データ開発（影響分析、帰属分析）、データガバナンス（リンクステータス追跡、データウェアハウスガバナンス）、データセキュリティ（セキュリティコンプライアンス検査、ラベル伝播）の4つの側面で使用されます。システム品質スコアを推奨するという現在の考え方では、影響分析は主に品質スコアを拡張するために使用され、障害のあるノードへのすべてのリクエストにマークを付け、対応するスコアを差し引きます。

レコメンデーションシステムのビジネスセマンティクスでは、スナップショット、プラン、コンポーネント、インデックス、モデル、機能の 6 種類のビジネスメタデータを定義します。メタデータに基づいて、タスクアクセス、系統分析、データエクスポートに分けられる系統を構築します。タスクアクセスは収集モジュールと保存モジュールに分かれており、タスクアクセスが完了すると、ノードとその関係がグラフデータベースに保存され、グラフアルゴリズムを使用して血縁関係が確立されます。血統を確立した後、ノード自身の異常がシステム検出と手動マーキングをサポートし、影響分析を自動的に完了できます。ノードに異常が発生すると、メッセージ通知が送信され、異常情報は血統に沿って伝播され、下流リンクの品質スコアの計算に影響を与えます。

異常がユーザー側に広がった場合、ビジネス言語を使用して損失を再説明しようとします。総合収益モデルに基づいて、各事業ラインの各意図された UV の値を計算し (マーチャント詳細ページとグループ注文詳細ページへのユーザー訪問を意図された訪問と呼びます)、このトラフィック位置の週ごとの訪問状況を使用して、事業損失を自動的に推測できます。

5. インジケーターの操作

5.1 システムの実装

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

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

スコアリングシステムの改善は徐々に行う必要があります。推奨システムの場合、推奨結果の欠如が最も深刻な品質問題です。最初に収集して計算するのは、推奨される空の結果です。これは、第 1 レベルの指標の結果の欠陥率とリコールの欠陥率、および第 2 レベルの指標の結果の空の値率とリコールの空の値率に対応します。同時に、総合の業務特性により、業界が多く、供給が時間と空間に不均等に分散しているため、クロススクリーニング条件の数が多くても空の結果が発生し、品質スコアの計算に影響を与えます。

追跡ポイントを実装した上で、ビジネスの期待に応える空の結果を排除し、品質スコアのノイズを排除する方法が、診断にとって非常に重要になります。空の結果を例にとると、主にパラメータ診断、データ診断、リンク診断の 3 つの側面から識別します。データ診断とは、オンラインスクリーニング条件で空の結果が表示された場合に、ソースに戻って基礎データを再度検証し、基礎となるテーブルデータが空かどうかを確認するプロセスを指します。ベーステーブルに実際に関連する供給がない場合、アラームなしルールが強制され、アラームなしの有効期間が設定されます。一定期間内に、現在の都市と現在の業界に関連する供給が不足し、空の結果は品質スコアの計算に含まれません。

ベーステーブルに供給がある場合は、データ処理またはサービス中に異常が発生し、リコールできないことを意味します。その後、リンク診断を通じてエラーリンクが決定され、対応する品質スコアの計算に含められます。ルールマッチングメカニズム（つまりルールエンジン）をどのように確立するかが診断エンジンの鍵となります。現在、EasyRule、Drools、Zools、Aviator など、選択できるルールエンジンは数多くあります。上記の分析によると、診断エンジンは、リクエストパラメータ、推奨リンク、および基礎データに対してルール診断を実行できる必要があります。リクエストパラメータや推奨リンクの診断はメモリパラメータを通じて実行できますが、データ診断ではサードパーティのストレージから情報を取得する必要があるため、一部はカスタマイズされた開発が必要になります。ツールの成熟度と使用の利便性を考慮すると、Aviator プレゼンテーションエンジンの方が適しています。診断のニーズを満たすために、表現診断プリミティブは次のように設計されています。

 //パラメータ診断プリミティブ式
//診断プリミティブが特定のパラメータを満たしているかどうか
グローバル: check = aviator [ cityId != nil && include ( string . split ( '1,2,3,4,5,6,7,8,9,10,16,17' , ',' ), str ( cityId ))]

 //リンク診断プリミティブ式
//1. 異常診断プリミティブをリコールする
グローバル: recallException = param [ $ { リコール#例外#}],
 グローバル: チェック= aviator [ リコール例外!= nil && リコール例外!= '' ]
 //2. 例外なしで診断プリミティブを呼び出します
グローバル: recallEmpty = param [ $ { recall #after #}],
 グローバル: チェック= aviator [ recallEmpty != nil && rememberEmpty != '' ]
 //3. リコールは空ではなく、フィルタルールの実行後に診断プリミティブは空になります
グローバル: recallEmptyCode = param [ $ { recall #after #}],
 グローバル: predictFiltersEmptyCode = param [ $ { predict #after #filters #}],
 グローバル: check = aviator [( rememberEmptyCode == nil || rememberEmptyCode == '' ) && predictFiltersEmptyCode != nil ]
 //4. 特定のフィルタリングルールを実行した後、一致する結果がない
グローバル: filterEmptyCode = param [ $ { PredictStage #filter# after #_compSkRef #}],
 グローバル: チェック= aviator [ filterEmptyCode != nil && filterEmptyCode == 'deleteItemByConditionalFilter' ]

 //データ診断 - プリミティブ式（基になるレイヤーにデータがあるかどうかを判定し、ない場合は true、ない場合は false になります）
 グローバル: keys = keySpread [ @ prefix 138_ ymtags_ ][ @ crossOrder city_$ { cityId } _platform_$ { platformNo } _surgery_prj_$ { genericLvlIds }],
 グローバル: cnt = cellar @ cellar [ @ count $ { keys }],
 グローバル: check = aviator [ cnt != nil && cnt != '' && long ( cnt ) <= 0 ]

5.2 アラームフォローアップ

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

図11 アラームフォローアッププロセス

5.3 ガバナンス効果

品質スコアの実装は、結果のヌル値率に基づいています。再現ヌル値率、モデル予測ヌル値率、再配置演算子ヌル値率は、プロセスに従って収集され、プラットフォーム、ビジネス、フォーム、プロジェクト、トラフィックなどの複数のディメンションに集計されます。ガバナンスのアクションと結果は、次の領域に分類されます。

追跡と診断を通じて、現在の空の結果が供給の問題なのか品質の問題なのかを判断します。誤報を回避するために、品質スコアの計算から空の結果の 98% を除外しています。空の結果の警報の 1 日あたりの平均数は 40 件から 5 件に減少しました。
リンクプロセスにおける各リンクのヌル値率の分析に基づいて、データ仕様（データ階層化の標準化、ラベルマーキング仕様）、サービスアーキテクチャ（ビジネス分離、基礎データのデュアルメディア、劣化）、変更仕様（構成オンラインパイプライン検査、トラフィック再生）などのガバナンス対策を講じ、ヌル結果システム検出率を60％以上に保ちます。
カスタマイズされたアラームルーティングは、アラームブロードキャストを回避し、フォローアップステータスのマーキングをサポートするために開発されました。空の結果アラームのフォローアップ率は、カウントできない状態からコアトラフィック位置の100％フォローアップにまで削減されました。

空結果の管理と識別後、コアトラフィックビットの現在の空値率は0.01％であり、コアトラフィックビットの要求の99.99％で結果が保証されることを意味します。品質スコアを構築しながら、システム検出率とアラームフォローアップ率が保証されます。

5.4 資産の沈殿

レコメンデーションシステムはデータの価値を伝えます。データが資産化されて初めて、この価値は持続可能になり、価値が高まります。推奨システムの品質モデルを構築するプロセスは、実際にはデータ資産の蓄積でもあります。収集されたデータが資産になるためには、一般的に、モバイル性、測定可能性、制御可能性、付加価値の 4 つの条件を満たす必要があります。これらはすべて、第 4 章の計算方法で説明されています。指標運用のプロセスは、質の高い知識資産を蓄積するプロセスでもあります。ソフトウェア欠陥モデルは、最終製品の納品品質にどのように影響しますか? 両者の間に相関関係や因果関係はありますか? この影響はスコア計算に明示的に関与しますか、それとも間接的な影響ですか?品質分析と運用のプロセスでは、徐々に頭の中に品質マップを埋めていき、指標と欠陥、指標と欠陥の間に位相的な関係を形成します。これは、品質を資産に変えるプロセスです。たとえば、レコメンデーションシステムのビジネスプラクティスを通じて、オンライン障害の 80% はリリースによって発生し、リリース障害の 80% はデータのリリースによって発生していることがわかりました。これにより、データリリースを管理することでオンライン障害を削減できます。

6 将来計画

可用性に基づいて計算方法を調整し、多段階の推奨システム品質スコアを確立し、さまざまな推奨資料や業務モジュールに拡張しました。その核心は、外部へのサービス提供の「存在」から外部へのサービス提供の「良し悪し」までの認知反復を完了したことであり、これは洗練された品質操作の基礎でもあります。今後は、品質モデルの計算とリンク範囲を引き続き充実させていきます。一方で、品質モデルに基づいた品質ガバナンス作業をさらに進めていきます。次の方向性が、今後の思考と反復の焦点となります。

追跡ポイントと診断を改善することで、品質スコアシステムのすべてのレベルで指標を徐々に実装し、品質スコアの含意を豊かにし、より多くの品質問題に対応できるようになります。
複数レベルの推奨による柔軟な劣化を構築することで、品質スコアの理解を繰り返し、さまざまな劣化がシステムに与える影響を定量化できます。
データ系統の精度、範囲、適時性を最適化して、特定のリンクにおける品質問題の影響をより正確かつ迅速に評価します。