婚活支援プロジェクト(1/4):構想からデータモデル設計まで #neo4j

「婚活支援プロジェクト」とは、いわゆる婚活をしている男女のプロファイルをグラフデータベース Neo4j に登録し、理想的な相手を予測するためのデータモデルや Cypher クエリーを開発してみようという企画です。これからグラフデータベース Neo4j の活用を検討 したい方のため、構想段階から進行過程、収束に至るまでのすべて経過を、順を追って連載で詳しく紹介していきます。

第1回目:構想からデータモデル設計まで
第2回目:データ処理と問題点
第3回目:どのように改善したらいいのか
第4回目:改善したデータモデルによるデータ処理

冒頭で唐突に「予測」という言葉を使っているのでこれについて説明します。最近私は「予測こそグラフデータベース Neo4j の本領」ではないかと考えています。Neo4jには様々なユースケースがありますがその間には一見あまり共通性はありません。詐欺の摘発、マスタデータ管理、組織の権限管理、リアルタイムレコメンデーション、ネットワーク&IT オペレーションなどの最終結果は、まるで何の関係もないように見えます。しかしそれは該当のシステムが提供するサービスのことであり、機能ではありません。実際にデータモデルやデータ処理のアルゴリズムを組み立てるレベルではどうでしょうか。どのデータもカオスをぎりぎりの線で脱出したグラフ形式のデータを入力とします。そして求められる結果(あるべき姿、又は期待する形)に対して一致するパターンか、あるいはどれほど類似しているパターンなのかを出力しています。これは明らかに一種の予測のプロセスではないでしょうか。もし、Neo4jの活用を検討している方は、「これをどこに利用すればいいのかではなく、何か予測とかをしてもらう必要があることはないか」とアプローチしてみては如何でしょうか。

なぜ婚活をテーマにしたのか

「婚活」と言うテーマを選んだ理由は、この時代の社会問題を扱って見たかったという志があったからではありません。単に様々な情報が入手しやすいだろうということや、疑似情報を作るにしてもリアルに作れるだろうということ。曖昧さや意外性だらけの男女の関係だから、ちょっと変な結果が出ても大抵の場合、面白がるだろうし、それなりに複雑性も存在しているだろうという。殆ど身勝手な理由ばかりです。

婚活に関わりそうな情報収集をしてみました

いずれにせよ、関係ありそうな情報収集を始めました。いくつかの婚活サイトを参照し、周りの同僚の話しを聞き、自分の経験も振り返ってみました。それで婚活と関係がありそうな 20 種のドメインと、それぞれの属性を決めました。リアルに近い複雑性を再現するために 20 種にしていますが、深い意味はありません。深く考えるとさらに増えそうだったので、この線で切っています。

[人]
男、女
[スポーツ]
野球,サッカー,バレーボール,バスケットボール,テーブルテニス,テニス,ヨガ,散歩,ダンス,その他
[休みの日]
休日,土日祝日,平日,不定期
[会話の傾向]
聞くタイプ,話すタイプ,とちらでも良い
[出会いの作り]
積極的,消極的,とちらでもない
[身長]
140,150,160,170,180,190,200
[性格]
外向的,内向的
[インドアで過ごすなら]
読書,映画感想,音楽感想,TV 感想,ゲーム,寝る,友たちとお喋り,料理を作る,その他
[アウトドアで過ごすなら]
海,山,川,公園,遊園地,どちらでもいい
[お酒は]
飲む,飲まない
[煙草]
吸う,吸わない
[カラオケは]
好き,嫌い
[占いは]
信じる,信じない
[ヘルスケアは]
意識して運動する,特に意識していない
[収入は]
100,200,300,400,500,600,700,800,900
[生れた年]
1995,1994,1993,1992,1991,1990,1989,1988,1987,1986,1985,1984,1983,1982,1981,1980,1979,1978,1977,1976,1975,1974,1973,1972,1971,1970
[結婚歴]
有り,無し
[ペット]
犬派,猫派
[教育]
義務教育,高等学校,各種専門学校,短大・高専,大学,大学院
[お仕事]
公務員,会社員,自営業,企業経営・役員,教師,医師,医療関係,保育士,農林・漁業,パート・アルバイト,学生,家事手伝,その他
[住んでいる地域]
北海道,青森県,岩手県,宮城県,秋田県,山形県,福島県,茨城県,栃木県,群馬県,埼玉県,千葉県,東京都,神奈川県,新潟県,富山県,石川県,福井県,山梨県,長野県,岐阜県,静岡県,愛知県,三重県, 滋賀県,京都府,大阪府,兵庫県,奈良県,和歌山県,鳥取県,島根県,岡山県,広島県,山口県,徳島県, 香川県,愛媛県,高知県,福岡県,佐賀県,長崎県,熊本県,大分県,宮崎県,鹿児島県,沖縄県

この段階では、ドメインや属性の妥当性よりも期待する条件の相手を見つけることができる最低限の「データモデル作成」に集中することにしました。Neo4j はスキーマフリーのデータベースですから、データ構造を変更してデータベースを再構成することは比較的に簡単です。長考するよりスピードを重視し、先ず考えられる範囲のデータモデルで作成し、いくつかのシナリオの Cypher クエリーを実行しながら、「トライ&エラー」で最適化を図っていく方法を選んだわけです。

データモデルの妥当性は長く議論したからと言って理想的なアイディアに繋がるとは限りません。そもそもデータモデルの段階では判断するだけの十分な情報が入手できない問題があります。実際に有用な情報が得られるのは、データを投入し、狙いのデータパターンが得られるかどうかやってみた時だからです。

婚活支援データモデルにおける特殊性

いずれにせよ軽い気持ちで始めましたが、婚活の対象になる人のプロファイルには様々な特徴があることが分かりました。

• 男性と女性で明確に分かれ、候補者間で特に関係性は持っていない。関係性を持っているのはカップル成立の関係か、どちらかに断わられた関係である。
• 理想の相手を予測するための条件となる、サブドメインの属性と人との関係性は 1:1 とは限らない。
• オリジナルプロファイルと理想の相手を予測するためのリクエストプロファイルの内容は一致しない。つまり一人の人に 2 種類のプロファイルが存在する。
• ある条件は重み付けをし、優先度を高くしたい場合がある。
• ある条件は必須となることがある。例えば身長や収入、住んでる場所などを限定した場合である。

ざっと考えてみましたが、かなり複雑なデータモデルになりそうですね。

希望の相手を予測する方法

希望の相手を予測する方法には大きく3つのパターンがありました。

諸条件を利用する方法

この方法は候補者のリクエストプロファイルと対象になる人のオリジナルプロファイルを突き合わせて、最適な候補者を予測してもらう方法を利用しています。 自分のリクエストが反映されるという安心感があり、相手のプロファイルを見た時に直観的で理解しやすいというメリットがあります。

適正検査による方法

この方法は候補者から数十から百数十の項目のアンケートに答えてもらって、その結果分析から、相性のよい相手をレコメンドしてもらうタイプです。これは理想の相手を予測する過程がブラックボックスであるため、システム自体を信頼できる人とできない人に分かれるというデメリットがあります。

ハイブリッド的な方法

諸条件を利用する方法と適正検査による方法をミックスして利用する方法です。適正検査による方法が参考になるメリットがあります。

1回目のデータモデリング開始

フェーズ1のデータモデル

今回は既に上記の『婚活支援モデルにおける特殊性』で述べているような要件をすべて取り入れたデータモデルを一気に作り上げることは無理だと判断し、いくつかの要件を省略したデータモデルを作ることにしました。

• 男女は人を親ドメインとして階層化する。

:Person:Man, Person:Woman

• オリジナルプロファイルのみを対象にする。
• プライマリドメインの属性とサブドメインの属性との関係性は 1:1 にする。

プライマリドメインとサブドメイン

グラフデータベースの利用を検討する上で問題点の一つは、データモデリングの方法論が確立してないことでしょう。殆どのケースにおいて経験や試行錯誤に頼っていると言っても過言ではありません。ここでは筆者の独断でドメインの種類を、次の2種類に分類しています。

• プライマリドメイン

分析の上で最も中心的な役割を果たす必須のドメインのこと。例えば今回の人(Person)のようなものであり、一般的にノード数が最も多く、トランザクション処理も頻繁に行われる。

• サブドメイン

分析の切り口として使われ、プライマリードメインを補助する役割を果たすドメインのこと。例えば人に紐づくスポーツのようなものであり、プライマリドメインに比べて相対的にノードの数も少なく、一度作られた後は参照だけのケースも多い。

