アルゴリズム モデルのライフ サイクル全体** (アルゴリズム モデルのライフ サイクル: 初期トレーニング データ --> モデル トレーニング --> モデル評価 --> モデル推定 --> トレーニング データ)** では、どの時点でも問題が発生する可能性があります。リンク アルゴリズム モデルの品質問題につながります。したがって、モデルの品質保証のプロセスでは、各段階の品質に注意を払う必要があります。
1. 背景
現在、アルゴリズム モデルは厳密な選択のさまざまな側面で広く使用されており、アルゴリズムはどこにでも存在すると言えます。
C 側で Yanxuan APP の検索および推奨機能を提供します。
インテリジェントタッチマーケティングシステムでパーソナライズされたマーケティング機能を提供します。
外部広告リアルタイム入札取引プラットフォームにインテリジェントな入札機能を提供します。
サプライチェーンにBサイドでの製品補充を見積もる機能を提供します。
……
ビジネスの継続的な発展に伴い、アルゴリズム モデルの品質保証の改善がますます緊急になっています。Yanxuan ではアルゴリズム モデルの品質保証は比較的遅くに開始され, 過去 2 年間で本格化し始めました. この記事では, Yanxuan の現在のモデル品質保証システムを簡単に要約し, モデルの品質保証の手段と優先実装について説明します延軒の保護手段。
アルゴリズムのアプリケーション コアは、呼び出し、並べ替え、再配置の 3 つの主要な部分に分割できます。
リコール層はまず、アルゴリズム モデルを通じて複数のターゲット候補セットからリソース (製品、リスト、アクティビティ、トピックなど) をリコールします。
ソート層のモデルは主に、正確なランキングを行うためのディープラーニング モデルであり、推定クリックスルー率、購入率、コンバージョン率などに基づいてソートされます。
再配置層には主に、トラフィック意思決定アルゴリズム、ダイバーシティ再配置アルゴリズムなどの再配置アルゴリズムと戦略が含まれます。
最後に、パーソナライズされた結果がユーザーに表示され、ユーザーがクリック、購入、購入などの行動を分析し、トレーニング サンプルが抽出されてモデルの更新に使用されるため、良性の閉ループ システムが形成されます。
アルゴリズムの全方位的な品質保証を検討するために、アルゴリズム モデル システムのライフ サイクルを抽象化しました アルゴリズム モデルのライフ サイクルは、大まかに次のプロセスを経ます: 初期トレーニング データ -> モデルトレーニング (モデルの生成) -> モデル評価 (モデルのテスト) -> モデル予測 (モデルを使用) -> モデル適用 (フィードバック モデル)、最終的に閉ループを形成します。
モデル トレーニング プロセスは、トレーニング サンプルと回答を通じてアルゴリズム モデルを取得するプロセスです。
モデル評価は、サンプルと新しくトレーニングされたモデルを評価することによって新しい答えを得るプロセスです。評価サンプルには既知の答えがあるため、新しい答えと参照答えを比較することでモデルの効果を評価できます。
モデル推定とは、サンプルとモデルを推定して答えを得るプロセスであり、製品の推奨シナリオでは、サンプルの推定はユーザー + 製品として理解でき、推定するのはユーザーのクリックまたは製品の購入確率であり、クリックするかどうかだけです。 . 購入は将来発生します。
モデル適用は、フィードバック モデルによって新しいトレーニング サンプルを生成するプロセスであり、製品レコメンデーション シナリオでは、推奨される製品がユーザーに表示され、ユーザーの実際のクリック、購入などの行動データが取得されます。
アルゴリズム モデルのライフ サイクルでは、リンクに問題が発生すると、アルゴリズムの品質の問題が発生します。
また、他のサーバー側テストと比較したアルゴリズム テストの難しさも分析しました。
まず、他のサーバーの動作はさまざまな入力に基づいて事前に決定されますが、アルゴリズムのテスト入力は機能 (たとえば、ユーザーの機能はリアルタイムで更新されます) であり、テスト出力は推定値であり、不確実性があります。解釈性の面では、深層学習モデルの限界により、ニューラルネットワークは解けないため解釈性が悪く、結果の検証においては、出力に対応する入力の論理が正しいかどうかを確認することができず、結果の検証が困難である。
テストサイクルに関しては、モデルのバージョンが更新されるため、時間の経過とともに推定されるモデルの効果が乖離する可能性があり、モデルの立ち上げ後にモデルに問題が発生しないとは言い切れませんので、引き続き注意が必要です。
テストに関する懸念に関しては、モデルの品質だけでなく、特徴の品質とデータの品質にも焦点を当てる必要があります。
さらに、他のサーバー側テストと比較して、モデルの問題は非常に抽象的であり、分析して特定することが困難です。
次に、アルゴリズム モデルのライフ サイクルを通じてモデルの問題を分析します。
2. モデルの問題分析
アルゴリズム モデル システムから閉ループを抽象化しました。リンクに問題が発生すると、アルゴリズム モデルの品質に問題が発生します。したがって、次にアルゴリズム モデルの閉ループから開始し、アルゴリズムの問題の観点からアルゴリズムで発生する典型的な問題を説明し、アルゴリズムの包括的な品質保証方法を紹介します。
モデル適用の段階から分析を開始します モデル適用とは、モデル推定後にモデルにフィードバックするプロセスです 例えば、厳選したレコメンドシナリオで推奨された商品をユーザーに公開し、ユーザーが一連の操作を実行しますクリック、収集、購入の追加、購入などの行動このデータは機械学習を構築するための最初のステップであり、この段階ではデータ品質の問題が発生する傾向があります。
モデルをモデル トレーニングに適用するプロセスでは、アルゴリズム エンジニアは元のデータに基づいた一連のスプライシングや計算などを通じてトレーニング用の特徴を取得します。このプロセスでは、特徴の品質の問題が発生しやすくなります (問題が発生する可能性もあります)。データ品質の問題として分類されます)。
モデルのトレーニング段階では、アンダーフィッティングやオーバーフィッティングなどの一連の問題が発生しやすくなりますが、これらはアルゴリズムエンジニアが注意すべき問題であり、QA はあまり注意を払う必要はありません。
モデルの評価段階では、検証セットと学習セットの分割が不均一になり、モデルの評価が歪むなどの問題が発生しやすくなりますが、アルゴリズムエンジニアはこれらの問題にも注意する必要があります。
モデルのトレーニングからモデルの推定までのプロセスでは、モデルの遅延問題が発生しやすく、Yanxuan は現時点ではモデルの有効性に対する高い要件を持っていませんが、将来的には時間レベルの更新にアップグレードされ、遅延の問題はより深刻になるでしょう。目立つ。
モデルの推定段階では、政策メカニズムの一貫性の問題（実際のモデル効果が研究の期待を満たしていない）、データ品質の問題（サンプルデータの問題、特徴量計算の問題）、機能、パフォーマンスの問題などが発生しやすくなります。
まず、症状の顕在性によって問題を大別すると、急性の問題は症状が重篤で明らかであり、これを阻止する必要がある問題、慢性の問題は初期症状が明らかではなく徐々に蓄積していくため、対応が必要となる問題です。想起。閉ループのアルゴリズム モデル全体を分析すると、問題が 5 つの主要なカテゴリに分類されます。
1 つ目のカテゴリは主に、検索の推奨など、表示されやすい悪いケースです。
2 番目のカテゴリは、モデルの推定段階で発生する戦略メカニズムの一貫性の問題です。
3 番目のカテゴリはモデルの遅延問題で、モデルの評価からモデルの推定までのプロセスで発生します。
4 番目のカテゴリはデータ品質の問題で、モデルの予測段階、またはモデルの予測からモデルのトレーニングまでのプロセスで発生します。
5 番目のカテゴリは、モデルの推定段階で現れる機能およびパフォーマンスの問題です。
そのうち 2 つは急性の問題、2 つは慢性の問題、そして 1 つはより特別なもので、Badcase です。より正確に言えば、badcase は結果であるはずであり、その結果の原因には他にも 4 つの問題が含まれる可能性があるため、badcase mining はアルゴリズム システム全体をブラック ボックスとしてテストすることと理解できます。
これらの問題を分析すると、最終結果は次の 3 つのタイプに分類できることがわかります。
1 つ目は Badcase です。
2 番目のタイプはアルゴリズム モデルの効果の問題で、ポリシー メカニズムの一貫性の問題、モデルの遅延の問題、データ品質の問題、パフォーマンスの問題などが含まれ、これらはすべて最終的なモデルの効果に影響します。
3 番目のタイプは、機能戦略の問題です。
これは、アルゴリズム モデルの品質保証の焦点、つまり不良ケース マイニング、アルゴリズム モデル効果の問題の発見、および機能戦略の問題の発見にもつながります。
アルゴリズム モデルの効果の品質保証は、モデルの品質保証の焦点であり、困難でもあります。モデルの効果に影響を与えるさまざまな要因があり、その結果、非常に抽象的で、分析と特定が困難なモデルの問題が発生します。優先順位と入出力比を考慮すると、アルゴリズム モデルの効果の品質保証は、浅いものから深いものへのプロセス、つまり、問題が認識可能で測定可能になり、問題が制御可能になるまでのプロセスです。
したがって、アルゴリズムモデルの効果と品質を初期段階で確保する目的は、アルゴリズム学習者によってモデルのオフライン評価が完了するため、問題点を知らせることであり、評価指数が低下するとモデルはブロックされます。オンラインで使用されないため、モデルの事前および事後を使用できます。 効果の一貫性を使用して実際の効果の問題を発見し、これに基づいてパフォーマンスの問題が実際の効果に及ぼす影響に注意を払います。データ品質の問題、ポリシーメカニズムの一貫性の問題、モデル遅延の問題などは、将来さらに改善する必要があります。さらに、自動化されたパイプライン オンライン検証により、モデルのオンライン パフォーマンスをさらに向上させました。
3. モデルの品質保証のポイント
3.1 バッドケースマイニング
アルゴリズム モデルにより、オンラインの検索や推奨事項には、検索結果と一致しない検索語句、推奨結果に表示されるべきではない製品や推奨事項など、明らかな悪いケースが存在する可能性があります。これらの悪いケースはユーザー エクスペリエンスに非常に有害であり、コンバージョンや収益に影響を与える可能性もあります。
ではどうするかというと、そういった問題をオフラインで可能な限り遮断し、オンラインでできるだけ早くリコールすることです。したがって、問題分析は次の 2 つの点に要約できます。
モデル評価からモデル予測までのプロセスでは、高効率、高カバレッジのアルゴリズム モデルの Badcase オフライン検証および傍受機能が不足しています。
モデル推定プロセスでは、効果的なアルゴリズム モデル Badcase オンライン リコール機能が不足しています。
この点に関して、私たちはプラットフォーム上に Badcase マイニング機能を構築しました. 新しいモデルがオンラインになる前のモデルのアップグレードと品質保証の重要な部分として, モデルによって引き起こされる可能性のある Badcase をオフラインで傍受できます. 属性条件によってユーザーをスクリーニングできます高レベルのテスト ユーザーを達成するために自動的にマイニングされ、カバレッジと効率が高くなります。これまでは、オフラインで Badcase を調査する場合、カバレッジが低かった自分のアカウントを参照して APP をテストすることしかできませんでした。または、手動のユーザー リクエスト インターフェイスを構築して検索推奨の製品 ID を取得し、その ID を視覚化することもできました。ガジェットを使用するため、非効率的でした。
Badcase マイニング プラットフォームは主に 2 つの段階を経ました。
第一段階はマニュアルマイニングで、モデルの影響下でユーザーに推奨された商品やユーザーが検索した商品をプラットフォームが手動で確認し、ユーザーが特定の商品を推奨したり、特定の商品を検索した理由を分析し、これによりモデル効果が確認されます。しかし、手動評価モデルはテスターの経験の蓄積に大きく依存しており、閾値が高く、一度に 1 人のユーザーの推奨製品と検索された製品しか評価できないため、非効率であり、対象ユーザーも限られています。閾値が低く、より効率的で、カバレッジの高い手法を模索するために必要な、オフライン効果検証機能のモデル化。
第 2 段階は自動マイニングです。プラットフォームは、テスト結果のバッチを生成するユーザーのバッチを選択し、モデル評価指標を自動的に計算し、Badcase リスク レベルの高い結果を自動的に選別し、最後にリスクの高い結果を手動で確認します。ユーザーカバレッジが向上し、テスト効率が向上します。
3.2 モデル効果の品質
問題分析では、アルゴリズムモデルの効果の品質を確保する際に、問題を知るという問題を優先し、最初のステップでモデルの事後効果モニタリングを確立し、モデル効果のT+1の既知性を達成しました。問題。これに基づいて、パフォーマンスの問題をリアルタイムで把握するための洗練されたパフォーマンス監視を確立しました。今後は、データの品質やモデルの遅延などの保証をさらに徹底していきます。
3.2.1 モデル事後効果
モデル効果の評価指標は数多くありますが、シナリオやビジネスに応じて適切な指標を選択することで、評価指標を観察することでモデルの実際の効果を判断することができ、モデルの高度化を支援します。そして反復。
一般的なモデルには主に分類モデル、回帰モデル、クラスタリングモデルが含まれますが、最初にこれらのモデルに共通するモデル効果評価指標を分析します。
分類モデルの一般的な評価指標には、適合率、再現率、正解率、F1 スコア、AUC/GAUC、KS 値、PSI 値などが含まれます。
回帰モデルの一般的な評価指標には、平均絶対誤差、平均二乗誤差、二乗平均平方根誤差、平均二乗対数誤差、中央値絶対誤差、決定係数などが含まれます。
クラスタリング モデルの一般的な評価指標には、純度、F1 スコアなどが含まれます。
検索、レコメンデーション、広告などでは通常回帰モデルが使用されますが、実際の測定基準はクリックかコンバージョンかという分類問題であるため、指標の評価には分類モデルを使用する方が合理的です。一方で、モデルのオフライン評価は通常、アルゴリズムの学生によって完了することがわかり、オフライン評価に合格したモデルのみがオンラインで使用されます。オフラインの評価指標はベンチマークとして使用する必要があります。
Yanxuanを例に挙げると、検索、レコメンデーション、広告などのモデルのオフライン評価では、クリック数、追加購入数、コンバージョン数のAUC/GAUCが用いられるため、オンラインモデルの評価でも注目すべき指標は以下の通りです。クリック、追加購入、またはコンバージョンの AUC/GAUC これに基づいて、他の指標を改善することは、モデル効果の多次元分析に役立ちます。
理想的には、モデル予測フローとモデル評価フローによる特定の製品に対するユーザーの興味スコアの結果は同じであるため、事前効果と事後効果の一貫性を通じてこの問題を発見できます。では、事前効果と事後効果とは何でしょうか?
いわゆるアプリオリ効果はモデル評価効果（モデルが有効になる前に発生する）であり、事後効果は非リアルタイムを指し、実際のオンライン効果指標はフィードバックエクスポージャを適用することによって計算する必要があります。クリックとコンバージョンデータ。
この図は、モデル予測とモデル評価の 2 つのストリームの論理的抽象化を示しています。
事前効果と事後効果の一貫性の原理図
モデルの評価段階では、回答が既知の評価サンプルの特徴を計算し、モデルの並べ替え手法を使用して、変換されたサンプルが可能な限り上位にランクされるかどうかを観察して、モデルの効果（事前効果）を評価します。モデルはクリックまたはコンバージョンであり、アプリオリ効果はクリック AUC/GAUC またはコンバージョン AUC/GAUC によって測定できます。
モデル推定段階では、同様に推定サンプルの特性を計算し、モデルを使用して推定値を計算して並べ替えますが、将来的にはユーザーが実際にクリックおよび購入行動を起こすようになり、実際の効果が明らかになるでしょう。同様に、事後効果指標を事前効果指標と一致させることができます。
しかし、多くの場合、モデルの評価段階と予測段階では異なる評価体系が用いられており、新旧モデルのクリック数、コンバージョン数、UV値などの業績指標は、オンラインでの実験を通じてのみ比較されています。これの問題は、オンラインのクリック率やコンバージョン率、あるいは期待される結果を達成するためにどの程度の改善が必要かを知るだけでは十分ではないため、モデルの効果を判断するのに十分ではありません。
3.2.2 パフォーマンスの監視
パフォーマンスの問題は、ほとんどのエンジニアリング サービスの問題と共通点があり、誰もがよく知っているはずです。たとえば、イベント中にトラフィックが指数関数的に増加することがよくあり、アルゴリズム サービスにパフォーマンスの問題がある場合、多数のタイムアウトが発生します。
リコール段階でタイムアウトが多数発生した場合、リコールされた製品はユーザーとの関連性がなく、結果も悪く、コンバージョン、収益、さらには天窓が開く可能性に影響を与えます。
洗練されたランキングモデルや再配置アルゴリズムで多数のタイムアウトが発生すると、オンラインアルゴリズムのボーナス効果が大幅に減少し、コンバージョンと収益に影響を与えます。
これに関連して、すべてのシナリオで、リコール時間、ファイン スケジューリング時間、再スケジュール時間、リコール タイムアウト量/レート、ファイン スケジューリング タイムアウト量/レート、再スケジュール時間の消費/レート、および前処理を監視しました。時間がかかる、パイプラインに時間がかかる、合計に時間がかかるなど。すべてのシナリオの各段階でのタイムアウトの問題がリコールされ、タイムリーに処理されます。
3.3 オンラインでのパイプラインの自動検証
さまざまなシナリオでのYanxuanの検索、推奨、呼び出し、ソート、再配置に適応するために、使用されるモデル、アルゴリズム、戦略はすべてオペレーターの概念に基づいて任意に構成および組み立てられ、構成は手動で操作されるため、モデルの推定段階では、構成エラーによってポリシーやアルゴリズムの問題が発生する傾向があり、場合によってはモデルが有効にならず、モデルの結果の品質に影響を与えます。モデルの事後効果は T+1 問題から知ることができ、問題はラグとともに知ることができるため、この段階での基本的な検証が必要です。これにより、ほとんどの戦略とアルゴリズムの問題がオンライン プロセスに影響を与えるのを効果的に阻止できます。自動検証結果をパイプラインがオンラインになるためのブロック ポイントとして使用しており、検証に合格したパイプラインのみがオンラインになります。
オンライン化前のこの段階で、戦略やアルゴリズムの有効性、バッドケースマイニングなどを検証できます。妥当性チェックでは、マルチチャネルリコールのリコールタイプ、アルゴリズムスコア、ソート前後の位置変化、ソートモデルスコア、再配置前後の位置変化などが検証されます。Badcase マイニングでは、さまざまなシナリオに応じてさまざまな自動マイニング インジケーターを構成します。
自動検証が行われる前は、パイプラインをオンラインにするための厳密なブロック ポイントはなく、学生がアルゴリズムに依存して自分で検証するため、オンラインで頻繁に問題が発生していました。また、検証にはパイプラインの構成 -> 実験の構成 -> 手動ユースケースリクエスト -> 手動検証 -> オンライン化という一連の操作が必要で、これには 1 時間以上かかります。パイプライン自動検証にアクセスした後は、「パイプラインの設定」→「自動検証」→「オンラインにする」という操作のみで、プロセス全体が分単位に短縮され、自動検証にかかる時間は 2 分未満です。このようにして、パイプラインの立ち上げ効率が大幅に向上します。
4. モデル品質プラットフォーム
モデルの品質保証の重要なポイントに基づいて、プラットフォーム アプローチを通じてテストおよびモニタリング機能を実装しました。以下にプラットフォームのデザインと表示について紹介します。
4.1 モデル品質のプラットフォーム設計
4.1.1 プラットフォームのアーキテクチャ設計
現在、バッドケース マイニング、モデル効果品質、自動パイプライン検証スタック ポイントなどの機能をアルゴリズム モデル品質プラットフォームに統合しています。
モデル評価とは、オンラインでのモデル評価のことで、元データを加工して露出コンバージョン、露出追加購入、露出クリックなどのデータを生成し、評価指標を計算・分析し、分析結果をMySQLに保存します。設定と視覚化は、プラットフォーム、監視、警報を通じて実現されます。プラットフォームの現在の評価指標には、さまざまなシナリオにおけるさまざまなモデルターゲット、オペレータータイプ、モデルバージョン、ピット位置などの AUC、GAUC、CTR、PCTR、CVR、PCVR、PCOC などが含まれます。
モデル評価モジュールは、手動マイニングや自動マイニングなどのBadcaseマイニング機能を提供し、実際のユーザーの推奨結果や検索結果を取得して計算・分析を行い、分析結果をMySQLに保存します。
モデル検証モジュールは、パイプライン起動の自動検証機能を提供し、パイプラインの有効性の自動検証結果と Badcase の自動マイニング結果を統合します。パイプラインの妥当性検証は各事業者の妥当性検証であり、Badcase miningには一致度、分散度、網羅度などが含まれます。このモジュールは、プラットフォームの各シナリオで設定された検証項目としきい値に基づいてオンラインに移行できるかどうかを判断し、ワンクリック検証をトリガーした後、コンピューティング センターが結果を計算します。
4.2 モデル品質プラットフォームの表示
4.2.1 バッドケースマイニング
「自動マイニング」インターフェースに入る -> フィルタ条件に基づいてユーザーをクエリ -> バッチでテストするユーザーを選択 -> テストするインターフェース（モデル）を選択 -> バッチリクエストデータを生成 -> リクエストデータを編集および確認 - > リクエストを送信し、Badcase dig を開始します。
マイニング レポート インターフェイス:
上部はすべてのテスト ユーザー評価指標の平均値であり、各評価指標におけるモデルのパフォーマンスの全体的な傾向を反映できます。
下部には、すべての単一テスト ユーザーの評価指標が表示されます。これにより、Badcase リスク レベルが高いテスト ユーザーを迅速に除外できます。
詳細を確認して、Badcase かどうかを手動でさらに確認し、フィードバックを提供します。
4.2.2 モデル事後効果
モデルの事後効果の計算はクライアントの埋め込みポイント データに依存しており、結合と計算の後、露出クリック、露出変換、その他のデータを取得できます。
そして、モデルの評価指標を計算により求める。現在、指標のリファインを行っている 対象モデルはクリック数、追加購入数、コンバージョン数 演算子の種類はリコール、ファインランキング、並べ替えなど 配置バージョンはオンラインで有効な全バージョンを含む ピット位置は全ピットを含むピットは複数あり、新旧ユーザーも区別される。このようにして、モデルの実際の効果が多次元で分析されます。
指標に関しては、AUC、GAUC、PCOC、CTR、PCTR、CVR、PCVRなどを優先しました。
最後に、プラットフォームの構成に応じて、異常箇所に対してタイムリーなアラームが発行されます。
4.2.3 オンラインでのパイプラインの自動検証
共同アルゴリズム統合プラットフォームは、リリース前の段階でワンクリックで自動検証をトリガーし、検証に合格した場合にのみオンラインに移行できます。
その後、テスト レポートの詳細をさらに表示して、問題を特定できます。
4.3 モデル品質プラットフォームの概要
モデル品質のプラットフォームは 1 年以上にわたって洗練され、進化し、複数の段階を経てきました。バッドケース マイニングは手動マイニングから自動マイニング、そして自動検証に進化し、モデルのポストテスト効果はスクリプト ツールの段階からプラットフォーム化に進化し、モデルのオンライン フローは手動検証からワンクリック自動検証に進化しました。厳選されたアルゴリズムモデルの品質保証の多くの側面をゼロから実現し、モデル品質保証の技術的閾値を下げ、同時に効率を向上させました。
5. 展望
モデル品質プラットフォームは、自動化、ツール化、サービス化、視覚化などの機能を実現しました。将来的には、モデルのトレーニング、モデルの評価、モデルの予測、モデルの適用の各段階で、プロセス全体の品質保証の閉ループを実現したいと考えています。
- まず、アルゴリズム モデルの品質保証の深さの観点から、特徴品質とデータ品質についてさらに深化する必要があります。
- 次に、有効性の観点から見ると、現行モデルの事後効果はT+1問題でわかっており、即日リコールできないため、有効性をさらに向上させる必要がある。
最後に、私の記事を注意深く読んでくださった皆さんに感謝します。互恵性は常に必要です。それほど価値のあるものではありませんが、使用できる場合は、直接受け取ることができます。
この情報は、[ソフトウェア テスト] の友人にとって最も包括的かつ完全な準備倉庫となるはずです。この倉庫は、最も困難な旅を乗り越える何万人ものテスト エンジニアにも同行してきました。また、皆さんのお役に立てれば幸いです。