Building a serverless AI assistant at Pelago: concept to care in two weeks

在 Pelago 构建无服务器 AI 助手：从概念到落地仅用两周 | AWS 架构博客

在 Pelago 构建无服务器 AI 助手：从概念到落地仅用两周

医疗健康组织面临一个关键的扩展挑战——如何在会员基数增长时，保持深度个性化的患者互动，同时不压垮护理团队或牺牲服务质量。Pelago 是一家专注于物质使用障碍支持的数字健康公司，其工程团队发现了一种方法，仅用两周时间就通过 AWS 服务构建了一个 AI 驱动的解决方案来应对这一挑战。

在本文中，您将了解 Pelago 如何使用 AWS 无服务器和 AI 服务（如 Amazon Bedrock 和 AWS Lambda）构建并部署一个基于事件驱动的 AI 助手。该服务能够为护理团队生成具有上下文感知的建议考虑因素。该系统在保留医疗健康领域所需的人工监督的同时，消除了传统开发工作数月的耗时和管理复杂基础设施的负担。

挑战概述

Pelago 是一家提供全面支持的数字诊所，包括一对一辅导、药物管理和行为治疗，服务于全美会员，帮助其应对酒精、烟草、兴奋剂、大麻和阿片类药物使用障碍及相关行为的康复旅程。Pelago 护理团队通过物质使用康复辅导会员。单个辅导员可能同时与数十名会员进行活跃对话。每条辅导员发送的消息都需要反映数周的先前上下文，而手动从头起草回复需要的时间是护理团队并不总是拥有的。

当 Pelago 工程团队开始为护理团队构建 AI 助手时，他们面临一组相互关联的限制条件。行为健康对话需要数周甚至数月的积累。辅导员在每条回复中都需要考虑这一历史。仅理解最新消息的 AI 助手在这里并不实用——它必须掌握完整的长期对话历史。这种深度上下文也是人工监督不可妥协的原因。系统必须为 Pelago 护理团队生成建议，而非自动化回复。每条反馈都必须由人工辅导员阅读、评估和调整后才能发送给会员。

受保护健康信息（PHI）要求增加了另一层复杂性——数据不能离开 Pelago 的 AWS 环境。所有 AI 集成必须完全在现有 Amazon 虚拟私有云（VPC）基础设施内运行，且不得暴露于公共互联网。

除了合规性和临床安全性，还有实际限制。护理团队成员需要在打开对话的瞬间获取信息，但通过大型语言模型处理数十条、有时是数百条先前消息以生成相关内容，长时间等待是不可接受的，尤其是在辅导员每班次需要打开数十个对话时。

工程团队需要在高度监管的环境中快速交付所有这些功能，并具备完整的审计跟踪和安全控制。他们必须在不阻塞用户体验的情况下解决预生成上下文建议的问题，同时保持合规性。

Pelago 团队通过事件驱动架构分离了关注点。护理团队在访问系统时需要即时获取建议回复，但若同步实时生成这些回复，由于大语言模型（LLM）的处理时间，会导致用户体验被阻塞数十秒。通过将每个成员的入站消息视为异步事件，系统可以将处理流程分发给独立的消费者，而无需将它们耦合到消息传递路径中。新增消费者（如AI助手）无需影响现有组件或代码。由于每个处理步骤都在自己的Lambda函数中运行，推理请求的激增不会影响消息传递或处理。

图1 — 完整的端到端解决方案架构

该架构使用Amazon简单通知服务（Amazon SNS）进行消息分发，使用Lambda函数进行处理。以下是其工作原理：

• 成员通过AWS AppSync发送消息，消息被转发到一个Lambda函数。
• Lambda函数将消息存储在Amazon DynamoDB表中。
• Lambda函数将消息发布到一个SNS主题。
• SNS将消息分发给多个Lambda订阅函数，例如元数据存储、Amplitude分析以及负责基于AI的建议消息生成的聊天助手。
• 聊天助手Lambda函数异步运行。它从DynamoDB中检索完整的对话历史，调用Amazon Bedrock生成上下文建议，并将结果存储在Amazon关系数据库服务（Amazon RDS）托管的MySQL中。此流程在后台运行，不会阻塞用户体验，通常在10秒内完成。
• 当护理团队成员打开对话（通常在几分钟或几小时后），请求会通过Amazon API Gateway传输。
• Lambda函数从MySQL中检索预生成的建议。
• 前端在100毫秒内显示建议。

此模式将消息传递、分析和AI生成解耦。每个成员的PHI数据单独处理，并完全保留在Pelago的AWS边界内。一个成员的反馈生成失败或激增不会影响其他成员的处理流程。

由于推理在后台异步进行，护理团队无需等待LLM处理。建议消息在教练打开对话时已预先生成、存储并随时可用。这确保了无论AI生成耗时多久，检索时间均保持在100毫秒以内。

