次の方法で共有

Azureでのエージェントのビルド

スタートアップがプロトタイプを超えて運用グレードの AI エージェントを構築することを決定すると、実験からアーキテクチャに焦点が移 ります。 エンタープライズ顧客向けのエージェントを構築するには、複数の顧客にわたるセキュリティ、信頼性、適応性が必要です。 スタートアップ企業は、思慮深い設計とスピードとシンプルさのバランスを取る必要もあります。

Azureでエージェントを構築する場合、スタートアップごとに次の 4 つの主要な設計領域に対処する必要があります。

  1. マルチテナント: データ、コンテキスト、コンピューティングを分離しながら、複数の顧客に安全かつ効率的にサービスを提供する方法。
  2. アプリケーション層: ユーザーが API、Teams アプリ、または Web エクスペリエンスを介してエージェントと対話する方法、およびそれらのインターフェイスがテナント固有のロジックとセキュリティにどのようにマップされるか。
  3. オーケストレーションレイヤー: 推論、ツールの使用、およびアクションの調整を管理して、多様なタスクとモデルにわたって信頼性の高い監査可能な結果を生成する方法。
  4. コンテキスト レイヤー: ベクトル検索、メモリストア、ライブデータ統合を使用して、エージェントが関連する知識を検索し、構造化し、推論する方法。

これら 4 つの領域は、 スケーラブルなエージェント アーキテクチャのバックボーンを形成します。 エージェントの実行方法だけでなく、エージェントの進化、継続的な改善のサポート、テナントごとのカスタマイズ、顧客エコシステムへのより深い統合を決定します。

マルチテナンシー

スタートアップ企業にとって、マルチテナントは、持続可能でスケーラブルなエージェント プラットフォームを構築するための基礎となります。 セキュリティ、パフォーマンス、コスト効率を維持しながら、システムが複数の顧客にサービスを提供する方法を定義します。それぞれに独自のデータ、モデル、コンテキストがあります。 コンテキストとパーソナル化が価値創造の中心となる AI エージェントの世界では、マルチテナントによって、テナント間でのインテリジェンスのパーティション分割、共有、および進化の方法も制御されます。

Azureでは、マルチテナントを柔軟かつ安全にするためのネイティブ パターンとサービスがいくつか用意されています。 適切なアプローチは、製品モデル、データの機密性、およびスケールの要件によって異なります。

論理マルチテナントと物理マルチテナント

  • Logical multitenancy は、共有リソース内で顧客のデータと構成を分離することによって実現されます (たとえば、テナント固有のパーティションまたはコレクションを持つ単一の Cosmos DB インスタンス、テナントごとのインデックスを持つ単一のAzure AI 検索 サービスなど)。 このモデルは、高効率でシンプルな運用を提供し、初期段階のスタートアップに最適です。
  • Physical マルチテナントは、個別のデータベース、ストレージ アカウント、Azure アプリケーション オファーを使用したデプロイ全体など、テナントごとに専用リソースをプロビジョニングすることで、より強力な分離を実現します。 このアプローチは、規制対象の業界や、データ所在地の保証を必要とする企業のお客様に一般的です。

ほとんどのスタートアップ企業では、テナントの大半に対する論理的な分離と、価値の高い顧客やコンプライアンスに基づく顧客向けの物理的な分離という ハイブリッド モデルが採用されています。 これは、 水平方向にパーティション分割されたデプロイと呼ばれることがよくあります。 水平方向のパーティション分割されたデプロイは、B2B クライアントにテナント データの分離を提供しながら、最小限のアプリケーション インフラストラクチャを可能にするため、初期段階のスタートアップに最適です。 これにより、複雑なデータパーティション分割の必要性が軽減され、冗長インフラストラクチャのコストが削減されます。

AI エージェントのマルチテナンシー

アイデンティティとアクセス制御

マルチテナントの中心にあるのは ID です。 Microsoft Entra ID (Azure AD) は、セキュリティで保護されたテナント対応のアクセス制御の基盤を提供します。

多くのマルチテナント ソリューションは SaaS として動作します。 ただし、Microsoft Entra IDまたは外部 ID を使用する選択は、テナントまたは顧客ベースの定義方法によって部分的に異なります。

このガイドに従ってください (シングルテナント アプリを Microsoft Entra ID 上のマルチテナントに変換する: Microsoft ID プラットフォーム |Microsoft Learn) を使用してEntra IDを使用してマルチテナント アプリケーションを有効にします。

