web-dev-qa-db-ja.com

igraphのコミュニティ検出アルゴリズムの違いは何ですか?

約100個のigraphオブジェクトのリストがあり、一般的なオブジェクトには約700個の頂点と3500個のエッジがあります。

つながりがよりありそうな頂点のグループを特定したいと思います。私の計画では、混合モデルを使用して、頂点属性とグループ属性を使用してグループ内にある頂点の数を予測します。

私のプロジェクトの他の側面に応答したい人もいるかもしれませんが、それは素晴らしいことですが、私が最も興味を持っているのは、頂点をグループ化するためのigraphの関数に関する情報です。私はこれらに遭遇しました コミュニティ検出アルゴリズム しかし、それらの長所と短所、または他の機能が私の場合により良いかどうかはわかりません。リンクも見ました here ですが、それらはigraphに固有のものではありません。アドバイスをしてくれてありがとう。

80
Michael Bishop

以下は、igraphで現在実装されているコミュニティ検出アルゴリズムに関する短い要約です。

  • Edge.betweenness.communityは、エッジ間のエッジスコア(つまり、特定のエッジを通過する最短パスの数)の降順でエッジが削除される階層的な分解プロセスです。これは、多くの場合、あるグループから別のグループに移動する唯一のオプションであるため、異なるグループを接続するエッジが複数の最短パスに含まれる可能性が高いという事実に基づいています。この方法では良い結果が得られますが、Edge間の計算の計算が複雑であるため、およびEdgeを削除するたびに中間スコアを再計算する必要があるため、非常に遅くなります。 〜700の頂点と〜3500のエッジを持つグラフは、このアプローチで分析するのに適したグラフのサイズの上限を超えています。もう1つの欠点は、Edge.betweenness.communityが完全な樹状図を作成し、最終的なグループを取得するために樹状図をどこでカットするかについてのガイダンスを提供しないことです。樹状図の各レベルでのパーティションのスコア)。

  • fastgreedy.communityは別の階層的アプローチですが、トップダウンではなくボトムアップです。貪欲な方法でモジュール性と呼ばれる品質機能を最適化しようとします。最初は、すべての頂点が個別のコミュニティに属し、コミュニティは反復的にマージされ、各マージがローカルに最適化されます(つまり、モジュール性の現在の値が最大に増加します)。アルゴリズムは、モジュール性をこれ以上高めることができない場合に停止するため、系統樹だけでなくグループ化も可能になります。この方法は高速で、調整するパラメーターがないため、通常は最初の近似として試行される方法です。ただし、解像度の制限を受けることが知られています。つまり、特定のサイズのしきい値(正しく覚えている場合はノードとエッジの数に応じて)未満のコミュニティは、常に近隣のコミュニティとマージされます。

  • walktrap.communityは、ランダムウォークに基づくアプローチです。一般的な考え方は、グラフ上でランダムウォークを実行すると、特定のコミュニティの外部につながるエッジがわずかしかないため、同じコミュニティ内にとどまる可能性が高くなるということです。 Walktrapは、3-4-5ステップの短いランダムウォーク(パラメーターの1つに依存)を実行し、これらのランダムウォークの結果を使用して、fastgreedy.communityのようなボトムアップ方式で個別のコミュニティをマージします。繰り返しますが、モジュール性スコアを使用して、樹状図をカットする場所を選択できます。貪欲な高速アプローチよりも少し遅くなりますが、(元の出版物によると)少し正確です。

  • spinglass.communityは、いわゆるポッツモデルに基づいた統計物理学からのアプローチです。このモデルでは、各粒子(つまり頂点)はcスピン状態のいずれかになり、粒子間の相互作用(つまりグラフのエッジ)はどの頂点のペアにとどまるかを指定します。同じスピン状態で、どのスピン状態が異なるスピン状態を好むか。その後、与えられたステップ数でモデルがシミュレートされ、最終的に粒子のスピン状態がコミュニティを定義します。結果は次のとおりです。1)cを最大200に設定できますが、最後にcを超えるコミュニティはありません。あなたの目的に十分です。 2)スピン状態の一部が空になる可能性があるため、最終的にコミュニティがc未満になる場合があります。 3)ネットワークの完全に離れた(または切断された)部分のノードが異なるスピン状態を持つことは保証されません。これは、切断されたグラフのみの問題である可能性が高いので、心配する必要はありません。この方法は、(シミュレーション自体のため)特に高速で決定的ではありませんが、クラスターサイズを決定する調整可能な解像度パラメーターがあります。スピングラス法の変形では、ネガティブリンク(つまり、エンドポイントが異なるコミュニティにあることを好むリンク)を考慮することもできます。

  • leading.eigenvector.communityは、モジュール性機能を再度最適化するトップダウンの階層的アプローチです。各ステップで、分離自体がモジュール性を大幅に向上させるように、グラフが2つの部分に分割されます。分割は、いわゆるモジュラリティマトリックスの主要な固有ベクトルを評価することによって決定されます。また、密に接続されたグループがさらに分割されないようにする停止条件もあります。固有ベクトル計算が関係するため、ARPACK固有ベクトルソルバーが不安定な縮退グラフでは機能しない場合があります。非縮退グラフでは、高速の貪欲な方法よりもモジュール性スコアが高くなる可能性がありますが、少し遅くなります。

  • label.propagation.communityは、すべてのノードにkラベルのいずれかが割り当てられる単純なアプローチです。次に、この方法は繰り返し実行され、各ノードが近隣の最も頻繁なラベルを同期的に取得するように、ノードにラベルを再割り当てします。このメソッドは、各ノードのラベルがその近隣で最も頻繁なラベルの1つになると停止します。非常に高速ですが、初期構成(ランダムに決定されます)に基づいて異なる結果が得られるため、メソッドを何度も(たとえば、グラフに対して1000回)実行し、コンセンサスラベリングを作成する必要があります。退屈。

igraph 0.6には、情報理論の原理に基づく最先端のInfomapコミュニティ検出アルゴリズムも含まれます。グラフ上のランダムウォークの最短の記述長を提供するグループ化を試みます。記述の長さは、ランダムウォークのパスをエンコードするのに必要な頂点あたりの予想ビット数で測定されます。

とにかく、おそらく最初の近似としてfastgreedy.communityまたはwalktrap.communityを使用し、何らかの理由でこれら2つが特定の問題に適さないことが判明したときに他の方法を評価します。

180
Tamás

さまざまなコミュニティ検出アルゴリズムの概要は、ここにあります: http://www.r-bloggers.com/summary-of-community-detection-algorithms-in-igraph-0-6/

特に、InfoMAPアルゴリズムは有用な最近の新人です(有向グラフもサポートしています)。

13
timothyjgraham