AWS 给4000名高管用了一个 AI 助手：它为什么不敢只依赖一个模型？

很多大模型 Demo 看起来都很惊艳。

输入一段问题，模型几秒钟后就能生成一份结构完整、语言流畅的回答。

但当 AI 真正进入生产环境，问题会完全不同：

• 模型偶尔返回错误数字怎么办？
• 上游服务突然限流怎么办？
• 流式输出了一半才发现结果不可信怎么办？
• 主模型不可用，能不能自动切换？
• 切换模型后，输出格式是否还能保持一致？
• 如何知道错误发生在哪一步？

AWS 最近公布了一个很有代表性的生产案例。

其内部系统 NarrateAI 服务超过 4000 名 AWS 高管，用于在业务会议中实时查询数据。官方称，这套系统通过多层质量控制，实现了约 99% 的数字准确率。

值得注意的是，它没有把可靠性全部寄托在某一个最强模型上，而是同时采用了多模型故障转移、实时流式评测和数据准确性验证等机制。

AWS：NarrateAI 的生产级大模型质量保障架构

这说明了一件事：

大模型进入生产环境后，决定系统可靠性的往往不只是模型能力，而是模型之外的工程架构。

一、为什么高管使用的 AI 助手更难做？

普通聊天助手偶尔出现一个错误，用户可能重新提问一次。

但会议场景完全不同。

假设一名高管在业务会议中询问：

AI 如果回答：

这个数字看起来非常合理。

但如果真实数据是 8.7%，模型只是多生成了一个“1”，错误就可能直接影响会议判断。

这种错误最危险的地方是：

• 语言非常流畅
• 格式非常专业
• 数字看起来很合理
• 用户很难第一时间发现问题

所以，生产级 AI 系统不能只追求“回答得像不像”，还要验证：

• 数据是否来自正确的数据源
• 计算过程是否正确
• 时间范围是否匹配
• 单位是否一致
• 引用是否能够追溯
• 最终数字是否通过验证

二、AWS 使用了哪五层质量控制？

根据 AWS 的技术说明，NarrateAI 的实时问答层主要组合了五类机制：

这些机制共同解决不同类型的问题。

三、第一层：动态工作流编排

并不是所有问题都需要调用最强模型。

例如下面几个问题，复杂程度完全不同：

第一个问题主要是数据查询。

第二个问题需要汇总多个指标。

第三个问题则需要更复杂的关联分析和解释。

因此，系统应该先识别问题类型，再决定后续流程：

不同任务可以采用不同处理方式：

如果所有请求都交给同一个模型，不仅成本更高，也很难针对不同风险设置验证规则。

四、第二层：多模型故障转移

生产环境中，模型调用失败并不罕见。

常见原因包括：

• 上游限流
• 网络超时
• 服务暂时不可用
• 上下文超过限制
• 返回格式错误
• 内容安全策略拒绝
• 单个模型所在区域出现异常

如果应用只配置一个模型，一次上游故障就可能导致整个功能不可用。

因此，需要设置主模型和备用模型：

一个简单的 Python 实现如下。

这里没有把模型名称写死，而是通过环境变量配置：

实际模型名称和可用范围，应以当前平台控制台为准。

五、Fallback 不是简单地“换一个模型”

很多系统虽然设置了备用模型，但实际上仍然不够可靠。

例如主模型返回的格式是：

备用模型可能返回：

人可以看懂，但程序可能直接解析失败。

因此，多模型切换至少要保证：

• 输入协议一致
• 输出结构一致
• 字段名称一致
• 错误格式可以识别
• Token 限制满足任务要求
• 工具调用方式兼容
• 切换后重新进行结果验证

可以要求模型按照固定 JSON Schema 输出：

如果当前模型或接口不支持 JSON Schema，也可以在应用层解析和校验 JSON。

六、第三层：实时流式评测

为了降低等待感，很多 AI 应用采用流式输出：

但流式输出带来了新的问题：

如果答案已经显示给用户，系统才发现数字错误，应该怎么办？

所以，生产系统不能只在最终结果生成后评测，还需要在生成过程中同步检查。

