グラフ、分析、そして生成AI グラフニュースレターの年

グラフ、分析、そして生成AI：グラフニュースレターの年を振り返って

ニュースレターは、Knowledge Graphs、Graph Databases、Graph Analytics、およびGraph AIに焦点を当てたニュースレターにおいて、生成AIの導入は必要でしょうか？通常、必要ではありませんが、本号に含まれるアイテムにおける生成AIの影響は圧倒的でした。その理由には簡単な説明があります。

ChatGPTのリリース以来、生成AIは主流になりました。技術的なパフォーマンスや精度、ビジネスの信頼性といった面においてはあまり優れているとは言えませんが、世界中の経営者の注意を引いているのは否定できません。

ChatGPTのデビュー以来、収益の電話会議での「生成AI」に関する言及は、Q4’22の28件からQ3’23の2,081件まで急増し、74倍に増加しました。AIの旅程が早い段階にある企業が多いため、経営者は生成AIブームの中で行動を起こすプレッシャーを感じています。

これはつまり、生成AIは非常に注目を集めていることを意味します。フォーリスターによれば、採用は2030年までに年率36%の成長が予想され、アメリカのだけでも1億人以上が来年生成AIを使用するでしょう。したがって、ベンダーは自社製品を適切に位置づけしようとしています。

適切に行動を起こせば、これは単なるマーケティングの手法以上のものになるかもしれません。グラフと生成AIは互いを補完する方法があり、知識を豊かにした生成AIによる責任ある企業の意思決定につながるのです。

RAGは、Retrieval Augmented Generationの略です。ChatGPTのような大規模言語モデルは、特定のバックグラウンド知識を使用して処理を文脈化するように指示するための技術です。これにより、プロプライエタリデータに対する対話型インターフェースが提供され、LLMが必要なビジネスシナリオに適用されるようになります。

過去1年間で、グラフデータベースへの関心が急増したのはRAGの主な理由です。すべての機械学習モデルと同様に、LLMはベクトルと連携して動作します。そのため、情報を保存し、LLMにフィードするためのベクトルデータベースを持つことは、RAGにとって合理的な選択となります。しかし、それだけではありません。実際には、Damien Benveniste氏などが主張しているように、グラフデータベースがRAGにはより良い選択肢かもしれません。

グラフを使用すると、テキスト内の異なるエンティティ間の関係を抽出して使用し、テキストに含まれる情報の知識ベースを構築することができます。LLMはその種の三項関係情報（[エンティティA] -> [関係] -> [エンティティB]）を抽出するのに適しています。

情報が解析されれば、グラフデータベースに保存することができます。保存される情報は知識ベースであり、元のテキストではありません。情報の検索には、LLMが質問に関連するエンティティクエリーを考案し、関連するエンティティと関係を取得する必要があります。取得される情報は、ベクトルデータベースの場合よりも非常に簡潔かつ的確です。

RAGは、LLMのファインチューニングの代替案であり、より要求の少ない即時に適用可能な手法です。さらに、データ管理がコアコンピタンスであるベンダーが提供できます。

既に組織内で存在感を持っているため、データ管理ベンダーはLLMとの統合作業を引き受けることができます。これはWin-Winの関係です。経営者は生成AIの要件を満たすことができ、ベンダーはその範囲を拡大し、ブームに乗りつつクライアントを満足させることができます。

このため、グラフデータベースのベンダーは自社製品にベクトル機能を追加しています。Neo4jは2023年8月にそのオファリングにベクトル機能を含める最初の企業でした。Neo4jのCPOであるSudhir Hasbeが2023年7月に発表したロードマップの一環として、両方の利点を組み合わせるというアイデアです。

Neo4jとAmazon Neptuneは、類似の軌道をたどっているようです。両社とも、過去数か月間に新しいアナリティクスエンジンを発表しましたが、これによってグラフアナリティクスの処理速度が向上し、以前にも増して処理されなかったシナリオでもパラレル処理を活用しています。

Neo4jの新しいアナリティクスエンジンに関して、Hasbeさんが共有したように、典型的な例はグラフデータの大部分をトラバースする解析クエリです。このパラレルランタイムは、特にこれらの解析クエリに対応するために設計されています。