データとコンテキストの分離

エージェントはコンテキストに関する知識に大きく依存するため、テナントごとにデータの取得と埋め込みを分離することが重要です。 Azure Cache for Redis, Cosmos DB, および Azure Storage ではテナント固有の名前空間とインデックスがサポートされますが、Azure Confidential Computing や Private Endpoints。

取得拡張生成 (RAG) に ベクター データベース を使用する場合、スタートアップは テナントごとのベクター名前空間 または個別のコレクションを実装して、顧客間のデータ漏洩を防ぐ必要があります。 これにより、テナントごとのスケーリングと課金も簡略化されます。

可観測性、コスト、スケール

運用の可視性は、マルチテナント エージェント プラットフォームの重要な要素です。

  • Azure Monitor と Application Insights はテナントごとの使用状況をログに記録するように拡張でき、トラブルシューティング、パフォーマンス チューニング、使用量ベースの課金に役立ちます。
  • Azure Container Apps と AKS では、テナントの負荷に基づく自動スケールが可能になり、コスト効率が維持されます。
  • Microsoft コマーシャル マーケットプレースを通じて収益化する場合、テナントの使用状況データは、課金とレポートの自動化のために測定 API に直接フィードできます。

重要な理由

すぐにマルチテナントを取得すると、スタートアップ企業は次のことができます。

  • インフラストラクチャを複製することなく、多くのお客様にサービスを提供します。
  • 強力なデータ境界とコンプライアンス制御を適用します。
  • カスタマイズされた分離を使用して、小規模テナントとエンタープライズ テナントの両方をサポートします。
  • 将来のマーケットプレースの収益化と共同販売の準備を簡素化します。

つまり、マルチテナントは、エージェントをスタンドアロンプロトタイプからプラットフォームビジネスに変換し、単一の安全で柔軟なAzureバックボーンを通じて何百もの組織にサービスを提供できます。

アプリケーション レイヤー

アプリケーション レイヤーは、チャット インターフェイス、API、または Microsoft Teams などのツールに埋め込まれた副操縦を使用してエージェントと対話する場所です。 スタートアップ企業の場合、このレイヤーは顧客価値が具体的になる場所です。 これにより、オーケストレーション ロジックとコンテキスト インテリジェンスが、テナント間で応答性が高く、パーソナライズされ、セキュリティで保護された ユーザー エクスペリエンス に変換されます。

Azureでは、アプリケーション レイヤーは次の 2 つの重要な役割を果たします。

  1. テナント固有の要求と ID 検証の ゲートウェイ として機能します。
  2. ユーザー、開発者、および外部システムが対話する エクスペリエンス レイヤー を定義します。

テナントに配慮したアプリケーション境界

アプリケーション層は、要求を行っているテナントと、アクセスできるデータまたは機能を十分に認識している必要があります。 Azureでは、これを有効にするためにいくつかのサービスが提供されます。

  • Azure Front Door または API Management (APIM) は、グローバル エントリ ポイントとして機能し、テナント固有の環境または機能に要求をルーティングできます。
  • Entra ID は認証と承認を処理し、ユーザートークンとサービス トークンが適切なテナント コンテキストにマップされるようにします。
  • Azure App Configuration と Key Vault テナント固有の構成、API キー、および環境シークレットを管理します。

これらの境界により、各テナントは同じエージェント プラットフォームを使用しますが、セキュリティで 保護された独自の論理サンドボックス内に配置されます。これは、データの交差を防ぎ、エンタープライズ レベルのコンプライアンスを維持するための重要な手順です。

マルチチャネル配信

最新のエージェント エクスペリエンスは、1 つのチャット UI を超えて拡張されます。 スタートアップ企業は、複数の配信チャネルを通じてエージェントを公開できます。

  • 職場のコラボレーションと会話型ワークフローのための Teams Copilots とメッセージ拡張機能。
  • Web および Mobile AppsAzure App Service または Static Web Apps でホストされる React や React Native などのフレームワークを使用して構築されます。
  • API エンドポイントEntra IDまたは APIM によってセキュリティ保護されているため、お客様のシステムとのプログラムによる統合が可能になります。 これらは多くの場合、Azure Functions を使用して構築されます。

