2024年11月26日

Databricksエージェントフレームワークで自律AIアシスタントを構築する

Archived. This article has not been updated since the publish date above. The dynamic nature of information means that previously accurate content can become outdated or even obsolete over time. Readers are advised to exercise due diligence and cross-check any information found in this blog post before making decisions or adopting any practices based on said information.

大規模言語モデルは、高度な自然言語処理を活用して複雑なタスクを実行することで、私たちがテクノロジーと対話する方法を革新しています。
LLMエージェントは、推論、先を見越した思考、過去の会話を覚えておく、さまざまなツールを使用して応答を調整する必要がある複雑なタスクを実行するために設計された次世代の高度なAIシステムです。
Databricksエージェントフレームワークは、開発者が任意のLLMを通じてプロダクション規模のエージェントシステムを構築することを可能にし、カスタマイズを可能にし、エージェントが自律的な決定を下すことを強化します。

大規模言語モデルは、高度な自然言語処理を活用して複雑なタスクを実行することで、私たちがテクノロジーと交流する方法を革新しています。近年では、最先端のLLMモデルが幅広い革新的なアプリケーションを可能にしてきました。昨年は、RAG（Retrieval Augment generation）に向けたシフトが見られ、ユーザーは自組織のデータ（ベクトル埋め込みを通じて）をLLMに供給することで、対話型AIチャットボットを作成しました。

しかし、まだ表面をかすっているだけです。強力ではありますが、「Retrieval Augment Generation」は私たちのアプリケーションを静的な知識の取得に制限します。内部データからの質問にだけ答えるのではなく、行動も最小限の人間の介入で取る典型的なカスタマーサービスエージェントを想像してみてください。LLMを使用すれば、ユーザーのクエリに対して単に応答するだけでなく、行動する完全自動化された意思決定アプリケーションを作成することができます。可能性は無限大で、内部データ分析からウェブ検索まで何でも可能です。

大規模言語モデルのセマンティック理解と言語能力により、ユーザーのクエリに基づいて回答だけでなく「行動」も可能な完全自動化された意思決定アプリケーションを作成することができます。

Databricksエージェントフレームワーク：

DatabricksはDatabricks Agentフレームワークを立ち上げ、開発者が任意のLLMを通じて生産規模のエージェントフレームワークを構築できるようにしました。主な機能の一つは、Databricks上でツールを作成し、生産品質のAIエージェントを構築、デプロイ、評価するためのものです。これには、Retrieval Augmented Generation（RAG）アプリケーションなどが含まれます。開発者はエージェントを作成し、ログに記録することができ、任意のライブラリを使用してそれらをMLFlowと統合できます。エージェントをパラメータ化して、開発を迅速に試行錯誤することができます。エージェントトレーシングを利用すると、開発者はログを記録し、分析し、トレースを比較して、エージェントがリクエストにどのように応答するかをデバッグし、理解することができます。

このブログの最初の部分では、エージェントとそのコアコンポーネントを探求し、オンライン小売会社のための自律的なマルチターンのカスタマーサービスAIエージェントを、プラットフォーム上で最も性能の良いオープンソースで公開された Databricks Foundational Model (基盤モデル)を用いて構築します。次のブログシリーズでは、マルチエージェントフレームワークを探求し、同じビジネスアプリケーションのための高度なマルチステップ推論マルチエージェントを構築します。

LLMエージェントとは何ですか？

LLMエージェントは、推論が必要な複雑なタスクを実行するために設計された次世代の高度なAIシステムです。彼らは先を考え、過去の会話を覚えており、状況や必要なスタイルに基づいて反応を調整するためのさまざまなツールを使用することができます。

RAGの自然な進化として、LLMエージェントは、最先端の大規模言語モデルが外部システム/ツールや機能を活用して自律的な決定を下すアプローチです。複合AIシステムでは、エージェントはメモリ、内省能力、ツールの使用、その他多くを備えた意思決定エンジンと考えることができます。彼らを学習し、推論し、自律的に行動できる超スマートな意思決定エンジンと考えてみてください - これが真に自律的なAIアプリケーションを作成する究極の目標です。

コアコンポーネント:

エージェント型アプリケーションの主要な要素には、次のようなものがあります：

