従業員を見つけるのに役立つAIの教え方

SuperJobの主任開発者であるSergey Saygushkinが、データの準備と再開スコアリングモデルのトレーニング、本番環境での実装、品質メトリックの監視、および再開スコアリング機能のABテストについて説明します。



この記事は、RIT 2017「機械学習を使用した応募者の回答のランキング」のレポートの資料に基づいて作成されました。

リクルーターがAIを欠いているのはなぜですか？

採用担当者がSuperJobと連携する2つの基本的な方法があります。 サービスの内部検索を使用して、履歴書を確認し、適切なスペシャリストを面接に招待できます。 また、空席を投稿して、専門家のフィードバックを活用することもできます。



SuperJobの求人の15％は、1日あたり100件以上の回答を受け取ります。 応募者は、常にそのポジションに対応する履歴書を提出するとは限りません。 したがって、eycharsは適切な候補者を選択するために余分な時間を費やす必要があります。



たとえば、空席の「主要なPHP開発者」は、「1C」プログラマー、テクニカルライター、さらにはマーケティングディレクターのフィードバックを確実に収集します。 これにより、1つのポジションでも選択が複雑になり、速度が低下します。 そして、同時にリクルーターの仕事には、数十の欠員があります。



空席にまったく適さない履歴書を自動的に選択する履歴書スコアリングアルゴリズムを開発しました。 それを使用して、無関係な応答を決定し、雇用主の個人アカウントの応答リストでそれらを悲観します。 分類問題を2つのクラスに分類します。



+適切

-不適切な応答



そして、リクルーターに彼の個人アカウントのこの基準に従って回答をフィルターする機会を与えます。

夏、冬、秋、春にデータを準備します。 そしてまた-夏に

トレーニング用のデータの準備は、最も重要なステップの1つです。 あなたの成功は、この段階がどれだけ慎重に準備されているかにかかっています。 リクルーターの個人アカウントからのイベントで勉強します。 サンプルには、過去3か月間の約1,000万〜1200万のイベントが含まれています。



クラスラベルとして、履歴書拒否イベントとインタビューへの招待を使用します。 採用担当者が面接への招待なしに履歴書をすぐに拒否する場合、それはおそらく無関係です。 したがって、採用担当者が面接に招待した場合（その後拒否されたとしても）、回答は欠員に関連します。



空席ごとに、面接の招待と拒否の分布を考慮せずに確認します。したがって、拒否の数が招待の数を大幅に超える空席イベントについてモデルをトレーニングしません。 またはその逆：リクルーターが全員を連続して招待する（または連続して全員を拒否する）場合、このような空席の排出も考慮します。







X軸-面接への招待数

Y軸-空室数



グラフは、採用担当者が一般に1人の欠員に対して5〜6人の応募者を招待することを示しています。 ボックスラフトによると、招待の中央値、上位四分位数および下位四分位数を評価し、排出量を特定できます。 この例では、14人を超える求人のある求人はすべて外れ値です。





X軸-履歴書の逸脱の数

Y軸-空室数



平均して、1人の欠員について、採用担当者は8〜9人の応募者を拒否します。 また、偏差数が25を超えるすべての空室は外れ値であり、ボックスプロットに表示されます。

誰が彼の頭で働きたくない-彼の手で働く

各採用担当者向けにモデルをトレーニングした後、独自のエラーマトリックスを作成し、モデルがうまく対処できない雇用主のクラスターを見つけました。 これらの採用担当者の行動のログを分析した後、面接に招待された応募者の回答をモデルがなぜ悲観したかが明らかになりました。 これらの採用担当者は、欠員に対応していない別の専門分野からの一般的な履歴書の面接応募者に大量に招待しました。つまり、全員を連続して招待しました。 つまり、欠員は、招待された候補者の履歴書からほぼ完全に分かれました。 奇妙なことに、これらは主に無制限の関税を持つ顧客でした。 データベースへのフルアクセスを取得し、品質ではなく量を取得します。 これらのリクルーターをブラックリストに含めましたが、彼らの行動については訓練されていませんでした。 行動パターンはタスクとは異なります。



最も記憶に残る例は、モスクワ地下鉄警察の欠員でした。 採用担当者は、売り手、営業担当者、俳優などの面接に招待し、国家警備隊と警察の従業員を拒否しました。 おそらく、彼は自分の個人アカウントのインターフェースの「拒否」ボタンと「招待」ボタンを混同していたのでしょう。







