DEIM2022 - 技術報告 / DEIM2022 - Technical Report

■イベント 
：DEIM2022（第14回データ工学と情報マネジメントに関するフォーラム）
https://event.dbsj.org/deim2022/

■登壇概要
タイトル：【技術報告】大規模名刺交換ネットワークに基づいた Node2vec の実装ごとの埋め込み結果の比較
発表者： 

技術本部 研究開発部 研究員 吉村 皐亮

■ R&Dの採用情報
https://media.sansan-engineering.com/randd

Transcript

1. ⼤規模名刺交換ネットワークに基づいた Node2vec の実装ごとの埋め込み結果の⽐較 Sansan株式会社 技術本部 研究開発部 吉村 皐亮 , 新⽥ 洸平（インターン⽣ ） DEIM2022 技術報告
3. クラウド名刺管理サービス 名刺アプリ クラウド請求書受領サービス
4. Sansanの研究開発部 Automation これまでにない速度と限りなく100％に 近い精度、セキュリティーの確保を⽬指 し、画像認識や機械学習などの技術を⽤ いて、名刺やビジネス⽂書といった⾮定 型でアナログな情報のデータ化を効率化 ・ ⾃動化する技術の研究開発に取り組む。 機械学習、⾃然⾔語処理、画像処理といっ た技術を⽤いて、あらゆるビジネスデータ を収集・解析する。多様なビジネスデータ を組み合わせることで、レコメンデーショ ンエンジンやニュース配信エンジンなどの 構築に取り組む。 Data Analysis OCR・データ化・⾃動化 レコメンド・予測・⾃然⾔語処理 幅広い領域を対象に OCR や NLP から MLOps まで SocSci Architect 社会科学の各領域を専攻するメンバーで構成。 「リアルとバーチャルのはざまで、社会理論 を武器に名刺交換の価値を拡張する」をミッ ションとして掲げ、研究を通して得られた知 ⾒や成果を事業やサービス、社会へと還元す ることに取り組む。また、外部有識者との共 同研究も積極的に展開する。 新規プロダクト開発・効果検証 「研究開発部が提供するサービスに責任を持 つ」「DSOCをデータで⽀える・リードする」 をミッションとして掲げ、サービスの可⽤性、 拡張性、保守性の担保に取り組む。また、研究 開発部の開発⽣産性に向き合いながら、データ 基盤の整備、データの品質、データの取り扱い における安全性の担保にも取り組む。 DevOps・MLOps・データ分析基盤
5. ⼤規模名刺交換ネットワークに基づいた Node2vec の実装ごとの埋め込み結果の⽐較
6. • 名刺交換ネットワーク*1 をもとに、顧客に新しい価値を届けるために 新機能を開発したい。 • ネットワークがグラフ構造のままでは機械学習に⽤いにくいので、 ノードの埋め込み表現を経由して機能開発に役⽴てたい。 はじめに 名刺交換ネットワークを埋め込みたい *1:分析に当たっては、Eightのデータについて個⼈を匿名化し、Eightの利⽤規約で許諾を得ている範囲で使⽤した 𝒗𝟏,𝟏, … , 𝒗𝟏,𝒏 𝑻 ⋮ 𝒗𝒎,𝟏, … , 𝒗𝒎,𝒏 𝑻 名刺交換ネットワーク 埋め込み 応⽤先 • Eight Newsのフィルタリング • Eight Career Design での 類似企業検索 etc. ノードをベクトルで表現 𝒎: ノード数 𝒏: 次元数 ノード: 企業 エッジ: 名刺交換
7. Node2vec: ノードとエッジの両⽅に属性がない場合のノード埋め込み⼿法 1. ハイパーパラメータで探索の深さと幅を調整した遷移確率を⽤いて ランダムウォークで系列をサンプリング 2. 同系列の2ノードは内積が⼤きく 、それ以外は内積が⼩さく なるように学習 max ! $ "∈$ − log $ %∈$ exp 𝑓 𝑣 &𝑓 𝑢 + $ '!∈(" " 𝑓 𝑛) &𝑓 𝑢 • Node2vec は SNAP の C++ 実装が有名 • SNAP 実装の⽋点 • メモリとデータ構造が⾮効率 • → ⼤規模ネットワークに適⽤できない or ⼤規模なメモリを搭載したマシンが必要 (属性がないグラフの) ノードの埋め込み Node2vec [1] が有効であり、SNAP の実装 [2] が有名 𝑉 : ノード集合 𝑢, 𝑣, 𝑛! : ノード 𝑓 : 埋め込み関数 𝑁" (𝑢) : ノードuを含む系列S内のノード集合
8. PecanPy: Node2vec の効率的な Python 実装 • バイオインフォマティクス分野で R. Liu らが提案。 • ランダムウォークをメモリ・計算時間の両⾯で、下記のように効率化*2: 効率の良い Node2vec の実装 Node2vec の効率的な実装 PecanPy [3, 4] が提案された 実現したこと 実現⽅法 省メモリ化 Node2vec で⽤いるグラフを CSR (Compressed Row Storage) 形式で扱う。 省メモリ化 遅延評価により、遷移確率⾏列の全ての値を事前に計算しない。 ⾼速化 ランダムウォーク部分を効率的に並列化。 *2: 実際には⼊⼒するグラフの密度やノード数によって効率化処理は⼀部異なる。
9. ⽬標 効率的に学習できることから SNAP を PecanPy に差し替える ⽬標実現のための要件 • SNAP と⽐べて: 1. ピーク時のメモリ使⽤量が少ない 2. 同等かそれ以上に⾼速な計算時間を担保 3. 同等かそれ以上の品質を担保 → 評価実験により、上記の要件を満たすかを確認する。 現状の SNAP ベースの埋め込みを差し替える 質を担保しつつ、メモリと処理時間の両⽅を効率化したい
10. データ • ⼀年分の Eight の名刺交換ネットワーク*3 *4 • ノード: 企業, エッジ: 名刺交換, 属性情報なし • ノードは数百万のオーダー 評価指標 • ピーク時のメモリ使⽤量 • 計算時間 • ノードの多クラス分類を Accuracy で評価 (※ Baseconnectの業界カテゴリを利⽤) • リンク予測を Accuracy で評価 • 定性評価 (各ノードの近傍を⽬視で確認) 評価実験 名刺ネットワークを埋め込み、各種評価指標で評価を実施 *3: 分析に当たっては、Eightのデータについて個⼈を匿名化し、2020年10⽉から2021年10⽉にEightのユーザーによって登録された名刺の情報を、Eightの利⽤規約で許諾を得ている範囲で使⽤した *4: 各ノードに対応する企業の情報についても匿名化したネットワークデータをもとに、インターン⽣の新⽥洸平さんが実験・分析を実施
11. PecanPy でピーク時メモリ使⽤量がどの程度削減可能か？ → 少なく⾒積もってもSNAPの ! "# 程度まで削減 PecanPy では遷移確率⾏列を事前に計算せず、遅延評価を⾏っているために ピーク時のメモリサイズが劇的に削減できている。 実装 ピーク時の消費メモリ [GB] メモ SNAP 976 ~ 1952 メモリサイズ 976 GB 以下では処理不可。 PecanPy 27.04 CPU: 64, Memory: 1,952GB のマシンでの⽐較 実験結果 (ピーク時のメモリ使⽤量) 64 GB のメモリサイズのマシンで処理可能
12. PecanPy でどの程度学習時間が短くなるか？ → SNAP の 2.3 倍程度まで⾼速化 実装 処理時間 [分] SNAP 233 PecanPy 100 CPU: 64, Memory: 1,952GB のマシンでの⽐較 実験結果 (計算時間) 計算時間も半分程度まで削減できる ランダムウォークでの系列サンプリング部分が並列処理されることで、 処理時間が半分以下まで削減されている。 ただし、当然 PecanPy の⾼速化具合は CPU 数に依存する。
13. SNAP と PecanPy で埋め込んだ分散表現の品質は下記の3点で同等か？ 1. ノードの多クラス分類による Accuracy での評価 2. リンク予測による Accuracy での評価 3. 各ノードの近傍ノードの類似度合いについての定性評価 → 上記の３点の全てでアルゴリズムが異なるように⾒える結果 ⼿法 多クラス分類 リンク予測*5 定性評価 SNAP 0.5050 0.9056 どちらも品質は良いが 傾向が異なる。 PecanPy 0.5396 0.8677 *5: 予測対象の2つのノードの埋め込み表現をアダマール積で統合して後段のロジスティック回帰に⼊⼒した。 各⼿法での埋め込み結果を特徴量としてロジスティック回帰で予測した結果。評価指標は Accuracy。 実験結果 (品質評価) SNAP と PecanPy で品質が⼤きく異なる
14. ネガティブサンプリング max ! $ "∈$ − log $ %∈$ exp 𝑓 𝑣 &𝑓 𝑢 + $ '!∈(" " 𝑓 𝑛) &𝑓 𝑢 ⽔⾊の枠で囲った部分は計算量が⼤きいので、ネガティブサンプリングで近似計算を⾏う。 SNAP と PecanPy でのネガティブサンプリングのアルゴリズムの違い • SNAP: ランダムウォークでの出現頻度が⾼いノードを積極的にサンプル • PecanPy: ランダムウォークでの出現頻度が低いノードを積極的にサンプル → 同じノードでも実装ごとに負例としてサンプリングされる回数が ⼤きく異なることになる。 埋め込みに影響する実装の違い 実はネガティブサンプリングの処理が異なっている
15. SNAP と PecanPy の埋め込みを PCA で３次元に次元圧縮 • SNAP: ⼤きなクラスタが2つに分かれている • PecanPy: ⼤きなクラスタが1つに集まっている → おそらくネガティブサンプリングの差異による影響であると考えられる。 PecanPy SNAP SNAP と PecanPy の埋め込みの可視化 可視化すると実際に実装ごとの埋め込み形状が異なる
16. ⽬的 : 名刺交換ネットワークを効率的に埋め込みたい → ⽅向性 : 現状の SNAP 実装の代替案として PecanPy を検討 課題 : 差し替えるためにPecanPy が下記の要件を満たすか? 1. ピーク時のメモリ使⽤量が少ない 2. 同等かそれ以上に⾼速な計算時間を担保 3. 同等かそれ以上の品質を担保 分かったこと • PecanPy は SNAP よりも処理時間とメモリの両⾯で⾮常に効率的である。 • しかし、両者はネガティブサンプリングのアルゴリズムも異なる。 → これを理解して利⽤する必要がある。 Future Work • 各ノードの近傍に来るノードについての定性評価を代替できるような、評価⽅法を実現したい。 • なぜなら、ダウンストリームのタスクでの精度と近傍ノードの定性評価とは必ずしも関連が強くないため。 まとめ PecanPy は効率的だが、アルゴリズムに差分がある
17. [1] A. Grover and J. Leskovec., node2vec: Scalable Feature Learning for Networks, ACM SIGKDD 2016. [2] https://github.com/snap-stanford/snap/tree/master/examples/node2vec [3] R. Liu and A. Krishnan., PecanPy: a fast, efficient and parallelized Python implementation of node2vec, Bioinformatics 2021. [4] https://github.com/krishnanlab/PecanPy References: