新しいllama-index拡張パッケージにより、RAGシステムのネットワークを迅速に作成することができます。 データ提供業者は、データ上に強力なRAGを構築し、ContributorServiceの背後に公開して、LlamaIndex Networkに参加することができます。
RAGの主要な前提は、LLMにコンテキスト（または知識）を注入して、より正確な応答を得ることです。そのため、RAGシステムの重要な構成要素は、知識を得るデータソースです。したがって、RAGシステムがアクセスできる知識が多ければ多いほど、最終的には（深さと幅の両方のクエリに対する回答として）より優れたものになるというのは直感的な理由です。このコンセプトの精神は、基本的にすべての他のデータ駆動型の学問で見られるものとそれほど変わりません。つまり、より多くの（良質な）データにアクセスし、それを適切に活用することは、通常、より良い結果につながります。
それを背景に、私たちは最新のllama-indexライブラリ拡張機能であるllama-index-networksのリリースを発表できることを喜んでいます。このライブラリ拡張機能により、外部データソースに基づいて構築され、外部のアクターによって提供されるRAGsのネットワークを構築することが可能になります。この新しいネットワークパラダイムにより、データ提供業者がデータを提供し、より知識豊かなシステムを構築したい人々に提供する新しい方法が可能になります！
このブログ投稿では、新しい拡張ライブラリの主要なクラスを紹介し、わずか数行のコードでQueryEngineをRAGsネットワークの一部として貢献できるようにする方法を示します。また、このLLMsの新しい時代において、データサプライヤーが実際にデータを消費者に供給する方法についてのアイデアを共有します。
用語に関する注意：この投稿では、実際の拡張機能を指すために llama-index-networks を使用し、llama-index[networks] は llama-index-networks 拡張機能が付属する llama-index のインストールを指します。
Alex、Beth、およびBobの物語
ネットワーク内のアクターと彼らの問題声明の説明的な例。
llama-index-networksパッケージの使用方法を説明するために、Alex、Bob、Bethの3人の架空のキャラクターと次のシナリオを考えてみましょう。
- ボブとベスはそれぞれ独自の文書セットを持っており、両方ともすでに優れたRAGシステムを構築しています（もちろん、ラマ指数を使用して！）
- アレックスは、ボブとベスの洞察に富んだ文書について聞いており、両方の個々のRAGをクエリできるようになりたいと考えています。
- ボブとベスは、親切な人物であると同時に（または、おそらく非公開の金額が支払われたかもしれません）、アレックスに自分たちのRAGシステムへのアクセスを提供することに同意します。
この新しい知識交換の流れを促進するために、彼らはアレックスがクエリを送信できるRAGsのネットワークを設定することに同意します。
BobとBethは、RAGsを使ってWebサービスを構築します
ContributorServiceはQueryEngineを中心に構築されています。
BobとBethは、llama-index-networksパッケージを使用して、わずか数行のコードでそれぞれのQueryEngineをネットワークに参加できるように準備することができます。
"""Beth's contributor service file.
Bethは自分のQueryEngineを構築し、それを標準のLlamaIndex Network Contributor Serviceの背後に公開します。
NOTE: BobはおそらくDockerとクラウドコンピューティングサービスを利用して、これを本番向けにするでしょう。"""'
from llama_index.networks.contributor import ContributorService import uvicorn
beth_query_engine = ...
beth_contributor_service = ContributorService.from_config_file(
".env.contributor",
beth_query_engine
)
if name == "main:
uvicorn.run(beth_contributor_service.app, port=8000)
Bobは、QueryEngineを任意のLlamaIndexネットワークに貢献できるようにするために、同様のコードラインを使用します。 .env.contributorというdotenvファイルには、サービスの設定や必要なAPIキー（例：OPENAI_API_KEYまたはANTHROPIC_API_KEY）が含まれており、その内部ではFastAPIを使用したRESTサービスとして実装されています。
AlexはNetworkQueryEngineを構築します
Alexは、BethとBobの個々のContributorServiceに接続するNetworkQueryEngineを構築しています。
Alexの場合、彼はllama-index-networks拡張機能のNetworkQueryEngineクラスを使用して、BethとBobのContributorServiceの両方に接続できるようにしています。
"""Alexのネットワーククエリエンジン。
AlexはNetworkQueryEngineを構築して、ContributorServiceのリストに接続します。
from llama_index.networks.contributor import ContributorClient from llama_index.networks.query_engine import NetworkQueryEngine from llama_index.llms.groq import Groq
beth_client = ContributorClient.from_config_file( env_file=".env.beth_contributor.client" ) bob_client = ContributorClient.from_config_file( env_file=".env.bob_contributor.client" ) contributors = [beth_client, bob_client]
llm = Groq() network_query_engine = NetworkQueryEngine.from_args( contributors=contributors, llm=llm )
network_query_engine.query("空はなぜ青いのか？")
ここでは、dotenvファイルにContributorServiceに接続するために必要なapi_urlなどのサービスパラメータが保存されています。
このブログ投稿の次のセクションに進む前に、AlexがNetworkQueryEngineをクエリする際に裏側で何が行われているかを少し説明します。query()メソッドが呼び出されると（非同期もサポートされています！）、クエリがすべての貢献者に送信されます。彼らの応答は新しいNodesとして保存され、応答は（関連するResponseSynthesizerを使用して）合成されます。これを読んだ後、いくつかの人は、私たちのライブラリでQueryEngineの抽象化を扱う際の通常のパターンであることに気づくかもしれません。そして、それが実際の目的でした。NetworkQueryEngineを使用することは、当社のライブラリ内の他のQueryEngineを使用する方法と非常に似ているはずです！
これで、アレックス、ボブ、ベスに関する小さなストーリーは終わりです。このブログ投稿を締めくくる前に、まずllama-index-networksの使用を通じて生じるかもしれないいくつかの潜在的な機会を提供します。
データ供給と消費の新しい世界
RAGマーケットプレイスは、llama-index[networks]を使って実現可能なユースケースです。
llama-index[networks] によって容易に動作する可能性のある1つの世界は、RAGのためのマーケットプレイスです。データ供給業者が自らのデータをRAGの形式でパッケージ化し、データ消費者が自らのクエリシステムの知識を拡大するために求める場所です。潜在的なRAG（データ）供給業者には、地元の新聞社、書籍出版社などが含まれます。
この新しいデータ供給と消費モデルでは、データサプライヤーには、データを消費しやすくするための形式でデータを準備する責任がより多くかかります。具体的には、サプライヤーがクエリエンジンの構築を担当します。これにより、ContributorService（QueryEngineをカプセル化する）などによって提供される標準インターフェースを使用することで、データ消費者は従来のデータマーケットプレイスと比較して、求めている知識にアクセスしやすくなります。
このようなビジョンを持って、llama-index[networks]を構築しました。これにより、(i) データ提供者がデータに含まれる知識を新しい、そしておそらくより効果的な方法で提供しやすくなり、(ii) データ消費者がこれらの新しい形式の外部知識に接続しやすくなります。
内部ネットワーク: もう1つの潜在的なユースケース
RAGマーケットプレイスを駆動するだけでなく、総合的な企業が所有するが必ずしも管理しないRAGを接続する必要性を予見しています。より具体的には、フランチャイズはすべての運営にわたるデータの権利を持つかもしれません。そして、彼らはデータベース全体に「中央」で一元的なRAGを構築することができますが、個々のオペレーターにRAGを構築し、それらをクエリする方が効率的かつ効果的かもしれません。
情報を交換してより良い、より知識豊富なシステムを構築するという考え方は新しいものではありません。ただし、その交換を促進するためにRAGsを使用するという考え方は（私たちの知識では）、既存の利用事例と新しい利用事例の両方がこの協力を必要とする場合に恩恵を受けると信じています。
プライバシーに関する簡単な注意
データの協力において重要な考慮事項はプライバシーとセキュリティです。上記の例では、ネットワークを通じて共有されるデータがデータプライバシーとセキュリティの法律と規制に準拠していると仮定しています。この技術が成長するにつれて、必要な機能と能力が開発され、法令遵守のRAGネットワークを促進するために組み込まれると信じています。
より詳しく知るためにデモをご覧ください！
実際のデモを見るには、Githubリポジトリcodeのllama-index-networksをチェックし、examples/demoサブフォルダに移動してください。