LLM/セントラルエージェント：これはワークフローの中心的な意思決定コンポーネントとして機能します。
メモリ：過去の会話とエージェントの以前の応答を管理します。
プランニング：エージェントが将来のタスクを実行するための計画を立てるコアコンポーネントです。
ツール：特定のタスクを実行し、メインのLLMと対話するための関数とプログラム。

セントラルエージェント：

エージェントフレームワークの主要な要素は、データを処理し理解することができる事前に訓練された汎用的な大規模言語モデルです。これらは一般的に高性能な事前訓練モデルであり、これらのモデルとの対話は、必要なコンテキストを提供する特定のプロンプトを作成することから始まります。これにより、どのように応答するか、どのツールを活用するか、対話中に達成すべき目標は何かを指導します。

エージェントフレームワークはカスタマイズを可能にし、モデルに独自のアイデンティティを割り当てることができます。これにより、特定のタスクやインタラクションの要求により適合するように、その特性や専門知識を調整することができます。結局のところ、LLMエージェントは高度なデータ処理能力とカスタマイズ可能な機能をシームレスに組み合わせ、多様なタスクを精度と柔軟性で処理するための貴重なツールとなります。

メモリ：

メモリはエージェントのアーキテクチャの重要なコンポーネントです。エージェントが会話を保存するために使用する一時的なストレージとして利用されます。LLMエージェントが現在の情報と直接的なコンテキストを保持し、タスクが完了したらメモリをクリアする短期的なワーキングメモリであることができます。

一方、長期記憶（時々エピソード記憶と呼ばれる）は長期間の会話を保持し、エージェントがパターンを理解し、以前のタスクから学習し、将来のインタラクションでより良い決定を下すための情報を思い出すのに役立ちます。この会話は通常、外部のデータベースに保存されます。（例 - ベクトルデータベース）。

これら二つのメモリの組み合わせにより、エージェントは時間の経過とともにユーザーの好みに基づいてより適切なレスポンスを提供し、より良く機能することができます。ただし、エージェントのメモリとLLMの会話メモリを混同しないでください。両者は異なる目的を果たします。

プランナー：

LLMエージェントの次のコンポーネントは、複雑なタスクを管理可能なタスクに分解し、各タスクを実行するための計画能力です。計画を立てる際、プランナーコンポーネントは思考の連鎖推論や階層的推論など、複数の推論手法を利用して、どの道を進むべきかを決定することができます。

計画が作成されると、エージェントはさまざまな内部フィードバックメカニズムを通じてその効果をレビューし評価します。一般的な方法にはReActとReflexionがあります。これらの方法は、LLMが一連の思考を繰り返し、結果を観察することで複雑なタスクを解決するのに役立ちます。このプロセスは反復的な改善のために繰り返されます。

典型的なマルチターンチャットボットでは、単一のLLMエージェントが計画とオーケストレーションを行いますが、マルチエージェントフレームワークでは、ルーティングや計画などの特定のタスクを別のエージェントが実行するかもしれません。これについては、ブログの次の部分でさらに詳しく説明します。

ツール:

ツールはエージェントの構築ブロックであり、セントラルコアエージェントの指導に従ってさまざまなタスクを実行します。ツールは、API呼び出し、PythonまたはSQL関数、ウェブ検索、コーディング、Databricks Genie spaceまたはツールが機能するために必要な他のものなど、任意の形式でのさまざまなタスク実行者になることができます。ツールの統合により、LLMエージェントはワークフローを通じて特定のタスクを実行し、観察を集め、サブタスクを完了するために必要な情報を収集します。

これらのアプリケーションを構築する際に考慮すべき一つのことは、インタラクションがどれほど長引くかです。インタラクションが長期間続くと、LLMのコンテキスト制限を簡単に使い果たし、古い会話を忘れる可能性があります。ユーザーとの長い会話中に、決定の制御フローは単一スレッド、並列のマルチスレッド、またはループであることがあります。決定チェーンが複雑になるほど、その実装も複雑になります。

下の図1では、単一の高性能LLMが意思決定の鍵となります。ユーザーの質問に基づいて、どのルートを取るべきかを理解します。特定のアクションを実行するために複数のツールを利用し、中間結果をメモリに保存し、その後の計画を行い、最終的に結果をユーザーに返すことができます。