Azureの ID レイヤーにより、これらのインターフェイスが異なるバックエンド サービスに接続されている場合でも、統合された認証と承認モデルが確実に共有されます。 この一貫性により、スタートアップ企業は、顧客またはユース ケースごとにカスタマイズされたフロントエンドを提供しながら、1 つのエージェント コアを維持できます。

状態管理とセッション コンテキスト

エージェント アプリケーションでは、セッションは多くの場合、複数の相互作用とモダリティをブリッジします。 たとえば、ユーザーは Teams で会話を開始し、API を使用して続行し、Web ダッシュボードで分析情報を確認できます。

一貫性を維持するには:

  • Azure Cosmos DB または Azure Cache for Redis は、テナントごとにセッション状態と会話コンテキストを保持できます。
  • Durable Functionsは、分散コンポーネント間でもエージェントの推論手順を追跡する実行時間の長いワークフローを有効にします。
  • Event Grid または Service Bus は、ユーザーまたはシステムが更新をトリガーするときに、モジュール間でコンテキストとシグナルを伝達できます。

このセッション対応の設計により、エージェントは、各対話モードのワークフローをハードコーディングすることなく、継続的かつコンテキストに応じてインテリジェントに感じることができます。

テレメトリとエクスペリエンスの分析情報

また、アプリケーション 層では、スタートアップ企業は、顧客がエージェントとどのように関わるかについての分析情報を得ることができます。

  • Application Insights は、 対話メトリック、待機時間、ユーザー満足度のシグナルをキャプチャします。
  • カスタム ログでは、 意図の成功率、 完了時間、または フィードバック ループ を追跡して、オーケストレーションの品質を継続的に向上させることができます。
  • スタートアップは、使用量ベースの価格または SLA レポートを促進するために、テナント別にテレメトリを集計できます。 このデータは、収益化のためにマーケットプレースの使用状況測定にもフィードされます。

重要な理由

アプリケーション層は、エージェント プラットフォームの カスタマー エクスペリエンスサーフェス を定義します。 最初からテナント対応、チャネルフレキシブル、およびデータセキュリティで保護されるように設計することで、スタートアップ企業は次のことができます。

  • Teams、Web、API 間で一貫した信頼できる対話を提供します。
  • エンタープライズ レベルの ID、監査、コンプライアンスの要件をサポートします。
  • エージェントの推論とパフォーマンスを向上させる貴重な分析情報を収集します。
  • 使用状況テレメトリと使用状況測定を通じて、将来のマーケットプレースの収益化を有効にします。

本質的に、アプリケーション層は、製品の設計、セキュリティ、ユーザーエクスペリエンスが融合するエージェントの知性の入口です。

エージェント ワークフローのユーザー インターフェイスの統合

アプリケーション層では、エージェントが API を公開し、アクセスを管理する方法が定義されますが、 ユーザー インターフェイス統合 によって、エンド ユーザーがエージェントを使用する方法が定義されます。 スタートアップの場合、これは強力なレバーです。 Microsoft Teams、Outlook、Microsoft 365 アプリ導入サイクルを短縮し、持続性を高めることができます。

Microsoft Teamsでのビルド

Teams は、エンタープライズ レベルのエージェント向けの自然なインターフェイスです。 Teams アプリを使用すると、スタートアップ企業はエージェントをチャット、会議、チャネルに直接埋め込むことができます。これにより、ユーザーは既に作業しているエージェントと対話できます。

  • ボットとメッセージ拡張機能 を使用すると、セキュリティで保護された API を介してエージェントのオーケストレーションレイヤーに直接接続する会話操作やクイック アクションが可能になります。
  • アダプティブ カード と Task Modules は構造化された出力を表示でき、ガイド付きワークフローと承認を有効にすることができます。
  • teams 内の SaaS または Azure アプリ オファーのリンクを使用すると、Azure Marketplaceリストに関連付けられた収益化されたエクスペリエンスを実現できます。
  • Entra ID統合により、シングル サインオンとテナント レベルのアクセス制御が保証され、組織全体のマルチテナントデプロイが簡素化されます。

Teams は、delivery チャネルと trust layer の両方として機能し、Microsoftのセキュリティ モデルの下でエンタープライズ ワークフローを使用して AI システムをブリッジします。 M365 Agents Toolkit は、M365 スイートから Teams やその他の製品と統合するためのエンタープライズ対応エージェントの構築を効率化するために使用できます。 Toolkit は、Copilotや Teams などのMicrosoft 365 プラットフォーム用のカスタム エージェントの構築、デバッグ、デプロイを効率化するVisual Studio Code拡張機能と CLI です。 マニフェスト管理、サイドローディング、Azure リソース プロビジョニングなどのタスクが自動化され、開発者は ID とデータ アクセスを統合して宣言型またはプロコード型のエージェントを作成できます。

Microsoft 365 エクスペリエンスへの埋め込み

Teams を超えて、スタートアップ企業は、より広範な M365 エコシステム全体でエージェントを拡張できます。

  • Outlook アドインでは、電子メールでプロアクティブまたはリアクティブな支援を行えます (スレッドの概要作成やフォローアップ アクションの生成など)。
  • Graph Connectors は、構造化データを M365 Search および Copilot エクスペリエンスにフィードして、エージェントのリーチを企業の知識にまで広げることができます。

M365 サーフェスと統合することで、スタートアップ企業は Microsoft Graph API を利用してコンテキストを統合し、メッセージ、カレンダー イベント、ドキュメント、タスクをまとめ、エージェントがユーザーの作業環境をコンテキストに応じて認識できるようにします。

その他のインターフェイス オプション

外部またはハイブリッドのシナリオでは、スタートアップ企業は以下を統合することもできます。

  • Web アプリまたはポータルAzure App Service または Static Web Apps で構築され、多くの場合、管理コンソールまたはダッシュボードとして機能します。
  • Mobile アプリ React Native または .NET MAUI を利用し、Entra ID経由で認証され、API Management 経由で接続されます。
  • Third-party integrations Slack、Salesforce、または ServiceNow の REST または Microsoft Graph API を使用して、エージェントがエコシステム間で対話できるようにします。

エクスペリエンスとセキュリティの設計

インターフェイスに関係なく、スタートアップは次の設計を行う必要があります。

  • Contextual groundingにより、エージェントは関連するテナントやユーザーデータをMicrosoft Graphまたは内部APIから引き出すことができます。
  • シームレスなユーザー エクスペリエンスを実現するために、Entra シングル サインオンまたは委任されたトークンを使用した低摩擦認証。
  • 一貫性のある UX とブランド化により、エージェントの対話が各ホスト環境内で自然に感じられるようにします。

エージェントをMicrosoft 365エコシステムに統合することは、利便性だけではありません。 これは、ユーザーが作業する場所にユーザーを会議し、別のサイロ化されたアプリではなく、AI ソリューションを生産性ツールの自然な拡張機能にすることです。

オーケストレーション レイヤー

アプリケーション層がエージェント プラットフォームの フロント ドア である場合、 オーケストレーションレイヤー は 頭脳であり、推論、ツール、ワークフローを調整して、一貫性のあるコンテキストに対応した結果を提供します。 ここでインテリジェンスとアクションが結びつきます。

オーケストレーションレイヤーは、ユーザーの意図 (アプリレイヤーから) をドメイン ロジック、データ、および外部システムに接続します。 エージェントスタートアップの場合、これはアーキテクチャの最も戦略的な部分であり、柔軟性、スケーラビリティ、可観測性のバランスを取りながら、フロントエンドから複雑さを抽象化します。

オーケストレーションレイヤーのコア機能

オーケストレーション レイヤーは、通常、次の 5 つの重要な役割を実行します。

  1. 意図の解釈: ユーザー プロンプトまたは API 呼び出しを構造化されたアクションまたは目標に変換します。
  2. コンテキスト アセンブリ: 推論モデルを呼び出す前に関連するデータ、メモリ、またはツールを取得します。
  3. ツール呼び出し: エージェントに代わって API 呼び出し、ワークフロー、または統合を実行します。
  4. 応答合成: 推論出力とドメイン ロジックを組み合わせて意味のある応答を生成します。
  5. 観察と学習: 継続的な改善のための結果、エラー、メトリックのログ記録。

企業の場合、これらの関数は、単一のモノリスではなく 、マイクロ オーケストレーションのパイプライン としてモデル化できます。 しかし、スタートアップ企業は、速度と簡素化のために最適化するために、以前の段階でより多くのモノリシック設計パターンを活用する傾向があります。

Azureでの実装