コンセプトデータモデル

ここまでの調査結果や私自身が決めた方針に従って、概念レベルのデータモデルを作成してみました。人(Person)がプライマリドメインであり、スポーツや休日などは、サブドメイン(:Category)の位置づけです。

ディテールデータモデル

コンセプトデータモデルのサブドメインを5つサンプリングし、詳細レベルのデータモデルを作成してみました。今回のケースではサブドメインのパターンが同じなので、すべて書いても意味がないことから省略しています。

今回のデータモデルのラベル及び関係性を定義し、すべてのドメインモデルを網羅すると、次のようになります。

Person:Woman-[:SUCCESS]->Person:Man
Person: Man-[:SUCCESS]->Person:Woman
Person:Woman-[:DISAGREE]->Person:Man
Person:Man-[:DISAGREE]->Person:Woman
Woman-[:MY_SPORT]->sport
Woman-[:MY_HOLIDAY]->holiday
Woman-[:MY_TALK]->talk
Woman-[:MY_HEIGHT]->height
Woman-[:MY_PERSONALITY]->personality
Woman-[:MY_INDOOR]->indoor
Woman-[:MY_SMOKING]->smoking
Woman-[:MY_ALCOHOL]->alcohol
Woman-[:MY_KARAOKE]->karaoke
Woman-[:MY_FORTUNETELLING]->Fortunetelling
Woman-[:MY_OUTDOOR]->Outdoor
Woman-[:MY_INCOME]->Income
Woman-[:MY_BORN]->Born
Woman-[:MY_LOCATION]->Location
Woman-[:MY_PET]->Pet
Woman-[:MY_EDUCATION]->Education
Woman-[:MY_JOB]->Job
Woman-[:MY_MEET]->Meet
Woman-[:MY_MARRIAGE]->Marriage
Woman-[:MY_HEALTHCARE]->Healthcare
Man-[:MY_SPORT]->Sport
Man-[:MY_HOLIDAY]->Holiday
Man-[:MY_TALK]->Talk
Man-[:MY_HEIGHT]->Height
Man-[:MY_PERSONALITY]->Personality
Man-[:MY_INDOOR]->Indoor
Man-[:MY_SMOKING]->Smoking
Man-[:MY_ALCOHOL]->Alcohol
Man-[:MY_KARAOKE]->Karaoke
Man-[:MY_FORTUNETELLING]->Fortunetelling
Man-[:MY_OUTDOOR]->Outdoor
Man-[:MY_INCOME]->Income
Man-[:MY_BORN]->Born
Man-[:MY_LOCATION]->Location
Man-[:MY_PET]->Pet
Man-[:MY_EDUCATION]->Education
Man-[:MY_JOB]->Job
Man-[:MY_MEET]->Meet
Man-[:MY_MARRIAGE]->Marriage
Man-[:MY_HEALTHCARE]->Healthcare

プライマリドメインを軸としてみたサブグラフのイメージ

このサブグラフはプライマリドメインのノードから、サブドメインのノードへ放射型に広がっているシンプルグラフです。このパターンでは人のプロファイルを取捨選択しながら低コストで取得することを狙いとしています。

関係性の方向はどのように決めるのでしょうか。これは、美的な要素よりパフォーマンスの面の考慮が最も必要だと思います。今回のグラフは人のノードの数が圧倒的に多いなかで、アクセスパースの観点から人を決めてからサブドメインにアクセスして行きます。さらに人が決まってしまうと、周りのサブドメインとの関係は 1:1 となっているためアクセスコストも最低になるはずです。仮にアクセスパースの開始ノードがもっぱら「年収」だとすると、おそらく別のデータモデルへと変更が必要になるかもしれません。

サブドメインを軸としてみたサブグラフのイメージ

次のグラフはスポーツサブドメインの野球ノードを軸にして人が集中型に集まっているシンプルグラフにしています。グラフの方向は分析におけるアクセスパースとパフォーマンスを意識した構成にしています。

まとめ

ここまでで、とりあえず婚活支援プロジェクトの「データモデル設計」が終了しました。次回は実際にサンプルデータをロードし、Cypher クエリーで理想の相手を予測してみたいと思います。