単一の高性能LLMが意思決定の鍵となります。ユーザーの質問に基づいて、どの道をたどるべきかを理解し、決定フローをルーティングします。特定のアクションを実行するために複数のツールを利用し、中間結果をメモリに保存し、その後の計画を行い、最終的に結果をユーザーに返すことができます。

オンライン小売のための会話型エージェント：

このブログの目的のために、私たちはDatabricksエージェントフレームワークを通じてオンライン電子小売業者のための自律的なカスタマーサービスAIアシスタントを作成します。このアシスタントは顧客と対話し、彼らの質問に答え、ユーザーの指示に基づいて行動を行います。私たちは人間をループに導入して、アプリケーションの応答を確認することができます。私たちはDatabricksのツール機能を使用して、Unityカタログ内に私たちのツールを作成し登録します。以下は、ブログのために作成したエンティティ関係（合成データ）です。

エンティティ関係図

以下は、私たちのユースケースのためのシンプルなプロセスフロー図です。

シンプルなエージェントフレームワークのプロセスフロー

コードスニペット：（SQL） 注文詳細

以下のコードは、ユーザーが提供した注文IDに基づいて注文詳細を返します。入力フィールドの説明とコメント 関数のフィールドに注意してください。LLMが適切に関数/ツールを呼び出すためには、関数とパラメータのコメントをスキップしないでください。

コメントは、ユーザーのクエリに基づいてどの関数を実行するかを決定するためのメタデータパラメータとして、私たちの中央LLMによって利用されます。不正確または不十分なコメントは、LLMが不正確な関数/ツールを実行する可能性を露呈する可能性があります。

コードスニペット：（SQL）出荷詳細

この関数は、IDが与えられた場合に出荷テーブルから出荷詳細を返します。上記と同様に、メタデータのコメントと詳細は、エージェントがツールと対話するために重要です。

コードスニペット：（Python）

同様に、任意のPython関数を作成し、ツールや関数として使用することができます。それは同様の方法でUnityカタログ内に登録することができ、上記のすべての利点を提供します。下記の例は、私たちが構築し、エージェントが呼び出すエンドポイントとして使用したウェブ検索ツールの例です。

私たちのユースケースのために、以下のような様々なタスクを実行する複数のツールを作成しました：

タスクを実行するツール

return_order_details	注文IDを指定して注文詳細を返す
return_shipment_details	返品詳細は、出荷IDを提供します
return_product_details	商品IDが与えられた場合に商品詳細を返す
return_product_review_details	非構造化データからレビューの要約を返す
search_tool	キーワードに基づいてウェブを検索し、結果を返します
process_order	ユーザーのクエリに基づいて返金リクエストを処理する

Unity Catalog UCFunctionToolkit :
私たちはLangChainオーケストレータを使用して、Databricks UCFunctionToolkitと基本的なAPIモデルと組み合わせてChainフレームワークを構築します。エージェントを構築するための任意のオーケストレータフレームワークを使用することができますが、私たちはUCFunctionToolkitを使用して、UC関数（ツール）を使用したエージェントを構築する必要があります。

エージェントの作成：

ツールが準備できたので、これらをDatabricksでホストされている大規模な言語基盤モデルと統合します。また、自分のカスタムモデルやAIゲートウェイ経由の外部モデルも使用できます。このブログの目的のために、私たちはdatabricks-meta-llama-3-1-70b-instruct Databricksでホストされているものを使用します。

これはメタによるオープンソースモデルで、Databricksで効果的にツールを使用するように設定されています。すべてのモデルが同等であるわけではなく、異なるモデルでは異なるツール使用能力があります。

今、私たちのLLMが準備できたので、LangChain Agent executorを使用してこれらすべてをまとめてエージェントを構築します：

サンプルの質問でこれがどのように見えるか見てみましょう：

顧客として、私がエージェントに特定の製品、「Breville Electrical Kettle」の価格を会社と市場で尋ね始めると、競争力のあるオファーが見えてきます。

質問に基づいて、エージェントは2つの機能/ツールを実行することを理解しました：

return_product_price_details - 内部価格のため
web_search_tool – ウェブを検索するためのもの。