キャラクター生成



このモデルは170以上の機能を使用しています。 すべての属性は、ジョブのプロパティ、履歴書、およびそれらの組み合わせに基づいています。 例には、空席の給与プラグ、履歴書の希望給与、履歴書と空室の特性の組み合わせとして履歴書の給与を空室の給与プラグに入れることが含まれます。



カテゴリ属性にバイナリコーディング（ワンホットエンコーディング）を適用します。 特定の種類の教育、運転免許証のカテゴリ、または外国語の1つに関する知識の有無に関する欠員の要件は、モデルのいくつかのバイナリ機能で明らかになります。



テキスト属性を操作します。



ストップワード、句読点、および見出し語のテキストをクリアします。 テストサインから、テーマグループを形成します。

• 履歴書からの職業の欠員と職業;
• 仕事の要件と主要な履歴書スキル。
• 欠員の職務および申請者の以前の勤務地からの職務。

グループごとに、TF-IDF Vectorizerをトレーニングします。 職業の全リスト、すべての職務要件、履歴書スキルなどについてベクトライザーをトレーニングします。 たとえば、求人の職業と応募者の経験からの職業との類似性などの特徴があります。 各フレーズに対して、tf-idfベクトルを取得し、ベクトルのスカラー乗算により別のフレーズのベクトルとのコサイン類似度（ベクトル間の角度のコサイン）を計算します。 したがって、2つのフレーズの類似性の尺度を取得します。



フィーチャを生成するプロセスで、SuperJob Research Centerと相談しました。 候補者を招待するか拒否するかを決定する最も重要な兆候を特定するために、採用担当者向けの調査が開始されました。



結果は予想されます。採用担当者は、すべての企業での仕事の経験、最後の場所での仕事の期間、平均の仕事の期間を調べます。 履歴書からの望ましい位置が候補者にとって新しいものかどうか、つまり 彼が以前にこの職業で働いていたかどうか。 モデルの特性をコンパイルするときに、調査データを考慮しました。



標識の例：

• 1か所での平均作業時間（月単位）。
• 最後の場所での作業の月数。
• 必要な空室経験と履歴書からの経験の違い;
• 希望の履歴書給与を空室の給与プラグに入れる。
• 希望する位置と以前の職場との類似性の尺度。
• 教育の専門性と欠員の要件間の類似性の尺度。
• 履歴書の評価（完全性）。

疑わしい場合は、xgboostを使用します

分類問題を解決するために、xgboost勾配ブースト実装を使用します。



モデルのトレーニング後、重要な理由で統計を収集することができました。 予想される重要な兆候の中には、仕事の経験、給与の特徴、履歴書から希望の給与を空席の給与プラグに入れること、仕事の職業と求職者の仕事の経験の類似性の尺度、仕事の要件と重要な履歴書のスキルの類似性がありました。



印の一番上には、申請者の年齢もありました。 応募者を差別したくないため、実験を行うことにし、この機能を削除しました。 その結果、年齢と明らかに相関する「卒業からの年数」という特徴がトップになりました。 この症状を取り除き、モデルを再トレーニングしました。 年齢に伴うすべての操作の後、モデルの品質指標が少し落ち込んだことがわかりました。 その結果、年齢を戻すことにしました。 マスセレクションでは、彼はリクルーターにとって本当に重要です、彼らは彼に注意を払います。 ただし、回答が関連するものに少しでも届かない場合は、高齢者のスコアポイントを補償します。 彼の履歴書を悲観したのは、申請者の年齢であったと信じています。



モデルのトレーニング、機能の準備を数回繰り返した後、優れた品質メトリックを備えたモデルが得られました。



ROC曲線は、真陽性の分類のシェアが偽陽性の分類のシェアに依存していることを示しています。 また、roc曲線の下の領域は次のように解釈できます。auc-rocは、ランダムに取得されたクラス1オブジェクトがランダムに取得されたクラス0オブジェクトよりも高い評価を得る確率に等しくなります。



このモデルにとどまらず、新しい実験を行います。 現在、doc2vecを使用して専門職の同義語のリストに記入し、履歴書の専門職が空席の専門職に対応するという事実をより正確に判断し、リードPHP開発者とシニアPHP開発者がモデルの異なる専門職ではないように取り組んでいます。 また、重要な仕事のトピックと履歴書を取得するために、BigARTMライブラリを使用したテーマ別モデリングの作業が進行中です。



