📢 转载信息
原文作者：Rishi Srivastava, Scott Reynolds, Brian Halperin, Brian Yost, Parth Patwa, Smita Bailur, Shreya Mohanty, and Yingwei Yu
本文由 Clarus Care 的 Rishi Srivastava 和 Scott Reynolds 合作撰写。
如今，许多医疗机构都在努力高效地管理大量的患者呼叫。从预约安排、处方续订到账单咨询和紧急医疗问题，医疗机构面临着在提供及时响应的同时保持优质患者护理的挑战。传统的电话系统通常会导致长时间的等待，患者感到沮丧，员工因需要手动处理和优先处理数百个日常呼叫而不堪重负。这些沟通瓶颈不仅影响患者满意度，还可能延迟关键的护理协调。
在本文中，我们展示了医疗联络中心解决方案提供商 Clarus Care 如何与 AWS 生成式 AI 创新中心 (GenAIIC) 团队合作，开发了一个由生成式 AI 驱动的联络中心原型。该解决方案通过自动化的语音机器人和聊天界面实现了会话式交互和多意图解决。它还纳入了一个可扩展的服务模型以支持增长、人工转接能力（应请求或在紧急情况下）以及用于性能洞察的分析管道。
Clarus Care 是一家医疗技术公司，通过人工智能驱动的呼叫管理系统帮助医疗机构管理患者沟通。通过自动转录、优先排序和路由患者消息，Clarus 提高了响应时间，减轻了员工的工作量，并最大限度地减少了等待时间。Clarus 是增长最快的医疗呼叫管理公司，为 40 多个专科的 16,000 多名用户提供服务。该公司每年处理 1500 万次患者呼叫，客户留存率保持在 99%。
用例概述
Clarus 正在踏上一段创新之旅，旨在将其患者通信系统从传统的菜单驱动式交互式语音应答 (IVR) 转变为更自然、更具会话性的体验。该公司旨在通过创建能够理解和解决单个交互中多个患者意图的生成式 AI 驱动的联络中心，彻底改变患者与医疗服务提供者互动的方式。以前，患者需要通过固定的菜单选项来留言，然后系统会将这些留言转录和处理。这种方法虽然有效，但限制了系统有效处理复杂患者需求的能力。Clarus 认识到需要一种更直观、更灵活的解决方案，因此与 GenAIIC 合作开发了一个 AI 驱动的联络中心，该中心能够理解自然语言对话、管理多个意图，并在语音和网络聊天界面中提供无缝体验。该项目的关键成功标准包括：
- 一种自然语言语音界面，能够在一次通话中理解和处理多个患者意图，例如账单咨询、预约和处方续订
- 后端处理和响应用户的延迟 <3 秒
- 转录、记录和分析呼叫信息的能力
- 针对紧急呼叫或患者要求直接与服务提供者交谈时的智能转接功能
- 支持语音呼叫和网络聊天界面，以适应各种患者偏好
- 可扩展的基础设施，以支持 Clarus 不断增长的客户群和不断扩大的医疗机构网络
- 实现 99.99% SLA 要求的高可用性，以确保可靠的患者沟通
解决方案概述与架构
GenAIIC 团队与 Clarus 合作，使用 Amazon Connect 和 Amazon Lex 创建了一个生成式 AI 驱动的联络中心，并通过 Amazon Bedrock 集成到 Amazon Nova 和 Anthropic 的 Claude 3.5 Sonnet 基础模型中。选择 Connect 作为核心系统是因为它能够在提供全面的联络中心能力的同时，跨语音和聊天渠道保持 99.99% 的可用性。
Bedrock 的模型灵活性是系统的核心，它允许根据准确性和延迟选择特定任务的模型。Claude 3.5 Sonnet 因其高质量的自然语言理解能力而被选用，而 Nova 模型则针对低延迟以及相当的自然语言理解和生成能力进行了优化。下图说明了主联络中心解决方案的架构图：
工作流程包括以下高层步骤：
- 患者通过电话或网络聊天界面发起联系。
- Connect 处理初始联系并将其路由到配置的联络流。
- Lex 处理转录并维护对话状态。
- 一个 AWS Lambda 履行函数通过 Bedrock 使用 Claude 3.5 Sonnet 和 Nova 模型来处理对话，包括：
- 分类紧急程度和意图
- 提取所需信息
- 生成自然回复
- 在适用时管理预约安排
用于每个特定功能的模型在解决方案的详细部分中进行了描述。
- 当检测到紧急情况或患者要求与服务提供者交谈时，启动到员工的智能转接。
- 对话数据通过分析管道进行处理，用于监控和报告（本博文稍后将介绍）。
团队在开发过程中解决的一些挑战包括：
- 以一种可互换的方式格式化联络中心呼叫流和服务模型，以适应不同的客户，且代码和配置更改最少
- 管理自然对话体验所需的延迟
- 患者姓名的转录和理解
除了语音呼叫，团队还使用 Amazon CloudFront 和 Amazon S3 静态网站托管开发了一个网络界面，演示了系统的多渠道能力。该界面展示了患者如何通过聊天小部件参与 AI 驱动的对话，提供与语音呼叫相同水平的服务和功能。虽然网络界面演示使用了与语音呼叫相同的联络流，但可以针对聊天特定语言进行进一步定制。
团队还构建了一个分析管道，用于处理对话日志，从而提供有关系统性能和患者交互的宝贵见解。一个可定制的仪表板提供了一个用户友好的界面来可视化这些数据，使技术和非技术人员都能从患者通信中获得可操作的见解。分析管道和仪表板是使用先前发布的 可重用 GenAI 联络中心资产 构建的。
对话处理详情
该解决方案采用了一个复杂的对话管理系统，通过 Bedrock 的多模型能力和精心设计的提示分层来协调自然的患者交互。该系统的核心是 Bedrock 能够提供对多个基础模型的访问，使团队能够根据准确性、成本和延迟要求为每个特定任务选择最佳模型。对话管理系统的流程如下所示；NLU 代表自然语言理解。
对话流程从问候和紧急程度评估开始。当患者来电时，系统会立即使用 Bedrock API 评估情况是否需要紧急关注。此第一步确保紧急情况得到快速识别和适当路由。系统使用一个集中的提示，根据预定义的紧急意图类别分析患者的初始陈述，返回“urgent”（紧急）或“non_urgent”（非紧急），以指导后续处理。
接下来，系统进入意图检测阶段。这里的关键创新是系统能够在单次交互中处理多个意图的能力。系统不再强制患者通过固定的菜单树，而是可以利用强大的语言模型来理解何时患者同时提到了处方续订和账单问题，并将这些意图排队按顺序处理，同时保持自然的对话流程。在提取过程中，我们确保同时提取意图和用户输入的引文。这会产生两个结果：
- 集成的模型推理，以确保提取正确的意图
- 导致意图提取的对话历史引用，因此除非明确要求，否则不会重复提取相同的意图
一旦系统开始按顺序处理意图，它就会开始提示用户提供服务当前意图所需的数据。这发生在两个相互依赖的阶段：
- 检查缺失的信息字段并生成自然语言提示以向用户索要信息
- 解析用户话语以分析和提取已收集的字段和仍缺失的字段
这两个步骤会循环进行，直到收集到所需信息。系统在此阶段还会考虑特定于服务提供者的服务，收集所需字段。该解决方案会自动将患者提到的服务提供者名称与系统中的正确服务提供者匹配。这可以处理诸如“史密斯医生”匹配到“詹妮弗·史密斯医生”或“珍妮·史密斯”之类的变体，从而消除了传统 IVR 系统中严格的名称匹配或分机要求。该解决方案还包括智能交接功能。当系统需要确定患者是否应与特定服务提供者交谈时，它会分析对话上下文，以考虑所表达意图的紧急程度和路由需求。此过程会保留对话上下文和收集到的信息，在请求人工干预时，从而实现无缝体验。在整个对话中，系统通过 Lex 会话属性保持全面的状态跟踪，而自然语言处理则通过 Bedrock 模型调用进行。这些属性充当对话的记忆，存储从用户的收集信息和对话历史到检测到的意图和收集到的信息的所有内容。这种状态管理使得系统能够在多次 Bedrock API 调用中保持上下文，从而创建更自然的对话流程。
意图管理
意图管理系统是根据患者自然表达需求的方式设计的，采用分层服务模型结构。为了遍历这种分层服务模型，使用自然语言理解来解析用户输入，这些解析是通过 Bedrock API 调用来处理的。
分层服务模型将意图组织成三个主要级别：
- 紧急程度级别：将紧急服务与非紧急服务分开，有助于适当的处理和路由。
- 服务级别：将预约、处方和账单等相关服务分组，创建逻辑类别。
- 服务提供者特定级别：提供更精细的粒度，以适应服务提供者特定的要求和子服务
这种结构使系统能够有效导航可能的意图，同时保持跨不同医疗机构进行定制的灵活性。模型中的每个意图都包含可以动态注入到 Bedrock 提示中的自定义指令，从而无需代码更改即可实现高度可配置的行为。意图提取过程利用了 Bedrock 的高级语言理解能力，通过一个指示模型识别患者自然语言输入中存在的意图的提示来实现。该提示包含有关什么是新意图、所有可能的意图列表以及响应格式要求的全面说明。我们旨在检测同时表达的多个需求，而不是强制将分类限制为单个意图。识别出意图后，它们被添加到处理队列中。然后，系统按顺序处理每个意图，进行额外的模型调用，以多层方式通过自然对话收集所需信息。为了优化质量和延迟，该解决方案针对各种对话任务，以类似方式利用 Bedrock 的模型选择灵活性：
- 意图提取使用 Bedrock 中的 Anthropic Claude 3.5 Sonnet 进行详细分析，该分析可以从自然语言中识别多个意图，确保患者无需重复信息。
- 信息收集采用 Bedrock 中的更快速模型 Amazon Nova Pro，以保持对话语气的同时进行结构化数据提取。
- 响应生成利用 Bedrock 中的较小模型 Nova Lite，根据对话状态创建低延迟、自然且富有同理心的响应。
这样做有助于确保解决方案能够：
- 保持对话语气和同理心
- 只询问缺失的具体信息
- 承认已提供的信息
- 处理特殊情况，如拼写出姓名
整个意图管理管道受益于 Bedrock 统一的 Converse API，它提供了：
- 跨模型调用的一致接口，简化了开发和维护
- 模型版本控制，促进了跨部署的稳定行为
- 面向未来的架构，允许随着新模型的发布无缝采用，以实现长期可扩展性和性能优化。
通过实施这种分层意图管理系统，Clarus 可以为患者提供更自然、更高效的沟通体验，同时保持适当路由和信息收集所需的结构。将 Bedrock 的多模型能力与可配置的服务模型相结合的灵活性，允许在保持核心对话逻辑一致性和可维护性的同时，针对不同的医疗机构进行简单的定制。随着 Bedrock 中新模型的可用，可以通过对架构进行重大更改而无需更改，来更新系统以利用改进的功能，从而促进长期可扩展性和性能优化。
预约安排
解决方案的预约安排组件在一个单独的、专门构建的模块中处理。如果在主处理程序中检测到“appointment”（预约）意图，则将处理传递给调度模块。该模块作为由对话状态和下一步组成的状态机运行。调度系统的总体流程如下所示：
调度系统流程 1. 初始状态 - 说明营业时间 - 询问预约偏好 - 进入 GATHERING_PREFERENCES (收集偏好) 2. GATHERING_PREFERENCES 状态 - 使用 LLM 提取和处理时间偏好 - 将时间偏好与现有调度数据库进行核对 - 三种可能的结果： a. 存在特定时间 - 呈现时间以供确认 - 进入 CONFIRMATION (确认) 状态 b. 存在时间范围偏好 - 在范围内查找最早可用时间 - 呈现此时间以供确认 - 进入 CONFIRMATION 状态 c. 无可用时间（特定时间或范围） - 查找备用时间（请求时间的前后 1 天） - 呈现可用时间段 - 询问偏好 - 保持在 GATHERING_PREFERENCES - 增加尝试计数器 3. CONFIRMATION 状态 - 两种可能的结果： a. 用户确认（是） - 预订预约 - 发送确认消息 - 进入 END (结束) 状态 b. 用户拒绝（否） - 询问新偏好 - 进入 GATHERING_PREFERENCES - 增加尝试计数器 4. 附加功能 - 最大尝试次数跟踪（默认 MAX_ATTEMPTS = 3） - 达到最大尝试次数时： - 道歉并升级到办公室员工 - 进入 END 状态 5. END 状态 - 对话完成 - 成功预订或升级到员工 在调度流程中使用了三种主要的 LLM 提示：
- 提取时间偏好（使用 Nova Lite 实现低延迟和偏好理解）：
从对话中提取当前的预约偏好。响应必须采用此格式：<reasoning> 解释： - 表达了哪种类型的偏好（特定时间或范围） - 您如何解释任何相对日期或时间 - 您如何构建和优先排序偏好的原因 - 您所做的任何假设 </reasoning> <json> [ {{ "type": "specific", "priority": n, "specificSlots": [ {{ "date": "YYYY-MM-DD", "startTime": "HH:mm", "endTime": "HH:mm" }} ] }}, <!-- 每个不同偏好重复 --> {{ "type": "range", "priority": n, "dateRange": {{ "startDate": "YYYY-MM-DD", "endDate": "YYYY-MM-DD", "daysOfWeek": [], // "m", "t", "w", "th", "f" "timeRanges": [ {{ "startTime": "HH:mm", "endTime": "HH:mm" }} ] }} }} <!-- 每个不同偏好重复 --> ] </json> 指南： - 如果对话中时间偏好有所变化，只提取当前偏好 - 如果需要，可以有多个相同类型的偏好 - 确保正确的 JSON 格式，输出的 JSON 部分应能正确地与 json.loads() 配合使用。请勿在 JSON 中包含注释。 - 将相对日期（明天，下周二）转换为特定日期 - 关键词：* 上午: 09:00-12:00 * 下午: 12:00-17:00 - 将时间描述转换为特定范围（例如，“上午 11 点之前”：09:00-11:00，“下午 2-4 点”：14:00-16:00） - 预约仅在工作日 9:00-17:00 开放 - 如果未指定时间段的结束时间，则假定持续 30 分钟 示例： (示例部分为简洁省略) 现在，从给定对话中提取预约偏好。当前时间：{current_time} 今天是 {current_day} 对话： <conversation> {conversation_history} </conversation>- 确定用户是在确认还是拒绝时间（使用 Nova Micro 实现简单任务的低延迟）
确定用户是确认还是拒绝建议的预约时间。如果他们明确确认，则返回 "true"，否则返回 "false"。 <confirm>true|false</confirm> 用户消息：{user_message}- 根据下一步生成自然回复（使用 Nova Lite 实现低延迟和响应生成）
考虑到对话历史和下一步，生成一个自然且符合上下文的回复给用户。将您的回复输出在 <response> 标签中： <response>您的回复在这里</response> 对话历史： {conversation_history} 下一步： {next_step_prompt}可能的步骤包括：
- 初始问候
询问用户他们希望与 {provider} 安排预约的时间。不要说 Hi 或 Hello，因为这是对话中段。告知他们我们的营业时间是 {office_hours}。- 确认时间
{provider} 医生在 {time} 有空。在继续预订之前，询问用户是同意还是不同意此时间。 不要说预约已确认。- 显示备用时间
告知用户他们请求的时间 {requested_time} 不可用。 向他们提供 {provider} 医生的以下备用时间或时间范围：{blocks} 询问哪一个时间最适合他们。- 询问新偏好
确认建议的时间不适合他们。 询问他们希望与 {provider} 医生预约什么其他日期或时间。 提醒他们我们的营业时间是 {office_hours}。- 告知用户您将升级给办公室人员
为未能找到合适的时间表示歉意。 告知用户您将让我们的办公室工作人员联系他们，以帮助找到一个适合他们的预约时间。感谢他们的耐心等待。- 以预约确认为对话收尾
非常简短地确认 {provider} 医生的预约已在 {time} 确认。不要再说其他任何话。 示例：已确认与 Wolf 医生预约在 6 月 5 日系统扩展
将来，Clarus 可以将联络中心的语音机器人与 Amazon Nova Sonic 集成。Nova Sonic 是一款语音到语音的 LLM，可提供实时、类人语音对话，并具有领先的价格性能和低延迟。Nova Sonic 现在已直接集成到 Connect 中。
Bedrock 有几项附加服务有助于扩展解决方案和将其部署到生产环境，包括：
- 通过 Bedrock Knowledge Bases 对检索增强生成 (RAG) 和结构化数据检索的原生支持
- Bedrock Guardrails，用于实施内容和 PII/PHI 安全措施
- Bedrock Evaluations，用于自动化和基于人工的对话评估
结论
在本博文中，我们演示了 GenAIIC 团队如何与 Clarus Care 合作，使用 Amazon Connect、Amazon Lex 和 Amazon Bedrock 开发了一个生成式 AI 驱动的医疗联络中心。该解决方案展示了一个会话式语音界面，该界面能够处理多个患者意图、管理预约安排并提供智能转接功能。通过利用 Amazon Nova 和 Anthropic 的 Claude 3.5 Sonnet 语言模型以及 AWS 服务，该系统在提供更直观、更高效的患者通信体验的同时实现了高可用性。该解决方案还包含一个用于监控呼叫质量和指标的分析管道，以及一个演示多渠道支持的网络界面。该解决方案的架构提供了一个可扩展的基础，可以适应 Clarus Care 不断增长的客户群和未来的服务产品。从传统的菜单驱动 IVR 过渡到 AI 驱动的会话界面，使 Clarus 能够帮助提升患者体验、增加自动化能力并简化医疗通信。随着他们向实施迈进，该解决方案将使 Clarus Care 能够在日益数字化的医疗环境中，满足患者和医疗服务提供者不断变化的需求。
如果您想为您的用例实施类似的解决方案，请参考博客 使用 Amazon Connect、Amazon Lex 和 Amazon Bedrock Knowledge Bases 在您的联络中心部署用于语音和聊天的生成式 AI 代理以了解基础架构设置。
作者简介
🚀 想要体验更好更全面的AI调用？
欢迎使用青云聚合API，约为官网价格的十分之一，支持300+全球最新模型，以及全球各种生图生视频模型，无需翻墙高速稳定，文档丰富，小白也可以简单操作。
评论区