求人のレベル判定に関する実験まとめ

はじめに

こんにちは、LAPRAS Researchチームの池・森元です。LAPRASでは最近、転職活動支援の一環として新機能のJOB LISTや転職支援サービスのLAPRAS CAREER β版をリリースしています。これらに伴い、私たちResearchチームでは、人と求人のマッチングアルゴリズム開発に注力しています。

人と求人のマッチング時には転職希望者と求人のレベル感をマッチさせる必要があります。どの軸でどのように比較をするかの定義は明確にはなっていません。考えられる軸としては、経験年数やポジション、スキルセット、年収などが考えられます。

そこで、エージェント経験のある社内メンバーへのヒアリング時の「年収はレベル感を示す」という情報を元に求人の年収レンジでレベルを定義できないかと考えました。

実データを見ると求人の年収情報には以下のような問題がありました。

  • 年収値が記載されていない求人が数多く存在する
  • 年収値が記載されているが、年収レンジが広く設定されており求める人材のレベルがわからない
  • 記載された年収値が適切でない

上記の問題があるため、年収が記載されていない求人のレベルの判定が必要になってきます。そこで私たちは検証の第一歩として求人の必須条件、歓迎条件から求人のレベル感を予測できないかを実験しました。

実験内容

求人レベル=ラベルの定義

今回は1642件の求人データに対し、以下のように年収の範囲でラベルを定義し、付与しました。また予測に用いる情報として、求人の募集ポジションの必須条件・歓迎条件に当たる文章を用いました。

ラベル付与状況とデータ量は以下のような分布になります。

年収範囲 ラベル データ量
~ 350万 0 150
350万 ~ 450万 1 696
450万 ~ 550万 2 543
550万 ~ 650万 3 226
650万 ~ 750万 4 69
750万 ~ 5 32

データの前処理

今回は以下のデータ前処理を行いました。

  • 必須条件・歓迎条件文の統合
  • MeCabの形態素解析によるトークンの抽出 (品詞は名詞・動詞・副詞・形容詞に限定)
  • ストップワードの削除

実験モデル

今回の実験では大きく3種類のモデルを用いて比較を行いました。

  • ロジスティック回帰モデル
  • Bi-LSTMモデル
  • BERTモデル

1. ロジスティック回帰モデル

実験モデルの1つ目、tf-idf+ロジスティック回帰を用いてモデル構築しました。今回は求人情報のうち、必須条件、歓迎条件に当たる文面を合わせて求人文章とみなし、各求人文章の特徴を表す単語と該当tf-idf値を特徴量として使います。

tf-idf:
tf-idfとは文書中に含まれる単語の重要度を評価する手法の1つです。tf-idfは、tfとidfの二つの指標に基づいて計算されます。「tf」は(Term Frequency)の略で「単語の出現頻度」と呼ばれます。「idf」は(Inverse Document Frequency)の略で「逆文書頻度」と呼ばれ、いろいろな文書に出現する場合低く、少数文書にしか出現しない場合は高くなります。

tf,idfはそれぞれ以下の式から得られます。

$$tf\left(t_i, d_j\right)=\frac{文書d_j内の単語t_iの出現回数}{文書d_jのすべての単語の出現回数の和}$$

$$=\frac{f({t_i}, {d_j})}{\Sigma_{t_k \in d_j}f\left(t_k, d_j\right)}$$

$$idf(t_i)=log\left(\frac{総文書数}{単語t_iが出現する文書数}\right)=log\left(\frac{N}{df(t_i)}\right)$$

tf-idfはtfとidfをかけ合わせたものになります。

$$tfidf(t_i,d_j)=tf(t_i,d_j) \cdot idf(t_i)$$

ロジスティック回帰モデル:
ロジスティック回帰はベルヌーイ分布に従う変数の統計的回帰モデルの一種です。ロジスティック回帰分析を用いれば必ず予想結果が0から1の範囲に収まるので、確率を予測、分析したいときなどに用いられます。確率については、以下の計算式で算出できます。

