Natera利用Amazon Bedrock AgentCore实现智能预约安排

了解Natera如何在Amazon Bedrock AgentCore上构建自动语音代理,让患者通过自然对话预约移动抽血服务。文章涵盖了双WebSocket桥接、事件驱动延迟掩蔽和渐进信任机制。

来源:亚马逊云科技 _机器学习

对于已经在接受治疗的肿瘤患者来说,预约抽血不应成为一件麻烦事。Natera的服务由Amazon Bedrock AgentCore提供支持,允许抽血师上门服务,为Natera提供更便捷的患者体验。

Natera是一家专注于游离DNA检测的全球诊断公司,希望通过更优的方式取代人工预约电话,从而改变其患者体验。他们利用Amazon Bedrock AgentCore构建了一个自动语音代理,使患者能够通过对话预约,同时保持医疗保健领域所需的准确性和合规标准。

在本文中,我们将分享Natera基于Bedrock AgentCore构建的语音调度代理的架构模式和设计决策。您将了解Natera和AWS如何利用三大核心架构原则设计一个连接电话系统、基础模型和后端服务的实时语音代理:双WebSocket桥接模式、事件驱动延迟掩盖技术,以及对话中认证的渐进式信任模型。文章解释了每项设计选择的理由,并展示了该架构在500次端到端通话模拟验证中实现了100%的工具调用准确率,感知延迟低于7秒,每次通话成本低于0.01美元。本文还提供了一个系统设计,展示了每个AWS服务如何连接,以及Natera为何在其实施中做出特定的集成选择。

我们将带您了解Natera如何从Amazon Elastic Container Service迁移到Amazon Bedrock AgentCore运行时,包括团队在此过程中如何应对WebSocket生命周期和会话状态挑战。

挑战:大规模调度的复杂性

Natera当前的移动抽血服务帮助患者在家预约抽血,而非前往诊所。调度系统支持这一工作流程。

患者致电、完成身份验证,并提供三个首选预约日期及其服务地点。随后,人工调度团队与抽血师和供应商协调,确认其中一个提议的时间段。

该工作流程需要利用个人标识符和短信验证码进行患者身份验证,集成多个第三方供应商系统以获取预约可用时段,并为复杂场景提供优雅的降级选项。现有系统使用第三方人工智能提供商进行语音交互和编排,通过Twilio连接电话连接,并在Amazon ECS容器上运行。虽然功能可用,但团队发现了在准确性、可扩展性和对话参与度方面的改进机会。

对于使用Epic或Cerner并具备标准预约预订工作流程的组织,Amazon Connect Health提供预构建的患者参与代理,可开箱即用地处理验证和调度。Natera的用例需要自定义供应商协调和电话灵活性,超出了预构建解决方案当前的支持范围,因此AgentCore成为合适的架构基础。

为何选择Amazon Bedrock AgentCore

Natera选择在Amazon Bedrock AgentCore上重建其调度代理,该服务可用于使用任何框架或模型大规模构建、连接和优化代理。他们在评估了该服务如何应对其核心运营挑战后做出了这一选择。该团队需要大规模地利用自主AI代理满足客户需求,而无需承担管理容器基础设施或扩展配置的负担。AgentCore的完全托管架构减轻了这种运营开销。

同样重要的是在处理延迟期间保持高客户参与度,他们可以通过Amazon Bedrock使用快速基础模型生成上下文感知的中间响应,从而保持对话自然,从而实现这一目标。内置内存管理系统存储之前的患者活动,使代理能够提供个性化、主动式的支持。

Natera还采用AgentCore的内置可观测性。每当代理处理请求时,AgentCore都会捕获每个步骤发生情况的详细追踪信息。团队可以查看调用了哪些工具、每个步骤耗时多久以及模型做出了什么决策。他们可以端到端地跟踪各个会话,并精确定位延迟发生的位置,无论是模型推理、工具执行还是内存检索。对于准确性和性能不容妥协的医疗保健环境而言,这种可见性水平使得无需猜测即可快速识别和修复问题成为可能。

解决方案概述