一个简化的架构可以是：

注意，这里的“实时”不一定意味着每生成一个字就调用一次评测模型。

更合理的方式是：

• 按完整句子检查
• 按数据段落检查
• 对数字和单位单独检查
• 先写入缓冲区，通过后再显示
• 高风险回答延迟展示，优先完成验证

对于会议、金融、医疗等高风险场景，多等待几百毫秒，往往比快速显示错误答案更合理。

七、第四层：组合式质量评价

只用一个指标评价答案是不够的。

一份回答可能：

• 语言非常流畅
• 数据来源正确
• 但计算过程错误

也可能：

• 数字完全正确
• 但没有回答用户真正的问题

因此，需要把质量拆成多个维度：

例如：

根据分数设置处理方式：

权重不能照搬，需要根据业务风险调整。

例如财务系统应该提高数据准确性权重，客服系统则可能更关注指令遵循和回答完整度。

八、第五层：数据准确性验证

这是 NarrateAI 场景中最重要的一层。

如果用户问：

模型应该负责理解问题和组织语言，但最终数字不应该由模型凭记忆生成。

正确流程应该是：

假设数据库返回：

模型可以负责把它改写成：

但系统仍然需要检查：

• 128500000 是否正确转换为 $128.5 million
• 币种是否遗漏
• 时间范围是否一致
• 是否把季度数据误写成年度数据

可以在应用层进行确定性验证：

能用程序确认的内容，尽量不要再交给模型猜测。

九、统一 API 网关在生产系统里有什么作用？

多模型故障转移看起来只需要写几个 try...except，但生产环境要处理的问题远不止这些。

网关层通常需要统一管理：

• API Key
• 模型路由
• 请求超时
• 重试策略
• Fallback
• 用户配额
• Token 统计
• 调用日志
• 成本核算
• 错误分类
• 上游健康状态

整体架构可以写成：

这样，业务团队不需要在每个项目里重复实现模型切换。

十、哪些错误应该重试，哪些不应该？

不是所有错误都适合自动重试。

如果不区分错误类型，系统可能陷入无意义重试：

因此，每次失败都应该记录原因和处理结果。

十一、生产环境还应该记录哪些数据？

建议至少记录以下字段：

这些数据可以帮助开发者回答：

• 哪个模型最容易超时？
• 哪类任务最常触发 Fallback？
• 备用模型的结果是否更差？
• 哪些用户消耗最多 Token？
• 哪个业务流程成本最高？
• 模型升级后质量是否下降？

没有这些记录，模型切换就只能依靠感觉。

十二、开发者可以从小规模方案开始

并不是所有项目都要一开始就复制 AWS 的完整架构。

一个小型项目可以先实现四项能力：

第一步：统一模型调用入口

不要在各个业务模块中分别初始化客户端。

第二步：配置主模型和备用模型

模型名称通过配置或环境变量管理。

第三步：校验结构化输出

保证切换模型后，程序仍然能正确解析结果。

第四步：记录调用日志

至少记录模型、耗时、Token、错误和是否发生切换。

等请求量增加后，再逐渐增加：

• 实时评测
• 动态模型路由
• 自动质量评分
• 成本预算
• 人工审核
• 完整链路追踪

结语

AWS 的 NarrateAI 案例说明，生产级 AI 系统的可靠性并不来自某一个“永远不会出错”的模型。

它来自一整套控制机制：

模型能力仍然重要，但模型越多、调用量越大，工程层的重要性就越明显。

对于开发者来说，真正需要建设的不是一个简单的模型调用接口，而是一套能够回答下面这些问题的系统：

• 这次请求调用了哪个模型？
• 为什么选择它？
• 它失败后切换到了哪里？
• 最终结果是否经过验证？
• 这次调用花了多少成本？
• 出现错误后能否完整追踪？

当 AI 开始服务真实业务时，最强模型只是起点。

模型路由、Fallback、验证、审计和成本控制，才是系统能否稳定运行的关键。

参考资料

• AWS：NarrateAI 的生产级大模型质量保障架构（Amazon Bedrock 技术博客）