此示例方案演示如何使用专用搜索服务显著增加电子商务客户的搜索结果相关性。
建筑
下载此体系结构的 Visio 文件。
工作流
此方案涵盖一个电子商务解决方案,客户可在其中搜索产品目录。
- 客户从任何设备 转到
电子商务 Web 应用程序。 - 产品目录保留在 Azure SQL 数据库 中,用于事务处理。
- Azure AI 搜索使用 搜索索引器 通过集成更改跟踪自动使其搜索索引保持最新。
- 客户的搜索查询将卸载到 AI 搜索 服务,该服务处理查询并返回最相关的结果。
- 作为基于 Web 的搜索体验的替代方法,客户还可以使用社交媒体中的 聊天机器人 或直接从数字助手搜索产品,并增量优化其搜索查询和结果。
- (可选)客户可以使用 技能组 功能来应用人工智能,以便更智能地进行处理。
组件
- Azure 应用服务 - Web 应用 托管允许自动缩放和高可用性的 Web 应用程序,而无需管理基础结构。
- Azure SQL 数据库 是 Microsoft Azure 中通用的关系数据库托管服务,支持关系数据、JSON、空间和 XML 等结构。
- AI 搜索 是一种云解决方案,它通过 Web、移动和企业应用程序中的专用异类内容提供丰富的搜索体验。
- Azure AI 机器人服务 提供了用于生成、测试、部署和管理智能机器人的工具。
- Azure AI 服务 使你能够使用智能算法通过自然的通信方法查看、倾听、说话、理解和解释用户需求。
选择
- 可以使用 数据库内搜索 功能,例如,通过 SQL Server 全文搜索,但事务存储还处理查询(增加处理能力的需求)和数据库中的搜索功能更加有限。
- 可以托管开源 Apache Lucene(在 Azure 虚拟机上构建 AI 搜索),但随后又回到管理基础结构即服务(IaaS),并且不会受益于 AI 搜索在 Lucene 上提供的众多功能。
- 还可以考虑从 Azure 市场部署 Elasticsearch,这是第三方供应商提供的替代且能够搜索的产品,但在这种情况下,还要运行 IaaS 工作负荷。
数据层的其他选项包括:
- Azure Cosmos DB - Microsoft的全球分布式多模型数据库。 Azure Cosmos DB 提供了一个平台来运行其他数据模型,例如 MongoDB、Cassandra、Graph 数据或简单的表存储。 AI 搜索还支持直接为 Azure Cosmos DB 中的数据编制索引。
方案详细信息
搜索是客户查找并最终购买产品的主要机制,使得搜索结果与搜索查询的 意向 相关至关重要,并且端到端搜索体验通过提供近乎即时的结果、语言分析、地理位置匹配、筛选、分面、自动完成和命中突出显示来匹配搜索巨头。
假设一个典型的电子商务 Web 应用程序,其产品数据存储在关系数据库中,如 SQL Server 或 SQL 数据库。 搜索查询通常通过使用 LIKE
查询或 全文搜索 功能在数据库中进行处理。 改用 AI 搜索,你可以从查询处理中释放操作数据库,并可以轻松开始利用那些难以实现的功能,从而为客户提供最佳的搜索体验。 此外,由于 AI 搜索是一个平台即服务(PaaS)组件,因此无需担心管理基础结构或成为搜索专家。
潜在的用例
此解决方案针对零售行业进行优化。
其他相关用例包括:
- 查找用户物理位置附近的房地产列表或商店(对于设施和房地产行业)。
- 在新闻网站上搜索文章或查找体育结果,更倾向于更 最近的 信息(对于体育、媒体和娱乐行业)。
- 在大型存储库中搜索 以文档为中心的 组织,例如决策者和公证员。
最终,具有某种形式的搜索功能的任何 应用程序都可以从专用搜索服务中受益。
考虑
这些注意事项实现 Azure Well-Architected 框架的支柱,这是一组指导原则,可用于提高工作负荷的质量。 有关详细信息,请参阅 azure Well-Architected Framework
可伸缩性
AI 搜索服务的 定价层 主要用于 容量规划,因为它定义了获得的最大存储以及可以预配的分区和副本数。 分区 允许索引更多文档并获取更高的写入吞吐量,而 副本 每秒提供更多的查询(QPS)和高可用性。
可以动态更改分区和副本的数量,但无法更改定价层。 因此,应仔细考虑适合目标工作负荷的层。 如果需要更改层,则需要并排预配新服务,并在该处重新加载索引,此时可将应用程序指向新服务。
可用性
AI 搜索提供 99.9% 可用性服务级别协议(SLA),用于 读取(即查询),如果至少有两个副本,则提供 更新(即更新搜索索引),前提是至少有三个副本。 因此,如果希望客户能够可靠地 搜索,则应预配至少两个副本,如果实际 索引 的更改也应考虑高可用性操作。
如果需要在不停机的情况下对索引进行重大更改(例如,更改数据类型、删除或重命名字段),则需要重新生成索引。 与更改服务层级类似,这意味着创建新的索引、使用数据重新填充索引,然后将应用程序更新为指向新索引。
安全
AI 搜索符合许多 安全性和数据隐私标准,因此可以在大多数行业使用它。
若要保护对服务的访问,可以使用
建议使用 Azure RBAC,因为它使用与 Microsoft Entra ID 集成的 Azure 角色。 使用 Azure 角色时,还可以使用无密码身份验证方法,例如 Azure 资源的托管标识。
API 密钥包括 管理密钥,这些密钥为所有内容操作提供完全访问权限,查询密钥,后者提供对搜索索引文档集合的只读访问权限。 应设置不需要更新索引的应用程序以使用查询密钥而不是管理密钥,尤其是最终用户设备(如 Web 浏览器中运行的脚本)执行搜索。
还可以通过在专用终结点
搜索相关性
电子商务应用程序的成功程度在很大程度上取决于搜索结果与客户的相关性。 仔细优化搜索服务,根据用户研究提供最佳结果,或依靠 搜索流量分析 了解客户的搜索模式,使你可以根据数据做出决策。
优化搜索服务的典型方法包括:
- 使用 计分配置文件 来影响搜索结果的相关性,例如,根据与查询匹配的字段、数据的最近程度以及与用户的地理距离。
- 使用 Microsoft提供的语言分析器 使用高级自然语言处理堆栈来更好地解释查询。
- 使用 自定义分析器,以确保正确找到产品,尤其是在你想要搜索非语言信息(如产品的制作和模型)时。
成本优化
成本优化是研究减少不必要的开支和提高运营效率的方法。 有关详细信息,请参阅 成本优化支柱概述。
若要探索运行此方案的成本,前面提到的所有服务都预配置在成本计算器中。 若要查看特定用例的定价如何更改,请更改相应的变量以匹配预期使用情况。
根据预期处理的流量考虑这些示例成本配置文件:
-
Small:此配置文件使用单个
Standard S1
Web 应用来托管网站、Azure AI 机器人服务的免费层、单个Basic
搜索服务和Standard S2
SQL 数据库。 -
中等:此配置文件将 Web 应用纵向扩展到
Standard S3
层的两个实例,将搜索服务升级到Standard S1
层,并使用Standard S6
SQL 数据库。 -
大型:此配置文件使用
Premium P2V2
Web 应用的四个实例,将 Azure AI 机器人服务升级到Standard S1
层(高级通道中包含 1.000.000 条消息),并使用两个单元Standard S3
搜索服务和Premium P6
SQL 数据库。
部署此方案
若要部署此方案的某个版本,可以按照此 分步教程 提供运行作业搜索网站的 .NET 示例应用程序。 它演示了迄今为止讨论的大部分 AI 搜索功能。
贡献
本文由Microsoft维护。 它最初由以下参与者编写。
主体作者:
- Jelle Druyts |首席客户工程师
若要查看非公共LinkedIn配置文件,请登录到LinkedIn。
后续步骤
若要了解有关 AI 搜索的详细信息,请访问
若要详细了解其他 Azure 组件,请参阅以下资源: