Databricksにおける生成AIアプリの紹介
Mosaic AIは、 アプリケーションAI(AI 世代アプリ) を構築 、 評価 、 デプロイ 、 監視 生成するためのコードファースト プラットフォームです。一般的なオープンソースフレームワークと統合すると同時に、エンタープライズグレードのガバナンス、可観測性、運用ツール(総称してLLMOps)を追加します。
Mosaic AIでのオープンソースサポート
Mosaic AIは、次のような既存のオープンソース 生成AI ライブラリと SDK を補完 するものですが、置き換えるものではありません。
- OpenAI
- LangChain
- LangGraph
- AutoGen
- LlamaIndex
- CrewAI
- Semantic Kernel
- DSPy
Mosaic AIは、組み込みロギング、モニタリング、堅牢なインフラストラクチャ、安全なデプロイオプションを提供することで、これらのフレームワークを使用して、企業向けの高品質な生成AIアプリを大規模に構築できるようにします。重要なのは、Databricks内外で生成AIアプリを構築、ホスティングする場合においても、依然としてMosaic AIの評価と監視の機能を活用できるということです。よりきめ細かく直接的な制御を好むチームのために、Mosaic AIはPythonのみを使用してゼロから構築されたカスタム生成AIアプリもサポートしており、フレームワークは必要ありません。
生成AIアプリとは?
生成 アプリ AI は、生成AI モデル (LLM、画像生成モデル、テキスト読み上げモデルなど) を使用して、新しい出力を作成したり、複雑なタスクを自動化したり、ユーザー入力に基づいてインテリジェントな対話を行ったりするアプリケーションです。 生成 AI アプリではさまざまなモデルを使用できますが、このガイドでは LLM を搭載したアプリケーションに焦点を当てています。
LLMで駆動する生成 アプリ AI はさまざまな方法で組み込みできますが、通常は次の 2 つのアーキテクチャ パターンのいずれかに分類されます。
タイプ 1: モノリシック LLM + プロンプト | タイプ 2 (推奨): エージェント システム | |
---|---|---|
それはなんですか。 | 慎重に設計されたプロンプトを備えた 1 つの LLM。 | 複数の相互作用するコンポーネント(LLMコール、レトリーバー、APIコール)が連携してオーケストレーションされ、単純なチェーンから高度なマルチエージェントシステムまで多岐にわたります。 |
ユースケースの例 | コンテンツ分類: LLMを使用して、顧客サポート チケットを事前定義されたトピックに分類します。 | インテリジェントアシスタント: ドキュメントの取得、複数の LLM コール、外部 APIs を組み合わせて、包括的なレポートを調査、分析、生成します。 |
どのようなタスクにベストなのか | シンプルで焦点を絞ったタスク、迅速なプロトタイプ、明確で明確に定義されたプロンプト。 | 複雑なワークフロー、複数の機能を必要とするタスク、前の手順を振り返る必要があるタスク。 |
主なメリット | 実装の簡素化、開発の迅速化、運用の複雑さの軽減。 | 信頼性と保守性の向上、制御と柔軟性の向上、テストと検証の容易さ、コンポーネント・レベルの最適化。 |
制限事項 | 柔軟性が低く、最適化が難しく、機能が制限されます。 | より複雑な実装、より多くの初期設定、およびコンポーネントの調整が必要です。 |
ほとんどのエンタープライズユースケースでは、Databricks は エージェントシステムを推奨しています。 システムを小さく、明確に定義されたコンポーネントに分割することで、開発者は、エンタープライズ・アプリケーションに必要な高レベルの制御とコンプライアンスを維持しながら、複雑さをより適切に管理できます。
Mosaic AI は、モノリシック システムとエージェント システムの両方で動作するツールと機能を提供し、このドキュメントの残りの部分では、両方のタイプの生成 AI アプリの構築について説明します。
エージェントシステムとモノリシックモデルの背後にある理論の詳細については、 Databricksの創設者のブログ記事を参照してください。
エージェントシステムとは?
エージェントシステムとは、 目標を達成するための環境を自律的に認識し、決定し、行動することができるAI駆動型のシステム です。プロンプトが出されたときにのみ出力を生成するスタンドアロンの LLM とは異なり、エージェント システムにはある程度の エージェンシー があります。最新のLLMベースのエージェントシステムは、LLMを「頭脳」として使用して、コンテキストを解釈し、次に何をすべきかについての推論を行い、API呼び出し、取得メカニズム、タスクを実行するためのツール呼び出しなどのアクションを発行します。
エージェントシステムは、単に LLM を中核とするシステムです。そのシステムは:
- 別のエージェントからユーザー要求またはメッセージを受信します。
- 進め方に関する理由: フェッチするデータ、適用するロジック、呼び出すツール、ユーザーからさらに入力を要求するかどうか。
- プランを実行し、場合によっては複数のツールを呼び出すか、サブエージェントに委任します。
- 回答を返すか、ユーザーに追加の説明を求めます。
エージェント システムは、 一般的なインテリジェンス ( LLMの事前トレーニング済み機能) と データ インテリジェンス (ビジネスに固有の専門知識と APIs ) を橋渡しすることで、高度な顧客サービス フロー、データ豊富なアナリティクス ボット、複雑な運用タスクのためのマルチエージェント オーケストレーションなど、影響力の大きいエンタープライズ ユース ケースを可能にします。
エージェントシステムで何ができるのか?
エージェント・システムでは、次のことができます。
- アクションを動的に計画する
- 1 つのステップから次のステップに状態を運ぶ
- 新しい情報に基づいて戦略を調整し、継続的な人間の介入を伴わない
スタンドアロンの LLM が求められたときに旅行の旅程を出力するのに対し、エージェントシステムは自律的にAPIやツールを活用し、顧客情報を取得し、実際にフライトを予約することができます。 LLMによる「汎用インテリジェンス」と「 データインテリジェンス 」(ドメイン固有のデータまたはAPI)を組み合わせることで、エージェントシステムは、単一の静的モデルでは解決に苦労する高度なエンタープライズユースケースに取り組むことができます。
エージェンシーは連続体です。システムの動作を制御するためのモデルを提供する自由度が高まれば高まるほど、アプリケーションはよりエージェント的になります。実際には、ほとんどの本番運用システムは、コンプライアンスと予測可能性を確保するために、リスクの高いアクションに対して人間の承認を求めるなど、エージェントの自律性を慎重に制限しています。
一般的なインテリジェンスとデータインテリジェンス
- 一般的なインテリジェンス: LLM が多様なテキストに関する広範な事前トレーニングから本質的に知っていることを指します。これは、言語の流暢さと一般的な推論に役立ちます。
- データインテリジェンス: 組織のドメイン固有のデータと APIを指します。 これには、顧客レコード、製品情報、ナレッジ ベース、または独自のビジネス環境を反映したドキュメントが含まれる場合があります。
エージェントシステムは、LLMの広範な一般的な知識から始まり、次にリアルタイムまたはドメイン固有のデータを取り込んで、詳細な質問に答えたり、専門的なアクションを実行したりするという、これら2つの視点を融合させています。
エージェントシステムの例
顧客と AI エージェント世代との間のコール センターのシナリオを考えてみましょう。
顧客は「最後の注文を返品するのを手伝ってもらえますか?」とリクエストします。
-
理由と計画 : クエリの意図を考慮して、エージェントは「ユーザーの最近の注文を検索し、返品ポリシーを確認する」と「計画」します。
-
情報の検索 (データインテリジェンス):エージェントは、注文データベースを照会して関連する注文を取得し、ポリシードキュメントを参照します。
-
理由 : エージェントは、その注文が返品ウィンドウ内に収まるかどうかを確認します。
- オプションのヒューマンインザループ: エージェントは、アイテムが特定のカテゴリまたは通常の返品期間外である場合は、人間にエスカレーションするという追加のルールを確認します。
-
アクション : エージェントは返品プロセスをトリガーし、配送ラベルを生成します。
-
理由 : エージェントは、顧客への応答を生成します。
AIエージェントは、顧客に対して次のように応答します。これがあなたの配送ラベルです...」
人間の コールセンターの文脈では、これらのステップは第二の性質です。 エージェントシステムの コンテキストでは、LLMは「理由付け」を行い、システムは詳細を埋めるために特殊なツールまたはデータソースを呼び出します。
複雑さのレベル:LLMからエージェントシステムまで
LLMを利用したアプリケーションを構築するときは、シンプルに始めましょう。そこに行く方法の80%を取得するソリューションは、多くの場合、取得または慎重に設計されたプロンプトによって強化された単一の LLM コールを含みます。 より複雑なエージェントの動作(動的なツールコールやマルチエージェントオーケストレーションなど)は、柔軟性の向上やモデル主導の意思決定のために本当に必要なときに導入します。決定論的チェーンは、明確に定義されたタスクに対して予測可能なルールベースのフローを提供しますが、よりエージェント的なアプローチは、余分な複雑さと潜在的なレイテンシを犠牲にします。
AIシステムを構築する際には、いくつかのレベルの複雑さに遭遇する可能性があります。
-
LLM(LLM + プロンプト)
- 事前学習済みの知識を使用してテキストプロンプトに応答するスタンドアロンのLLM。
- 単純なクエリや一般的なクエリに適していますが、多くの場合、実際のビジネスデータから切り離されています。
-
ハードコードされたエージェントシステム(「チェーン」)
- 決定論的な事前定義されたステップを使用してオーケストレーションします (たとえば、常にベクトル ストアから取得し、常に結果をユーザーの質問と組み合わせてから、LLM を呼び出します)。
- ロジックは固定されており、LLM は次に呼び出すツールを決定しません。
-
ツールコールエージェントシステム
- LLMは、実行時に自動的に「ツール」を選択して呼び出します。
- このアプローチは、CRM データベースや Slack ポスティング API など、どのツールを呼び出すかについて、コンテキストに応じた動的な決定をサポートします。
-
マルチエージェントシステム
- それぞれが独自の機能またはドメインを持つ複数の特殊なエージェント。
- コーディネーター (AI スーパーバイザー の場合もあれば、ルールベースの場合もあります) は、各ステップで呼び出すエージェントを決定します。
- エージェントは、全体的な会話の流れを維持しながら、相互にタスクを引き継ぐことができます。
Mosaic AI Agent Framework はこれらのパターンにとらわれず、簡単に始めて、アプリケーション要件の増加に応じてより高いレベルの自動化と自律性へと進化させることができます。
エージェント・システム内のツール
エージェント システムのコンテキストでは、ツールは、LLM が明確に定義されたタスクを実行するために呼び出すことができる 1 つの対話機能です 。通常、AIモデルは各ツール呼び出しのパラメーターを生成し、ツールは簡単な入出力インタラクションを提供します。ツール側にはマルチターンメモリはありません。
一般的なツールカテゴリには、次のようなものがあります。
-
データを取得または分析するツール
- ベクトル検索ツール: ベクトル インデックスをクエリして、最も関連性の高いテキスト チャンクを見つけます。
- 構造化データ取得ツール: Deltaテーブルをクエリするか、APIを使用して構造化情報を取得します。
- Web検索ツール: インターネットまたは内部 Web コーパスを検索します。
- クラシック ML モデル: ML モデルを呼び出して分類または回帰予測を実行するツール (scikit-learn モデルや XGBoost モデルなど)。
- 生成AIモデル: コード生成やイメージ生成などの特殊な生成を実行し、結果を返すツール。
-
外部システムの状態を変更するツール
- API呼び出しツール: CRMエンドポイント、内部サービス、または「配送ステータスの更新」などのタスクのためのその他のサードパーティ統合。
- コード実行ツール: ユーザー指定の (場合によっては LLM で生成された) コードをサンドボックスで実行します。
- SlackまたはEメールの統合: メッセージを投稿するか、通知を送信します。
-
実行するツールは、ロジックを実行したり、特定のタスクを実行したりします
- コード エグゼキューター ツール: ユーザーが指定したコードまたは LLM生成されたコードをサンドボックスで実行します ( Python スクリプトなど)。
Mosaic AI エージェント ツールの詳細については、 AI エージェント ツールを参照してください。
ツールの主な特徴
エージェントシステムのツール:
- 明確に定義された 1 つの操作を実行します。
- その 1 回の呼び出しを超えて進行中のコンテキストを保持しないでください。
- エージェント・システムが、LLM が直接アクセスできない外部データまたはサービスにアクセスできるようにします。
ツールエラー処理と安全性
各ツール呼び出しは外部操作 (API の呼び出しなど) であるため、システムは、タイムアウト、エラー処理、不正な形式の応答、無効な入力などのエラーを適切に処理する必要があります。本番運用では、許可されるツール・コールの数を制限し、すべてのツール・コールが失敗した場合にフォールバック応答を設定し、ガードレールを適用して、エージェント・システムが同じ失敗したアクションを繰り返し試行しないようにすることができます。