検索が適切に機能するためには、メトリックのシステムが非常に重要です-ローカル、A / Bテスト、製品でのキューなど。このシステムには個別の注意とリソースが必要です。 クールなMLを切り裂いて「テープ」でこれらすべてのメトリックを固定するだけで十分だと考えるのは間違っています。 既に実行中のシステムの作業の品質を測定するだけでは不十分です。MLを使用するかLuceneが「そのまま」であるかはそれほど重要ではありません。
旧式のソリューションが私たちにとって時代遅れに見えたからでも、MLがスタイリッシュでファッショナブルで若々しいからでもありませんでした。 古い検索には、長期的な実験に着手する前に変更の利点を測定できるローカル品質メトリックがありませんでした。 さらに、継続的な改善のプロセスを編成するために何を変更し、測定するかが明確ではありませんでした。
MLで検索システムを構築し始めたとき、すぐにローカルメトリックのシステムを提供しました。 開発プロセス中に、MLでの新しい検索の品質と、応答の可能性を予測するモデルの速度、および要求と空室のテキストマッチングのみを使用したキーワードによる古い検索の品質を比較しました。 このため、通常のローカルメトリック、MAP、NDCG、ROC-AUCを使用しました。 さらに、このプロセスでは、A / Bテストのメトリックとコホートの数を増やし、自動テストで新しい検索をカバーしました。 この記事では、推奨モデルの品質をどのように監視するかについて説明します。HeadHunterエクスペリエンスは、MLに基づいて構築されているかどうかはそれほど重要ではないため、あなたにとっても役立つ可能性があります。
統計的検定
まず、ローカルMAP、NDCG、ROC-AUCメトリックを使用してモデルの品質の測定を開始し、キーワード検索からMLベースの検索への移行による大幅な改善に気付きました。 これは、LuceneまたはSphinxに基づく従来の検索では、ターゲットアクションの確率を予測してランク付けする方法がわからないという事実によって説明されます。 たとえば、欠員や応募者の履歴書に示されている給与の役割を考慮する方法がわかりません。 履歴書の重要なスキルと職務要件を関連付けず、単語を比較する際にセマンティック接続を考慮しません。 Luceneでのテキストマッチングの速度をMLを使用して選択されたモデルの速度と比較し、応答と招待の確率によるランキングとフィルタリングを提供する場合、これは検索品質メトリックで確認できます。
| メートル法 | キーで検索します。 によると | ML検索 |
| ROC曲線の下の領域 | 0.608 | 0.717 |
| 平均平均精度 | 0.327 | 0.454 |
| NDCG | 0.525 | 0.577 |
ローカルメトリックの値は、製品の値と、これらのローカルメトリックがどの程度正確に測定されるかを予測できます。 たとえば、相互検証中に時間とユーザーによる分割の分割に切り替えると、メトリック値は減少しましたが、A / Bテストの将来の変化をより正確に予測し始めました。
過去1年間で、検索と推奨の品質が向上したため、アプリケーション、モバイルサイト、およびデスクトップでの検索セッションの成功率が平均22％増加しました（グラフの失敗は年末年始です）。
自動テスト
単体テストと煙テストの対象範囲を拡大した後。 たとえば、高頻度クエリ（[accountant]、[driver]、[administrator]、[manager]）のスモークテストと、参照データベースからの参照ユーザー履歴書を使用したモデルの動作を確認します。したがって、リリースするたびに、検索を中断せず、「セールスマネージャー」のリクエストには関連する欠員があり、最初のページにはプロジェクトマネージャーの欠員などの欠員はありません。
A / b
A / Bテストシステムの主な目的は、制御と意思決定です（新しいモデル、インターフェイスなどを展開するかどうか）。 制御する（既に動作しているモデルの品質を確認する）ために、古いモデルが実験として含まれている場合にリバーステストを実行します。 したがって、現在のモデルが古いモデルよりも優れていることを確認できます。
かなり長い間、独自のA / Bテストシステムを使用しています。 たとえば、MLでアルファ版の推奨の最初のリリース後、推奨の成功が30％増加したことがわかりました。 ちなみに、A / Bテストシステムの品質と、 記事で個別に使用されているメトリックを調べました。
性能
ただし、ローカルメトリックまたはA / Bテストでの新しいモデルの「勝利」は、このモデルが製品で機能することを意味するものではありません。モデルはリソース集中型であり、負荷の高いサイトであるhh.ruでは完全に受け入れられません。 リソースの強度を測定するために、ドキュメントの速度を計算するすべての段階を監視しました。
グラフは、各段階で検索に費やした時間を示しています。 新しいモデルは重すぎることが判明しました。ロールバックし、機能を最適化し、計算量の軽いものを展開する必要がありました。
その他の指標
検索および推奨システムの最も重要なタスクは、ユーザーが応答する可能性が最も高い空席の選択です。 求人への回答数を増やして、人々がより早く仕事を見つけられるようにしたいと考えています。 したがって、CTRと成功した検索セッションの数に加えて、検索の最も重要な指標は、空席に対する回答の絶対数でした。 新しいモデルの導入により、回答数が急激に増加し始めました。現在、1日平均hh.ruで、ユーザーは空席に対して600,000件以上の回答を行っています。 これは変動インジケータです。100万件を超える応答を記録する日があります。 また、候補者をお気に入りの候補として追加したり、たとえば、提案された空室の連絡先を表示したりすることの成功を検討することもできます。
この話の終わりに、少し離れて、新しい検索を作成するときに思いついたもう1つの結論を述べたいと思います。品質は測定するには十分ではありません。最初に製品に組み込む必要があります。 わかりやすいメトリックに加えて、これはタスクの正しい設定によって促進されます。そのため、タスクをやり直す必要がないように、適切な計画を立てることで、緊急事態のない静かな作業、チームに対する慎重な態度、アイデア、時間を確保できます。 これらの条件では、測定するものがあります。