Docker拡張機能による分散グラフベースのLLMおよびAIインフラストラクチャの合理化

グラフと大規模言語モジュールに関する作業と、Docker拡張機能で開発環境を強化した方法について、この機会に共有できることを嬉しく思います。

私はNebulaGraphというオープンソースのグラフデータベースのコントリビューターであり、NebulaGraph DGLやNebulaGraph AI SuiteなどのグラフとAI関連のプロジェクトの作成者でもあります。 また、Llama Index というオーケストレーター プロジェクトのトップ 10 コントリビューターでもあります。 ですから、私は公の場で構築し、言語モデルやグラフに関するものを共有することを楽しんでいますので、遠慮なく私に手を差し伸べてください。

今日のトピックは、グラフとは何か、そしてなぜグラフが必要なのかについての背景から始めます。 NebulaGraphというプロジェクトについて簡単に紹介し、その後、私たちが取り組んでいる言語モジュールのRAGパラダイムにグラフがどのように役立つかについて、興味深い調査と研究を共有します。 次に、最後にDocker拡張機能を紹介します。

では、グラフとは何でしょうか? なぜグラフを気にする必要があるのですか? この定義(グラフ理論の意味でのグラフ用語)は、ヨーロッパの旧市街では、都市を横切って土地をさまざまな部分に分割する川があり、そこには7つの橋があるという、7つの橋の問題と呼ばれる古い問題に由来しています。

そこで疑問だったのは、7つの橋を繰り返さずに、それぞれを一度だけ横断する方法はないか、ということでした。 したがって、答えのネタバレはノーです。 しかし、人々はこの結論を証明したかったのです。 そこで、ある論文で、これを数学の問題に抽象化し始めました。 そのため、この抽象化を行う方法は、土地を小さな点(または頂点と呼ばれるもの)にマッピングすることで、橋はそれらまたは端を結ぶ線として抽象化されます。 したがって、グラフ理論の観点からは、グラフは頂点とそれらの頂点をつなぐエッジのセットにすぎません。

ナレッジグラフ

実際、グラフはすでにその下にあり、私たちの現実世界で多くのことを可能にしています。 最初に共有したいことの 1 つは、ナレッジ グラフと呼ばれるものです。 ナレッジグラフは、Googleが特定のタイプの検索を処理し始めたときに発明した用語です。 キーワードを検索できるように、従来の検索方法では問題ありませんでした。 Elasticsearchと同じように転置インデックスを設定しています。 しかし、人々が有名人の年齢などを検索しているとき、ですよね? 転置インデックスでそれをどのように行うのですか? それは実行不可能です。 そこで、Googleがそれを修正しようとしたのは、ナレッジグラフと呼ばれるシステムを設定することでした。

この考え方は、セマンティックネットワークと呼ばれる古い用語に由来します。 文字通り、知識のエンティティをグラフのノードに配置するだけで、エッジはそれらの間の関係にすぎません。

グラフのユースケース

また、別のユースケースでは、グラフがどのように機能するかについて、より理解を深めます。 これは、レコメンデーションシステムの一般的なユースケースです。 そこで、Netflixのおもちゃ版を考えて、システムが新しいユーザーに映画を推薦するようにしています。 では、このユーザーがすでにいくつかの映画を視聴し、そのうちのいくつかを高く評価しており、それらのノードから逆に同様のエッジに移動することができるとします。 そのため、これらの類似した映画に同様の関心を共有する他のユーザーに連絡を取ります。 そして、そこから、同じような好みを共有する候補者によって高く評価されている他のノードに手を差し伸べます。 しかし、それらの映画は私たちのユーザーに直接接続されていません。 これは簡単なレコメンデーションシステムです。

別のケースでは、現実の世界では、レコメンデーションシステムは複雑なシステムであり、多くの場合、ブラックボックスです。 しかし、ここのグラフは、グラフを設定でき、ユーザーとレコメンデーション候補を取得でき、細かいパスを行うことができるため、役に立ちます。 これは、一般的なグラフの一致パターンです。 その場合は、レコメンデーション結果の推論が生成されます。 そのため、グラフは解釈可能なレコメンデーションを有効にすることもできます。

