適用於電子商務的智慧型產品搜尋引擎

Azure AI Bot Service
Azure AI 搜尋
Azure AI 服務
Azure SQL Database
Azure App Service

此範例案例示範如何使用專用的搜尋服務，大幅提升電子商務客戶的搜尋結果相關性。

架構

此圖顯示了電子商務智慧產品搜尋引擎中涉及之 Azure 元件的架構概觀。

下載此架構的 Visio 檔案。

工作流程

此案例涵蓋可讓客戶透過產品目錄搜尋的電子商務解決方案。

  1. 客戶會從任何裝置前往電子商務 Web 應用程式。
  2. 該產品目錄會保留在 Azure SQL 資料庫以供交易處理。
  3. 「Azure AI 搜尋服務」使用搜尋索引器，透過整合式變更追蹤自動將搜尋索引保持在最新狀態。
  4. 客戶的搜尋查詢會卸載至 AI 搜尋服務，以處理查詢並傳回最相關的結果。
  5. 作為基於網路的搜尋體驗的替代方案，客戶也可以使用社交媒體中的交談機器人，或直接從數位助理搜尋產品，或直接透過數位助理來搜尋產品並逐步完善其搜尋查詢和結果。
  6. 或者，客戶可以使用技能功能，應用人工智慧進行更智慧的處理。

元件

  • Azure 應用程式服務- Web Apps 裝載 Web 應用程式，允許自動縮放和高可用性，而不需要管理基礎結構。
  • Azure SQL 資料庫 是 Microsoft Azure 中的一般用途關聯式資料庫受控服務，支援關聯式資料、JSON、空間和 XML 等結構。
  • AI 搜尋服務是雲端解決方案，可透過 Web、行動和企業應用程式中的私用異質內容，提供豐富的搜尋體驗。
  • Azure AI Bot Service 提供工具來建置、測試、部署和管理智慧型機器人。
  • Azure AI 服務讓您使用智慧型演算法，透過自然的溝通方式，來查看、聆聽、述說、了解及詮釋您的使用者需求。

替代項目

  • 例如，您可以透過 SQL Server 全文搜尋使用資料庫內搜尋功能，但您的交易存放區也會處理查詢 (增加處理能力的需求)，而且資料庫內的搜尋功能會更加有限。
  • 您可以在「Azure 虛擬機器」上託管開放原始碼 Apache Lucene (「AI 搜尋服務」以其為基礎建置)，但隨後您又會回到管理基礎結構即服務 (IaaS)，無法從「AI 搜尋服務」在 Lucene 之上提供的許多功能中受益。
  • 您也可以考慮從 Azure Marketplace 部署 Elasticsearch，這是來自第三方廠商的替代且功能強大的搜尋產品，但在這種情況下，您也正在執行 IaaS 工作負載。

資料層的其他選項包括：

  • Azure Cosmos DB - Microsoft 的全域散發多模型資料庫。 Azure Cosmos DB 提供平台來執行其他資料模型，例如 MongoDB、Cassandra、Graph 資料或簡單的資料表儲存體。 「AI 搜尋服務」也支援直接從 Azure Cosmos DB 為資料編製索引。

案例詳細資料

搜尋是客戶尋找並最終購買產品的主要機制，因此搜尋結果必須與搜尋查詢的意圖相關，並且整體搜尋體驗應該與搜尋巨頭的標準相符 提供近乎即時的結果、語言分析、地理位置比對、篩選、Facet、自動完成和點擊醒目提示等功能。

想像一下典型的電子商務 Web 應用程式，其產品資料會儲存在關聯式資料庫中，例如 SQL Server 或 SQL 資料庫。 搜尋查詢通常會使用LIKE查詢或全文搜尋功能在資料庫內處理。 透過使用 AI 搜尋服務，您可以將操作資料庫從查詢處理中解放出來，並且可以輕鬆地開始利用那些難以實作的功能，為您的客戶提供最佳的搜尋體驗。 此外，因為「AI 搜尋服務」是平台即服務 (PaaS) 元件，因此您不必擔心要管理基礎結構或成為搜尋專家。

潛在使用案例

該解決方案針對零售業進行了最佳化。

其他相關用例包括：

  • 尋找使用者實體位置附近的房地產清單或商店 (用於設施和房地產行業)。
  • 在新聞網站中搜尋文章或尋找體育結果，對較新的資訊偏好較高 (針對體育、媒體和娛樂業)。
  • 在大型存放庫中搜尋以文件為中心的組織，例如政策制定者和公證人。

最後，任何具有某種形式搜尋功能的應用程式，都可以受益於專用的搜尋服務。

考量

這些考量能實作 Azure Well-Architected Framework 的支柱，其為一組指導原則，可以用來改善工作負載的品質。 如需詳細資訊，請參閱 Microsoft Azure Well-Architected Framework (部分機器翻譯)。