这种无服务器架构还提供了有机扩展能力。每个Lambda函数根据当前流量自动水平扩展——在流量高峰时扩展，需求下降时自动缩减，无需预配置或扩展设置。添加新的事件驱动下游功能（如AI助手本身）只需新增一个SNS订阅，无需修改现有消息发布或处理代码。

使用Amazon SNS的事件驱动分发

Pelago聊天架构的基础是一个SNS主题，它作为对话事件的消息总线。SNS是一个完全托管的发布/订阅消息服务。当消息发布到主题时，SNS会自动并行地将消息传递给订阅的消费者。这意味着单个入站消息可以同时触发多个独立的处理步骤。

当用户或教练发送消息时，系统会将标准化的有效负载发布到SNS主题，例如：

{
    "identityId": "085cdc3c-f223-419a-9c80-5535c9983549",
    "messageId": "7a4d2b8e-1c9f-4e3a-b5d6-8f2e1a3c4b5d",
    "sender": "user",
    "timestamp": "2025-07-15T14:32:18Z",
    "conversationId": "conv-abc123"
}

SNS 将此事件发送给四个 Lambda 函数订阅者。元数据存储 Lambda 将消息元数据写入 MySQL 用于报告。分析 Lambda 将事件发送到 Amplitude 用于产品分析。推送通知 Lambda 触发教练的移动通知。聊天助手 Lambda 使用 Amazon Bedrock 生成基于助手的建议。

图 2 — 使用 SNS 进行消息广播和解耦处理

这种广播模式使 Pelago 团队能够在不修改现有消息处理代码的情况下添加 AI 聊天助手功能。团队只需创建一个新 Lambda 函数并将其作为 SNS 订阅添加。发布者不需要知道存在多少消费者或它们的功能，因此可以独立构建和部署新功能，而不会影响消息处理流程的稳定性。

使用 Amazon Bedrock 进行异步 AI 生成

聊天助手 Lambda 处理计算密集型的 AI 生成。该函数实现了一个多步骤工作流程：

图 3 — 聊天助手架构和工作流程

第一步是检索对话历史。行为健康对话可能跨越数周数十甚至数百条消息，AI 助手需要所有上下文才能为 Pelago 护理团队生成有用的建议。该函数会查询 DynamoDB 以获取对话中的先前消息。DynamoDB 的单数字毫秒级读取性能意味着即使是很长的对话（50+ 条消息）通常也能在 20 毫秒内检索完成。

# 简化伪代码
conversation_messages = dynamodb.query(
    TableName='conversations-messages',
    IndexName='identityId-index',
    KeyConditionExpression='identityId = :id',
    ExpressionAttributeValues={':id': identity_id}
)

下一步是准备和格式化推理所需的上下文。该函数将检索到的消息结构转换为提供完整上下文的对话历史格式，例如：

[User]: 今天我很难控制渴望

[Coach]: 我理解你。渴望确实很难应对。现在有什么事情让你觉得此刻很难受吗？

[User]: 我在参加聚会，大家都在喝酒。我感到被排除在外。

[Coach]: 这是一个非常具有挑战性的情况，感到这样完全是可以理解的...

[User]: 我最终提前离开了。感到自豪但也有点难过。

格式化对话后，Lambda 函数使用 Amazon Bedrock Runtime API 调用 Claude 模型。提示工程聚焦于共情和验证——帮助模型承认成员的感受，而不是急于提供建议。它经过调整以保持上下文连贯性——拾取成员在早期消息中提到的内容，而不是将每次对话视为独立的上下文。它还会引导模型避免虚假乐观或轻视性语言，并保持建议简短，更像短信而非电子邮件。这与应用程序上教练对话的流动方式相匹配。

response = bedrock_runtime.invoke_model(
    body=json.dumps({
        "anthropic_version": "bedrock-2023-05-31",
        "max_tokens": 4096,
        "temperature": 0.7,
        "system": "You are a supportive coach...",
        "messages": [{
            "role": "user",
            "content": f"""
Here is the conversation history:

<chatHistory>
{chat_history_string}
</chatHistory>

Provide the next coach message suggestion as plain text.
"""
        }]
    })
)

衡量系统性能和业务影响

从SNS触发到建议存储到MySQL的整个流程，通常在4秒内完成，远低于可接受的处理时间。当护理团队成员在仪表板上打开对话时，前端会立即检索预先生成的建议消息。护理团队感知到的总响应时间低于100毫秒。

Pelago团队从技术设计到首次生产部署仅用了2周时间。与临床团队花两天进行架构和模型选择，三天构建核心Lambda函数，三天进行集成测试和提示优化，最后两天进行部署和监控。