Azureは、オーケストレーション ロジックを構築およびスケーリングするためのネイティブ基盤を提供します。

  • Azure Functions は、特定の推論またはタスク フローを実行するステートレス コンピューティング ノードとして機能します。 各関数は、特定のテナント、トピック、またはイベントの種類にバインドできます。
  • Durable Functionsは、実行時間の長いオーケストレーション パターンまたはマルチステップ オーケストレーション パターンを有効にします。これは、推論ループ、エージェントコラボレーション、またはマルチターン ワークフローに適しています。
  • Azure Service Bus は、オーケストレーション コンポーネント間の信頼性の高い順序付けされたメッセージ配信を提供します。これは、分散サービス全体での確定的な実行に不可欠です。

これらのサーバーレス プリミティブを使用すると、スタートアップは単純な要求応答エージェントから、ユーザーとシステムコンテキストに動的に適応する 事後対応型のイベントドリブン AI システム に進化させることができます。

AI の推論とツールの使用

オーケストレーションレイヤーの中核には、Azure OpenAI モデルのGPT-5または他のAzureダイレクトモデルオファリングを利用した推論があります。

これらのモデルは、モノリシック 頭脳としてではなく、構造化パイプライン内の 推論ノード として最適に使用されます。

  • システム プロンプトと関数呼び出しを使用して、制御された方法で推論モデルをガイドします。
  • 各エージェント インスタンスが動的にクエリを実行できる central tool registry (たとえば、Cosmos DB または Azure App Configuration) にツール定義とエンドポイント メタデータを格納します。
  • 管理 ID を介して高い特権アクションを実行し、エージェントが資格情報を埋め込まずにAzureまたは外部 API を安全に呼び出すようにします。

モデルが決定 する内容 を実行 の 動作から分離することで、 セキュリティの分離 と 監視の 両方を推論プロセスに組み込みます。

コンテキスト アセンブリとメモリの調整

推論は、提供されたコンテキストと同じくらい良いです。 オーケストレーション レイヤーは、モデルの呼び出し前に複数のソースからこのコンテキストをアセンブルする役割を担います。

この方法により、コンテキストに対応した推論が可能になります。 これは、高度なエージェントシステムの特徴です。

可観測性とフィードバック ループ

エージェントの信頼性とデバッグを大規模に維持するために、オーケストレーションレイヤーは豊富なテレメトリを出力する必要があります。

  • Azure アプリケーション Insights は、すべての推論手順、モデル呼び出し、および API の実行をトレースできます。
  • Azure Monitor Logs は、テナント、意図、またはツールの使用状況によってエージェントのパフォーマンスを追跡できます。
  • フィードバック信号 (ユーザーの修正や成功率など) は、 AI レイヤーの微調整またはプロンプト最適化パイプラインに送ることができます。

重要な理由

オーケストレーション レイヤーは、エージェントに計画し、決定し、そして自律的に行動する能力を与える要素です。
Azureのイベント ドリブンインフラストラクチャとサーバーレス インフラストラクチャを使用してこのレイヤーを実装することで、スタートアップ企業は次のことができます。

  • テナントまたはワークロードごとにオーケストレーションを動的にスケーリングします。
  • ツールのアクセスと推論コンテキストをきめ細かく制御できます。
  • コンプライアンスとデバッグのために、追跡可能な一連の思考を維持します。
  • 新しいツール、チャネル、または動作を使用してエージェントを迅速に拡張します。

要するに、オーケストレーションレイヤーは、Azureをクラウド プラットフォームからインテリジェント エージェント用の実行ファブリックに変換します。このファブリックでは、推論、ツール、コンテキストがシームレスに収束します。

コンテキスト レイヤー

コンテキスト レイヤーは、エージェントが理解を得る場所です。 これは、推論と実際の知識を結び付け、応答が正確で関連性があり、テナント固有であることを保証します。 適切に設計されたコンテキスト レイヤーがないと、最も高度な推論モデルであっても、信頼性が低い、または汎用的になるリスクがあります。

スタートアップ企業にとって、このレイヤーは競争上の差別化要因です。 独自のデータ、顧客の分析情報、システム統合が収束し、エージェントが本当に 役立つ場所です。 課題は、ユース ケースや顧客間で セキュリティで保護され、マルチテナントで動的に構成されるように 設計することです。

エージェント システムにおけるコンテキストの役割

AI エージェントのインテリジェンスは、モデルだけでなく、推論時に認識される内容にも依存します。 コンテキストは、次の 3 つの重要な目的を果たします。

  1. 知識の基礎: ファクト、データ、構造化されたビジネス ロジックを使用してモデルの応答を強化します。
  2. メモリ: 会話、ワークフロー、またはセッション間の継続性を維持します。
  3. 取得と合成: 関連するデータをリアルタイムでフェッチ、フィルター処理、および要約します。