延展性

「AI 搜尋服務」的定價層主要用於容量規劃，因為它會定義您取得的最大儲存體，以及您可以佈建的分割和複本數目。 分割可讓您編製更多文件的索引，並取得更高的寫入輸送量，而複本則每秒提供更多的查詢 (QPS) 和高可用性。

您可以動態變更分割和複本的數目，但無法變更定價層。 因此，您應該仔細考慮目標工作負載的正確分層。 如果您無論如何都需要變更分層，則需要並排佈建新服務並在那裡重新載入索引，此時您可以將應用程式指向新服務。

可用性

如果您至少有兩個複本，則「AI 搜尋服務」為讀取 (即查詢) 提供 99.9% 的可用性服務等級協定 (SLA)；如果您至少有三個複本，則為更新 (即更新搜尋索引) 提供 99.9% 的可用性服務等級協定 (SLA)。 因此，如果您希望客戶能夠可靠地搜尋，則應至少配置兩個複本；如果實際對索引的變更也應視為高可用性操作，則應配置三個複本。

如果需要在不停機的情況下對索引進行重大變更 (例如，變更資料類型、刪除或重新命名欄位)，則必須重建索引。 類似於變更服務層級，這表示建立新的索引、重新填入資料，然後更新應用程式以指向新的索引。

安全性

「AI 搜尋服務」符合許多安全性和資料隱私權標準，因此您可以將其用於大多數產業。

若要保護服務的存取，您可以使用 Azure 角色型存取控制 (RBAC) 或使用 API 金鑰進行連接。

建議您使用 Azure RBAC，因為它使用與 Microsoft Entra ID 整合的 Azure 角色。 當您使用 Azure 角色時，您也可以使用無密碼驗證方法，例如 Azure 資源的受控識別。

API 金鑰包括系統管理金鑰，該金鑰可提供所有內容作業的完整存取權，以及查詢金鑰，該金鑰提供搜尋索引文件集合的唯讀存取權。 您應該設定不需要更新索引的應用程式，以使用查詢金鑰而不是系統管理金鑰，特別是當最終使用者裝置 (例如在 Web 瀏覽器中執行的指令碼) 執行搜尋時。

您也可以透過私人端點公開 AI 搜尋服務，從而在網路層級保護對「AI 搜尋服務」的存取。

搜尋相關性

電子商務應用程式的成功程度，主要取決於搜尋結果與客戶的相關性。 仔細微調您的搜尋服務，根據使用者研究提供最佳結果，或依賴搜尋流量分析來了解客戶的搜尋模式，讓您根據資料做出決策。

調整搜尋服務的典型方式包括：

  • 使用評分設定檔來影響搜尋結果的相關性，例如，根據哪一個欄位符合查詢、資料的最近程度，以及使用者的地理距離。
  • 使用 Microsoft 提供的語言分析器，這些分析器使用進階的自然語言處理堆疊來更妥善地解譯查詢。
  • 使用自訂分析器來確保正確找到您的產品，特別是如果您想搜尋非語言資訊，例如產品的品牌和機型。

成本最佳化

成本最佳化是關於考慮如何減少不必要的費用，並提升營運效率。 如需詳細資訊，請參閱成本最佳化支柱的概觀。

若要探索執行此案例的成本，先前提到的所有服務都會預先設定在成本計算機中。 若要查看定價如何針對您的特定使用案例變更，請變更適當的變數以符合您預期的使用量。

請根據您預期處理的流量，考量這些範例成本設定檔：

  • 小型：此設定檔會使用單一 Standard S1Web 應用程式來裝載網站、Azure AI Bot Service 的免費層、單一Basic搜尋服務和Standard S2 SQL 資料庫。
  • 中型：此設定檔會將 Web 應用程式擴大至 Standard S3 層級的兩個執行個體，將搜尋服務升級至 Standard S1 層級，並使用 Standard S6 SQL 資料庫。
  • 大型：此設定檔使用四個 Premium P2V2Web 應用程式的執行個體、將 Azure AI Bot Service 升級至 Standard S1 層級 (進階通道中有 1.000.000 則訊息)，並使用兩個 Standard S3 搜尋服務單元和一個Premium P6 SQL 資料庫。

部署此案例

若要部署此案例的版本，您可以遵循這個逐步教學課程，提供執行作業搜尋網站的 .NET 範例應用程式。 它示範到目前為止所討論的大部分「AI 搜尋服務」功能。

參與者

本文由 Microsoft 維護。 原始投稿人如下。

主要作者：

若要查看非公開的 LinkedIn 設定檔，請登入 LinkedIn。

下一步

若要深入了解「AI 搜尋服務」，請瀏覽 文件中心或查看 範例。

若要深入了解其他 Azure 元件，請參閱下列資源：