新しいNeptuneアナリティクスエンジンは、次の3つのユースケースに向けられています。第一に、一時的なアナリティクスです。顧客がグラフを非常に迅速に起動し、いくつかの分析を実行してオフにする必要があるワークフローです。

第二に、低レイテンシの分析クエリです。これには、リアルタイム予測を実行するための特徴テーブルを持つ既存の機械学習パイプラインが含まれます。第三のユースケースは、GenAIアプリケーションの構築です。Neptuneアナリティクスにエンベッディングを保存する際にベクトルの類似検索を行うことができれば、自然言語の質問をグラフクエリに翻訳するのがずっと簡単になります。

新しいアナリティクスエンジンをパワーアップするため、双方のチームはハイパフォーマンスコンピューティング（HPC）からいくつかのアイデアを借りているようです。Neo4jの実装は、「Morsel-Driven Parallelism: A NUMA-Aware Query Evaluation Framework for the Many-Core Age」という研究論文からの影響を受けました。

Amazon Neptuneの具体的な実装については特定の指標はありませんが、Amazon NeptuneのゼネラルマネージャーであるBrad Bebeeは、いくつかの類似点を認めています。どちらのチームも、多様なグラフの顧客とグラフのユースケースを見ているようです。

両チームには、大規模グラフの処理（HPC）からの文献やテクニックに詳しいメンバーがいます。並列処理やメモリ最適化の技術は、HPCコミュニティでよく理解されているものです。

Neo4jとAmazonはグラフデータベースの領域で確立されていますが、この2つの領域を超えてこの領域には多くの活動があります。ほとんどのベンダーは、自己生成AIの景観に自らを位置づけるために取り組み、または製品に対話インターフェースを追加しています。

しかし、自己生成AIが全てではないことを意味しています – 他のユースケースも存在します。 Aerospike Graphは、グラフデータベース市場への新しい参入企業です。スケールの大きな複雑な問題に取り組むことを目指しています。

Aerospikeは、最初はキーバリューストアとしてスタートしました。その後、提供範囲はドキュメントモデル（JSON）およびStarburstを介したSQLインターフェースを含むものに拡大されました。グラフは次のステップであり、採用は顧客主導で行われました。

Aerospike Graphのためには、Apache TinkerPopの創設者であるMarko Rodriguezやプロジェクトへの重要な貢献者など、チームが組まれました。彼らは、グラフレイヤーをAerospikeのコアエンジンとインターフェースする方法において、シェアードナッシングアーキテクチャで水平方向にスケーリングするようにAerospikeを支援しました。

偶然にも、Aerospike Graphの公開から数日後には、最近グラフデータベース市場に参入した同様のプロファイルを持つ他のデータベンダーが撤退を発表しました。

2019年にRedisは自身のグラフデータベースを紹介し、パフォーマンスとスケーラビリティを提供したと述べました。しかし、2023年にはRedisGraphを終了させることを発表しました。

「多くのアナリストレポートは、グラフデータベースが指数関数的に成長すると予測していました。しかし、私たちの経験に基づくと、企業はしばしばグラフデータベースを利用したソフトウェアの開発に支援を必要とします。グラフデータモデリング、クエリの構成、クエリの最適化など、新しい技術的スキルが多く必要です。どんな技術でも、グラフデータベースには制約と欠点があります。

この学習曲線は急勾配です。コンセプト証明は予想よりも長時間かかることがあり、成功率は他のデータベースモデルに比べて低いです。顧客と開発チームにとって、これはしばしば欲求不満を意味します。Redisのようなデータベンダーにとっては、トータルのプリセールス（およびポストセールス）の投資が他のデータベースモデルに比べて非常に高いことを意味します」と述べています。

スコーピングおよびナレッジグラフの構築

ナレッジグラフを構築することは、まるで巨大で恐ろしいプロジェクトであるように見えるかもしれませんが、マイク・ディリンジャー氏が指摘しているように、それは主にナレッジグラフが巨大である必要があると考えるソフトウェアエンジニアから来ているのです。

技術の組織は、エンジニアマネージャーがエンジニアに何でもできると思ったり（または期待したり）することで溢れています。そして、マネージャーやエンジニアが理解し、納得するために、ナレッジグラフの構築をフレーム化できるくらいナレッジグラフに精通しているプロダクトマネージャーは非常に少ないです。

