メインコンテンツへジャンプ

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

Share this post

Summary

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

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

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

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

Databricks Mosaic AIエージェントフレームワーク:

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

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

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

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

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

コアコンポーネント: 

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

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

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

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

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

メモリ:

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

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

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

プランナー:

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

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

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

ツール: 

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

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

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

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

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

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

エンティティ関係図

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

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

コードスニペット:(SQL) 注文詳細

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

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

sql
CREATE OR REPLACE FUNCTION 
mosaic_agent.agent.return_order_details (
  input_order_id STRING COMMENT 'クエリから検索する注文詳細' 
)
returns table(OrderID STRING, 
              Order_Date Date,
              Customer_ID STRING,
              Complaint_ID STRING,
              Shipment_ID STRING,
              Product_ID STRING
              )
comment "この関数は指定されたOrder IDの注文詳細を返します。戻りフィールドには、日付、製品、顧客詳細、クレーム、出荷IDが含まれます。この関数は、注文IDが与えられたときに使用します。質問はさまざまな形で来ることがあります"
return 
(
  select Order_ID,Order_Date,Customer_ID,Complaint_ID,Shipment_ID,Product_ID
  from mosaic_agent.agent.blog_orders
  where Order_ID = input_order_id 
  )

コードスニペット:(SQL)出荷詳細

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

sql
CREATE OR REPLACE FUNCTION 
mosaic_agent.agent.return_shipment_details (
  input_shipment_id STRING COMMENT 'The Shipment ID received from the query' 
)
returns table(Shipment_ID STRING, 
              Shipment_Provider STRING,
              Current_Shipment_Date DATE,
              Shipment_Current_Status STRING,
              Shipment_Status_Reason STRING


              )
comment "This function returns the Shipment details for a given Shipment ID. The return fields include shipment details.Use this function when Shipment ID is given. The questions may come in different form"
return 
(
    select Shipment_ID,
    Shipment_Provider , 
    Current_Shipment_Date , 
    Shipment_Current_Status,
    Shipment_Status_Reason
  from mosaic_agent.agent.blog_shipments_details
  where Shipment_ID = input_shipment_id 
  )

コードスニペット:(Python) 

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

