モデルより先に考えたデータ

AI 推薦 システム、モデルより 先に 検討した のは データでした

-バンジャンノート プロジェクトで モデル別の データ 要件と フィルタリング 基準を 検討した 経験-

1. 最初からモデルを選ばなかった理由

AI推薦システムを準備すると聞くと、協調フィルタリングやディープラーニングモデルをまず思い浮かべることが多いでしょう。私もどのような推薦方法を使えるのかに関心がありましたが、バンジャンノートプロジェクトで最初に確認したのは、アルゴリズムではなくデータでした。

当時は、推薦に活用できる行動履歴や学習データが蓄積されていませんでした。職種、経験、給与のようにサービスで入力してもらえる項目は考えられましたが、ユーザーが実際にどの対象を選び、どのような結果につながったのかを示す記録はまだありませんでした。結局、モデルを学習させたり、性能を比較したりするための根拠が不足していました。

この状況でモデルを一つ先に決めてしまうと、そのモデルが要求するデータを後から収集しなければならないかもしれません。反対に、データを手当たり次第に保存すると、実際の学習に必要な区分や文脈が抜け落ちる可能性があります。そこで、取り組む順序を変えました。現在確保できる項目を確認したうえで、複数の推薦方法が求めるデータを比較し、サービスの初期段階で何を記録すべきかから検討しました。

「今 どの モデルが 最も 優れているか？」よりも「後で モデルを 比較できる ように するには 今 どの データを 残しておく べきか？」が 先でした。

この記事は、推薦モデルの実装結果や性能を紹介するものではありません。現在、データ収集を準備する過程で私が検討した推薦方法、必須条件の処理について下した判断、そしてデータ構造を考える中で見つかった技術的な問題を共有することを目的としています。

2. 推薦モデルをデータの観点から比較してみました

推薦方法によって、必要な情報の形式は異なります。プロフィールの属性を比較する方法、複数のユーザーの行動パターンを比較する方法、実際のリクエストや承認の結果を学習する方法では、データが生成される場所からして異なります。そのため、アルゴリズムの一般的な長所や短所よりも、バンジャンノートでどのようなデータがあれば機能するのかを基準に検討しました。

属性ベースの推薦：保有している情報がそのまま好みとは限らない

職種や経験のような構造化された値は比較しやすい一方、こうした情報だけで「誰をより好むか」を説明するのは困難です。たとえば、最低経験年数の条件を二人とも満たしている場合、経験年数がより長い人が必ずより頻繁に選ばれるかどうかは、データがなければ判断できません。

そのため、基本プロフィールに加えて、役割や仕事の進め方、協働環境に関する好みなどの追加項目を検討しました。アンケートを活用して、こうした情報を選択式で収集する方法も検討しました。ただし、アンケートの回答はユーザー自身が表明した好みであり、実際の行動に基づく正解データとは区別する必要があります。好みだと答えた条件が実際の選択につながるかどうかは、後から確認しなければならないためです。

協調フィルタリング：ユーザー数が多いだけでは不十分です

協調フィルタリングは、特に検討してみたい手法の一つでした。複数の担当者が似たような班長に関心を示したり、リクエストしたりするパターンがあれば、プロフィールだけでは明らかにならない類似した好みを活用できる可能性があります。そのためには、「どの担当者がどの班長とやり取りしたか」を結び付けられる履歴が必要です。

ここでユーザー数より先に考えたのは、インタラクション行列の密度でした。行を担当者、列を班長と考えると、初期段階ではほとんどのセルが空欄である可能性があります。特に、新しい班長や新しい担当者には履歴がなく、同じ対象とやり取りした記録が少なければ、似た好みを推定するのも困難です。

また、リクエストが発生した記録は関心の表れと解釈できる可能性がありますが、リクエストの記録がないからといって、関心がなかったと断定することはできません。候補を一度も目にしていなかった可能性もあるためです。このように、協調フィルタリングに使う行動データをどのような意味に解釈するかも念頭に置いて、収集項目を検討しました。実際に適用するかどうかは、まだ決めていません。