系统在初期取得了显著成果。从业务角度看，根据Pelago内部测量数据，平均响应准备时间减少了40%，护理团队将79.6%的AI建议评为有用。在运营方面，使用无服务器服务没有引入新的开销。没有新的基础设施需要管理，无需修补服务器或维护扩展配置。架构成功应对了季节性活动期间消息量激增8倍的情况，而无需更改配置。

实施细节和关键决策

在核心事件驱动架构就绪后，Pelago团队做出了一系列实施选择，以满足医疗行业需求、处理应用特有的流量模式，并确保系统可靠性。

PHI必须保持安全

Pelago利用多项AWS安全功能，在使用AI模型的同时保持HIPAA合规性。其中一项要求是PHI数据不得通过公共互联网传输。为解决此问题，Pelago团队使用Amazon Bedrock的VPC端点，使模型调用保留在私有网络内。Python Lambda中的Boto3客户端会自动通过私有端点路由流量。DynamoDB和RDS上的数据静态加密，服务通信使用TLS 1.2+，IAM策略采用最小权限原则，仅针对特定资源操作和ARN。模型调用的审计日志会发送到Amazon CloudWatch，仅捕获消息ID而非内容。

多语言跨运行时实现

团队使用Python编写调用Amazon Bedrock模型的Lambda函数。Boto3原生的Amazon Bedrock支持和更简单的字符串操作使Python成为构建和迭代提示的最佳选择。检索功能用TypeScript编写，以保持与Pelago后端大部分代码的一致性，并复用共享库和Zod模式实现类型安全的API契约。这种分工使团队能够为每个任务选择最适合的语言，而无需在整个系统中强制使用单一运行时。

突发流量和按调用计费的计算

Pelago 应用主要服务于美国用户。消息流量集中在工作日的工作时间，高峰时段的消息量是低谷期的10倍以上。Lambda 的按调用次数付费模式与这种流量特征高度契合。在周一早晨的流量高峰期间，Lambda 可以在无需预先配置的情况下自动扩展。在非高峰时段，Lambda 函数会自动缩减规模，从而帮助 Pelago 避免空闲计算资源的费用。如果使用其他长期运行的计算方案，则需要要么为峰值负载过度配置资源，要么维护可能在突发流量时出现延迟的自动扩展策略。通过 Lambda，解决方案的成本与用户参与度直接相关，且没有空闲资源的额外成本。

选择合适的存储方案并处理幂等性

团队根据两种场景的不同访问模式，选择使用 DynamoDB 存储对话消息，使用 MySQL 存储助手建议。对话消息需要高写入吞吐量（峰值超过 100 次/秒）、毫秒级读取延迟以及自动扩展能力，这些需求使 DynamoDB 成为理想选择。助手建议的写入负载较轻（10-20 次/秒），但需要关系型数据库天然支持的结构化查询、外键关系和嵌套分析连接。

由于 SNS 可能重复投递消息，Chat Assistant Lambda 在生成新消息前会先检查 MySQL 中是否已存在该消息。这种幂等性校验可防止重复调用 Amazon Bedrock，避免计算资源浪费和向教练展示冲突建议。如果因限流或模型不可用导致 Amazon Bedrock 调用失败，函数会记录错误但不会阻塞消息流程。内置的重试机制可处理临时故障，即使 Amazon Bedrock 短暂出现容量限制，建议内容仍能最终生成。

监控与可观测性

团队跟踪多项业务和运营指标。CloudWatch 指标捕获建议生成延迟，帮助团队识别模型响应时间是否超出可接受阈值。检索率指标显示教练实际使用了多少生成的建议消息，这能揭示异步处理时机与实际使用模式的匹配程度。系统还允许教练通过点赞或点踩对每条建议进行评分，这些评分会存储在 MySQL 中，用于未来提示词优化和模型评估。CloudWatch 警报监控 Amazon Bedrock 的限流错误率和数据库连接失败率，这些警报会在运营问题影响护理团队体验前通知工程团队。

结论

像 Amazon Bedrock 这样的托管 AI 服务与无服务器架构使医疗保健组织能够快速推进项目同时保持合规控制。Pelago 的聊天助手展示了将无服务器事件驱动处理与异步 AI 生成、快速同步检索相结合的潜力。使该方案成功的关键模式包括：通过 SNS 扇出解耦处理流程，使新功能易于扩展；预先异步生成消息建议，避免护理团队等待；通过 VPC 终端节点将 PHI 数据与公共互联网隔离；以及从基础模型和提示工程入手，而非耗费数月时间进行定制模型训练。

Pelago 从概念到生产部署的历程展示了在受监管行业中，小型工程团队如何平衡快速迭代与保持合规性姿态。

有用的链接

• 无服务器架构和模式
• 入门 Amazon Bedrock
• 入门 AWS Lambda

关于作者

'\"