また、関係のない適切な履歴書をできるだけ少なくする必要がありました。 第2種のエラーまたは偽陰性の応答の数を最小限に抑える必要があります。 これを行うために、関連するクラスに属するしきい値確率をわずかに減らしました。 したがって、FNエラーの数が削減されました。 しかし、これには逆の効果がありました。FPエラーの数が増加しました。



Flaskフレームワークでは、RESTスコアリングAPIを使用して小さなマイクロサービスを実装し、Dockerコンテナーにパックして、このタスク専用のサーバーにデプロイしました。 uWSGI Webサーバーは、マスタープロセスと24のワーカープロセス（コアごとに1つ）を持つコンテナーで起動されました。



ユーザーがサイトの空きに応答すると、この事実に関するメッセージがrabbitmqキューに入ります。 キューハンドラーはメッセージを受信し、データ、ジョブオブジェクト、再開オブジェクトを準備し、スコアリングエンドポイントAPIを呼び出します。 さらに、スコアリング値はデータベースに保存され、個人アカウントのリクルーターによる応答の後続のフィルタリングに使用されます。



最初は、個人アカウントに連絡するときにオンラインスコアリングを直接実装したいと考えていましたが、一部の空席への応答数と、モデルが1組の履歴書欠員に取り組んだ合計時間を見積もって、非同期モードでスコアリングを実装しました。



スコアリングプロセス自体には、約0.04〜0.05秒かかります。 したがって、現在のハードウェア上のすべてのアクティブな応答のスコアリング値を再計算するには、約18〜20時間かかります。 一方で、これは大きな数字ですが、一方で、新しいモデルが生産に導入された場合にのみ、スコアリングを非常にまれに数えます。 そして、現時点でこの問題があれば、なんとか生きることができます。



スコアリングサービスの最大の負担は、空席に対応する応募者ではなく、「再開登録」メールサービスです。 このサービスは1日に1回アクティブ化され、求人者に求人者を募集しています。 当然、リクルーターに関連する回答のみをアドバイスするために、サービスの結果もスピードアップする必要があります。



その結果、作業のピーク時には、1秒あたり1000〜1200のリクエストを処理します。 スコアリングする必要がある応答の数が増加した場合、別のサーバーを近くに配置し、スコアリングサービスを水平方向にスケーリングします。

モニタリング

個人アカウントの実際のデータでモデルの品質指標を継続的に評価するために、jenkinsで監視タスクを設定します。 このスクリプトは、招待と拒否に応じて1日数回verticaからデータを収集し、これらのイベントに対するモデルの動作を監視し、メトリックを計算して監視システムに送信します。



また、個人アカウントの同じデータで異なるスコアリングモデルのメトリックを比較することもできます。 すぐに新しいモデルを導入するのではなく、最初に実験モデルですべての応答を高速化し、スコアリング値をデータベースに保存してから、グラフで実験モデルがより良いか悪いかを確認します。



グラフは私たちの生活を落ち着かせ、得点の質は変わらず、すべてのステージが通常どおり機能することを確信しています。

アカウントでの実装

特定の欠員に対する応答のリストに、適切な応答と不適切な応答の2つのタブが表示されました。 例として、同じ欠員はSuperJobの主要なphpプログラマーです。 PHPプログラマの履歴書は、たとえリーダーやシニアでなくても、PHPの知識を持つフルスタック開発者の履歴書には正しい反応がありました。

ABテスト

スコアリング機能を実装した後、採用担当者に対してabテストを実施しました。

テストでは、次のメトリックを選択しました。

• 提出された履歴書の招待への変換- 影響8.3％
• 招待された履歴書の数- 影響6.7％
• 空室から閉店への変更- 影響6.0％
• 求人の数- 影響5.4％
• 空室閉鎖までの日数- 影響7.7％

5％の有意水準でこのテストを実行しました。つまり、第1種の間違いまたは誤検知が5％発生する可能性があります。



アブテストの後、スコアリング機能を備えたオプションに陥った採用担当者からフィードバックを収集しました。 フィードバックも好意的でした。 彼らは機能を使用し、大量選択に費やす時間を短縮します。

結論

最も重要なことは、トレーニングサンプルです。

モデルの品質指標を監視します。

random_stateを修正します。