以下のスクリーンショットは、ユーザーの質問に基づいて異なるツールが順次実行される様子を示しています。

最終的に、これら二つの関数/ツールからの応答を元に、エージェントは答えを合成し、以下の応答を提供します。エージェントは自律的に実行する関数を理解し、あなたに代わってユーザーの質問に答えました。なかなか素晴らしいですね！

ユーザーの質問に基づいた異なるツールの順次実行。

MLflow Traceを通じてエージェントの実行をエンドツーエンドで追跡することもできます。これはあなたのデバッグプロセスを大いに助け、各ステップがどのように実行されるかについての明確さを提供します。

MLflow Traceを通じたエージェント実行のエンドツーエンドトレース

メモリ：

エージェントを構築するための重要な要素の一つは、その状態とメモリです。上記で述べたように、各関数は出力を返し、理想的には、マルチターンの会話を持つためには前の会話を覚えておく必要があります。これは、任意のオーケストレータフレームワークを通じて複数の方法で達成することができます。このケースでは、マルチターンの会話型ボットを構築するためにLangChain Agent Memoryを使用します。

LangChainとDatabricks FM APIを通じてこれをどのように達成できるかを見てみましょう。前のエージェントエグゼキュータを利用し、LangChainのChatMessageHistoryとRunnableWithMessageHistoryを追加した追加のメモリを使用します。

ここではデモンストレーションのためにインメモリチャットを使用しています。メモリがインスタンス化されたら、それをエージェントエクゼキュータに追加し、以下のチャット履歴を持つエージェントを作成します。新しいエージェントでのレスポンスがどのように見えるか見てみましょう。

エージェントエグゼキュータを定義したので、エージェントにいくつかのフォローアップの質問をしてみて、会話を覚えているかどうかを確認してみましょう。session_idに注意を払ってください。これは進行中の会話を保持するメモリスレッドです。

エージェントのチャット履歴

いいね！それはユーザーの以前の会話すべてを覚えており、フォローアップの質問も非常にうまく実行できます！エージェントの作成方法と履歴の維持方法を理解したところで、エンドツーエンドの会話チャットエージェントがどのように動作するかを見てみましょう。

私たちはDatabricks AI Playgroundを利用して、エンドツーエンドでどのように見えるかを確認します。Databricks AI Playgroundは、複数のLLMをテスト、プロンプト、比較できるチャットのような環境です。作成したエージェントをサービングエンドポイントとして提供し、Playgroundでエージェントのパフォーマンスをテストすることもできることを覚えておいてください。

マルチターン会話型チャットボット：

私たちは、Databricksエージェントフレームワーク、Databricks Foundational Model API、およびLangChainオーケストレータを使用してAIエージェントを実装しました。

以下のビデオは、私たちが作成したマルチターンエージェントとMeta-llama-3-1-70b-instruct DatabricksのUC関数/ツールとの間の会話を示しています。

これは、顧客と私たちのエージェントとの間の会話の流れを示しており、エージェントは適切なツールを動的に選択し、一連のユーザークエリに基づいてそれを実行し、顧客にシームレスなサポートを提供します。

これは、私たちのオンライン小売店の新しく構築されたエージェントとの顧客の会話フローです。

私たちのオンライン小売店の新しく作成したエージェントとの顧客の会話の流れ。

顧客の名前での注文ステータスの質問開始から注文の発注まで、すべてが人間の介入なしに自動的に行われます。

エージェントデモ

結論:

以上で終わりです！たった数行のコードで、会話し、推論し、お客様の代わりに行動を取ることができる自律的なマルチターンエージェントの力を解放しました。結果は？手動タスクの大幅な削減と自動化の大幅な向上です。しかし、これはまだ始まったばかりです！Databricksエージェントフレームワークは、Databricksでの可能性の世界を開きました。

次回のインストールメントをお楽しみに。そこでは、複数のエージェントが調和して最も複雑なタスクにも取り組むマルチエージェントAIを次のレベルに引き上げます。さらに、MLflowとモデルサービングエンドポイントを介してすべてをデプロイする方法を示します。これにより、データガバナンスを妥協することなく、プロダクション規模のエージェント型アプリケーションを簡単に構築することができます。AIの未来はここにあり、クリック一つで手に入れることができます。