Splunk DSDL 5.2のリリース：LLM-RAG機能とユースケース

背景

大規模言語モデル（LLM）に関する技術が急速に進化する中で、2つの重要な課題が浮上しています。それは、LLMサービスをどのように安全に活用するか、そして各組織にとって有益で正確な回答をどのように生成するかです。現在のLLMサービスは、一般的にSoftware-as-a-Service（SaaS）製品として提供されており、顧客データやクエリがパブリッククラウドを通じて送信されます。これにより、LLMを安全に活用しようとする多くの組織にとって大きな障害が生じています。さらに、LLMはその学習データに基づいて応答を生成するため、最新の情報や内部知識へのアクセスなしに、顧客の特定のユースケースに関連する回答を生成することが難しいです。

最初の課題に対処するには、LLMをローカル環境でホスティングし、顧客が自分のデータを完全に管理できるようにする必要があります。第二の課題については、Retrival-Augmented Generation（RAG）が広く採用されています。RAGは、カスタマイズ可能なナレッジベースを追加のコンテキスト情報として利用し、LLMの応答を強化します。通常、追加の知識を含む資料（内部文書やシステムログメッセージなど）はベクトル化され、ベクターデータベース（VectorDB）に保存されます。クエリが実行されると、ベクトル類似性検索を通じて関連する知識コンテンツが特定され、LLMプロンプトのコンテキストに追加されて生成プロセスを支援します。

Splunk DSDL 5.2のLLM-RAG機能

このリリースでは、オンプレミスの LLM-RAGシステムのアーキテクチャ（図1）を用いてSplunk DSDLを拡張し、Splunk DSDL appからLLM-RAG機能を活用するための一連のコマンドとダッシュボードを提供します。このシステムは、3つの主要なコンポーネントで構成されています。ローカルLLMサービス用のOllamaモジュール、ローカルVectorDB用のMilvusモジュール、LLMとVectorDBモジュールを制御してRAGを行うためにLlamaIndexフレームワークを利用するDSDLコンテナです。

^{図1：LLM-RAGシステムのアーキテクチャ}

このアーキテクチャに基づいて、Splunk DSDLを次の4つのユースケースで拡張しています：

1. Standalone LLM：LLMを使用して、ゼロショットQ&Aや自然言語処理タスクを実行します。

2. Standalone VectorDB：VectorDBを使用してSplunkからデータをエンコードし、類似性検索を行います。

3. Document-based LLM-RAG：内部知識や過去のサポートチケットなどのドキュメントをVectorDBにエンコードし、LLM生成のためのコンテキスト情報として使用します。

4. Function-calling-based LLM-RAG：Jupyter NotebookでFunctionツールを定義し、LLMが自動的に実行して生成のためのコンテキスト情報を取得します。

このブログでは、4つのユースケースの簡単な紹介とサンプル出力を提供します。

ユースケース1：Standalone LLM

Standalone LLMは、Splunkに取り込まれたデータに基づいてQ&Aを実行するために使用できます。以下の例では、Splunk DSDL 5.2で提供されるダッシュボードを使用して、Splunkに取り込まれたテキストデータを分類します。まず、対象のテキストメッセージを出力するためにSplunkサーチを実行します。次に、設定パネルでLLMモデルを選択し、次のプロンプトをテキストボックスに入力します：

Categorize the text. Choose from Biology, Math, Computer Science and Physics. Only output the category name in your answer.

「Run Inference」ボタンをクリックすると、ローカルLLMがプロンプトと共にテキストデータを受け取ります。生成が完了すると、結果と各テキストデータの実行時間が出力パネルに表示されます。

ユースケース2：Standalone VectorDB

DSDL 5.2では、Splunkデータを VectorDB コレクションにエンコードし、そのコレクションに基づいて類似検索を行うためのダッシュボードが提供されています。以下の例では、Splunkの_internalインデックス内のエラーログが、コサイン類似度に基づくベクトル検索を利用して、VectorDBコレクション内の過去のログと一致しています。検索結果から選択されたログ（Socket error … broken pipe）は、設定パネルの上部で設定されたコレクション「Internal_Error_Logs」に記録された4つの類似したログメッセージと一致しています。

ユースケース3：Document-based LLM-RAG

DSDL 5.2では、Dockerホスト上にあるドキュメントをVectorDBコレクションにエンコードし、それらのコレクションをLLM生成に使用するためのダッシュボードを提供しています。以下の例では、「Buttercup_store_info」というベクトルコレクションに、Buttercupオンラインストアに関するドキュメントをすでにエンコードしています。LLM-RAGダッシュボードで、このコレクションとローカルLLMを選択し、次のクエリを入力します：

Customer customer@email.com had a Payment processing error during checkout for the product page of DB-SG-G01. Answer the following questions: 1.List of employees in charge of this product support 2.What were the resolution notes in the past tickets with the same issue description?

「Query」ボタンをクリックすると、クエリがコンテナ環境に送信され、コレクションから関連するドキュメントが自動的に取得され、クエリにコンテキスト情報として追加され、LLMに送信されます。LLMによって生成された応答が出力パネルに表示され、参照されたドキュメントのリストも表示されます。

ユースケース 4：Function-Calling-based LLM-RAG

LLMが追加のコンテキスト情報を取得するためのもう1つの方法は、Function ツールを実行することです。このユースケースはユーザーのカスタマイズに大きく依存し、ユーザーは特定のユースケースに合わせたカスタムツールをPythonで実装することを強く推奨します。DSDL 5.2では、2つの例として以下の関数ツールを提供しています：SplunkイベントのサーチとVectorDBの類似サーチです。

以下の例では、LLMに次のクエリが提示されます：

Search Splunk events in index _internal and sourcetype splunkd from 510 minutes ago to 500 minutes ago containing keyword Socket error, look for similar records from vectorDB collection phoebe_log_message and tell me what might be going on.

このクエリを受け取ると、LLMは自動的に2つの利用可能な関数ツールを実行して、SplunkインデックスとVectorDBコレクションから結果を取得します。これらの結果は、LLMによって最終的な出力を生成するために使用されます。このサンプルダッシュボードでは、LLMの応答が出力パネルに表示され、2つの関数ツールの実行結果も表示されます。

まとめ

Splunk DSDLバージョン5.2のリリースでは、上記に示したLLM-RAG機能を提供しており、これらは特定のユースケースに合わせて柔軟で拡張可能です。詳細については、Splunkのドキュメントをご確認ください。

Note: This project is conducted during my rotation in the GTS Global Architect team. I’d like to acknowledge the work and time of a number of amazing colleagues in researching, developing and refining these ideas: 

• Philipp Drieger
• Joshua Cowling
• Paul Davies
• Tatsu Murata