ソーシャルネットワークでもグラフを見かけます。 LinkedInで、2親等以内の友人がいると想像してみてください。 おすすめの新しい友達ができます。 そのため、多くの共通の友人を共有しているのに、まだつながっていない可能性があります。 また、ソーシャル ネットワークのグラフからグラフのインサイトを得て、クラウド ネイティブ、ビジュアライゼーション、SRE の領域にたどり着くことができるため、すべてを 1 つのグラフにまとめることができます。 このようにして、ハイパーバイザーが1つあり、セキュリティの問題やディスクの問題、高負荷があるように、状態を伝播でき、このアラーム、状態、またはセキュリティの問題をグラフ全体にすぐに伝播でき、グラフベースのアルゴリズムを実行することもできます。

データ内のクラスタリングの検出に役立つアルゴリズムがいくつかあります。 そのため、それらのいくつかはグラフアルゴリズムのある意味で密接に位置しており、グラフ全体のメモのいくつかを選択して、他のメモよりも重要として扱うことができます。 したがって、そのノードにアラームが発生した場合は、他の重大度で処理できます。 これは、この分野でグラフがどのように役立つかを示す 1 つのケースにすぎません。 また、データリネージのようなものを設定して、すべてのデータ資産、列、データワークフローのリネージを追跡し、それらをすべて接続してグラフビューでリアルタイムに検査できるようにすることもできます。

これは、不正検出やリスク管理における別のユースケースです。 したがって、eコマース銀行またはコンテンツWebサイトを運営しています。 詐欺にはパターンがあり、管理しなければ、つまりコントロールしなければ、混乱が発生する可能性があります。 したがって、詐欺のパターンは、通常、特定のタイプのグラフパターンで表すことができます。 たとえば、このデバイスまたはこのIPアドレスは、他の膨大な数のイベントに接続されていたり、さまざまなユーザーによって作成された投稿でした。 したがって、このパターンはリスクの高い状況として認識できます。 そのため、黒のノードとしてマークされたノードを1つ持つことができ、eコマースで新しい投稿や新しいトランザクションが発生したときにも使用できます。 したがって、おそらく 3 つまたは 4 つのホップで、それらは接続されます。 それらを検出し、このトランザクションをリアルタイムで防止する機会があります。 したがって、これは非常に一般的なグラフのユースケースです。

そして、製造業、つまり非デジタルの実際のケースにたどり着きます。 これは、自動車製造のサプライチェーンの事例です。 機能、モジュール、コンポーネント、サプライヤーなど、すべてを 1 つのグラフの 1 つのグループにまとめることができます。 そのため、私たちが想像もしなかった方法でインサイトをパッケージ化することができます。 これは、グラフなしでは想像できなかったサービス提供の洞察を得て、機能を設定するための非常に興味深い方法です。 実際には他にも多くのユースケースがありますが、最後に配置したいのはこれです。 したがって、これは、言語モジュールベースのアプリケーションを設定するときにグラフが役立つユースケースです。 これが興味深いのは後ほど詳しく説明しますが、その前に、グラフ データベースに関する別の背景について簡単に説明したいと思います。

ですから、私たちの多くはすでにそれに精通しているかもしれませんが、システムにさらに別のデータベースを導入するかどうかを決定するのは難しい場合があります。 そして、おそらく最も懸念される理由のいくつかがあります。 その理由の 1 つは、グラフ データベースがグラフ セマンティクスのデータに対するグラフ センスに対するクエリを有効にできることです。 それはどういう意味ですか。 たとえば、レコメンデーションシステムで述べたパターンのように、ユーザーにこれを推奨した理由の理由を持つパスを見つけたい場合。 したがって、これはグラフの世界ではグラフ クエリの典型的な簡単なバージョンですが、表形式データベースでは比較的困難です。 理想的には、RDBMSに表形式でグラフデータとして配置することもできますが、それらを照会したい場合、それは本当に困難です。 したがって、クエリの欠点は、任意のタイプのエッジタイプの1つのグラフ内の2つのノード間の細かいパスにすぎないことです。 したがって、これはグラフ クエリ パターンのほんの始まりのバージョンにすぎません。

