このシナリオ例では、専用の検索サービスを使用することにより、eコマースの顧客に対する検索結果の関連性が大幅に向上することを示します。
アーキテクチャ
このアーキテクチャの Visio ファイルをダウンロードします。
ワークフロー
このシナリオでは、顧客が製品カタログを検索できる eコマース ソリューションについて説明します。
- 顧客は、任意のデバイスから eコマース Web アプリケーションにアクセスします。
- 製品カタログは、トランザクション処理のために Azure SQL データベースに保持されています。
- Azure AI Search は検索インデクサーを使用して、統合された変更追跡によって検索インデックスを自動的に最新の状態に維持します。
- 顧客の検索クエリは AI Search サービスにオフロードされ、そこでクエリが処理されて、最も関連性の高い結果が返されます。
- Web ベースの検索エクスペリエンスの代替手段として、顧客は、ソーシャル メディア内で、またはデジタル アシスタントから直接会話型ボットを使用して、製品を検索し、検索クエリと結果を段階的に調整することもできます。
- 必要に応じて、顧客はスキルセット機能を使用して人工知能を適用し、処理をさらにスマートにすることができます。
コンポーネント
- Azure App Service - Web Apps により Web アプリケーションがホストされ、自動スケーリングと高可用性が可能になります。インフラストラクチャの管理は不要です。
- Azure SQL Database は、リレーショナル データ、JSON、空間データ、XML などの構造をサポートする、Microsoft Azure の汎用リレーショナル データベース管理サービスです。
- AI Search はクラウド ソリューションで、多彩な検索機能を、Web、モバイル、およびエンタープライズ アプリケーション内のプライベートな異種コンテンツに提供します。
- Azure AI Bot Serviceは、インテリジェントボットの構築、テスト、導入、管理を行うためのツールを提供します。
- Azure AI サービスを使用すると、インテリジェントなアルゴリズムを使用して、自然なコミュニケーション手段を通じてユーザーのニーズを見たり、聞いたり、話したり、理解したり、解釈したりできます。
代替
- たとえば、SQL Server のフルテキスト検索でデータベース内検索機能を使用できますが、その場合、トランザクション ストアでもクエリが処理され (必要な処理能力の増加)、データベース内の検索機能の方が限定的です。
- AI Search が構築されている、オープンソースの Apache Lucene を Azure Virtual Machines 上でホストすることもできますが、その場合、サービスとしてのインフラストラクチャ (IaaS) の管理に戻り、Lucene の上で AI Search が提供する多くの機能の恩恵を受けられません。
- また、サードパーティ ベンダーの高機能な代替の検索製品である Elasticsearch を Azure Marketplace からデプロイすることも検討できますが、この場合も IaaS ワークロードを実行することになります。
データ層の他のオプションを次に示します。
- Azure Cosmos DB - Microsoft のグローバル分散型マルチモデル データベースです。 Azure Cosmos DB では、MongoDB、Cassandra、Graph データ、シンプルなテーブル ストレージなど、他のデータ モデルを実行するためのプラットフォームが提供されます。 AI Search では、Azure Cosmos DB からのデータに直接インデックスを付けることもサポートされています。
シナリオの詳細
検索は顧客が製品を探して最終的に購入するときに利用する主要なメカニズムなので、検索結果が検索クエリの意図に関連していること、およびほぼ即時の結果、言語分析、地理的な場所の一致、フィルター処理、ファセット、オートコンプリート、検索結果の強調表示などを提供することによって、検索エクスペリエンスが大手の検索エンジンに匹敵することが重要になります。
SQL Server や SQL Database などのリレーショナル データベースに製品データが格納されている一般的な eコマース Web アプリケーションを想像してください。 検索クエリは多くの場合、LIKEクエリまたはフルテキスト検索機能を使用してデータベース内で処理されます。 代わりに AI Search を使用することで、クエリ処理から運用データベースを解放し、顧客に最高の検索エクスペリエンスを提供する実装が難しい機能の数々を簡単に利用できます。 また、AI Search はサービスとしてのプラットフォーム (PaaS) コンポーネントであるため、インフラストラクチャの管理を心配することも、検索のエキスパートになる必要もありません。
考えられるユース ケース
このソリューションは、小売業界向けに最適化されています。
その他の関連するユース ケース:
- ユーザーの物理的位置の近くにある不動産物件や店舗の検索 (施設/不動産業界向け)。
- "最近" の情報を優先した、ニュース サイトの記事やスポーツ結果の検索 (スポーツ、メディア、エンターテイメント業界向け)。
- 政策立案者や公証人など、"ドキュメント中心" の組織向けの大規模なリポジトリの検索。
最終的には、何らかの形式の検索機能を持つ "すべての" アプリケーションが、専用検索サービスからメリットを得ることができます。
考慮事項
以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。
スケーラビリティ
AI Search サービスの価格レベルは、最大ストレージ容量と、プロビジョニングできるパーティションとレプリカの数を定義するため、主に容量計画に使用されます。 パーティションを使用するとより多くのドキュメントにインデックスを付けることができ、書き込みスループットが向上するのに対し、レプリカでは 1 秒あたりのクエリ数 (QPS) が増えて高可用性が提供されます。
パーティションとレプリカの数は動的に変更できますが、価格レベルを変更することはできません。 そのため、ターゲット ワークロードに適したレベルを慎重に検討する必要があります。 どうしてもレベルを変更する必要がある場合は、新しいサービスを並行してプロビジョニングし、インデックスを再度読み込む必要があります。この時点で、新しいサービスをアプリケーションから参照できます。
可用性
AI Search は、少なくとも 2 つのレプリカがあれば読み取り (すなわちクエリ) に対して、少なくとも 3 つのレプリカがあれば更新 (すなわち検索インデックスの更新) に対して、99.9% の可用性 SLA を提供します。 したがって、顧客が確実に検索できるようにする場合は少なくとも 2 つのレプリカをプロビジョニングし、インデックスへの実際の変更も高可用性操作と考える必要がある場合は少なくとも 3 つのレプリカをプロビジョニングする必要があります。
インデックスに対する破壊的変更 (たとえば、データ型の変更や、フィールドの削除または名前変更) をダウンタイムなしで行う必要がある場合は、インデックスを再構築する必要があります。 サービス レベルの変更と同様に、これは、新しいインデックスを作成し、それにデータを再設定して、新しいインデックスを参照するようアプリケーションを更新することを意味します。
セキュリティ
AI Search は、多くのセキュリティおよびデータ プライバシー基準に準拠しているため、ほとんどの業界で使用できます。
サービスへのアクセスをセキュリティで保護するには、Azure のロールベースのアクセス制御 (RBAC) を使用するか、API キーで接続します。
推奨されるのは、Microsoft Entra ID と統合される Azure ロールを使用する Azure RBAC です。 Azure ロールを使用する場合は、Azure リソースのマネージド ID などのパスワードレスの認証方法を使用することもできます。
API キーには、すべてのコンテンツ操作にフル アクセスできる管理者キーと、検索インデックスのドキュメント収集に読み取り専用アクセスできるクエリ キーがあります。 インデックスを更新する必要がないアプリケーションは、管理者キーではなくクエリ キーを使用するように設定する必要があります。具体的には、ウェブ ブラウザーで実行されているスクリプトのようにエンドユーザー デバイスが検索を実行するような場合が当てはまります。
AI Search サービスへのアクセスは、プライベート エンドポイント経由で公開することで、ネットワークレベルで保護することもできます。
検索の関連性
eコマース アプリケーションがどれくらい成功するかは、顧客に対する検索結果の関連性に大きく依存します。 検索サービスを慎重に調整してユーザーの調査に基づいて最適な結果を提供したり、お客様の検索パターンを理解するために検索トラフィック分析に依存することで、データに基づいて意思決定を行うことができます。
検索サービスを調整する一般的な方法は次のとおりです。
- スコアリング プロファイルを使用して、検索結果の関連性に影響を与えます。どのフィールドがクエリに一致したか、データはどれだけ新しいか、ユーザーへの地理的な距離はどれくらいか、などに基づいて調整します。
- 高度な自然言語処理スタックを使用してクエリをより適切に解釈する、Microsoft が提供する言語アナライザーを使用します。
- 特に、製品の製造元やモデルなどの言語に基づかない情報で検索する場合は、カスタム アナライザーを使用して製品が確実に正しく見つかるようにします。
コスト最適化
コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。
このシナリオの実行コストを調べることができるように、これまでに説明したすべてのサービスがコスト計算ツールで事前構成されています。 特定のユース ケースについて価格の変化を確認するには、予想される使用量に合わせて該当する変数を変更します。
想定されるトラフィックの量に基づいて、次の 3 つのサンプル コスト プロファイルを検討します。
- 小: このプロファイルでは、Web サイトをホストする単一の
Standard S1Web アプリ、Azure AI Bot サービスの Free レベル、単一のBasic検索サービス、Standard S2SQL データベースを使用します。 - 中: このプロファイルでは、Web アプリを
Standard S3レベルの 2 つのインスタンスにスケールアップし、検索サービスをStandard S1レベルにアップグレードし、Standard S6SQL データベースを使用します。 - 大: このプロファイルでは、
Premium P2V2Web アプリの 4 つのインスタンスを使用し、Azure AI Bot サービスをStandard S1レベル (Premium チャネルで 1.000.000 メッセージ) にアップグレードし、Standard S3検索サービスの 2 つのユニットとPremium P6SQL データベースを使用します。
このシナリオのデプロイ
このシナリオをデプロイするには、ジョブ検索の Web サイトを実行する .NET サンプル アプリケーションを説明しているこの詳細なチュートリアルで手順を確認することができます。 これまでに説明した AI Search 機能のほとんどを示しています。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- Jelle Druyts | プリンシパル カスタマー エンジニア
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。
次のステップ
AI Search について詳しくは、ドキュメント センターまたはサンプルをご確認ください。
他の Azure コンポーネントの詳細については、次のリソースを参照してください。