これらの関数を組み合わせることで、ステートレス モデルがステート フルな推論システム に変わり、すべての相互作用を学習して適応します。

Azureでのコンテキスト構成

Azureは、堅牢な多層コンテキスト スタックに構成できる複数のサービスを提供します。

  • Azure AI 検索: 取得拡張生成 (RAG) の基礎。 構造化データと非構造化データのインデックスを作成し、エージェントがクエリ時にテナント固有の知識をプルできるようにします。
  • Cosmos DB: テナントごとの半構造化ドメインの知識、ツール メタデータ、および構成を格納するのに最適です。
  • Azure Storage または Data Lake: 長期的なドキュメント ストレージおよびバッチ インデックス作成パイプラインに使用されます。
  • Redis Cache または PostgreSQL: 短期およびセッション メモリをサポートし、会話間のコンテキスト継続性を実現します。
  • Azure OpenAI Embeddings: テナント データのセマンティック ベクター化を有効にして、コンテキスト取得の類似性検索を有効にします。

これらのサービスを一緒に調整すると、 階層的なメモリ システムが形成され、高速アクセス キャッシュとより深い取得層が組み合わさり、長期的な接地が可能になります。

マルチテナント データ分離

スタートアップ企業は、知識境界をクリーンに分離するコンテキスト システムを設計する必要があります。

このアーキテクチャは、コンプライアンスを確保し、テナント間のデータ漏洩を防ぐのに役立ちます。 企業の信頼にとって重要です。

拡張リトリーバル推論

実行時に、コンテキスト レイヤーは RAG パイプラインを使用して動的な知識でプロンプトを強化します。 一般的なフローは次のようになります。

  1. オーケストレーション レイヤーからユーザー クエリまたは意図を受け取ります。
  2. 関連するドキュメントのセマンティック検索Azure AI 検索で実行します。
  3. サポートファクトまたはツール定義を取得します。
  4. 取得したコンテキストを使用して複合プロンプトを作成します。
  5. 強化されたプロンプトを推論モデル (GPT-4 Turbo など) に送信します。

スタートアップ企業は、知識を外部から取得することによって、モデルプロンプトを軽量化し、最新のテナント固有情報に基づく精度を維持することができます。

アダプティブ動作のためのメモリ システム

取得を超えて、コンテキストには 短期および長期のメモリが含まれます。これは、エージェントを進化させるメカニズムです。

  • ナレッジ: エージェントの動作を根拠とする静的データ (RAG と考えてください)。
  • 長期メモリ: 経験と相互作用によってエージェントによって蓄積されたセマンティック メモリ。 これにより、パーソナル化がサポートされ、時間の経過と共にユーザー エクスペリエンスが向上します。
  • 短期メモリ: セッション内のコンテキスト管理のための作業メモリ。 これは、セッションの永続化とマルチエージェント ソリューションに不可欠です。

この階層化メモリアプローチにより、エージェントはモデルを再トレーニングすることなく、時間の経過と同時に動作を調整できます。

監視とコスト管理

コンテキストの取得とベクター検索は、特に大規模なテナント データセットでは、大規模にコストがかかる場合があります。 Azureは、次の方法でこれを管理するのに役立ちます。

スタートアップ企業は、高頻度の取得をキャッシュしたり、埋め込みを圧縮したり、ドキュメント インジェストをバッチ処理したりすることで、コストをさらに最適化できます。

コンテキスト レイヤーが重要な理由

コンテキストレイヤーは信頼できるインテリジェンスの基盤です。それにより、エージェントが幻覚を起こさず、顧客データにしっかりと根付いた状態を保ち、現実世界の使用状況に合わせて進化します。 Azureネイティブ サービスを使用して実装することで、スタートアップ企業は次の利益を得ることができます。

  • テナントごとに隔離された、セキュリティで保護されたナレッジ アクセス。
  • スケーラブルな取得とメモリ管理。
  • ユーザーとコンテキスト間で一貫した、事実に基づく正確な推論。 このレイヤーが正しく設計されると、エージェントが会話システムから 知識豊富なアシスタントに変換され、各テナントのビジネスを独自のものであるかのように理解できます。
  • Last updated on