もう一つの理由は、RDBMSがトラバーサルの関係(グラフごとの関係)でうまく機能しないという面白い事実があることです。 そこで、その理由を説明します。 これがRDBMSであり、ある地点から別の地点への典型的なグラフトラバースを行うときを想像してみてください。 ですから、私たちはあるステージから別のステージへとジャンプするスノーブラザーズにすぎません。 つまり、これは結合であり、別のテーブルに結合するときは、あるポイントから別のポイントまで実行して、次の関連する接続ノードを見つけます。

これは、データがキーに基づいて並べ替えられるため、データのスケールと密接に関連しているため、スケーリングされません。 そのため、グラフのトラバースを行う場合、非常にコストがかかります。 ですから、それを軽減するために、あなたが知っているハックをいくつか行うことができます。 ですから、魔法を使ってより速く走ったり、雪玉を遠くに投げたりすることもできますが、それは解決策ではなく軽減策です。 そのため、データはより高い範囲で成長をスケーリングします。 場合によっては、30 秒程度でパターンをクエリできるか、30 分でクエリできるかの違いがあります。 そのため、これは多くのグラフ単位のユースケースでは受け入れられません。

ですから、グラフデータベースは、文字通りある地点から別の地点に飛ぶことができる魔法の緑色の瓶のようなものだと考えてください。 ですから、グラフ探索の 1 つのハブを実行しているときの 1 つの作業すべてに密接に関連していると考えてください。 そして、それは基本的にデータのスケーリング方法には関係なく、グラフクエリの1つのハブでは比較的安価です。 そのため、実際のグラフ クエリでは、複数のハブになる可能性があり、多くの違いが生じる可能性があります。 これがグラフデータベースが必要な理由です。 それが理にかなっていることを願っています。 こんなに早く、マーケティングの時期に、なぜ別のプロジェクトが必要なのでしょうか? では、なぜNebulaGraphが必要なのでしょうか?

ネビュラグラフ

NebulaGraphは、分散アーキテクチャとして設計されたため、完全に拡張できます。 というわけで、これは川の中の小さな形を描いた写真です。 元に戻したいときは、1人か2人で押し戻してもらいます。 2年前、コンテナ船が運河で立ち往生し、何ヶ月も世界の輸送を遮断したことを覚えていらっしゃると思います。 したがって、いくつかの問題は似ているように見えますが、解決策はまったく異なる場合があります。 NebulaGraphは、数千億のノードと数兆のエッジを処理するハイパースケール向けに構築されており、分散型であり、ゼロからコラボレーションとオープンソースになるように設計されています。

検索拡張生成

さて、言語モジュールでグラフがどのように役立つかというトピックに戻ります。 そのため、設定する最も一般的に使用されるパターンである言語モジュールベースのアプリケーションは、コンテンツ学習またはRAGパラダイムで呼び出されました。 つまり、RAGは検索拡張生成を指します。 したがって、RAGのプロセスは、生成を呼び出したり、言語モジュールを呼び出したりして、ソリューションや回答、またはReactパイプラインのネクストホップを合成する前に、プライベートデータの取得を行うことです。 つまり、言語モジュールは、スマートアプリケーションのセットアップ方法を永遠に変えたという考え方です。

以前は、比較的スマートな自動化タスクを可能にするためにモジュールをトレーニングする必要がありましたが、言語モジュールではプロンプトを使用するだけで済みます。 しかし、現実の世界では、言語モジュールに何かをさせるためのプロンプトを準備するだけでなく、ドメイン知識の内容(プライベートデータ)も提供しなければならない場合があります。 実際には、RAGが行っている方法は、インデックス作成フェーズを実行しているときに、個人データを準備またはインデックス化しているだけです。 そのため、クエリ時間中にタスクを送信し、インデックス データと比較して、特定のクエリまたは特定の質問で必要なデータを取得します。 そして、言語モジュールには、それが私たちの質問であることを感知するコンテンツ学習の機能があります。 そして実際には、私たちが物事をインデックス化する方法、または狭い定義や最も一般的な使用法は、基本的な方法を分割と埋め込みと呼びます。

