SOAR & DSDL：エージェンティックAIワークフローの設計と実行

背景

最近、Splunk App for Data Science and Deep Learning（DSDL）v5.2.0がリリースされました。このアップデートでは、大規模言語モデル（LLM）や検索拡張生成（RAG）と連携するための新機能が追加されました。DSDL v5.2.0では、ユーザーはアプリのダッシュボードから、LLMプロンプトの実行、ベクター検索、RAG、Function Calling などを簡単に行うことができます。これらの機能はDSDLコンテナ内のあらかじめ定義されたスクリプトと共に提供されるため、組織は自社のナレッジデータやSplunkにインデックスされたデータを使って、迅速にLLMを活用し始めることができます。

一方で、アナリストがより自分たちのニーズに合わせてワークフローをカスタマイズしたい場合、たとえば、LLMにベクターコレクションを選ばせ、その選択に基づいてRAGを実行させるような場合、には、コンテナ内のPythonスクリプトを修正したり、複数のFitコマンドを用いた複雑なSPLコマンドを作成する必要があります。この方法は複雑であり、エンドユーザーがカスタムワークフローを設計・テストするためのシンプルでビジュアルなインターフェースが不足しているため、LLM-RAG機能の実用的な活用に限界が生じることがあります。

幸いなことに、Splunk SOARは自動化とオーケストレーション分野で注目されており、ワークフローの設計やテストのための直感的なユーザーインターフェースを提供しています。本ブログでは、DSDLの機能を活用し、SOARをプラットフォームとしてエージェンティックAIワークフローを設計・実行する方法を紹介します。

アーキテクチャ

本提案のアーキテクチャは下図のようになっており、エージェンティックワークフローはSOARプレイブックとして作成されます。ここでは、LLMプロンプト、ベクター検索、Function Calling などのユーティリティ（utility）と呼ばれる基本的な構成要素を使用します。これらのユーティリティはSOAR内のカスタム関数（custom function）によって実現されており、各操作を実行する時にFastAPI経由でDSDLコンテナへリクエストを送ります。

LLM関連のユーティリティに加えて、既存のSOARツールもプレイブックに統合できるため、LLMの観察結果や判断に基づいたアクションを実行することが可能です。この統合により、高度なエージェンティックAIワークフローを開発するための大きな可能性が広がります。

このブログでは、カスタム関数の作成方法について詳しく解説し、プレイブックの例を紹介します。

カスタム関数

SOARのカスタム関数を利用することで、ユーザーはユーティリティとして実行されるPython関数を定義できます。これらはプレイブックの基本的な構成要素の一つです。今回は、エージェンティックAIワークフロー向けに以下の4つのカスタム関数を実装しました。

1. ベクター検索：vectorDBコレクションに対して類似度検索を行い、コンテキストを取得します。
2. LLMプロンプト：フォーマットされたクエリとコンテキストでLLMにプロンプトを送り、レスポンスを取得します。
3. LLM Function Calling：Splunkサーチを含む一連の関数ツールを実行し、LLMがクエリに回答します。
4. LLM意思決定：ユーザーが定義したラベルに基づいてLLMに意思決定を行います。

最初の3つの機能はDSDL 5.2.0でサポートされていますが、LLM意思決定機能についてはDSDLコンテナに新しいスクリプトを追加しました。（このスクリプトは次回のDSDLリリースで組み込まれ、利用可能となります。）これらの機能をSOARで利用するには、それぞれのカスタム関数をDSDLコンテナの該当スクリプトへFastAPI経由で呼び出すように実装します。カスタム関数の入力パラメータには、DSDLスクリプトで必要となるパラメータに加え、DSDLコンテナFastAPIのエンドポイントやAPIトークンなども含まれます。

以下は、LLMプロンプト用カスタム関数のサンプルコードです。

Python
def llm_prompt(query=None, model_name=None, api_endpoint=None, api_token=None, llm_service=None, system_prompt=None, **kwargs):
    ############################ Custom Code Goes Below This Line #################################
    import json
    import phantom.rules as phantom
    import requests
    import csv
    from io import StringIO
    url = f"{api_endpoint}/fit"
    headers = {
        "Authorization": f"Bearer {api_token}",
        "Content-Type": "application/json"
    }
    if system_prompt:
        system_prompt = system_prompt.replace('"', '').replace('\n', '')
    else:
        system_prompt = "You are an expert Q&A system that is trusted around the world. Always answer the query using the provided context information and reasoning as detailed as possible"
    data = {
        "data": f"text\n\"{system_prompt}\"",
        "meta": {
            "options": {
                "model_name": "llm_rag_ollama_text_processing",
                "params": {
                    "algo": "llm_rag_ollama_text_processing",
                    "llm_service": llm_service,
                    "model_name": model_name,
                    "prompt": query 
                }
            }
        }
    }
    # Send POST request
    outputs = requests.post(url, headers=headers, json=data, verify=False).json()
    df_data = outputs['results']
    df_data = StringIO(df_data)
    csv_reader = csv.DictReader(df_data)
    for row in csv_reader:
        outputs["llm_response"] = row['Result']
    assert json.dumps(outputs)
    return outputs

