在 Amazon Quick 中，提示工程的基础原则——具体性、上下文设定、少样本示例以及 CRISPE 框架——适用于所有场景。但每个组件对提示的解读方式不同，因此需要针对性的策略。本文是系列第二部分，逐一拆解 **Quick Research**、**Quick Flows**、**Quick Sight**、聊天代理和操作集成的提示模式，并指出常见陷阱。 ## Quick Research：从模糊目标到可执行报告 Quick Research 代理会将你的目标拆解为子主题，搜索企业数据和外部来源，最终生成带引用的结构化报告。**目标越具体，报告越有行动价值**。 AWS 文档明确指出：“要具体说明你想实现什么、为谁、以及为什么。”一个强有力的目标应包含： - **主题**：明确研究领域 - **时间范围**：限定数据区间 - **受众**：报告为谁而写 - **重点输出**：最关注哪些维度 例如： > 分析过去 12 个月美国医院系统对生成式 AI 的采用情况。重点关注两个领域：临床决策支持工具和行政自动化（排班、计费、记录管理）。面向正在决定下一步投资的医疗 IT 高管撰写报告。 这个目标告诉代理调查什么、用什么视角、读者关心什么。在撰写目标前，先问自己：这项研究将支持什么决策？谁会阅读？什么内容会让他们觉得“这正是我需要的”？ ## 分解复杂主题为子问题 Quick Research 会自动拆解目标，但**手动列出具体问题能获得更好结果**。对于多面性研究，明确列出你想回答的问题，给代理更清晰的指引，减少遗漏。 ## 其他组件的提示模式 - **Quick Flows**：用于自动化流程。提示需明确触发条件、步骤顺序和期望结果。避免模糊的“自动化这个流程”，而应指定输入、输出和异常处理。 - **Quick Sight**：数据可视化。提示需指明数据源、维度和度量、图表类型偏好。陷阱是假设代理知道你的业务术语，应提供字段映射。 - **聊天代理**：团队知识访问。提示应设定角色、知识范围和回答格式。常见陷阱是未限制范围，导致代理回答超出知识库的问题。 - **操作集成**：跨系统工作流。提示需定义系统间数据映射和权限。陷阱是忽略错误处理，导致流程中断。 ## 常见陷阱与规避 1. **过度依赖自动拆解**：手动提供子问题能提高精度。 2. **忽略受众**：未指定受众会导致报告深度和术语不匹配。 3. **缺乏时间范围**：研究可能包含过时数据。 4. **未定义输出格式**：报告结构可能不符合预期。 5. **假设代理理解业务上下文**：需显式提供术语和字段说明。 通过针对每个组件定制提示，并避免这些陷阱，你可以从 Amazon Quick 获得更精准、可操作的结果。
## 当 RAG 遇上“全量合同”问题 企业法务或采购团队常面临这样的场景：手头有 **250 份供应商合同**，每份 10–20 页，领导层却总在问“整体合同总价值多少？”“哪些合同已经过期？”“最贵的协议是哪一份？”——这些看似基础的问题，答案却散落在数千页非结构化 PDF 里。 传统的 AI 对话工具（基于 RAG 检索增强生成）在处理单份合同时表现不错，但一旦问题需要跨合同聚合，语义搜索只能抓取 top-k 片段，无法完成全量数据汇总。换提示词解决不了，需要换架构。 ## 新架构：AI 智能体提取 + 多模型验证 + 嵌入式分析 AWS 近期分享了一套合同情报平台架构，核心思路是**用 AI 智能体自动提取并验证合同字段**，再通过 **Amazon Quick 的分析能力**回答聚合与单合同问题。整个流程运行在一个 Web 应用中。 具体来说： - **提取阶段**：AI 智能体从每份合同中抽取关键字段，如合同金额、到期日、签署状态、关键联系人。 - **验证阶段**：采用多模型交叉验证，确保抽取准确率，减少人工复核成本。 - **查询阶段**：不再依赖 RAG 语义搜索，而是将结构化数据接入 Amazon Quick，支持自然语言聚合查询（如“总支出最高的供应商”“即将续约的合同”）。 ## 为什么这比“RAG 聊天”更实用？ RAG 擅长“答案在某一处”的问题，但合同组合管理本质是**结构化聚合**。新架构把非结构化合同转为结构化数据表，再用分析引擎处理，自然能回答“全量”问题。 对于拥有数百份合同的企业，这套方案可将原本需要一周以上的手动提取工作压缩到自动化流程中，且每份新合同都能即时纳入分析。 ## 落地价值与边界 该平台基于 **Amazon Bedrock AgentCore** 和 **Amazon Quick** 构建，适合合同量较大、需要频繁回答组合级问题的团队。不过，多模型验证会增加计算成本，且抽取准确率仍取决于合同格式的规范性。对于格式高度不统一的合同，可能仍需人工抽检。 目前 AWS 并未公布具体客户案例或性能数据，但架构思路值得关注：**当 RAG 不够用时，用智能体 + 分析引擎替代语义搜索，或许是合同智能的新方向。**
## Claude Sonnet 5.5 正式上线 Amazon Bedrock 与 AWS 上的 Claude Platform AWS 今日宣布，**Claude Sonnet 5.5** 已在 **Amazon Bedrock** 和 **Claude Platform on AWS** 上开放使用。官方将其定位为一款更智能、更高效的 Sonnet 模型，面向**聚焦式编码与知识工作**，在多数任务上实现**更低的单任务成本**与**更快的速度**。 ### 能力提升：从“完成”到“核对” Sonnet 5.5 的改进在边界清晰的工作中尤为明显。无论是开发者指派一个功能开发还是缺陷修复，它都能完成任务并**对照既定需求检查结果**。相比 Sonnet 5，它还能生成更精良的文档与可视化内容，包括**单页摘要、架构图和总结幻灯片**。 结合更低的单任务成本，Sonnet 5.5 适合**持续运行或大规模部署**的工作负载： - **工程场景**：告警第一响应、代理的持续监控、SQL 生成、UI/UX 测试，以及在 IDE 中设有固定支出上限的快速编码代理。 - **企业场景**：范围明确的分析、短表格编辑，以及面向大量用户的常规文档任务。 ### 与 Opus 5.5 分工协作 AWS 近期也推出了 **Opus 5.5**。现在，用户可以将两类工作结合： - **Claude Opus 5.5** 负责需要审慎判断的决策，例如发布调试、多 PR 功能栈、大型拉取请求的安全审查、目标明确的代码迁移，以及最终产出表格、演示文稿或报告的长篇分析、金融研究和合同批注。 - **Claude Sonnet 5.5** 负责路径已明确、只需快速执行的任务，在多数工作上比 Opus 5.5 **成本更低、速度更快**。 ### 企业级集成与数据驻留 在 Amazon Bedrock 上使用 Sonnet 5.5，数据可保留在 **AWS 基础设施内**，并支持**区域数据驻留**。它兼容团队已有的 AWS 控制措施，包括： - **AWS Identity and Access Management (IAM)** 用于访问控制 - **AWS CloudTrail** 用于审计 - **Amazon CloudWatch** 用于监控 - **Amazon Bedrock Guardrails** 用于安全防护 使用量将直接计入 **AWS 账单**，便于成本管理。 ### 如何开始 用户可立即通过 Amazon Bedrock 和 Claude Platform on AWS 体验 Claude Sonnet 5.5。官方建议根据任务性质选择模型：判断密集型工作交给 Opus 5.5，执行密集型工作交给 Sonnet 5.5，以在成本与效率之间取得平衡。
## 为什么实时语音应用需要「边生成边播放」 语音助手、互动教学、无障碍工具和客服机器人都有一个共同的体验痛点：等待。用户说完话后，如果系统要等整段回复全部生成完再播放，中间会出现明显的静默空档。**流式语音合成**（streaming TTS）正是为了解决这个问题——让语音在生成过程中就开始播放。 AWS 最新发布的技术教程展示了如何用 **vLLM-Omni Deep Learning Container（DLC）** 在 **Amazon SageMaker AI** 上部署 **Qwen3-TTS** 模型，通过一条持久的**双向连接**同时完成文本输入与音频输出，并借助 **Gradio** 应用演示整个工作流。 ## 什么是 vLLM-Omni DLC vLLM 最初是为文本自回归生成设计的高性能推理框架，而 **vLLM-Omni** 将它的能力扩展到文本、音频、图像、视频等多模态模型的推理服务。AWS 提供的 vLLM-Omni DLC 在此基础上做了两件事： - 将跟踪的 vLLM-Omni 版本打包进 AWS 镜像，附带完整的框架依赖与部署配置； - 增加面向 SageMaker AI 的**路由中间件**，让容器可以直接对接 SageMaker 的双向流式接口。 这意味着开发者不需要自己拼装运行时环境，就能获得一条镜像化的路径，把多模态模型部署到 AWS 托管推理服务上。 ## 这篇教程具体做什么 这是关于专用 DLC 系列文章的**第一部分**，后续还会覆盖 WhisperX 和 llama.cpp，第二部分则聚焦图像与视频生成。本篇的核心任务是语音输出侧： 1. 克隆代码示例； 2. 在 SageMaker AI 上部署 Qwen3-TTS 模型； 3. 通过 SageMaker **双向流式（bidirectional streaming）** 能力，在持久连接上发送文本、接收音频分块； 4. 用 Gradio 应用实际体验流式语音效果。 ## 与既有方案的关系 AWS 此前已有一篇教程演示语音管道的**输入侧**：将麦克风音频流式传输给 Voxtral-Mini-4B Realtime 语音转文本（STT）模型，并返回转写事件。本篇则补上了**输出侧**——把文本送给 Qwen3-TTS，再将生成的语音流式返回。两者结合，就构成了一个完整的实时语音交互回路。 ## 值得关注的点 对于正在构建实时语音 Agent 的团队来说，这条路径的价值在于：**托管服务 + 流式协议 + 多模态容器**的组合，降低了自建推理集群的运维负担。不过教程目前只展示了 Qwen3-TTS 的部署与演示，实际生产中的延迟表现、并发能力和成本，还需要结合自身场景做基准测试。第二部分对图像和视频生成的覆盖，也值得持续跟进。
## 一个容器，两个端点：图像与视频生成的工作流 AWS 近日发布技术博客，介绍如何在 **Amazon SageMaker AI** 上使用同一个 **vLLM-Omni 深度学习容器（DLC）** 部署两个生成式媒体模型，实现从文本到图像、再到视频的完整流水线。这是该系列的第二部分，第一部分聚焦实时语音的双向流式传输，本部分则覆盖实时推理与异步推理两种模式。 ### 核心流程 整个方案的核心思路是：**同一个容器镜像，通过环境变量切换模型**，分别部署到两个 SageMaker 端点。 - **实时端点**：运行 **FLUX.2-klein-4B** 图像生成模型，请求路由到 `/v1/images/generations`，结果以内联 base64 编码的 PNG 返回。 - **异步端点**：运行 **Wan2.1-VACE-1.3B** 视频生成模型，请求路由到 `/v1/videos/sync`，生成耗时较长，输出 MP4 文件直接写入 **Amazon S3**。 工作流从文本提示词开始，先由图像模型生成静态图片，再将图片和运动提示词传递给视频端点，最终从 S3 取回生成的 MP4。示例代码还包含一个可选的 **Streamlit** 界面，方便交互操作。 ### 为什么值得关注 **vLLM-Omni** 将 vLLM 的能力从文本生成扩展到文本、音频、图像和视频的多模态处理，并通过 **OpenAI 兼容 API** 暴露接口。这意味着开发者可以用熟悉的调用方式，在 AWS 上快速搭建生成式媒体应用。 AWS DLC 则封装了框架和依赖，并针对 SageMaker AI 添加了路由中间件，减少了服务栈的差异性。两个端点共享同一个容器镜像，但可以根据各自负载选择不同的实例类型和推理选项——图像模型适合实时响应，视频模型则利用异步推理避免长时间等待。 ### 关键设计点 - **容器复用**：固定版本的 vLLM-Omni DLC 同时服务两个模型，部署脚本只需修改 `SM_VLLM_MODEL` 环境变量即可切换加载的模型。 - **存储解耦**：视频生成结果不直接返回，而是写入 S3，客户端通过轮询或通知机制获取，适合耗时较长的任务。 - **请求路径**：应用程序发送图像提示词到 FLUX.2-klein，收到 PNG 后调整尺寸，再连同运动提示词发送到视频端点。 该方案为希望在 AWS 上构建多模态生成应用的开发者提供了一个可复用的参考架构，兼顾了实时性与长任务处理的需求。
## 传统合成监控的痛点 合成监控通过自动化交易模拟真实用户旅程，让团队能在客户遇到问题之前，按计划持续验证登录、购买、表单提交等关键工作流。这对电商等面向客户的企业尤为重要：确保商品搜索、定价与库存展示、购物车操作以及结账确认都能正常完成。同样的思路也适用于金融服务的账户访问与交易流程、旅游酒店的预订旅程、SaaS 的注册与订阅升级路径，以及医疗机构的预约排程门户。 然而，大多数组织仍依赖指标、日志、追踪和 API 级检查来监控基础设施健康。真正高影响的故障往往发生在用户旅程层面，后端信号未必能立即暴露问题。常见例子包括：前端部署破坏了结账按钮、第三方登录页面意外变更、UI 回归导致关键元素无响应。 传统的浏览器自动化框架（如 **Selenium** 和 **Playwright**）依赖显式的 DOM 定位器和选择器，这带来了脆弱性。即使是微小的 UI 变更也可能破坏测试，需要持续维护。团队在管理选择器、处理时序不稳定以及随应用演进更新脚本上投入大量精力，往往维护时间超过构建新自动化的时间。 ## 代理驱动的合成监控方案 AWS 提出了一个基于 **Amazon Nova Act** 和 **Amazon Bedrock AgentCore** 的代理驱动合成监控方法。该方案旨在超越脆弱的 UI 脚本，实现有弹性、可托管的用户旅程验证。 **Amazon Nova Act** 是代理执行层，能够理解用户旅程意图，而不依赖硬编码的 DOM 选择器。**Amazon Bedrock AgentCore** 则提供托管运行时、工具集成和编排能力，让代理可以安全、可扩展地执行监控任务。 ### 核心架构与模式 该方案的核心架构围绕代理驱动的工作流验证展开： - **代理定义**：将关键用户旅程（如“完成一次购买”）描述为代理可执行的任务，而非逐步的 UI 操作脚本。 - **托管执行**：AgentCore 提供可扩展的托管环境，按计划触发代理运行，并处理身份、权限和工具调用。 - **弹性验证**：代理根据页面语义和视觉线索自主决策，适应 UI 变化，减少因选择器失效导致的误报。 - **结果上报**：验证结果可发送至监控系统，触发告警或仪表盘更新。 ### 与传统方案的对比 | 维度 | 传统脚本 | 代理驱动 | |------|----------|----------| | 定位方式 | DOM 选择器 | 语义与视觉理解 | | 维护成本 | 高，需频繁更新 | 低，自适应变化 | | 弹性 | 脆弱，易误报 | resilient，减少误报 | | 扩展性 | 手动编写脚本 | 托管编排，按需扩展 | ## 适用场景与落地价值 代理驱动的合成监控特别适合以下场景： - **高频变更的 UI**：前端迭代快，选择器经常失效。 - **第三方依赖**：登录页面或支付网关由外部控制，变更不可预测。 - **复杂用户旅程**：多步骤、有状态的工作流，传统脚本难以稳定覆盖。 - **跨行业合规**：金融、医疗等对关键流程可用性要求高的领域。 该方案并非完全取代传统监控，而是补充 API 级和基础设施监控，覆盖用户旅程层面的盲区。通过代理的自主决策能力，团队可以降低维护负担，将精力重新投入到构建新自动化上。 ## 实现与示例 AWS 提供了一个完整的示例仓库，包含代理定义、AgentCore 配置以及部署指南。开发者可以基于该示例快速搭建自己的代理驱动合成监控流水线。 > 注意：本文基于 AWS 官方博客内容编译，具体实现细节请参考原文及示例仓库。
## 从概念验证到生产：Textract 适配器管理的挑战 将文档提取工作负载从概念验证推向生产环境，往往面临一个容易被低估的工程难题：**适配器的生命周期管理**。Amazon Textract 作为全托管的机器学习服务，能够自动从扫描文档中提取文本、手写内容、布局元素和结构化数据，被广泛用于发票处理、抵押贷款申请、保险理赔和身份验证等场景。而 **Custom Queries 适配器**进一步允许企业针对特定文档类型微调提取逻辑，无需自建 ML 模型即可提升对独特表单布局和领域术语的识别准确率。 但训练出适配器只是第一步。一旦进入生产，三个核心挑战便浮出水面： - **适配器跨账户提升**：如何将训练好的适配器从训练账户迁移到生产账户？当前流程需要提交 AWS Support 工单，且**只有训练好的模型权重会转移，查询定义和训练数据不会随之迁移**。缺乏自动化时，这将成为手动瓶颈。 - **多表单版本的路由**：生产环境中往往同时存在多个表单版本，如何确保文档被路由到正确的适配器？ - **安全与合规**：如何以最小权限、加密和网络隔离的方式管理适配器？ ## 解决方案：基础设施即代码与零停机更新 针对上述问题，AWS 提供了基于 **AWS CloudFormation 和 Terraform** 的基础设施模板，并文档化了跨账户适配器提升流程。一个关键设计是将**适配器 ID 外部化到 AWS Systems Manager Parameter Store**。这样一来，更新生产环境中的适配器引用无需重新部署应用，也**不会造成停机**——原本需要数小时甚至数天协调的变更，现在只需几秒钟。 值得注意的是，虽然示例以 Custom Queries 适配器为主，但**解决方案架构、提升策略和安全配置等生命周期管理模式与适配器类型无关**，同样适用于 Forms 和 Tables 适配器。 ## 生产安全控制与预分类路由 在生产环境中，安全控制不可或缺。文章强调了以下措施： - **VPC 端点**：确保流量不经过公共互联网。 - **加密**：对静态和传输中的数据进行加密。 - **最小权限 IAM**：严格控制对适配器管理和调用 API 的访问。 此外，针对多表单版本场景，文章提出了一种**预分类路由模式**：在调用适配器之前，先对文档进行分类，再将其路由到对应的适配器。这避免了单一适配器无法覆盖所有表单变体的问题，同时保持了提取准确率。 ## 对企业的意义 随着文档处理自动化需求的增长，Textract 适配器的生产化管理正成为企业规模化部署的关键。通过基础设施即代码、跨账户提升自动化和参数存储外部化，团队可以显著缩短从训练到上线的周期，并降低运维风险。对于已经使用 Textract 但仍在手动管理适配器的组织，这套模式提供了一条清晰的升级路径。
## 当 MoE 遇上强化学习，基础设施面临三重考验 **混合专家模型（MoE）**已成为大语言模型扩展至千亿乃至万亿参数的主流架构，稀疏化设计让推理成本更可控。但当这类模型进入后训练阶段——尤其是 **RLHF**（基于人类反馈的强化学习）或 **GRPO**（组相对策略优化）——基础设施压力会陡然加剧。 AWS 团队在一篇技术博客中披露，他们通过组合 **Amazon EKS**、**Elastic Fabric Adapter（EFA）** 与 **DeepEP**，将大规模 MoE 强化学习的聚合 rollout 吞吐量提升了 **40%**。 ### 为什么 MoE 的 RL 后训练这么难？ 与稠密模型不同，MoE 后训练面临三个同时发生的挑战： - **异构计算协调**：rollout 生成（偏推理）与策略训练（偏训练）需要不同类型的资源，二者必须动态配合。 - **高吞吐通信**：数百个加速器之间需要持续保持高带宽互联。 - **子系统动态编排**：奖励模型、验证器、检查点更新等环节都会带来额外的内存、网络与编排压力。 文章特别指出，随着 MoE 架构越来越稀疏以降低推理成本，训练阶段的瓶颈正从**计算**转向**通信**。 ### 专家并行（EP）是通信开销的关键来源 在张量并行（TP）、数据并行（DP）、流水线并行（PP）之外，MoE 额外引入了**专家并行（Expert Parallelism，EP）**。EP 需要在设备之间进行动态的 **all-to-all token 路由**，这比结构化通信模式更难优化。 在紧耦合的异步 RL 工作负载中，训练与推理必须保持平衡：训练步太慢会拖住推理 worker，推理吞吐不足又会让训练加速器闲置。 ### 解决方案的核心组合 AWS 给出的架构方案整合了三个关键组件： 1. **Amazon EKS**：提供弹性容器编排，支撑异构计算资源的动态调度。 2. **EFA**：为数百个加速器提供低延迟、高带宽的网络通信能力。 3. **DeepEP**：针对专家并行的通信优化库，缓解 all-to-all 路由带来的开销。 该架构还结合了 **Amazon S3** 用于数据与检查点管理。最终效果是：大规模 RLHF 与 GRPO 训练的聚合 rollout 吞吐量提升 **40%**。 ### 这意味着什么？ 对于正在尝试 MoE 后训练的团队来说，这项实践传递了一个明确信号：**稀疏化带来的推理红利，需要配套的通信优化才能转化为训练效率**。单纯堆叠加速器并不够，编排层、网络层与通信库的协同设计才是关键。 AWS 此次披露的架构并未给出具体集群规模或模型参数细节，但 40% 的吞吐提升对于 RLHF 这类计算密集且通信敏感的场景而言，是一个值得关注的工程参考。
## 多模态强化学习训练的新基建 强化学习（RL）后训练正逐渐成为构建强能力语言模型智能体的标准环节。模型通过生成轨迹、接收奖励并依据结果更新策略，从而学会在多步序列中进行推理与行动。但当这种训练扩展到多节点、单次运行消耗数百 GPU 小时的规模时，持久化的集群基础设施就成了刚需——它必须能扛住长时间任务、在硬件故障时保住进度，并让训练动态全程可见。 **Amazon SageMaker HyperPod** 正是为此类大规模机器学习负载而生，运行在 **Amazon EKS** 之上。它的集群韧性特性会持续监控节点健康并自动替换故障节点，配合检查点机制，训练任务可以从上次保存的步骤恢复，而不是从头再来。对于动辄数小时的多节点 RL 运行来说，这一点尤为关键。 ### SkyRL + Qwen3-VL-8B：一个可复现的实战路径 AWS 最新发布的技术博文展示了如何在这套基础设施上运行开源 RL 框架 **SkyRL**，对一个 **Qwen3-VL-8B** 视觉语言模型进行后训练，任务是让模型学会走视觉迷宫，采用的算法是 **GRPO（Group Relative Policy Optimization）**。 整个流程覆盖了从构建容器镜像、在 SageMaker Studio 中启动 Ray 集群，到提交与监控任务，再到托管训练好的 LoRA 适配器用于推理的完整链路。 结果颇具说服力：从 **VisGym SFT 检查点**出发，经过 HyperPod 上的 GRPO 后训练，模型在固定的 64 个迷宫评测集上的解题率从 **43.75% 提升到 95% 以上**。 ### 关键能力拆解 - **集群韧性**：自动节点替换 + 检查点，避免长时间 RL 运行因单点硬件故障而损失数小时进度。 - **Ray on HyperPod**：可从 SageMaker Studio 创建 Ray 集群，通过安全连接远程提交任务。 - **可观测性**：HyperPod Observability EKS 插件预置了 Amazon Managed Grafana 仪表盘，训练动态一目了然。 ### 前置条件速览 要复刻这一流程，需要： - 一个由 Amazon EKS 编排的 SageMaker HyperPod 集群，至少包含 **3 台 ml.g7e.12xlarge** 和 **1 台 ml.r5d.16xlarge** 实例。 - 集群中安装 **KubeRay operator**、**HyperPod Observability EKS 插件**和 **HyperPod Ray Endpoint Operator**（用于远程任务提交）。 - 安装 **Amazon FSx for Lustre CSI 驱动**，并准备一个 FSx for Lustre 文件系统及对应的 PersistentVolume。 ### 为什么值得关注 多模态 RL 后训练长期以来受制于工程复杂度：分布式 rollout、奖励计算、策略更新之间的协调，加上硬件故障带来的不确定性，让很多团队望而却步。HyperPod 把集群韧性、Ray 编排和可观测性打包成托管能力，SkyRL 则提供了开源的算法实现，二者的结合降低了从实验到规模化训练的门槛。 对于正在探索视觉语言模型智能体、或需要稳定跑长周期 RL 任务的团队来说，这条技术路径提供了一个值得参考的落地范式。
## 当高管在会议上向 AI 提问，错误的数字意味着什么？ 在实时业务评审中，高管需要基于数据做决策，准确性和速度缺一不可。一个对话式智能助手可以即时回答数据问题，但风险同样巨大：在领导面前报错一个数字或响应迟缓，会带来直接的职业后果。单靠一个强大的大语言模型（LLM），并不能同时保证准确和快速。 在生产环境中，这个缺口表现为**幻觉指标、API 限流、验证延迟和主观语言**。要弥合它，需要将生产级质量保障嵌入从数据检索到响应交付的每一步。 AWS 近日分享了 **NarrateAI** 的工程实践——这是一个基于 **Amazon Bedrock** 构建的系统，已为超过 **4,000 名 AWS 高管** 提供商业智能服务。NarrateAI 采用两层架构：一层负责批量处理的**自动叙事生成层**，另一层负责实时交互的**对话式 AI 接口层**，底层依托 **Amazon Bedrock AgentCore** 构建、连接和优化智能体。 ### 五项技术，构筑质量防线 该系统的核心在于五项协同工作的技术，每项针对一种特定的故障模式： - **自适应管道编排**：动态调整数据处理流程，应对不同查询的复杂度和数据源差异。 - **跨账户多模型故障转移**：当某个模型或账户出现 API 限流时，自动切换到备用模型，保障可用性。 - **实时流式评估**：在响应流式生成的过程中同步进行质量检查，而不是等全部生成完毕再验证，从而降低延迟。 - **复合评估框架**：从多个维度综合评估回答质量，而不仅仅是单一指标。 - **数据准确性验证**：对生成的数字和事实进行校验，防止幻觉指标。 这五项技术形成一条**分层依赖链**，每一层为下一层提供支撑，共同实现约 **99% 的数值准确率**，同时保持实时流式响应。 ### 为什么这很重要 对于构建 LLM 应用的工程师和架构师而言，NarrateAI 的实践揭示了一个关键趋势：**模型能力本身只是起点，生产级质量保障才是决定应用能否真正落地的关键**。尤其是在金融、商业智能等对数字准确性极度敏感的领域，单纯的模型调用远远不够。 NarrateAI 的思路是将质量保障从“事后检查”转变为“全程嵌入”，在数据检索、模型调用、响应生成和交付的每个环节都设置防线。这种系统化思维，或许比任何单项技术都更值得借鉴。 > 本文基于 AWS 机器学习博客的工程实践分享，是 NarrateAI 系列的第二篇，侧重于实时层的高级质量保障机制。
语音克隆正在从实验室走向生产环境。现在，你可以通过 **Amazon SageMaker JumpStart** 将公开可用的 **Qwen3-TTS-12Hz-1.7B-Base** 文本转语音模型部署到全托管的实时推理端点，仅需一段几秒钟的参考录音，就能复刻说话人的音色、音高与节奏，并用其声音合成全新文本。 ## 模型能力与适用场景 Qwen3-TTS 由阿里云 Qwen 团队开发，覆盖 **10 种语言**：中文、英语、日语、韩语、德语、法语、俄语、葡萄牙语、西班牙语和意大利语。它采用 Qwen3-TTS-Tokenizer-12Hz 语音分词器，支持流式生成，适合低延迟的交互场景。 本次部署使用的是 **Base 变体**，其特点是仅凭几秒用户音频即可完成语音克隆，也可作为微调的基座模型。与使用固定预设音色的 CustomVoice 变体不同，Base 变体通过参考音频及其转录文本捕捉说话人的声学特征，再将其应用到新文本上。跨语言克隆还能在切换语言时保留说话人身份。 这一能力对媒体团队、教育工作者和应用开发者都有直接价值：可以打造个性化语音体验、进行多语言内容本地化，也能支持无障碍沟通。由于模型自托管且公开可用，你可以掌控成本、将音频数据保留在自有 AWS 环境中，并针对特定领域做适配。 ## 部署方式与运维要点 借助 Amazon SageMaker AI，模型可运行在全托管的实时端点上。基础设施预置、健康监控和自动扩缩容均由平台处理，你无需管理底层 GPU 服务器。文章演示了如何使用 **Amazon SageMaker Python SDK** 从 JumpStart 部署该模型，并调用端点从参考片段克隆声音。 实际部署中还需要关注配置参数，以及可用于监控和调整端点规格的 **Amazon CloudWatch** 指标。对于希望将个性化语音能力快速产品化的团队来说，这条路径显著降低了工程门槛。
## 从「等 IT 出报表」到「自己问数据」 对于工业气体和焊接分销商来说，钢瓶、储罐等资产的租赁计费是营收的重要来源。但 Datacor 的 TrackAbout 客户长期面临一个尴尬的现实：租赁数据虽然躺在系统里，想拿到洞察却必须走 IT 流程——提交 SSRS 报表需求或原始数据导出申请，等上几天甚至几周，拿到的还是一份只能回答单一问题的静态报告。 Datacor 的 TrackAbout 平台目前帮助客户管理着 **2750 万个资产**，每月处理超过 **72.5 万笔账单**。在这个体量下，数据不可及意味着直接的收入损失：未计费的租赁天数、未被回收的营收，都在无声地流失。 ## 解决方案：嵌入式仪表盘 + 自然语言查询 Datacor 选择将 **Amazon Quick Sight**（Amazon Quick 中的嵌入式分析能力）集成进 TrackAbout，为平台增加了交互式仪表盘和自然语言搜索栏。业务用户现在可以： - 自主探索租赁绩效数据，不再依赖 IT 工单； - 用自然语言直接提问，由生成式 BI 能力返回答案； - 基于实时数据做决策，无需等待定制报表。 支撑这一体验的是一套自动化跨云数据管道，以及**多租户行级安全**机制，确保不同客户只能看到自己的数据。 ## 关键启示 这个案例的价值不在于「接入了 BI 工具」，而在于 Datacor 把分析能力从「IT 交付物」变成了「产品内置功能」。对于 SaaS 平台而言，当客户的核心营收数据分散在多个运营系统中时，嵌入式分析 + 自然语言查询的组合，可能是降低支持成本、提升客户留存的有效路径。 Datacor 的工程与产品团队在官方博客中分享了完整的业务挑战、架构设计和经验教训，值得正在考虑嵌入式分析策略的团队参考。
在 AI 模型规模持续膨胀的当下，GPU 算力与训练数据往往分布在不同的 AWS 区域，跨区读取带来的延迟和成本让团队陷入两难：要么复制 PB 级数据，要么忍受训练变慢。**Amazon SageMaker HyperPod** 与 **Qumulo** 的联合方案给出了新答案。 ## 架构与验证 该方案将 **SageMaker HyperPod** 与 **Cloud Native Qumulo (CNQ)** 及 **Qumulo Cloud Data Fabric (CDF)** 结合，允许训练任务直接读取位于其他 AWS 区域或本地的数据集，无需复制数据或修改代码。 为了验证效果，团队在 **US East (Ohio)** 区域部署了与数据同地的 hub 集群，在 **US West (Oregon)** 区域部署了通过 CDF 远程读取数据的 spoke 集群，网络延迟约 **60 毫秒**。两者运行相同的训练任务，对比吞吐量。 ## 关键结果 - **单区域性能**：CNQ 的云原生架构使其性能可独立于存储容量扩展，实现 **99% GPU 利用率**、p5.48xlarge 网络饱和以及 **亚 3 毫秒**的数据操作延迟。 - **远程集群表现**：跨区域集群在短暂预热后，吞吐量达到与同地集群相同的水平（**115–117 样本/秒**），无需额外数据编排。吞吐量在 **100–150 个批次**内收敛，预热时间占比极小——在 10,000+ 批次时低于 **1%**，在 100,000+ 批次时低于 **0.1%**。初始阶段 GPU 利用率为 **80–90%**，随后稳定在 **98–100%**。 ## 行业意义 这一方案解决了 AI 训练中数据本地性的核心痛点。以往，团队要么将数据复制到算力所在区域，消耗大量存储和传输成本；要么忍受跨区延迟，拖慢训练速度。SageMaker HyperPod 与 Qumulo 的组合让算力与数据解耦，同时保持高性能，为分布式 AI 训练提供了更灵活的架构选择。尤其对于需要频繁更新前沿模型、且数据分散在多地的大型团队，这意味著无需移动数据即可保持模型时效性，有望降低总体拥有成本并加速迭代。
## 从「听清」到「分清」：WhisperX 补齐语音转录的两块短板 通用语音转文字工具在处理**电话客服录音、全员会议、播客、庭审记录和广播媒体**等场景时，往往会撞上同一堵墙：时间戳只落到句子级别，误差可达数秒；而且无法回答「谁说了什么」。这两个缺口让转录文本难以被搜索、加字幕、脱敏或大规模分析——缺少说话人标签会卡住合规审查，时间戳不准则会让字幕和脱敏出错。 **WhisperX** 正是为填平这两道沟而生的开源项目。它在 OpenAI 的 **Whisper** 基础上做了三件事： - 引入**批处理推理**，提升转录速度； - 加入 **wav2vec2 强制对齐**，产出精确到每个词的时间戳； - 集成**说话人分离（diarization）**，为每段话标注说话人。 这些能力直接对应真实业务需求。客服中心可以借此统计通话时长、检查话术执行情况、做情感分析；团队能把会议变成可搜索的笔记；媒体和在线教育团队可以为海量内容库批量生成准确的 **SRT** 和 **VTT** 字幕；对时效性要求高的场景，则能在有人开口的瞬间拿到文字。在医疗、法律、金融等受监管领域，带说话人标签的转录还能支撑审计与法律取证。 ## AWS 把整套流程打包成了一个容器 AWS 推出的 **WhisperX 深度学习容器（DLC）** 将上述能力封装进一个 GPU 就绪的镜像。开发者无需自己构建自定义镜像，即可将其部署到 **Amazon SageMaker AI** 的**实时端点**或**异步端点**。 官方博客给出了两种端点类型的部署方法，并说明了各自适用场景，同时覆盖了生产环境中的关键细节： - **GPU AMI 版本锁定**：确保运行环境与镜像兼容； - **扩缩容策略**：应对负载波动； - **Amazon S3 配置**：用于存放音频与输出结果； - **成本控制**：避免 GPU 资源空转。 该内容属于 AWS 多模态 DLC 系列的一部分。该系列横跨三个 DLC、覆盖四类用例：**vLLM-Omni 用于文本转语音**、**vLLM-Omni 用于图像与视频**、**WhisperX 用于语音转文本**（即本文），以及 **llama.cpp**。 对于正在构建语音分析、会议记录、字幕生成或合规审计管线的团队而言，WhisperX 在 SageMaker AI 上的托管部署，提供了一条从开源模型到生产端点的相对短路径。不过，实际落地效果仍取决于音频质量、说话人重叠程度以及所选端点的伸缩配置——这些细节需要结合具体业务负载来验证。
## 让数据留在原处，让智能体看得更全 企业里有个越来越普遍的矛盾：AI 智能体需要跨多个 AWS 账户的数据才能做出有价值的推理，但每个业务团队又希望数据留在自己的账户里——所有权清晰、边界隔离、独立部署。复制数据或硬拉跨账户 IAM 关系，都不是长久之计。 AWS 给出的解法是 **Amazon Bedrock AgentCore Gateway** 配合 **Model Context Protocol（MCP）**，在不搬动数据的前提下，让智能体拥有统一查询入口。 ### 三层架构怎么搭 这套方案的核心是三个层次： - **平台账户**：作为智能体控制平面，运行在 **AgentCore Runtime** 上。这是一个无服务器、框架无关的环境，用专属 microVM 做会话隔离，按用量计费，内置认证。本次示例只跑一个智能体，但同一模式可以扩展出多个。 - **业务线（LOB）账户**：各团队把自己的数据和工具暴露为 **MCP 服务器**，数据始终不离开所属账户。 - **AgentCore Gateway**：架在平台账户里的集成层，给智能体一个单一端点，用来发现和调用已注册 LOB 的工具。 关键在于：智能体连的是平台账户的 Gateway，而不是逐个去连 LOB 的 MCP 服务器。只有当前请求真正需要的那部分数据，才会在查询时流出，底层数据集本身不会离开所属账户。 ### 安全与治理不能少 跨账户调用要解决身份和权限问题。方案中用到 **AgentCore Identity** 做认证，并结合 **Okta**；细粒度授权则交给 **Policy in Amazon Bedrock AgentCore**。这些治理控制是走向生产环境的必要环节——毕竟智能体一旦能跨账户取数，权限边界就必须足够清晰。 LLM 推理由平台账户内的 **Amazon Bedrock** 承担，智能体本身部署在 AgentCore Runtime 上。 ### 为什么值得关注 这不是一个炫技的 demo，而是对“数据不出域”与“智能体要全局视野”这对矛盾的工程化回应。对于已经在多账户 AWS 环境下运营、又不想为 AI 复制一份数据湖的企业来说，这种模式提供了一条可落地的路径：数据所有权不变，智能体的查询能力却可以横跨整个组织。 目前该方案仍以架构示例形式呈现，实际落地时需要结合各团队的账户结构、身份提供商和授权策略做适配。
快餐店往往需要同时维护 App、网站、电话和柜台等多个订餐渠道，每个渠道都是独立的系统，不仅开发和运维成本高，还容易造成顾客历史记录的碎片化——同一顾客在不同渠道上可能被当作陌生人对待。如今，顾客早已习惯在即时通讯应用中完成日常沟通，WhatsApp 拥有超过 20 亿用户，如果顾客能在同一个对话中发送文字、语音消息或直接拨打语音电话，无需下载新应用或登录，体验将大幅提升。 本方案基于 Amazon Bedrock AgentCore 和 Amazon Nova 2 构建了一个多模态 WhatsApp 订餐助手，将文本、语音消息和实时语音通话整合到同一个 WhatsApp Business 号码上。顾客可以通过文字、语音消息或语音电话下单，AI 助手将全程处理从问候到确认订单的流程。所有渠道共享同一个后端和跨渠道记忆，因此顾客今天发消息、明天打电话，系统仍能识别为同一人。 架构上，**Meta WhatsApp Business Platform** 作为客户入口，负责处理 webhook、消息、媒体和通话 API。**Amazon Bedrock AgentCore** 托管智能体，**Amazon Nova 2 Lite** 通过 Bedrock Converse API 处理文本，**Amazon Nova 2 Sonic** 处理语音消息和通话中的实时语音。智能体通过 **Model Context Protocol (MCP)** 与餐厅后端对接。整个系统基于 **AWS CDK** 部署，在 AWS 侧自动创建所需资源，并输出 webhook URL 供 Meta 注册。 设计上，渠道层、智能体运行层和业务后端层相互分离，添加或移除渠道时无需改动后端逻辑。入站流量通过单一 HTTPS webhook 接收，立即返回 200 确认，然后异步处理，避免请求阻塞。这种分层架构让每个部分可以独立部署和推理，简化了维护和扩展。
## 管理 AI 代理的记忆：从混乱到有序 随着 AI 代理在生产环境中运行数月，它们积累的海量记忆可能会成为一把双刃剑。一方面，记忆赋予了代理连续性；另一方面，过时的记忆会降低响应质量，甚至带来合规风险。本文以 Amazon Bedrock AgentCore 为例，探讨如何设计记忆生命周期策略，确保代理始终基于最新、最相关的信息做出决策。 ### 记忆的三种类型 AgentCore 将代理的记忆分为三类，各有不同的保留需求： - **情景记忆**：记录过去的对话，具有时间戳和会话绑定，数据量大，用于短期连续性。 - **语义记忆**：从对话中提取的事实性知识，如用户偏好或产品规则，具有长期价值。 - **程序性记忆**：指导代理如何执行任务，例如操作手册或工作流程，需要保持最新。 这种分类为制定差异化保留策略奠定了基础。 ### 生命周期策略的核心：评分、整合与修剪 设计生命周期策略的关键在于三个操作：**评分**、**整合**和**修剪**。 - **评分**：定期评估每条记忆的相关性、准确性和价值。例如，可以用 LLM 对记忆进行打分，或基于时间衰减函数降低旧记忆的分数。 - **整合**：将相关的记忆合并为更精炼的形式，减少冗余。例如，将多次会话的语义记忆整合为一个用户画像。 - **修剪**：删除低价值或过时的记忆，释放存储空间，降低合规风险。 ### 可部署的夜间工作流 文章提出了一个基于 AWS Step Functions 的夜间工作流，结合 Amazon Bedrock 和 AgentCore 记忆功能，自动化执行上述策略。该工作流由 AWS CDK 部署，代码已开源在 GitHub 上。 工作流的核心步骤包括： 1. 触发：每晚定时启动。 2. 提取：从 AgentCore 获取新增或待处理的记忆。 3. 评分：利用 LLM 评估每条记忆的价值。 4. 整合：对高价值但零散的记忆进行合并。 5. 修剪：删除低价值记忆并记录日志。 所有阈值均可配置，以适应不同场景。 ### 适用场景与注意事项 该方案特别适合高交互量的代理，如客户支持、销售顾问和 IT 帮助台机器人。对于个人助手等低流量代理，可能只需简单的 TTL 过期和 GDPR 合规即可。 **案例分析**：一家客服代理引用了四个月前已解决的账单纠纷，将其视为当前问题；另一个代理因记忆中有过时的部署手册而重复给出错误建议。这些问题凸显了记忆管理的必要性。 ### 小结 记忆生命周期管理是 AI 代理长期有效运行的保障。通过将记忆视为受管资源，并实施定期的评分、整合和修剪，企业可以显著提升代理的响应质量，同时降低合规风险。本文提供的架构为开发者提供了一个实用的起点。
物理AI系统，如机器人和自动驾驶汽车，其开发并非一次性的训练任务，而是一个持续不断的管道：生成合成数据、训练感知与策略模型、在闭环仿真中评估，循环往复。这一过程需要一个“模型工厂”来高效运转。本文深入探讨如何利用 **NVIDIA Cosmos 3** 与 **Amazon SageMaker HyperPod** 构建这样的物理AI模型工厂。 ## Cosmos 3 的独特之处 Cosmos 3 作为开源的全模态世界基础模型，其核心是 **Mixture-of-Transformers (MoT)** 架构，采用逐层联合注意力机制，并刻意设计了训练与推理的不对称性。这一设计使得模型在处理视频、图像和动作等多种模态数据时，能够更高效地学习世界物理规律，为物理AI提供强大的基础。 ## 为何选择 SageMaker HyperPod？ Cosmos 3 的设计与 SageMaker HyperPod 的特性高度契合。HyperPod 在 Amazon EKS 上提供持久、弹性的集群，能够应对模型工厂对计算资源的持续需求。关键在于 **GPU 有效吞吐率**，即每个保留的 GPU 小时实际产生的有用管道进度，而非单个作业的峰值性能。 ## 构建模型工厂的实践 文章详细介绍了如何在 HyperPod 上搭建集群，配置共享的多 TB 级存储层，并展示了针对三种代表性工作负载的分布式后训练过程，包括在公开的 DROID 数据集上完成机器人策略阶段的端到端演示。配套的代码仓库提供了所有基础设施模板和作业清单。 ## 容量承诺与成本考量 运行这样的循环管道需要长期的容量承诺。逐步获取 GPU 会导致可用性和交付周期的波动，而一次性承诺整个循环的容量，可以避免这种波动，无论是通过灵活的训练计划还是容量预留。由于无论管道是否在进展，都需要为容量付费，因此控制成本的关键是最大化 GPU 有效吞吐率。 ## 总结 物理AI模型工厂的构建不再是零散的GPU任务集合，而是一个需要精心设计容量、架构和流程的整体系统。NVIDIA Cosmos 3 与 SageMaker HyperPod 的组合，为这一需求提供了坚实的基座，助力开发者更高效地将数据流转化为更智能的物理AI模型。
运行基础模型（FM）工作负载时，您往往需要处理一系列相互依赖的任务，而不仅仅是单一操作。基础设施团队需要按顺序创建网络和控制平面、附加加速器容量、安装集群依赖项，同时还要准备存储和身份认证，确保分布式作业在硬件故障中存活，部署模型服务器并监控一切。每个步骤都有各自的API、故障模式和等待时间，而操作痛点大多存在于这些步骤之间的交接处。 Amazon SageMaker HyperPod 通过提供托管且有弹性的计算以及集成 Amazon EKS 的能力，减轻了大量此类负担，涵盖健康监控、节点自动扩缩、训练恢复和推理。Amazon EKS 仍然是用户管理的编排面，这虽然让团队可以直接访问 Kubernetes，但也意味着他们需要负责将 AWS 资源、附加组件、工作负载和日常运维组合成一个协调的整体。 **HyperPod InstantStart** 正是一个围绕这一组合问题构建的开源控制平面。它提供两种方式来驱动同一控制平面：通过 Web 界面，创建集群（包括安装依赖、启用自动节点恢复、挂载存储）只需填写表单、查看进度并点击刷新；而在终端中，只需一句话，例如“帮我创建一个新的 HyperPod 集群”。AI 智能体随后会规划多阶段工作流，启动每个阶段，并轮询异步 AWS 操作直至完成，仅在真正需要您决策的地方（如可用区、实例类型和容量类型）暂停。完成后，它会交付一个已挂载存储的运行中集群。 两种界面调用相同的后端 API，通过相同的验证，并读取相同的持久化操作状态，没有哪一方拥有另一方不具备的私有逻辑。本文将深入解析该系统，展示如何将集群引导、容量、训练、推理和存储转化为受保护且可重试的操作，并解释为何将操作规则编码到控制平面 API 中，而不是向智能体提供原始 CLI，是使智能体驱动的基础设施可靠的关键。 ## 解决方案概览 HyperPod InstantStart 作为开源控制平面运行，它组合了 Amazon EKS 的编排能力和 SageMaker HyperPod 的托管能力。它通过 Web 界面和 AI 智能体驱动相同的受保护操作，将集群引导、容量管理、训练、推理和存储转化为可靠的、智能体驱动的基础设施。 ## 核心优势 - **统一操作界面**：无论使用 Web UI 还是 AI 智能体，都通过同一后端 API 执行操作，保证一致性和可预测性。 - **受保护的操作**：每个操作都经过验证和重试机制，减少人为错误。 - **智能体协作**：AI 智能体规划并执行多阶段工作流，仅在关键决策点请求用户输入，提高效率。 ## 与传统方式的对比 传统上，操作人员需要手动执行一系列命令，处理各种故障和等待。而 InstantStart 通过将操作逻辑编码到控制平面中，使得智能体能够可靠地执行复杂流程，无需逐条输入 CLI 命令，降低了出错风险。 ## 适用场景 - **快速原型开发**：需要快速创建测试集群时，可通过 AI 智能体一句话完成。 - **生产环境管理**：通过 Web 界面进行受控操作，确保合规和审计。 - **自动化运维**：将 InstantStart 集成到 CI/CD 管道中，实现基础设施即代码。 ## 总结 HyperPod InstantStart 为 SageMaker HyperPod 用户提供了一种更智能、更可靠的操作方式。无论是通过 Web 界面还是 AI 智能体，它都简化了复杂集群的创建和管理，让团队专注于更高价值的任务。如果您正在使用 HyperPod 并希望提升操作效率，InstantStart 值得一试。
对于每月处理数千张水电费账单的客服团队来说，准确解析和分析复杂的多页文档是一项持续的挑战。格式不一致、表格密集、版式多样，使得快速提取正确信息变得困难，导致响应延迟、计费错误和客户不满。随着文档量的增长，这些低效问题不断累积，使组织无法利用手中已有的数据。 Amazon Bedrock 与 Amazon Textract 的集成提供了解决这一问题的检索和生成能力。通过将 Amazon Textract 对结构和非结构化内容的高精度提取与 Amazon Bedrock 的生成式 AI 能力相结合，组织可以从手动搜索文档转变为以编程方式查询文档，从而大规模地从水电费账单中解锁可操作的见解，并提供更快、更准确的客户交互。 在本文中，我们演示了如何与复杂 PDF 和图像格式的水电费账单进行对话、解析它们、分析内容，并标记相关表格，以帮助大型语言模型（LLM）提取最有用的信息。本文的代码可在 GitHub 上获取。 ## 用例概述 客户服务支持团队收到大量关于水电费账单的查询，涵盖计费、用量、支付和客户服务等多个领域。团队难以高效解析和分析这些以 PDF、DOCX、TXT、HTML 和 XLSX 等多种格式出现的查询。从这些文档中手动提取相关信息既耗时又容易出错，导致响应延迟和客户不满。 为解决此问题，客户最初尝试直接使用水电费账单实施检索增强生成（RAG）解决方案。然而，他们很快遇到了重大问题。用于从这些文档中提取信息的 LLM 遗漏了关键细节，在某些情况下甚至产生幻觉，提供了不正确或不相关的信息。这使客户意识到，简单地将文档和账单以原始形式加载，无法产生可靠、准确的响应。 客户服务支持团队需要一个强大的解决方案来准确提取信息，而 Amazon Textract 与 Amazon Bedrock 的结合正是为此而生。通过利用 Amazon Textract 的高精度 OCR 和文档分析能力，以及 Amazon Bedrock 的生成式 AI 能力，组织可以构建一个定制化的知识库，使 LLM 能够准确回答复杂查询。