本节介绍Natera语音调度代理的端到端架构。该设计遵循三大核心原则,使其可适应其他实时语音AI用例:

  • 双WebSocket桥接模式通过在电话流媒体和模型推理之间放置一个编排层来分离两者。这意味着系统与电话提供商保持一个WebSocket连接,与基础模型保持另一个WebSocket连接,并由编排器管理两者之间的流量。这种分离使团队能够独立地更换任一端,例如在不重新设计整个系统的情况下,用Amazon Connect Health替换Twilio,或用Amazon Nova替换OpenAI。
  • 事件驱动的延迟掩盖将感知延迟视为头等设计问题,而非试图优化每个单独组件以追求原始速度。当代理需要调用工具(如检查预约可用性)时,该架构会并行生成上下文填充响应,因此患者听到的是自然的确认语而非静默。即使后端操作需要数秒才能完成,这种方法也能保持对话流畅感。
  • 渐进式信任模型随着对话的展开逐步升级认证和内存访问权限。系统并非要求患者在发生任何操作之前立即验证其身份,而是从低信任交互开始,并在患者通过身份验证后逐步授予对更敏感信息的访问权限。这创造了自然的对话流程,而非那种先验闸后进行的交易式体验。
  • 该架构的决策权衡点是编排复杂性的增加。管理两个并发的WebSocket连接、并行填充生成和渐进式内存会话需要仔细的状态管理。对于更简单的用例(如单轮问答或纯文本代理),无需桥接模式的直接集成将减少开销。

    下图说明了整体系统架构。它还展示了Natera如何将计算层从自管理容器过渡到完全托管无服务器环境,在保留前述设计原则的同时减轻了基础设施运维负担。

    图1:Natera在Amazon Bedrock AgentCore上的语音调度代理架构

    从Amazon ECS到AgentCore运行时的迁移方法

    Natera将其工作负载从Amazon ECS迁移到Bedrock AgentCore运行时。这是一个完全托管无服务器环境,在具有专用CPU、内存和文件系统资源的隔离微VM中托管AI代理。

    为开始迁移,团队将语音编排逻辑与容器特定的基础设施代码(如健康检查端点、扩展策略和部署清单)解耦。完成这种分离后,他们将代理的入口点重构为符合AgentCore运行时的调用接口,用AgentCore处理程序模式替换了HTTP服务器初始化。最后一步是将会话状态从容器本地存储迁移到Bedrock AgentCore内存,该内存提供了跨会话的持久存储,而无需管理单独的状态存储。

    团队在此迁移过程中遇到了两个主要挑战。一是使长期存在的WebSocket连接适应AgentCore运行时的执行模型。与无限期运行的Amazon ECS任务不同,AgentCore微VM的范围仅限于单次调用。团队通过在代理运行时上下文内实现连接池来解决这个问题,允许WebSocket会话在单次通话持续期间保持,而AgentCore管理底层计算生命周期。会话状态连续性构成了另一个挑战。在Amazon ECS上,对话状态存在于容器本地内存中,重启后丢失。迁移到AgentCore内存需要重新设计状态模型,将其外部化并按Actor ID作为键值,这最终提高了可靠性,但需要重构所有状态读写路径。

    这消除了管理容器扩展、健康检查和部署流水线的运营开销。

    请求流程详解

    以下各节描述了从患者拨打电话到收到确认预约的请求流程。

    通话发起和语音流式传输

    当患者拨打调度热线时,Twilio与运行AgentCore运行时的代理建立双向WebSocket连接。同时,代理与实时语音处理API建立第二个WebSocket连接。这创建了一个实时音频桥接。

    在入站路径上,Twilio将原始通话媒体(患者语音)流式传输到语音处理服务进行意图识别。在出站路径上,语音处理服务生成音频响应,并通过代理流式传输回Twilio,将合成语音传送到患者的电话。

    AgentCore运行时上的代理充当这两个WebSocket通道之间的编排层。它拦截来自语音处理服务的工具调用请求,执行业务逻辑,并将结果注入对话上下文。

    上下文感知填充生成(延迟掩盖)

    当代理处理工具调用时(步骤3-5),并行填充循环被激活以维持对话流畅性。该技术的工作方式如下:

    代理监控来自语音处理服务WebSocket流的工具调用事件。当工具调用开始时,填充循环启动一个定时器,该定时器根据该特定工具的预期持续时间进行校准(例如,认证API平均2.5秒,调度API平均4秒)。

    这些校准值来自团队在可观测性阶段运行的结构化测量过程。首先,他们利用AgentCore运行时的内置追踪导出功能,将每个工具延迟事件路由到Amazon CloudWatch Logs,覆盖两周的代表性通话流量。其次,他们查询日志以构建每个工具调用的延迟分布,提取P50响应时间作为基线。第三,他们从每个工具的P50中减去一秒以设置填充触发点,为Claude Haiku填充请求留出完成时间,并在大多数呼叫者注意到静默之前将其注入。

    结果是形成了一个每个工具的查找表(例如,认证触发点为1.5秒,调度触发点为3.0秒),当新的工具调用开始时,填充循环会查阅该表。采用此模式的团队可以通过对其自身的工具延迟分布重复相同的三个步骤,使用具备百分位数计算能力的日志分析工具来重新推导自己的表。

    在校准间隔(通常为工具调用开始后1.5秒),代理通过Amazon Bedrock发送请求以生成上下文响应。提示遵循以下模板结构:

    你是一个调度助理。系统当前正在执行[TOOL_NAME]。患者最后说的是:“[LAST_UTTERANCE]”当前工作流步骤:[STEP_NAME] 生成恰好一个短句(少于15个词),该句子:– 自然地承认短暂的等待 – 不承诺特定结果 – 与当前步骤的上下文匹配

    系统生成一个填充句(例如“让我调出你可用的时间段”或“我正在与你当地的供应商核对可用性”)。生成的填充句作为中间音频响应注入对话上下文。如果工具调用在填充间隔之前完成,则填充被抑制。这种事件驱动方法避免了对快速操作进行不必要的填充,同时掩盖了较慢操作的延迟。

    患者认证与内存转移

    代理通过利用AgentCore内存会话管理能力的分层验证过程来认证患者。

    过程从电话号码识别开始。代理使用SHA-256对来电者的电话号码进行哈希处理,并在通过AgentCore内存的会话管理API创建新会话时将该哈希值用作Actor ID。这会创建一个未认证会话,代理在其中存储早期对话上下文(如问候语和初始意图),而不会暴露敏感的患者数据。

    随着对话推进,代理通过收集患者的个人标识符来执行完整身份验证。在Natera身份服务成功验证后,代理使用已验证的患者ID作为Actor ID创建一个新的认证会话,从而建立对患者完整历史记录的访问权限。

    在建立两个会话后,代理迁移对话历史记录。它从未认证会话中检索对话轮次,并通过AgentCore内存的会话历史API将其注入认证会话。这提供了连续性,无需患者重复信息。随后,未认证会话被标记为已合并,并从未来的检索中排除。

    这种转换模式支持渐进式信任。基本交互(如回答一般性问题)在电话号码级别识别下进行。而敏感操作(如确认预约或访问健康记录)则需要完全验证。

    个性化上下文检索

    完成认证后,代理从两个来源检索患者的历史上下文。从Bedrock AgentCore内存中,代理检索之前的对话历史、预约偏好和先前交互的活动数据。AgentCore内存提供短期存储(当前会话对话)和长期存储(跨会话患者模式)。底层数据持久化在Amazon DynamoDB中,以实现大规模的低延迟读写访问。

    来自Amazon Managed Streaming for Apache Kafka和AWS Lambda事件流水线的数据,代理接收来自其他渠道的患者活动事件(网页门户活动、之前的短信、电子邮件和通话流量)。Lambda函数消费来自Amazon MSK的事件,并将相关的活动摘要写入AgentCore内存。这使语音代理即使对于首次使用AI的患者也能获得全面的上下文。

    知识库检索增强生成

    患者在调度通话中经常询问有关抽血过程、预期情况、如何准备或保险覆盖的问题。这些问题往往超出代理的预设提示范围。

    该系统使用Amazon Bedrock知识库(完全托管的检索能力)来实时扩展代理的知识。Natera将常见问题文档、程序指南和政策信息存储在Amazon Simple Storage Service中,无需维护专用的向量数据库基础设施。Amazon Titan Text Embeddings V2将文档和查询转换为向量表示以进行语义搜索。自定义分层分块策略在多个细节层级(章节、段落、句子)对文档进行分段。这支持与患者问题的具体性相匹配的精确检索。

    根据开发阶段对200个代表性患者查询数据集进行的内部测试,此配置对一般患者查询实现了超过90%的响应准确率。这使得对话能够持续进行,而无需将对话转接给人工操作员。

    预约调度与确认

    在患者通过身份验证并加载其偏好后,代理执行核心调度工作流程。代理首先检索产品类型和订单信息,以在继续之前宣布重要的产品特定提醒。然后,它根据患者的订单信息评估可用的预约时间窗口,并收集三个首选预约日期以及患者的服务地点。代理与Natera的其他服务交互以提交移动抽血预约请求,并通知患者预约详情。最后,它将确认的预约存储在患者的记忆档案中,以供将来参考。

    有关各区域模型可用性的信息,请参阅Amazon Bedrock中按AWS区域划分的支持模型。

    合规性与安全性

    该系统实施Amazon Bedrock Guardrails以维持对话安全和输出质量,并在商业伙伴协议下作为符合HIPAA资格的AWS服务运行。这些配置分为三个领域:数据隐私、对话安全和输出完整性。

    数据隐私和访问控制是系统设计的基石。该系统在符合HIPAA资格的AWS服务中并在商业伙伴协议下处理和存储受保护的健康信息。Guardrails提供输出级控制,阻止代理在语音交互期间回读敏感标识符,如SSN、信用卡或保险ID,即使底层基础设施安全地处理这些数据,也有助于防止口头泄露。处理个人信息工具的访问权限被置于身份验证之后。在患者通过身份验证之前,这些工具不会暴露给代理。即使在验证之后,工具访问范围也仅限于经过验证的患者的会话。代理在技术上没有能力查找其他患者的数据或为未经验证的呼叫者获取个人信息。

    语音处理架构在具有加密要求的数据处理协议下运行。Natera正在探索完全托管的AWS服务,以将所有音频处理保持在商业伙伴协议边界内。具有更严格数据驻留要求的组织现在就可以采用此路径。

    对话安全护栏定义了代理在患者交互期间能做什么和不能做什么的边界。代理不提供超出已验证工具调用返回内容的医疗建议、诊断或结果解读。当系统检测到亵渎语言、痛苦信号、紧急用语或某些标记的关键词时,会将对话升级给人工代理。该系统还会在验证患者的通信偏好并收到口头同意之前阻止短信通信。

    输出质量和RAG完整性护栏确保代理响应的准确性和可溯源性。确定性判定可防止重复、检测脱离上下文的响应,并在内容到达患者之前标记可疑内容。当代理与知识库交互时,幻觉检测和缓解在生成RAG响应之前运行。相似性评分和相关性评估在RAG响应呈现给患者之前进一步验证它们。

    结果

    经过四个月的迭代开发和跨越500次端到端通话模拟的测试,该解决方案在准确性和延迟方面表现出强劲性能。

    编排器在所有500个测试场景的验证中实现了100%的工具调用准确率,正确地将每个请求路由到相应的专业代理。参数提取同样精确:在模拟测试中,每次工具调用都收到了正确结构的参数。这些准确性指标通过AgentCore的内置追踪分析进行了验证,该分析记录每个代理循环迭代,并将调用的工具和参数与预期输出进行比较。

    感知延迟中位数为6.8秒,从患者输入到第一个有意义的响应(包括语音处理)端到端测量。仅Bedrock部分的耗时为6.2秒。这些数字是根据通过AgentCore的延迟细分工具捕获的会话时间戳计算的,样本来自真实患者交互的代表性样本。

    每次通话成本保持在每次完成通话低于0.01美元(测量为一次完整端到端患者交互的总成本,包括模型推理、工具执行和内存操作,而非每次对话轮次)。

    该语音代理处理从患者验证到确认的完整预约预订流程,包括身份验证、调度偏好和确认详情。响应准确率超过90%,通过将代理响应与人工审核的调度结果真实数据集进行比较,并根据预约详情、资格验证和患者特定上下文检索的正确性进行评分。

    团队的收获

    将此系统推向生产环境暴露了以下挑战:

    延迟感知比原始速度更重要。早期演示显示用户输入和代理响应之间有3-5秒的静默,造成了尴尬的停顿,有可能导致患者放弃AI转而寻求人工代理。团队发现瓶颈并非大型语言模型推理,而是外部服务调用,如API和身份验证检查。突破口来自于观察到人工代理完成相同任务比AI耗时更长,但能自然地管理等待时间,例如说“让我为您查一下”。患者不会将此视为延迟。通过在工具执行的同时生成上下文填充响应,团队将相同的原则应用于语音代理,无需加快后端调用速度即可消除静默。

    多样化输入测试及早揭示了盲点。语音识别能很好地处理常见名字,但误识别不常见的族裔名字,给患者身份验证带来了挑战。团队构建了一个姓名拼写辅助工具,当置信度较低时激活,要求患者逐字母拼写姓名。这种边缘情况只有通过使用代表性患者群体进行测试才会出现,强化了在生产部署前构建多样化测试套件的重要性。

    分步可观测性暴露了真正的瓶颈。Bedrock AgentCore的内置追踪分析捕获了每个代理循环迭代,包括工具调用延迟、LLM推理时间和内存检索持续时间。这种仪器化揭示出70%的感知延迟来自单个供应商API,而非LLM。没有分步追踪,团队就会优化错误的组件。端到端指标对于代理系统来说是不够的。每个工具调用都需要独立的仪器化来揭示实际的约束条件。

    渐进式认证需要预先设计。从哈希电话号码到已验证患者ID的内存交接模式运作良好,但需要从一开始就仔细规划。将渐进式信任改造到假定单一身份模型的代理中要困难得多。我们建议在编写代理逻辑之前规划好Actor ID策略和内存交接流程。AgentCore内存原生支持此模式,但您必须明确地设计它,而不是事后再添加。

    结论

    Natera的语音代理已完成验证测试,现已投入生产用于呼入式移动抽血调度,并正在扩展到呼入和呼出通话处理的全渠道支持。移动抽血调度用例证明,AI驱动的语音代理可以提供医疗级别的准确性,同时降低运营成本和患者摩擦。

    早期生产数据印证了这些结果。在四周的报告窗口期内,基于AgentCore构建的系统处理了4,744通电话,比之前系统增长了5.5%。它还减少了提前挂断率:短通话率从22%降至12%,表明患者参与度更高,而非放弃后转接人工代理。调查捕获量也显著扩大,净推荐值响应率上升了47%(从1.09%到1.60%),使团队能够更广泛地了解患者情绪。满意度评分总体保持稳定,尽管样本量更大,推荐者和批评者占比基本不变。验证完成率略有改善(66%对比64%),已解决交互的平均通话时长从79秒增加到101秒。这与让患者更长时间留在流程中而非早期升级的设计目标一致。

    展望未来,Natera计划将此基础扩展到运营、客户成功和实验室团队,使用Amazon Bedrock AgentCore作为多代理协调的支柱。目标是让非技术团队能够通过自然语言构建和部署AI代理,将原本需要工程资源的事情变成团队数分钟内即可完成的工作。随着Natera扩展这些能力,AgentCore运行时、AgentCore内存和Amazon Bedrock基础模型框架等服务将继续支撑他们的方法,为患者简化医疗交互,为服务他们的团队提高效率。

    后续步骤

    如果您正在为医疗保健、生命科学或其他受监管行业构建语音代理或对话式AI,以下是通过本文涵盖的服务入门的方法:

  • 在AgentCore运行时上部署您的第一个代理。如果您当前在容器上运行代理工作负载并希望减轻基础设施管理负担,请遵循AgentCore运行时入门指南,在30分钟内部署一个无服务器代理。
  • 为现有代理添加会话内存。如果您的代理在交互之间丢失上下文或要求用户重复信息,请集成AgentCore内存会话管理API,以跨会话持久化对话状态,而无需管理自己的状态存储。
  • 通过事件驱动的填充生成减少感知延迟。如果您的语音代理在工具调用期间有明显停顿,请使用本文描述的填充生成模式,利用AgentCore流式调用模式与后端操作并行生成上下文响应。
  • 构建渐进式认证流程。如果您的应用程序处理敏感数据,并且您希望避免前置认证门槛,请使用AgentCore内存基于Actor的会话模型,在用户对话中逐步验证身份时递增信任级别。
  • 关于作者

    Cem Onan

    Cem是Natera的软件架构师,在全渠道通信系统开发方面拥有四年的经验。在过去一年中,他一直致力于设计AI驱动的呼叫中心,其中智能代理管理有关检测状态、账单查询和移动抽血的患者咨询。他是无服务器架构专家,并热爱旅行。

    Tamara Gagliardi

    Tamara是AWS的高级解决方案架构师,在技术领域拥有超过15年的经验,涉及金融服务、零售和制造业等多个行业。过去几年,她专注于医疗保健和生命科学领域,与医疗器械和生物诊断客户紧密合作,加速他们的云之旅。作为值得信赖的技术顾问,Tamara帮助组织将复杂的业务挑战转化为可扩展、安全的技术解决方案,特别专注于生成式AI,指导客户识别高影响用例和设计智能工作流。

    Veronica Rule

    Veronica是AWS的高级客户解决方案经理,拥有超过10年支持医疗保健和生命科学客户云之旅的经验。她擅长指导组织实施AI/ML采用、代理AI战略和云转型计划。Veronica在帮助Natera成为领先的Bedrock和AgentCore客户方面发挥了重要作用,促进了客户工程团队与产品领导层之间的战略合作,以加速患者护理创新。她热衷于弥合先进AI能力与真实世界医疗保健和生命科学成果之间的差距。