教師あり学習：一つの「正解」にまとめられない行動

ロジスティック回帰やXGBoostのような教師あり学習ベースのランキングモデルも候補として考えました。この場合、求人情報と班長の特徴を特徴量にし、その後に発生した行動をラベルとして構成できます。問題は、どの行動を予測すべきかということでした。

担当者がリクエストするかどうかを予測する場合と、リクエストを受けた班長が承諾するかどうかを予測する場合は、別々の問題です。リクエストを受ける可能性が高い人が、承諾する可能性も高いとは限りません。実際のマッチング結果だけを保存すると、この二つの段階のどちらが影響したのかを区別するのも困難です。

そのため、教師あり学習モデルをあらかじめ一つに決めるのではなく、リクエスト、応答、最終結果を分けて記録すれば、今後、データの分布や量に応じて予測目標を比較できると判断しました。モデル候補を検討しながら、まずデータ収集について考えたのはこのためです。

3. 必須条件は推薦スコアで扱わないことにしました

複数のモデルを検討する中で、一つだけ比較的はっきりと決められたことがありました。職種、最低経験年数、給与のように必ず満たす必要がある条件は、ランキングモデルに任せるのではなく、事前にフィルタリングで処理すべきだということです。

たとえば、職種が異なる候補や最低経験年数を満たさない候補は、ほかの特性がどれほど優れていても、推薦可能な候補ではありません。こうした条件を重み付けスコアに含めると、ほかの要素で高い点数を獲得し、必須条件を満たさない候補が上位に表示される可能性があります。これは推薦品質以前に、サービスの制約条件を守れないという問題です。

そこで、全候補の必須条件を確認して推薦可能な集合を作ったうえで、残った候補の順位をランキングで決めるという形に役割を分けました。フィルタリングは「推薦可能かどうか」を判断する段階であり、ランキングは「推薦可能な候補のうち、誰を先に表示するか」を判断する段階です。

この決定は、特定のモデルを選択したという意味ではありません。協調フィルタリングであれ、属性ベースの方式であれ、教師あり学習によるランキングであれ、必須条件によるフィルターは同じように適用できます。逆に、フィルターを通過したからといって、候補の推薦順位が自動的に決まるわけでもありません。

必須情報が欠けていて条件を満たしているか判断できない場合も、単純に通過扱いにしてはいけません。こうした例外をどのように確認し、処理するかは、実際のフィルター実装段階で別途定めるべき検証基準です。設計レビューの過程で、モデルより先にドメインの必須条件を確定させる必要があることが明確になりました。

4. モデルを考えると「何を記録するか」が変わりました

モデル候補を検討し、フィルタリングの役割を切り分けた後は、データの項目を単純に増やすのではなく、それぞれのデータがどのような問いに答えられるかを中心に考えました。現在、これらの項目は実際の収集に向けて検討しているものであり、運用DBにすべて反映済みというわけでも、収集が完了しているというわけでもありません。

プロフィールとアンケート：特徴量になり得る情報か？

職種、経験年数、給与といった基本項目はフィルタリングに必要です。将来的には、必要な経験年数と実際の経験年数の差、提示給与と希望給与の差などに変換し、モデルの入力値として使用する可能性もあります。ただし、入力に使用できることと、実際に予測力があることは別です。

希望に関するアンケートも同じ観点から検討しました。すべてのユーザーに長いアンケートへの回答を求めるのではなく、まず、基本プロフィールでは説明しにくい違いを補えるかどうかを考える必要があります。同じ現場でも担当者の役割や運用方法は異なる場合があるため、作業方法や協業に関する希望が意味のある特徴量かどうかを検討します。実際に有効な情報かどうかは、データが蓄積された後に確認する必要があります。

表示・選択・応答：同じ行動として記録してはいけません

行動データでは、「記録がない」という事実が何を意味するかが特に重要でした。ある候補が依頼されなかった理由は、好まれなかったからかもしれませんが、そもそも推薦リストに表示されなかったからかもしれません。また、サーバーがリストを生成した事実と、画面上で候補が実際に表示された事実も区別する必要があります。

