次の方法で共有


Databricks での生成 AI アプリの概要

Mosaic AI は、検索拡張生成 (RAG) チャットボットからツール呼び出しエージェントまで、シンプルで複雑な Gen AI アプリケーションの両方をサポートします。 Gen AI アプリとエージェント システムの背後にある主要な概念について説明し、一般的な設計パターンを調べ、Gen AI アプリの構築、評価、スケーリングに関するチュートリアルを実際に使用します。

GEN AI アプリの概念について学習する

基本的な Gen AI アプリの概念について理解します。

モザイク AI が Gen AI 開発中の主要な課題にどのように対処するかについて説明します。

モザイク AI を使用して Gen AI アプリを構築する

次のノートブックチュートリアルを始めましょう。

複雑さを増す準備ができたら、高度なガイドとチュートリアルを参照してください。

Gen AI アプリとは

Gen AI アプリは、生成 AI モデル (LLM、画像生成モデル、テキスト読み上げモデルなど) を使用して新しい出力を作成したり、複雑なタスクを自動化したり、ユーザー入力に基づいてインテリジェントな対話を行ったりするアプリケーションです。 Gen AI アプリではさまざまなモデルを使用できますが、このガイドでは LLM を利用したアプリケーションに重点を置きます。

LLM を利用した Gen AI アプリはさまざまな方法で構築できますが、一般に、次の 2 つのアーキテクチャ パターンのいずれかに該当します。

型 1: モノリシック LLM + プロンプト タイプ 2 (推奨): エージェント システム
それはなんですか。 慎重に設計されたプロンプトを含む 1 つの LLM。 単純なチェーンから高度なマルチエージェント システムまで、複数の対話コンポーネント (LLM 呼び出し、レトリバー、API 呼び出し) が一緒に調整されます。
ユース ケースの例 コンテンツ分類: LLM を使用してカスタマー サポート チケットを定義済みのトピックに分類する。 インテリジェント アシスタント: ドキュメントの取得、複数の LLM 呼び出し、および外部 API を組み合わせて、包括的なレポートの調査、分析、生成を行います。
最適な用途 シンプルで焦点を絞ったタスク、簡単なプロトタイプ、明確で明確に定義されたプロンプト。 複雑なワークフロー、複数の機能を必要とするタスク、および前の手順のリフレクションを必要とするタスク。
主な利点 実装がシンプルになり、開発が高速化され、運用の複雑さが少なくなります。 信頼性と保守性が向上し、制御と柔軟性が向上し、テストと検証が容易になり、コンポーネント レベルの最適化が可能になります。
制限事項 柔軟性が低く、最適化が難しく、機能が限られています。 より複雑な実装、より多くの初期セットアップ、およびコンポーネントの調整が必要です。

ほとんどのエンタープライズ ユース ケースでは、Databricks は エージェント システムを推奨します。 システムをより小さく明確に定義されたコンポーネントに分割することで、開発者は複雑さを管理しながら、エンタープライズ アプリケーションに必要な高度な制御とコンプライアンスを維持できます。

Mosaic AI にはモノリシック システムとエージェント システムの両方で機能するツールと機能があり、このドキュメントの残りの部分では、両方の種類の Gen AI アプリの構築について説明します。

エージェント システムとモノリシック モデルの背後にある理論の詳細については、 Databricks の創設者からのブログ記事を参照してください。

エージェント システムとは

エージェント システムは、 目標を達成するために、環境で自律的に認識、決定、および行動できる AI 駆動型システムです。 プロンプトが表示された場合にのみ出力を生成するスタンドアロン LLM とは異なり、エージェント システムにはある程度の 機関があります。 最新の LLM ベースのエージェント システムでは、コンテキストを解釈し、次に何を行うかについての理由を解釈し、API 呼び出し、取得メカニズム、タスクを実行するためのツール呼び出しなどのアクションを発行するために、LLM を "頭脳" として使用します。

エージェント システムは、LLM をコアとするシステムです。 そのシステム:

  1. 別のエージェントからユーザー要求またはメッセージを受信します。
  2. 続行方法に関する理由: フェッチするデータ、適用するロジック、呼び出すツール、ユーザーにさらに入力を要求するかどうか。
  3. プランを実行し、場合によっては複数のツールまたはデリゲートをサブエージェントに呼び出します。
  4. 回答を返すか、ユーザーに追加の説明を求めます。