$$e=\frac{1}{1+exp^{-\left(b_1\cdot x_1+b_2\cdot x_2+...+b_0\right)}}$$

\(b_i\)は偏回帰係数と呼ばれる数値です。\(x_i\)にはそれぞれの説明変数が代入されます。\(b_i\)は最尤法(さいゆうほう)という方法で求めることができます。

2. Bi-LSTMモデル

2つ目のモデルは、word2vecとBi-LSTMを用いてモデル構築しました。

今回のタスクでは、事前学習済みのword2vecモデルで単語の意味をよりよく捉えてあろう単語分散表現を得た上で、Bi-LSTMを用いることで文章の前後情報を学習します。こちらにより求人レベルを表す情報が単語ではなく、文章前後に渡って含まれている場合、該当情報を学習することが可能になります。

word2vec:単語の埋め込みを生成するために使用されるモデル群をさします。詳しくはこちら:https://arxiv.org/abs/1301.3781

Bi-LSTM:LSTM(Long Short-Term Memory)という時間軸を保持して学習するRNN(リカレントニューラルネットワーク)技術の一種を用いています。RNNとは記憶を持つニューラルネットワークと表現され、LSTMもRNNから発展した一つです。このLSTMは過去から現在方向の一方向のみの処理をしていますが、Bi-LSTMは双方向から処理を行います。

3. BERTモデル

3つ目のモデルはBERTを用いたモデルです。今回は、BERTとBERT日本語学習済みモデル、求人情報の「歓迎条件」、「必須条件」をコーパスとして使用して、学習済みモデルのfine-tuningと求人レベルの多値分類を行います。BERTもBi-LSTMと同じく文章前後の関係情報を捉えていますが、仕組み上Bi-LSTMより長距離の関係情報をとることが可能です。よって、BERTモデルを使うことでより長い文面を考慮しながら求人レベルを判定することになります。

BERTとは、「Bidirectional Encoder Representation from Transformers」の略でTransformerによる双方向エンコード表現と訳され、GoogleのJacob Devlinらによって発表された自然言語処理モデルです。BERTは、文章を双方向から読むことによって”文脈を読む”ことを可能としています。

実験結果と考察

ロジスティック回帰、Bi-LSTM、BERTの3つのモデルによる求人レベル予測タスクの結果をまとめます。

精度比較

各モデルの精度(Accuracy)を以下に示します。

手法 Accuracy AUC F1
ロジスティック回帰 0.58 0.8 0.57
Bi-LSTM 0.35 0.61 0.33
BERT 0.4 0.68 0.27

テストデータに対して求人のレベル判定を行った結果、tf-idfを用いたロジスティック回帰法が一番良い精度となりました。また、一番良い精度でも0.58と低い水準となっています。

この結果から以下のようなことが推測されます。

  • 今回用いたデータ量が少なく十分な学習がされなかった
  • そもそも求人情報の必須条件、歓迎条件と求人レベル間には相関がない可能性がある

また、予測精度が ロジスティック回帰 > BERT > Bi-LSTMという順になっていることから、文書内の文脈情報は求人レベル判定においては重要ではないということが言えそうです。この結果は、求人の必須条件と歓迎条件が箇条書きで羅列する形式で記載されていることが多い点を考えるとある程度納得のいく部分だと考えられます。

文書全体の文脈は重要ではなさそうですが、箇条書きの各項目内の文脈を考えると短文の文脈情報はある程度利用できるのではないかという仮説が得られました。そこで私たちは追加で短文の文脈情報を取り入れる実験をしてみました。

追加実験:予測の内訳

短文の文脈情報の影響を調べるために、tf-idfの計算対象になるトークンの長さ(n_gram)を調整してその結果比較をしました。

トークンの長さがn=1の場合は各単語を対象にtf-idf値を計算することになり、n=2の場合は各単語と文章中の連続した二つの単語からなるトークンを対象にtf-idf値を計算することになります。トークンの長さが長い(nが大きい)ほど広い範囲の文の意味的情報が考慮できます。