埋め込みは、現実世界のものをベクトル感覚にマッピングするための機械学習の方法にすぎません。 このベクトル空間では、すべてのノードまたはすべてのベクトルが1つのエンティティを表し、それらがどれだけ近いかは、それらが意味的にどれだけ近いか、どれだけ類似しているかを表します。 この概念により、プライベートデータを小さなチャンクに分割し、それらすべての埋め込みベクトルを作成できます。 したがって、クエリ時間を実行しているときに、同じ埋め込みモジュール内のタスクの前置詞であるベクトル式を作成して、関連するデータまたはデータのチャンクを意味的に検索して、それを有効にすることができます。 これがRAGパラダイムの仕組みですが、今のところ非常に簡単なので、課題があります。 4行か5行のコードを使って、言語モジュールだけで独自のデータでクエリロボットを設定し、Llamaインデックスを起動することができます。 派手なデモには最適ですが、本番環境に対応した要件を用意するためにさらにプッシュすると、本当に難しくなります。 やるべきことはたくさんあります。

その理由の 1 つは、検索の方法の性質に起因しています。 したがって、データの分割を行うときは、参照したいデータがこれであるため、それらを小さなチャンクに分割する必要があります。 しかし、この分割には、トランクのサイズを強く想定しています。 例えば、スティーブ・ジョブズに関する本に基づいてQAシステムを作成し、データのページを1つのトランクに入れたとします。 要約を作成するので、スティーブ・ジョブズとアップルについて質問するとき、その下に各ページを埋め込んでいるだけなので、この質問の埋め込みも作成します。 そこで、スティーブとアップルのベクトル空間で検索しています。

だから、Appleが1ページ目と2ページ目にあることを想像してみてください。 1ページ目と2ページ目には情報がありますが、他のページには他の情報が散りばめられている可能性があります。 たとえば、Steve と Apple に関する 1 つの文章があります — 非常に重要ですが、このページには 1 行の情報しかありません。 この場合、分割は機能しないため、他のページに分散してきめ細かくなっていると、重要な知識を取得できない可能性があります。 本来、このアプローチの課題は、情報全体の相互関係、つまり相互作用を実際に壊してしまうことです。 私たちの知識はツリーやグラフのようなものなので、直線的な方法ではなく、つながりを持っているので、それらを直線的に分割して構造化するだけです。 そのため、これは本質的に、このグローバルなコンテキストの情報を失う可能性があります。 これが、私たちが幻覚に寄与する原因の1つです。

ここでのもう一つの課題は、埋め込み自体です。 通常、ベクトル表現は汎用埋め込みで作成しています。 ほとんどの場合、汎用埋め込みは機能しますが、ドメイン知識は認識されません。 認識できるすべての単語に用語や知識がある場合がありますが、ドメインの専門家でない場合は、それらが実際に何を意味するのかを認識していません。 ここで問題なのは、埋め込みが、これらの情報を空間に意味論的に配置する文字通りの(常識的な)方法に基づいていたことです。

左側は、現実の世界で遭遇する例で、いくつかのeコマースのユースケースに関連するQAチャットボードを設定したいと考えています。 ここでは、断熱カップについて疑問が投げかけられていますが、埋め込みスペースでは、システムは断熱温室を関連していると見なしており、なぜそれらが関連しているのか理解できません。 技術的に言えば、この2つのキーワードには多くの共通点があり、一見も近いですよね? しかし、人間として、どちらか一方について疑問を抱いているとき、もう一方は気にしないことを知っています。 これは、埋め込みが検索段階で幻覚を引き起こす可能性がある典型的な状況です。 ここでの解決策は、作成し、微調整し、埋め込みに現実世界の問題をより認識させることです。 しかし、埋め込みの微調整は複雑でコストがかかる場合があるため、ナレッジグラフに基づいてある程度軽減できます。