そこで、最終的に依頼されたかどうかだけを保存するのではなく、推薦が生成された記録、候補が表示された記録、依頼した記録、依頼に対する応答を相互に関連付けられるようにすることを考えました。表示順位も併せて残す必要があります。同じ候補でも、上位に表示されるか下位に表示されるかによって、選択される機会が変わる可能性があるためです。

たとえば、過去の依頼履歴だけを見て「依頼しなかったので、好んでいなかった」とラベル付けすると、学習データに誤りが生じる可能性があります。班長が実際には依頼を受けていないケースを「断った」と扱うのも同様です。後でモデルを学習する際に負例を定義するには、少なくとも、何が観察された行動で、何が観察されていない状態なのかを分けられる必要があります。

推薦時点の状態：後から変わった値で過去を説明することはできません

ユーザープロフィールや募集条件は、時間の経過とともに変わることがあります。現在保存されている経歴や希望給与だけを基に数週間前の推薦を分析すると、当時実際に使われた値とは異なる値で結果を説明してしまうおそれがあります。そのため、推薦時点で適用された条件やポリシーを再現できるかどうかも、検討項目に加えました。

すべての値を重複して保存するのか、変更履歴をバージョン管理するのかは、実際の保存構造に合わせて決める必要があります。しかし、どの方法を選んでも、推薦時点のFeatureと後から発生したLabelを正しく結び付けられる必要があるという原則は同じです。この点は、モデル構造よりも先にデータの意味を整理すべきところでした。

5. 今決めたことと、まだ決めていないこと

現時点で最も明確に決めたのは、必須条件を事前のFilteringとして分離することです。職種・経歴・給与の条件を満たさない候補はRankingの対象ではなく、推薦順位を決めるアルゴリズムが変わっても、このルールは維持する必要があります。

一方、フィルターを通過した候補の順序をどう決めるかは、まだ確定していません。属性ベースの推薦が適しているかもしれませんし、十分なインタラクションが蓄積されれば、協調フィルタリングを検討することもできます。実際の依頼・承諾の事例が蓄積され、Labelの意味が確認できれば、教師あり学習ベースのランキングを比較することもできます。どの方法が適しているかは、実際のデータを見る前に断定するのは困難です。

現時点では、モデルの学習結果や性能改善の数値を提示できる段階ではありません。データ収集の準備をしながら、各推薦方式に必要な情報やイベントの意味を検討しています。データが入り始めたら、単純に件数を数えるのではなく、ユーザーごとのインタラクションがどの程度重なっているか、依頼と応答のデータがどのように分布しているか、欠損や露出バイアスがないかを、まず確認する必要があります。

その分析結果に応じて必要な収集項目を調整できますし、当初考えていたモデルが適切ではないという結論に至ることもあります。初期段階では、こうした可能性を残しておくことがむしろ重要だと考えました。まだ分からないことを恣意的なスコアやモデル名で埋めるのではなく、後から判断するための根拠を残せる構造が必要だったからです。

6. おわりに

今回の作業を始めるとき、推薦アルゴリズムを選ぶことが最も大きな課題だと思いがちですが、実際に最初に直面したのはデータに関する問いでした。現時点でどのような情報がなく、その情報がなければどのモデルを評価できないのかを、まず検討しました。

その過程で、協調フィルタリングと教師あり学習ベースの推薦の可能性を検討し、必須条件とRankingを分離するという設計上の決定を下しました。また、今後活用できるデータは、単なる依頼やマッチングの結果だけではなく、推薦の表示から応答まで、意味の異なるイベントを結び付けた記録であるべきだという点も確認しました。

実際の推薦モデルの性能を示す結果は、まだありません。しかし、データをどのように記録するかによって、将来比較できるモデルや評価できる問いが変わるということは、設計段階から十分に考慮できました。

データが ない 推薦 システムにおける 最初の 一つの 技術的な 選択は, どの モデルを 使うか ではなく 何を 観察し 記録するかを 決める ことでした。

Y永劫