你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
解决方案构想
本文介绍了一种解决方案构想。 云架构师可以通过本指南来帮助可视化此体系结构的典型实现的主要组件。 以本文为起点,设计一个符合工作负荷特定要求的架构合理的解决方案。
此体系结构演示对话知识挖掘解决方案,该解决方案从大量聊天数据(例如从呼叫中心)中提取可作的见解。 该解决方案使用 Azure AI 内容理解、Azure AI 搜索、Azure OpenAI 和支持 Azure 服务来分析非结构化对话,并通过自然语言处理和基于矢量的搜索功能将其转换为有意义的结构化见解。
该体系结构演示如何构建可缩放的对话分析管道,这些管道通过事件驱动的工作流处理音频和视频输入、提取实体和关系,以及通过企业级聊天智能的自然语言聊天接口实现见解的交互式探索。
建筑
下载此体系结构的 Visio 文件。
Workflow
以下工作流与上图相对应:
原始呼叫音频文件和呼叫脚本存在于其源系统中。
音频文件和脚本作为初始数据源上传到 Azure 存储帐户。 数据处理管道分析客户服务调用中的音频和脚本文件,并创建可搜索的知识库。 在此引入阶段,音频文件使用语音转文本技术转换为文本,而直接处理脚本以供内容分析。 此过程每天发生,但你的方案可能需要不同的频率。
内容理解处理音频和文本文件,以提取对话详细信息、实体、关系和上下文信息。 此服务执行主题建模和关键短语提取,以识别聊天数据中的有意义模式。 此数据包括特定于呼叫的元素,例如解决状态、客户满意度指标和合规性标记。
提取的实体和已处理的聊天数据存储在 Azure SQL 数据库中进行结构化查询,而 AI 搜索则创建调用脚本的矢量化表示形式。 这些嵌入可实现跨整套脚本的语义搜索,并支持与调用结果、代理性能和客户情绪趋势相关的复杂查询。
自定义应用程序代码对步骤 3 提取的调用脚本数据执行主题建模。 它会自动识别和分类对话主题,例如计费问题、技术支持或产品反馈。 此过程使用 Azure AI Foundry 中托管的 Azure OpenAI 模型作为托管服务。 Azure AI Foundry 代理服务协调工作流,以分析脚本并提取主题。 主题建模应用机器学习算法,通过为每个对话分配主题标签和置信度分数来发现语言用法中的模式,并对相关字词或短语进行分组。 结果将保存到 SQL 数据库,该数据库可实现大规模客户呼叫的自动分类和见解生成。
计划批处理管道定期运行,以处理步骤 1 和 2 中存储在存储帐户中的新数据。 管道使用内容理解服务来分析呼叫音频文件和脚本。 它提取见解并将原始数据转换为结构化的可搜索信息。 处理的结果将写入 AI 搜索,后者存储矢量化调用脚本以启用语义搜索功能,以及存储提取的实体和结构化数据的 SQL 数据库。 管道可以在单线程模式下运行,以便进行顺序处理。 或者,它可以跨多个线程并行运行,以处理更大的数据卷并提高处理吞吐量,具体取决于工作负荷要求和系统容量。
Azure 应用服务中的业务流程层通过管理服务之间的数据流并提供 API 终结点来协调整个工作流。 它使用函数调用功能增强聊天分析工作流,将 Azure AI Foundry 和 Semantic Kernel 中的 Azure OpenAI 模型集成到智能处理和响应生成。 此业务流程仅用于处理聊天请求。
用户访问应用服务上托管的 Web 前端,以探索通话见解、使用自然语言查询与数据聊天以及生成可视化效果。 该界面提供对已处理知识库的对话访问,并启用查询,例如 显示上个月所有未解决的计费投诉 ,或者升级 最常见的原因是什么?
Azure Cosmos DB 存储聊天历史记录和会话数据。 它维护交互式前端体验的对话上下文,并在整个应用程序中启用持久用户会话。 聊天历史记录存储在 Azure Cosmos DB 中,因此 Azure Cosmos DB 仅与应用交互,以拉取用户以前的问题和答案。 要查询新问题的数据位于 SQL 数据库和 AI 搜索索引中。
组件
存储帐户是一种可缩放的云存储服务,可为各种数据类型提供安全且持久的存储。 在此体系结构中,存储帐户充当呼叫音频文件和脚本的主要引入点。 它为聊天分析管道提供了可靠的基础,并支持热、冷和存档存储层,以优化长期聊天数据保留的成本。
内容理解 是一种 AI 服务,用于从非结构化内容(包括音频和文本)中提取见解。 在此体系结构中,内容理解处理对话数据以标识实体、关系和关键主题。 它将原始对话转换为结构化、可分析的信息,包括特定于呼叫中心的见解,例如解决指示器、升级触发器和合规性标记。
AI 搜索 是一种云搜索服务,通过用户生成的内容提供丰富的搜索功能。 在此体系结构中,AI 搜索创建和管理呼叫脚本的矢量化表示形式。 此方法可实现语义搜索和检索扩充生成(RAG)模式,以便进行智能聊天探索。 它使用优化的索引策略高效处理数百万条聊天记录。
SQL 数据库 是一种完全托管的关系数据库服务,可提供高可用性和可伸缩性。 在此体系结构中,SQL 数据库存储提取的实体、聊天元数据和结构化见解。 此配置可实现对聊天智能数据的高效查询和分析,包括呼叫指标、代理性能数据和客户满意度分数。
应用服务 是一种平台即服务(PaaS)产品/服务,用于构建和托管 Web 应用程序。 在此体系结构中,应用服务同时托管协调数据处理工作流的业务流程 API 和交互式 Web 前端,使用户能够通过自然语言交互探索对话见解。
Azure OpenAI 是一个基于云的平台,Microsoft提供对高级语言模型的访问权限,以便进行自然语言处理和生成。 在此体系结构中,Azure OpenAI 为聊天聊天界面提供支持。 此界面使用户能够询问有关其聊天数据的问题,并通过 RAG 模式接收上下文响应。
语义内核 是一种开源 SDK,可将大型语言模型与传统编程语言集成。 在此体系结构中,语义内核协调 Azure OpenAI 与其他 Azure AI 服务之间的交互。 它还管理函数调用和协调智能工作流。
Azure Cosmos DB 是一种全球分布式多模型数据库服务,可保证低延迟。 在此体系结构中,Azure Cosmos DB 存储聊天历史记录和用户会话数据。 此存储支持快速访问交互式前端体验的对话上下文。
Azure 容器注册表 是用于存储和管理容器映像的托管 Docker 注册表服务。 在此体系结构中,容器注册表管理应用程序组件的容器映像。 此管理可确保整个解决方案的部署和版本控制一致。
Azure AI Foundry 是来自 Microsoft的统一 PaaS 产品/服务,它通过 REST API 和 SDK 提供全面的 AI 功能集合。 在此体系结构中,Azure AI Foundry 通过额外的主题建模功能增强聊天分析。 这些功能补充了核心内容理解和搜索功能。
方案详细信息
此对话知识挖掘解决方案解决了从大量非结构化对话数据中提取可作见解的挑战,组织从客户交互、支持呼叫、销售对话和内部会议中累积。 传统的分析方法难以大规模处理聊天数据并提取有意义的模式。 因此,组织在了解客户情绪、识别运营问题以及发现改进机会方面面临限制。
该解决方案使用高级 AI 功能自动处理音频录制和文本脚本、提取关键实体和关系,以及创建可通过自然语言交互探索的可搜索知识库。 这些功能使分析师和业务用户能够快速识别趋势、了解客户反馈模式,并做出数据驱动的决策,而无需数据分析或查询语言的技术专业知识。
可能的用例
请考虑以下潜在的用例。
客户服务优化
联系中心质量改进: 分析客户支持呼叫,以确定常见问题、衡量解决有效性,并发现跨不同生产线和服务类别的支持代理的培训机会。
代理性能评估: 分析聊天模式,确定表现最强的代理使用的技术,识别常见的解决策略,并突出指导机会。 跟踪指标,例如首次调用解决率和升级模式。
客户情绪分析: 从客户交互中提取情感指标和满意度趋势,以提高服务交付。 使用这些见解识别风险帐户并优化策略以增强客户体验。
支持票证关联: 将对话主题与支持票证结果相连接,以优化路由并减少解决时间。 此方法有助于主动解决定期客户问题。
质量评分自动化: 提取与客户满意度分数关联的聊天元素。 使用这些见解可以自动执行质量保证流程,并确保在所有交互中进行一致的评估。
销售和营销智能
- 销售对话分析: 从销售呼叫中提取见解,以识别成功的对话模式、反对处理技术和竞争智能。 使用这些见解来提高销售效率并增强培训计划。
替代方案
此体系结构包括多个组件,这些组件可以替换为其他 Azure 服务或方法,具体取决于工作负荷的功能和非功能要求。 评估以下替代方案和权衡,以符合特定目标。
内容处理方法
当前方法: 此解决方案使用内容理解作为主要服务,用于从对话数据中提取实体、关系和见解。 它提供专用对话分析功能,内置了对对话模式和对话上下文的理解。
替代方法: 使用 Azure AI 文档智能与 Azure OpenAI 结合使用,使用提示工程和少量学习(FSL)技术来处理脚本和提取结构化信息。
如果工作负荷具有以下特征,请考虑使用替代方法:
你需要处理已采用结构良好的文档格式的对话。
需要超出标准聊天分析的自定义实体提取。
你希望通过自定义提示和示例更好地控制提取逻辑。
对话包括需要文档特定处理的复杂格式或混合内容类型。
搜索和检索策略
当前方法: 此解决方案使用带有矢量嵌入的 AI 搜索,以跨对话脚本启用语义搜索。 它支持自然语言查询和基于 RAG 的交互。
替代方法: 使用具有矢量搜索功能的 Azure DocumentDB 实现纯矢量数据库解决方案。 或者,将 Azure Database for PostgreSQL 与 pgvector 扩展配合使用。
如果工作负荷具有以下特征,请考虑使用替代方法:
需要极其高性能的矢量相似性搜索,且延迟最小。
你的解决方案需要与现有的 MongoDB 或 PostgreSQL 生态系统紧密集成。
你希望最大程度地减少体系结构中不同服务的数量。
搜索要求主要是基于矢量的,不需要传统的全文搜索功能。
成本优化
成本优化侧重于减少不必要的开支和提高运营效率的方法。 有关详细信息,请参阅成本优化设计评审核对清单。
有关运行此方案的成本的详细信息,请参阅 Azure 定价计算器中的预配置估算值。
定价因区域和使用情况而异,因此无法预测特定工作负荷的确切成本。 此基础结构中的大多数 Azure 资源都遵循基于使用情况的定价层。 但是,某些服务(如容器注册表)为每个注册表产生固定的每日成本。 其他服务(如 SQL 数据库和 Azure Cosmos DB)可能会在预配基线费用后立即生成,而不管实际使用情况如何。
部署此方案
若要部署此体系结构的实现,请遵循 GitHub 存储库中的步骤。
部署包括自动化基础结构即代码(IaC)模板、用于测试的示例聊天数据,以及设置文档,以帮助你入门。
供稿人
Microsoft维护本文。 以下参与者撰写了本文。
主要作者:
- 所罗门·皮克特 |软件工程师 II
其他参与者:
- 马洛里·罗斯 |高级软件工程师
若要查看非公开的LinkedIn个人资料,请登录LinkedIn。