言語モジュールベースのアプリケーションをセットアップするとき、実際には知識を扱っています。 したがって、ナレッジグラフは本質的に洗練されたバージョンであり、ナレッジソースのきめ細かなセグメンテーションを備えているため、何らかの形で役立ちます。 また、ノードのエンティティ間の相互作用も追求します。 そのため、本質的に、分割によってもたらされる問題と、ナレッジグラフの相互接続を軽減するのに役立ちます。 適切に設定されていれば、ドメイン知識を追求/保持できます。 後でデモの例も紹介します。

ですから、これらの問題を軽減する方法は次のとおりですが、私たちはまだRAGのパラダイム、つまりコンテンツ内学習の中にいます。 インデックス作成を行う際には、データの埋め込みやベクターストアを作成するだけでなく、ナレッジグラフではなく、生の非構造化データからデータを抽出します。 また、クエリ、つまり検索フェーズでは、ベクトル検索で膨大な知識の幹を見つけるだけでなく、テストや質問の主要なエンティティと関係を抽出します。 そして、それらをナレッジグラフに見出すと、グラフ全体のサブグラフとなり、それが実際のコンテンツとなり、最終的な結果を一緒に生成するのに役立つ可能性があります。

このデモでは、Wikipedia ページからデータ ソースを設定します。 ガーディアンズ・オブ・ギャラクシー Vol. 3 (今年の私のお気に入りの映画)に関連しているので、ナレッジグラフを設定し、ロケットやライラについて質問しています。 そして、その下には、これは検索された知識文の一部であるため、その下にはサブグラフがあります。 後ほど、より多くのアイデアを示すためのビジュアルエイドバージョンを用意し、そのすべての情報を組み合わせて、この質問にどのように答えたいかを学びます。

これはグラフの単純なバージョンであり、RAGであり、はい、しかし現実の世界では、ナレッジグラフが自動化された方法ではないか、それが唯一の方法ではないため、純粋なグラフRAGはうまく機能しないと考えています。 知識の密度は必ずしもそれほど高くないため、永続的な知識が必要です。 大量のデータに含まれる非構造化データには、私たちが気にする詳細もいくつかあります。 そのため、この 2 つを組み合わせるのが最適な方法なので、後でどのように機能するかを示します。 これは、グラフRAGが視覚化された方法でどのように機能するかです。 したがって、グラフから関連するものを取得したい場合、次のようなサブグラフを取得します。 そして、答えはそれに基づいているので、私たちは問題を感じます。

もう一つお見せしたいデモは、これがベクトルとどのように連携して機能するかを評価する方法です。 これは一例です。 NASAの科学問題に関するウィキペディアのデータソースを設定し、検索と生成の3つのタイプがあります。 最初の列は純粋に埋め込み方法でベクトル検索から行われ、答えは非常に豊富で正しく、3番目の列は純粋なグラフです。 前述したように、情報はそれほど豊富ではありませんでしたが、それも正しいのですが、この2つを組み合わせると、ここで興味深い発見があります。 そこで、Steve と Apple についての質問を考えてみてください。 Appleに関する知識は、きめ細かな方法で広めることができます。 この例から、強い線は、知識の部分がベクトルではなく、グラフから来ていることがわかります。 ですから、2つを組み合わせると、品質を追求しているときにより良いパフォーマンスが得られます。

最後の例は、自然界が埋め込みから来る幻覚についてです。 これはガーディアンズ・オブ・ギャラクシーについて尋ねる同様のアセットで、映画には存在するが、あたかも存在するように見える質問をモックアップしようとしました。 そして、私たちはベクトルDBからの検索でベクトルにこの長い質問をしていますが、それは完全な幻覚を伴います。 しかし、ナレッジグラフに向かってそうすると、この質問には何の関連もないことを私たちに知らせるために厳密になります。 そこで最終的には、2つの質問を並行して検索するクロスチェックメカニズムを設定し、特定の問題で一方のみが検索結果を持ち、もう一方が空の場合、両方からダブルチェックプロセスを有効にします。 ですから、その場合は、そのような幻覚を軽減します。

上記で述べたことはすべてローカルで再現でき、オープンソースコミュニティへのこのアプローチでできることはすべてアップストリームにしています。 したがって、今のところLlamaインデックスを使用すると、3行のコードでグラフRAGを実行できます。 最初の行はインデックス作成時間に関するものなので、1行のコードで、特定の種類のドキュメントからナレッジグラフやベクター埋め込みを作成したり、サポートされているデータ形式を多数用意したりできます。 2行目はクエリエンジンを作成するためなので、その上でグラフRAGを実行できます。 そして、これはあなたが実際に質問したい行です、はい。

ドッカー拡張機能

最後のトピックはDockerについてでした。 したがって、データベース自体は分散プロジェクトであり、全部で複数のコンポーネントがあり、それはグラフクエリ専用です。 そのため、Spark GraphXをベースにしたASBなど、他のプロジェクトもあります。 これもまた分散システムです。 そのため、データサイエンティストのためにすべてを準備したいと考えています。 また、グラフの場合、グラフデータベースのユーザーの多くはコンピューターサイエンティストでさえなく、リスクの専門家であったり、サプライチェーンの専門家であったりしますが、それでもグラフデータベースを使いたいと考えています。 そのため、macOSデスクトップ上のWindowsでコマンドラインを使用したり作成したりするのは非常に困難です。

そこで役立つのがDocker拡張機能です。 Docker拡張機能は、Dockerチームが以前に行っていた別のステップにすぎないと思います。 Cグループ、名前空間、すべてを非常に優れた抽象化して、これらすべてのテクノロジーをエレガントに楽しむことができるようにしました。 しかし、Docker拡張機能は、すべてをサーバー側、Linux側、分散方式で、グラフィックでコマンドのないライブ方式で配置できるものでもあります。

これは、どのデスクトップオペレーティングシステムでもDockerデスクトップで実行できるため、必要なのはこれだけです。 そして、技術者以外の人にとっては、これはさらに別のソフトウェアです。 したがって、拡張機能マーケットプレイスでは、Nebulaを検索するだけで、NebulaGraph拡張機能をインストールできます。 そのため、ワンクリックで、グラフィックUIやグラフクエリなど、さまざまなコンポーネントを、すべてがすでに設定されている状態で持つことができます。 これにより、コミュニティユーザーは、バックグラウンドに関係なく、わずか5分で、すべての利点と魔法を非常に簡単に活用できます。

私はこの拡張機能の作成者でもあるので、実際にこれについて興味深いハックを行い、オプションでワークロードをインストールできるようにしました。 興味がある場合は、この拡張機能コードのリポジトリもチェックしてください。 今日はそれだけをお伝えしたいと思います。 つまり、グラフは頂点とエッジに関連するものであり、グラフ クエリはグラフ単位のパターン マッチングの一種であり、現実世界の問題を可能にするにはさらに別のデータベースが必要です。 NebulaGraphは、大規模なグラフデータに優れており、RAGを行う際に言語モジュールパターンに役立ちます。 Docker 拡張機能を使用すると、わずか 5 分ですべてを試すことができます。 実は、このスライドには他にもいくつかの情報を掲載していますので、もし興味があれば、グラフについて、またグラフが言語モジュールにどのように役立つかについて、遠慮なくお話しください。

ご不明な点がございましたら、 お願いします。

それで、私が持っている疑問の1つは、簡単な質問に答えて、セバスチャン、ある人について教えてくれたということです。 しかし、マルチオペッククエリに関しては、それほど最適ではありませんでした。 では、今後どのように対処していくのでしょうか?

今のところ、私たちはまだ始まりに過ぎません。 それで、あなたはグラフRAGまたはテキスト解読を使用していますか? グラフRAGです。 したがって、今のところ、実装は簡単に実現できる果実に過ぎず、グラフスキーマに強力な仮定があるため、改善すべきことがまだたくさんあります。 改善すべき点がたくさんあるので、後ほど詳しくお話しできると思います。 ありがとうございます。

さらに詳しく

• NebulaGraph Docker拡張機能を備えた分散型クラウドネイティブグラフデータベース
• Docker による人工知能と機械学習
• Docker デスクトップの最新リリースを入手します。
• 次のものに投票してください! 公開ロードマップをご覧ください。
• 質問がありますか? Docker コミュニティがお手伝いします。
• ドッカーは初めてですか? 始めましょう。