n_gram Accuracy AUC F1
1 0.5 0.78 0.5
2 0.55 0.8 0.55
3 0.58 0.8 0.57
4 0.56 0.81 0.55
5 0.57 0.8 0.56

結果、トークンの長さがn=3の場合に一番良い精度となることがわかりました。これは実際の箇条書きで書かれている求人条件を考えた時に妥当でありそうだと考えられます。

以下に例として、一部変更を加えた求人の必須条件と長さn=3のトークンを示します。

例
【必須スキル・経験】
・UI/UXデザインの経験3年以上
 ・プロトタイプの作成経験
【歓迎スキル・経験】
・業務要件からワイヤーフレームを起こした経験
・システム要件定義の経験 
・経営に関するコンサルティングの経験

上記のような必須条件・歓迎条件では、トークンの長さn=3の場合、「デザイン 経験 3年」、「用件 定義 経験」のようなトークンが得られていました。これらのトークンによって求める人材のレベルを表す情報を掴むことができ、これが精度向上に繋がったのではないかと考えられます。

問題発見のためのモデル分析

上記までに求人情報のレベル判定モデルが作れました。ただし、予測精度は0.58とそんなに高くないモデルになっています。モデルの予測結果と分類に役立った特徴量を調べることで精度が低い理由やモデルの予測力を詳しくみていきます。

予測結果

上記ベスト精度を出しているモデルのテストデータでの予測結果を以下に示します。

Accuracy: 0.58
Auc: 0.8
weighted f1_score:  0.57
Detail:
              precision    recall  f1-score   support

           0       0.59      0.42      0.49        31
           1       0.56      0.69      0.62       129
           2       0.60      0.58      0.59       117
           3       0.62      0.52      0.57        44
           4       0.57      0.25      0.35        16
           5       0.25      0.14      0.18         7

accuracy                            0.58    344
macro avg    0.53   0.43    0.47    344
weighted avg    0.58    0.58    0.57    344

結果から見ると、ラベル5 (年収750万以上)の求人に対するprecision, recallが他に比べて低いことがわかります。

ラベル5のテストデータを見ると以下の問題がわかりました。

  • ラベル5のトークンには相応するトークンがほとんどない
    例: Java C C++ C# JavaScript PHP Ruby Laravel Ruby on Rails React Anguler Vue js Web エンジニアなど技術用語リストからなる求人にラベル5がつけられていた

  • レベル感と全く関係のないトークンが含まれているのにラベル5と予測されている
    例: トークン:「プロジェクト 推進 コンサルタント」を含む求人がラベル5と判定される

前者に関して調べた結果、高いレベルの求人も低いレベルであると判定されるのは以下が原因で有用な情報の損失が発生していることがわかりました。

  • 私たちの用いる求人データはクローリングした求人ページからパージングを行い必須条件・歓迎条件を取得しています。この時にうまくパージング出来ておらず部分的な情報しか取れていないデータが多数あることがわかりました。その結果、異なる給与レベルの求人なのに同じトークン情報をもつようになっているということもわかりました。

一方、後者は(同じ会社、違う勤務地、同じ求人内容)、(同じ会社、違う媒体、同じ求人内容)のデータが多数存在していて結果的にレベルとは関係ないトークンを持っているものの、学習データとテストデータに同じデータが入っているため正しく判定されたのが原因でした。

上述の原因分析から、ノイズの影響を減らすために、

  • 必須条件・歓迎条件のトークン数が一定数以下の求人を除外
  • (同じ会社、同じ求人情報)を除外

といった処理を行い、モデルを再構築しました。

結果、以下のように全体的な精度向上が得られました。特にラベル5の求人の場合、precision, recall両方の向上がみられました。ただし、ラベル0, 3の場合、recallの減少が起きているので、データの更なるノイズの調査やクレンジングが必要になりそうです。

Accuracy: 0.61
Auc: 0.82
weighted f1_score:  0.6
Detail:
              precision    recall  f1-score   support

           0       0.67      0.38      0.48        21
           1       0.60      0.77      0.68       128
           2       0.62      0.58      0.60        91
           3       0.57      0.38      0.45        32
           4       0.50      0.27      0.35        11
           5       1.00      0.40      0.57         5

    accuracy                           0.61       288
   macro avg       0.66      0.46      0.52       288