エージェント システムは 、一般的なインテリジェンス (LLM の事前トレーニング済み機能) と データ インテリジェンス (ビジネスに固有の専門知識と API) をブリッジすることで、高度なカスタマー サービス フロー、データ豊富な分析ボット、複雑な運用タスクに対するマルチエージェント オーケストレーションなどの影響の大きいエンタープライズユース ケースを実現します。

エージェント システムでできること

エージェント システムは次のことができます。

  • アクションを動的に計画する
  • あるステップから次のステップに状態を伝達する
  • 継続的な人間の介入なしに新しい情報に基づいて戦略を調整する

スタンドアロンの LLM が要求されたときに旅行スケジュールを出力する場合、エージェント システムはツールと API を利用して顧客情報を取得し、フライトを自律的に予約できます。 LLM の "一般的なインテリジェンス" と "データ インテリジェンス" (ドメイン固有のデータまたは API) を組み合わせることで、エージェント システムは、単一の静的モデルが解決に苦労する高度なエンタープライズ ユース ケースに取り組むことができます。

エージェンシーは連続体である。システムの動作を制御するモデルに与える自由度が高いほど、アプリケーションはよりエージェンシー的になります。 実際には、ほとんどの運用システムでは、コンプライアンスと予測可能性を確保するためにエージェントの自律性を慎重に制限します。たとえば、危険なアクションに対して人間の承認を要求します。

一般的なインテリジェンスとデータ インテリジェンス

一般的なインテリジェンスとデータ インテリジェンスを比較した図。

  • 一般的なインテリジェンス: LLM が多様なテキストに対する広範な事前トレーニングから本質的に認識しているものを指します。 これは、言語の流暢さと一般的な推論に役立ちます。
  • データ インテリジェンス: 組織のドメイン固有のデータと API を参照します。 これには、顧客レコード、製品情報、ナレッジ ベース、または独自のビジネス環境を反映したドキュメントが含まれる場合があります。

エージェント システムは、次の 2 つの観点を組み合わせています。LLM の広範な一般的な知識から始まり、リアルタイムまたはドメイン固有のデータを取り込んで詳細な質問に回答したり、特殊なアクションを実行したりします。

エージェント システムの例

Gen AI アプリに対する顧客の対話のフローチャート。

顧客と Gen AI エージェントの間のコール センター シナリオについて考えてみましょう。

顧客が "前回の注文を返すのを手伝ってもらえますか" という要求を行います。

  1. 理由とプラン: クエリの意図を考えると、エージェントは "プラン": "ユーザーの最近の注文を検索し、返品ポリシーを確認します"。
  2. 情報の検索 (データ インテリジェンス): エージェントは注文データベースを照会して関連する注文を取得し、ポリシー ドキュメントを参照します。
  3. 理由: エージェントは、その順序が返品ウィンドウに収まるかどうかを確認します。
    • オプションの human-in-the-loop: エージェントは追加のルールをチェックします。アイテムが特定のカテゴリに分類されるか、通常の返品ウィンドウの外にある場合は、人間にエスカレートします。
  4. アクション: エージェントは返品プロセスをトリガーし、配送先住所ラベルを生成します。
  5. 理由: エージェントは顧客に対する応答を生成します。

AI エージェントは、顧客に対して "完了! こちらが発送ラベルです。

これらの手順は、人間 のコールセンターにおいては当たり前のことです。 エージェント システム コンテキストでは、LLM は特殊なツールまたはデータ ソースを呼び出して詳細を入力する一方で、"理由" を示します。

エージェント システムが使用するツールとデータ ソース。

複雑さのレベル: LLM からエージェント システムへ