python
CREATE OR REPLACE FUNCTION
mosaic_agent.agent.web_search_tool (
  user_query STRING COMMENT 'ユーザーがウェブを検索するためのクエリ'
)
RETURNS STRING
LANGUAGE PYTHON
DETERMINISTIC
COMMENT 'この関数は、提供されたクエリでウェブを検索します。この関数は、顧客が競合するオファー、割引などについて尋ねたときに使用します。これはウェブを検索して実行する必要があると評価します。'
AS 
$$


  import requests
  import json
  import numpy as np
  import pandas as pd
  import json
  url = 'https://<databricks workspace URL>/serving-endpoints/web_search_tool_API/invocations'
  headers = {'Authorization': f'Bearer token, 'Content-Type': 'application/json'}


  response = requests.request(method='POST', headers=headers,
url=url, 
data=json.dumps({"dataframe_split": {"data": [[user_query]]}}))


  return response.json()['predictions']

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

タスクを実行するツール

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関数(ツール)を使用したエージェントを構築する必要があります。

python(Auto-detected)
langchain_community.tools.databricksからUCFunctionToolkitをインポートします


def display_tools(tools):
    display(pd.DataFrame([{k: str(v) for k, v in vars(tool).items()} for tool in tools]))


tools = (
    UCFunctionToolkit(
        # UC関数を実行するためにはSQLウェアハウスIDが必要です
        warehouse_id=wh.id
    )
    .include(
        # その資格名を使用して、関数をツールとして含めます。
        # "{catalog_name}.{schema_name}.*"を使用して、スキーマ内のすべての関数を取得することができます。
        "mosaic_agent.agent.*"
    )
    .get_tools()
)

d

エージェントの作成:

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

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

from langchain.agents import AgentExecutor, create_tool_calling_agent
from langchain_core.prompts import ChatPromptTemplate
from langchain_community.chat_models import ChatDatabricks


# ChatDatabricksを介したFoundational Model APIを利用する


llm = ChatDatabricks(endpoint="databricks-meta-llama-3-1-70b-instruct")


# モデルのプロンプトを定義する、ツールの使用方法に注意を払う
prompt = ChatPromptTemplate.from_messages(
    [(
        "system",
        "あなたは大手オンライン小売会社の役立つアシスタントです。情報を得るためにツールを使用してください。ツールの説明を参照し、各ユーザーの問い合わせに対して呼び出すツールを決定してください。",
        ),
        ("placeholder", "{chat_history}"),
        ("human", "{input}"),
        ("placeholder", "{agent_scratchpad}"),
    ]
)

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

from langchain.agents import AgentExecutor, create_tool_calling_agent


agent = create_tool_calling_agent(llm, tools, prompt)
agent_executor = AgentExecutor(agent=agent, tools=tools, verbose=True)

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

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

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

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

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

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

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

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

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

メモリ:

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

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

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

from langchain_core.runnables.history import RunnableWithMessageHistory
from langchain.memory import ChatMessageHistory


memory = ChatMessageHistory(session_id="simple-conversational-agent")


agent = create_tool_calling_agent(llm, tools, prompt)
agent_executor = AgentExecutor(agent=agent, tools=tools, verbose=True)


agent_with_chat_history = RunnableWithMessageHistory(
    agent_executor,
    lambda session_id: memory,
    input_messages_key="input",
    history_messages_key="chat_history",
)

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

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

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

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

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

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

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

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

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

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

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

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

エージェントデモ

結論: 

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

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

 

参考文献&資料:

Mosaic AI: Build and Deploy Production-quality AI Agent Systems 

Mosaic AI Agent FrameworkとAgent Evaluationの発表 | Databricks Blog

Mosaic AI エージェントフレームワーク|Databricks

モデルから複合AIシステムへのシフト - バークレー人工知能研究ブログ 

React: 言語モデルにおける推論と行動のシナジー 

Reflexion: Language agents with verbal reinforcement learning 

リフレクションエージェント 

LLMエージェント:究極のガイド | SuperAnnotate 

LLMエージェントのメモリ - DEVコミュニティ 

大規模言語モデルに基づく自律エージェントに関する調査 arXiv:2308.11432v5 [cs.AI] 2024年4月4日

同じスレッド上で複数のエージェントを実行する方法

Databricks 無料トライアル

関連記事

Mosaic AI Agent Framework および Agent Evaluation の発表

Databricks は 、Data + AI Summit 2024 で、 生成 AI クックブック とともに、Mosaic AI Agent Framework および Agent Evaluation の パブリック プレビュー を 発表...

Mosaic AI:本番運用のための複合AIシステムの構築とデプロイ

Translation Review by saki.kitaoka 過去1年間で、一般知識タスクにおける優れた推論能力を示す商用およびオープンソースの基礎モデルの急増を目の当たりにしました。 一般モデルは重要な構成要素ですが、実際のAIアプリケーションは、調整されたモデル、検索、ツールの使用、および推論エージェントなど、複数のコンポーネントを活用する 複合AIシステム が採用されることが多くなっています。AIシステムは基礎モデルを強化し、品質を大幅に向上させることで、顧客がこれらの生成AIアプリケーションを自信を持って運用に導入できるようにします。 本日、Data and AI Summitで、Databricks Mosaic AIが本格的なAIシステムを構築するための最良のプラットフォームとなる新機能を発表しました。これらの機能は、数千の企業と協力してAI駆動アプリケーションを運用に投入してきた経験に基づいています。本日の発表には、基礎モデルのファインチューニングのサポート、AIツールのエンタープライズカタ
生成 AI一覧へ