weighted avg       0.61      0.61      0.60       288

特徴量によるモデル学習の確認

各ラベルの分類にポジティブな影響があった特徴量を10件ずつ取得し、一覧を見てみます。これにより学習がうまく行っているのかどうかを確認でき、各ラベルにおいて大事な単語が見えてきます。

ラベル ポジティブ特徴量一覧
0 (~350万) 1年, 経験 1年, 1年 以上, 経験 1年 以上, プログラマー, ある, システムエンジニア, ネットワーク, 開発 経験 1年, 開発 経験 1年 以上
1 (350万~450万) 営業, 実務 経験, 経験 持つ, 向け, 開発 実務, php, 経験 2年, 実務, 開発 実務 経験, 経験 2年 以上
2 (450万~550万) 開発, 開発 経験, 構築 経験, 管理, 環境, qa, られる, 能力, ブロックチェーン, 技術
3 (550万~650万) フロントエンド, sre, プログラミング 経験, 運用 経験, 用いる web アプリケーション, 知識 経験, 経験, 用いる, チームリーダー, 経験 チームリーダー
4 (650万~750万) 情報セキュリティ, マネジメント, マネジメント 経験, 経験, 開発 責任者, 実践 経験, isms, aws gcp, メンバー マネジメント, システム
5 (750万~) 法務, 組織, エンジニア 組織, マネージャー, 訴訟, レベル, 開発 マネージャー, ビジネス, マネジメント, anguler

上記はラベル毎に重要な特徴量の一覧ですが、それぞれのラベルに相応な単語が現れています。例えば、ラベル0に経験 1年 以上、ラベル3に運用 経験チームリーダー、ラベル5にマネーシャーなどのレベルを表す単語が含まれています。この傾向から学習が確実に行われていることがわかります。

しかし、ラベル1にphpがあったり、ラベル3にフロントエンドがあったりなどレベル感とは関係のない技術用語やポジション名が入っていることもありました。理由としてはデータ量が少ないため、学習データの傾向に偏った汎用性の足りないモデルが構築されたからではないかと考えられます。

まとめ

今回用いたデータでは、tf-idfを用いたロジスティック回帰モデルが最もAccuracyが高く、n_gram, max_lengthsを適切に大きくすると精度が上がるという結果となったことから、共起単語の情報が求人文書の分類にとって重要な情報であることが考えられます。一方で求人の必須条件、歓迎条件が箇条書きになっていることが多く、あまりにも長い情報を考えようとすると逆に精度が下がることもわかりました。

また、モデルの予測結果と特徴量をみた結果、学習データのノイズとデータ量が更なる学習のネックになっていることがわかりました。よって、モデルを実応用可能なレベルまで構築するには、更なるデータクレンジングやデータ量の増加が必要になることがわかりました。

最後に、実験内容でも記述しましたが今回は簡易的に全求人を年収によるしきい値から、レベルのラベルを付与してデータを作成しました。しかし、ポジションによって年収レンジが異なることもわかってきており、今後レベル感を判定する要素を特定する検証を進めていく方向性も必要であると考えています。

おわりに

今回、結果として得られたレベル感判定のモデルの精度はまだ実用段階にはありませんでした。まとめにも記述しましたがそもそもの年収をレベル感として定義してよいのかという疑問点も残したままです。今後私たちはエージェントの知見を分析して、レベル感を判定する要素の特定や素性・パラメータ調整などを続けてレベル感判定の精度を上げて行きます。

また、今回は求人側のレベル感判定に関する紹介をしましたが、マッチングには求人側だけでなく転職希望者側のスキルレベルなどを測る必要もあります。そちらに関してもエージェントとの連携やLAPRASポートフォリオ等を用いて検証を進めていく予定です。今後も私たちは最善なマッチングを実現できるように様々な視点でのマッチングの実験・検証を続けていきます。