AI システムを構築するときに、いくつかのレベルの複雑さが発生する場合があります。

  • LLM (LLM + プロンプト)

    • スタンドアロンの LLM は、膨大なトレーニング データセットからの知識に基づいてテキスト プロンプトに応答します。
    • 単純または汎用的なクエリに適していますが、多くの場合、実際のビジネス データから切断されます。

    LLM がユーザーに応答する

  • ハードコーディングされたエージェント システム ("Chain")

    • 開発者は、決定論的な定義済みの手順を調整します。 たとえば、RAG アプリケーションは常にベクター ストアから取得し、結果をユーザー プロンプトと組み合わせることができます。
    • ロジックは固定されており、LLM は次に呼び出すツールを決定しません。

    ハードコーディングされたツールチェーン

  • ツール呼び出しエージェント システム

    • LLM は、使用するツールと実行時に使用するタイミングを決定します。
    • このアプローチでは、CRM データベースや Slack 投稿 API など、呼び出すツールに関する動的なコンテキスト対応の決定がサポートされます。

    AI エージェントは、計画を合理化し、ツールを使用して実行します。

  • マルチエージェント システム

    • 独自の関数またはドメインを持つ複数の特殊なエージェント。
    • コーディネーター (場合によっては AI スーパーバイザー、場合によってはルールベース) は、各ステップで呼び出すエージェントを決定します。
    • エージェントは、会話フロー全体を維持しながら、タスクを相互に渡すことができます。

    コーディネーターは、複数の AI エージェントを管理します。

LLM を使用するアプリケーションをビルドするときは、単純に開始します。 柔軟性やモデル主導の意思決定を向上させるために本当に必要な場合は、より複雑なエージェント動作を導入します。 確定的なチェーンは、明確に定義されたタスクに対して予測可能なルールベースのフローを提供しますが、より複雑で潜在的な待機時間を犠牲にしてエージェント的なアプローチが増えます。

Mosaic AI Agent Framework は、これらのパターンに依存しないため、簡単に開始でき、アプリケーションの要件が拡大するにつれて、より高度な自動化と自律性に向けて進化します。

エージェント システムのツール

エージェント システムのコンテキストでは、ツールは、明確に定義されたタスクを実行するために LLM が呼び出す可能性がある 単一対話関数 です。 AI モデルは通常、各ツール呼び出しのパラメーターを生成し、ツールは入力と出力の簡単な対話を提供します。 ツール側にマルチターン メモリはありません。

一般的なツール カテゴリには、次のようなものがあります。

  • データを取得または分析するツール
    • ベクター取得ツール: ベクター インデックスにクエリを実行して、最も関連性の高いテキスト チャンクを見つけます。
    • 構造化された取得ツール: デルタ テーブルにクエリを実行するか、API を使用して構造化情報を取得します。
    • Web 検索ツール: インターネットまたは内部 Web コーパスを検索します。
    • クラシック ML モデル: ML モデルを呼び出して、scikit-learn や XGBoost モデルなどの分類または回帰予測を実行するツール。
    • Gen AI モデル: コードやイメージの生成など、特殊な生成を実行し、結果を返すツール。
  • 外部システムの状態を変更するツール
    • API 呼び出しツール: CRM エンドポイント、内部サービス、または "出荷状態の更新" などのタスクに対するその他のサードパーティ統合。
    • コード実行ツール: サンドボックス内でユーザー指定の (または場合によっては LLM によって生成される) コードを実行します。
    • Slack または電子メールの統合: メッセージを投稿するか、通知を送信します。
  • ロジックを実行したり、特定のタスクを実行したりするツール
    • コード 実行ツール: Python スクリプトなど、ユーザーが指定したコードまたは LLM によって生成されたコードをサンドボックスで実行します。

Mosaic AI エージェント ツールの詳細については、 AI エージェント ツールを参照してください。

ツールの主な特性

エージェント システムのツール:

  • 明確に定義された 1 つの操作を実行します。
  • その 1 回の呼び出しを超えて継続的なコンテキストを維持しないでください。
  • エージェント システムが LLM が直接アクセスできない外部データまたはサービスにアクセスできるようにします。

ツールのエラー処理と安全性

各ツール呼び出しは外部操作 (API の呼び出しなど) であるため、タイムアウト、エラー処理の形式が正しくない応答、無効な入力など、エラーを適切に処理する必要があります。 運用環境では、許可されるツール呼び出しの数を制限し、すべてのツール呼び出しが失敗した場合はフォールバック応答を持ち、エージェント システムが同じ失敗したアクションを繰り返し試行しないようにガードレールを適用します。

詳細情報