その結果、組織はナレッジグラフのような重要で未知のテクノロジーを実装していません。広く信じられている仮定とは異なり、Dillingerは付け加えていますが、ナレッジグラフの作成とキュレーションは inherently なマニュアル的なプロセスではありません。品質管理には専門家のレビューが必要ですが、補助的なナレッジグラフ作成のための最新の研究成果を共有しています。

最近では、ジェネレーティブなAIの勢いにより、補助的なナレッジグラフ作成の話題が再び注目を浴びています。これには十分な理由があります。LLMは、ラフール・ナヤクが示すように、任意のテキストを概念のグラフに変換するのに役立つことができます。

注目を浴びている取り組みの一つは、知識グラフ構築のために特にファインチューニングされた言語モデルである MechGPT です。 MechGPTはまずテキストを小さなチャンクに分割します。それぞれのチャンクは汎用のLLMにフィードされ、キーコンセプトを要約した質問と回答ペアを生成します。

オントロジーとは何でしょうか？ナレッジグラフに詳しい人にとっては些細な問題に思えるかもしれませんが、カート・ケグルが示すように、そうではありません。ケグルはオントロジーを、名前付きグラフ内のデータの形状を確立するためのスキーマの集合と定義しています。他の人々は異なる定義を好むかもしれません。

ホルガー・クヌブラッハは書いていますが、ナレッジグラフの世界では、オントロジーはクラスとプロパティを定義するドメインモデルです。クラスはグラフ内のエンティティ（インスタンス）のタイプであり、プロパティはそれらの間の属性と関係です。オントロジーはグラフの構造を定義し、ツールがそれらをより理解しやすくします。

ともかく、SHACL（SHApes Constraint Language）をオントロジーモデリングに使用することが受け入れられるようになっています。SHACLが導入される前は、ナレッジグラフの検証は主に手動か、OWL（Web Ontology Language）の制約に頼っていました。しかし、OWLの制約は直感に反するものです。

クヌブラッハは、SHACLチュートリアルに続いてPart 2では限定的な基数制約について、そしてPart 3ではSPARQLベースの制約について書いています。ラドスティン・ナノフも3部構成でSHACLガイドを執筆しており、SHACLが乱れたデータグラフを抑制する方法を学ぶ、データにSHACLを適用して出力を処理する、そしてSHACLエンジンの内部という内容です。イヴォ・ヴェリチコフとヴェロニカ・ハイムスバックもSHACLに関するWikiを管理しています。

DeepMindは、グラフAIの先駆者の一つでした。ここ数か月で、DeepMindはいくつかの高影響のユースケースで、彼らのグラフAIの使用について詳細を共有しています。

Scienceに掲載された論文で、DeepMindはGraphCastを紹介しました。これは、VoAGI範囲の天気予報を驚異的な精度で行う最新のAIモデルです。GraphCastは、産業のゴールドスタンダードの天気シミュレーションシステムよりも正確で、はるかに高速に、10日先までの天候条件を予測します。

GraphCastは、機械学習とGraphニューラルネットワーク（GNN）に基づいた天気予報システムであり、空間的に構造化されたデータの処理に特に役立つアーキテクチャです。DeepMindはGraphCastのモデルコードをオープンソース化しており、世界中の科学者と予測者が数十億人以上の人々の日常生活の利益に貢献できるようにしています。

DeepMind GNoMEは、380,000の安定した構造を含む2,200,000の新しい結晶構造を発見したGNNベースのシステムです。新しい機能性材料は、クリーンエネルギーから情報処理まで、技術的な応用の基本的なブレイクスルーを実現します。規模の大きいグラフニューラルネットワークは、一桁のオーダーで材料の発見の効率を向上させ、前例のないレベルの一般化を達成することができます。

グラフベースのデータは、エンタープライズ全体および業界の垂直分野に普及しており、機械学習のユースケースにますます必要とされています。グラフ技術は利用可能ですが、リレーショナルデータベースと比較してまだあまり広く使用されていません。それでも、AIアプリケーションの恩恵を受けるために、グラフと言語モデルを組み合わせることの利点から、知識グラフの実践への関心は最近高まっています。

