在Pelago构建无服务器AI助手：两周内从概念到落地
内容提要
Pelago公司利用AWS无服务器架构和Amazon Bedrock，在两周内构建了AI助手。该系统通过SNS异步处理消息，预生成情境化建议供护理团队参考，确保人工监督。响应时间低于100毫秒，准备时间降低40%，79.6%的建议被认为有用，且PHI数据安全合规。
延伸解读
异步预生成：平衡速度与体验的关键
Pelago 的架构核心在于将耗时的 AI 生成过程从用户请求路径中剥离。通过 SNS 异步触发，系统在后台预先生成建议，当护理人员打开对话时，只需从数据库快速读取，响应时间低于 100 毫秒。这种设计避免了同步调用大模型可能带来的数十秒延迟，确保了用户体验的流畅性，是应对高并发和长上下文处理的有效模式。
事件驱动架构的扩展性优势
采用 SNS 进行消息扇出，使得新增 AI 助手功能无需修改现有消息处理代码，只需添加新的订阅即可。这种解耦设计不仅降低了功能迭代的风险，还使得系统能够独立扩展。在流量高峰（如季节性活动）期间，Lambda 的自动扩展能力让系统无需预置资源即可应对 8 倍的消息量激增，体现了事件驱动架构在应对不确定负载时的灵活性。
医疗场景下的合规与安全实践
在医疗健康领域，保护 PHI 数据至关重要。Pelago 通过 VPC 端点调用 Amazon Bedrock，确保数据不经过公共互联网，同时使用加密、最小权限 IAM 策略和审计日志来满足 HIPAA 要求。这一案例表明，利用云服务的内置安全功能，可以在不牺牲创新速度的前提下，构建符合严格监管要求的 AI 应用。
多语言混合开发与存储选型考量
Pelago 根据任务特点选择不同的编程语言和存储服务：使用 Python 处理 AI 推理，利用其丰富的库支持；使用 TypeScript 保持后端一致性。存储方面，DynamoDB 适合高吞吐、低延迟的消息存储，而 MySQL 则用于需要复杂查询的建议数据。这种按需选型的方法，有助于在性能、开发效率和成本之间取得平衡。
Q&A
Pelago公司如何利用AWS服务在两周内构建AI助手？
Pelago公司采用事件驱动的无服务器架构，使用Amazon SNS进行消息扇出，AWS Lambda处理异步AI生成，Amazon Bedrock提供大语言模型，DynamoDB存储会话消息，MySQL存储生成的建议。通过预生成建议并异步处理，实现了快速响应和合规性。
Pelago的AI助手如何确保PHI数据安全合规？
Pelago使用Amazon VPC端点访问Amazon Bedrock，确保PHI不经过公共互联网。数据在DynamoDB和RDS中加密存储，服务通信使用TLS 1.2+，IAM策略采用最小权限原则，审计日志仅记录消息ID而非内容。
Pelago的AI助手为什么采用异步消息处理？
因为同步生成建议需要处理大量历史消息，耗时数十秒，会阻塞用户体验。通过将每条消息作为异步事件，利用SNS扇出和Lambda后台处理，预先生成建议并存储，当护理团队打开对话时能快速检索，响应时间低于100毫秒。
Pelago的AI助手如何保证人工监督？
系统生成的是建议而非自动回复，所有建议必须由护理团队阅读、评估和调整后才能发送给会员。系统设计强调人在回路中，确保临床安全。
Pelago的AI助手使用了哪些AWS服务？
主要使用了Amazon SNS（消息扇出）、AWS Lambda（计算）、Amazon Bedrock（AI模型）、Amazon DynamoDB（会话消息存储）、Amazon RDS for MySQL（建议存储）、Amazon API Gateway（API）、Amazon AppSync（实时API）、Amazon CloudWatch（监控）。
Pelago的AI助手性能表现如何？
系统从SNS触发到建议存储通常少于4秒，护理团队打开对话时响应时间低于100毫秒。准备时间平均降低40%，79.6%的建议被认为有帮助，并成功处理了8倍消息量峰值。
Pelago的AI助手如何处理突发流量高峰？
由于使用Lambda按调用付费和自动扩展，系统能自动应对流量高峰。在季节性活动期间，消息量增加8倍，无需配置更改即可处理。Lambda在高峰时自动扩展，低谷时缩减，避免闲置成本。
Pelago的AI助手如何选择存储方案？
会话消息存储在DynamoDB，因为需要高写入吞吐和低延迟读取；建议存储在MySQL，因为需要结构化查询和关联分析。这种选择基于不同访问模式。