リクエストはDSDLコンテナのFastAPIエンドポイントに送信されます。ペイロードには「algo」キーの下にスクリプト名と、その他の入力パラメータが含まれています。結果が返されると、それを解析してカスタム関数の出力変数「llm_response」に割り当てます。

他のカスタム関数も同様の方法で実装されています。すべてのカスタム関数は、このGithubリポジトリで公開されています。必要な入力パラメータやアルゴリズム名については、DSDL 5.2.0のドキュメントをご参照ください。
Note：「llm_service」パラメータは、今後のDSDLリリースで新たに導入されるパラメータです。現行バージョンでのパラメータ要件については、DSDL 5.2.0ドキュメント内のFitコマンドを参照してください。

プレイブック

カスタム関数を基に、複数の意思決定ポイントを持つエージェンティックAIワークフローの例として、下図のようなプレイブックを作成しました。

このプレイブックは、自然言語による問い合わせを処理し、リクエストのユースケースに応じて異なるエージェントにルーティングします。本ワークフローでは、以下の3つのシナリオを実現しています：

• ケース1：現在のSplunkサービスのステータスに関する問い合わせ
• ケース2：一般的なSplunk知識に関するQ&A
• ケース3：架空のButtercupオンラインストアに関するQ&A

プレイブックの最初のLLM意思決定ブロックは、クエリがSplunkに関するもの（ケース1または2）か、Buttercupストアに関するもの（ケース3）かを判別します。Splunk関連のクエリの場合、ワークフローは左側にルートされ、2つ目のLLM意思決定ブロックで、クエリがリアルタイムデータ（ケース1）を必要とするのか、静的な知識データ（ケース2）を必要とするのかを特定します。

ケース1：
リアルタイムデータが必要な場合は、Function Callingブロックが実行され、LLMがSplunkサーチツールを使って必要なコンテキストを収集します。その後、LLMはこれらのツールの出力に基づいて最終的な回答を生成します。

ケース2：
Splunkに関する知識が求められる場合、LLMは次の選択肢の中から適切なベクターコレクションを選択します：splunk_platform_knowledge、splunk_enterprise_security_knowledge、splunk_itsi_knowledge。それぞれのコレクションには製品の知識が含まれており、LLMが選んだコレクションを基にベクター検索が行われます。クエリとベクター検索結果はLLMに送られ、要約された回答が生成されます。

ケース3：
最初の意思決定ブロックでクエリがButtercupエージェントにルーティングされた場合、LLMはbuttercup_dev_knowledgeまたはbuttercup_support_ticketsから最も関連性の高いベクターコレクションを選択します。ベクター検索が実行され、LLMはその検索結果に基づいてクエリに回答します。

このプレイブック例では、各ステップの出力はSOAR上のイベントに紐づくノートとして記録されます。それでは次に、このワークフローがどのように動作するか、3つの例を見ていきましょう。

実行例

例1：
最初の例では、入力クエリは「私のSplunkにはどのようなインデックスがありますか？」となります。

ワークフロー実行の結果は下図に示されています。左側にはLLMによる最終的な回答が表示され、右側にはワークフロー実行の各ステップが示されています。

LLMの意思決定に基づき、このクエリは「Function Callingブロック」へルーティングされました。list_indexes()ツールが実行され、その出力をもとにLLMが最終回答を生成しました。

例2：
2つ目の例では、入力クエリは「Splunkプラットフォームでサービスポートを表示するCLIコマンドは何ですか？」となります。

LLMの意思決定に基づき、このクエリは「Splunkエージェント」、そして「knowledge_dataコンテキストタイプ」へルーティングされました。その後、「splunk_platform_knowledge」コレクションが選択され、検索が実行されました。ベクター検索の出力をもとにLLMが最終的な回答を生成しました。

例3：

3つ目の例では、入力クエリは「支払いに関する問題はありましたか？また、それらはどのように解決されましたか？」となります。

LLMの意思決定に基づき、このクエリは「Buttercupエージェント」にルーティングされ、その後、「buttercup_support_tickets」コレクションが選択されて検索が実行されました。ベクター検索の出力をもとにLLMが最終的な回答を生成しました。

上記の例のように、SOAR上で作成したこのエージェンティックAIワークフローは、自然言語入力に応じてさまざまなシナリオに対応し、各種ツールを連携させてLLMによる高精度な生成のためのコンテキストを取得します。SOARを用いることで、プレイブックの作成はシンプルかつ直感的であり、各ステップごとにテストやエクスポートによる共有も容易に行えます。

結論

本ブログでは、SOARをプラットフォームとして活用し、DSDLが提供する機能を用いてエージェンティックAIワークフローを設計・実行する方法を紹介しました。さらに、DSDLは意思決定やデータエンリッチメントのプロセスを強化し、SOARプレイブックの機能を拡張します。例えば、セキュリティのユースケースにおいては、LLMエージェントが最新の脅威インテリジェンスを収集し、インシデントの緊急度を評価し、SOARツールを使ってアクションを実行することが可能です。DSDLとSOARの統合により、SOARワークフロー内でAIの力を活用する幅広い可能性が広がります。