頻繁な懸念点は、グラフデータが低レベルで表現されるため、クエリがより複雑でコストがかかることが多いことです。視覚化以外に、異なる詳細レベルで知識グラフを理解するためのメカニズムはほとんどありません。つまり、より抽象的で集約された視点でグラフデータを扱うにはどうすればよいのでしょうか？

グラフデータにクエリを実行して集計メジャーを計算することはできますが、オンラインマップを使用する際にズームアウトするように、大きなグラフを考慮するためのプログラム的手段はありません。これにより、大規模システムの本質的な多スケール性に対処しなければならないエンタープライズアプリケーションは、AIアプリケーションを利用する際には明らかな不利益を被ることとなります。

Paco Nathanは、グラフ内の詳細レベルの抽象化に関連する手法の調査結果と今後の課題について説明しています。

グラフと大規模言語モデルの研究

最後に、グラフと大規模言語モデルを組み合わせたさまざまな側面に関する研究のコレクションを紹介します。Paco Nathanはまた、こちらでGraph MLと言語モデルを組み合わせた研究のコレクションも紹介しています。

IEEEの研究者は、大規模言語モデルと知識グラフを統合するためのロードマップを提案しています。彼らのロードマップには3つの一般的なフレームワークがあります。KGを強化したLLM、LLMを拡張したKG、および相互作用するLLM + KGです。前のYotG号も参照してください。

同様に、香港科技大学（広州）、香港中文大学、清華大学の研究者たちは、グラフと大規模言語モデルの調査を発表しています。彼らは、既存の方法を役割（エンハンサー、予測子、およびアライメントコンポーネント）に基づいて3つのカテゴリに分類するタクソノミーを提案しています。

ETH Zurich、Cledar、ワルシャワ工科大学の研究者たちは、Thoughtsのグラフ（GoT）を紹介しています。これは、大規模言語モデル（LLMs）のプロンプト機能を進化させるフレームワークで、Chain-of ThoughtやTree of Thoughts（ToT）などのパラダイムが提供するものを超えています。Tony Sealeはこのアプローチを要約しています。

Michael Galkin他は、Knowledge Graph推論のための単一の事前訓練推論モデルであるULTRAを提案しています。 ULTRAは、任意のエンティティおよびリレーションボキャブラリーの新しいKGに一般化することができ、KG推論問題に対するデフォルトのソリューションとなります。MonashとGriffithの研究者たちは、Graphs上の推論（RoG）という手法を提案しており、LLMsとKGsを組み合わせて忠実で解釈可能な推論を可能にしています。

学界、データベース企業、およびGartnerなどの業界アナリスト企業を含む業界全体の専門家の数が、LLMの応答精度向上手段としてKnowledge Graphsを指摘しています。この主張を評価するために、data.worldの研究者たちは、エンタープライズでのLLMの応答精度にKnowledge Graphが与える効果を調べるための新しいベンチマークを開発しました。

このベンチマークでは、LLMによって生成された回答をSQLデータベースに格納された知識グラフで裏付けられた回答と比較しました。調査結果は、知識グラフで裏付けられた回答の精度が、テストされたすべてのカテゴリで著しい改善があることを示しています。

A*Netは、Knowledge Graphs上でスケーラブルで帰納的で解釈可能なパスベースのグラフニューラルネットワークです。これを使って、ChatGPTに知識グラフ推論ツールを備えた形でより事実に基づいたものにすることができます。これはオープンソースで、ChatGPTと統合されています。

Google Researchでは、Talk Like a Graph: Encoding Graphs for Large Language Modelsを発表しています。これは、LLMsが読み込むためのテキストとしてグラフ構造化データをエンコードする包括的な研究です。

Jure Leskovac他は、Relational Deep Learningという、複数の表に広がったデータを直接学習するためのエンドツーエンドの深層学習アプローチを紹介しています。中核となるアイデアは、リレーショナルテーブルを異種グラフと見なし、各テーブル内の各行にノード、プライマリキーと外部キー関係で指定されたエッジを持つものとします。

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!

Share:

Was this article helpful?

93 out of 132 found this helpful

Related articles

Discover more

Want to read more? Go here