NarrateAI：Bedrock 上生产级 LLM 质量保障实战

高管在 live 业务评审中需要做出数据驱动的决策，准确性和速度同样重要。对话式智能体 AI 助手可以通过即时回答数据问题来满足这一需求。但风险很高——在领导面前给出一个错误的数字或缓慢的响应，会带来直接的职业后果，仅靠一个强大的大语言模型（LLM）无法保证这两点。在生产环境中，这一差距表现为：幻觉出的指标、API 限流、验证延迟以及主观化的语言。要弥合这一差距，需要在从数据检索到响应交付的每个环节都内置生产级质量保证。本文详细介绍了在 Amazon Bedrock 上实现的五种技术，它们协同工作来达成这一目标：自适应管道编排、跨账户多模型故障转移、实时流式评估、复合评估框架以及数据准确性验证。每种技术针对一种特定的故障模式，同时作为一个协调系统运行。

本文是我们 NarrateAI 系列的第二篇。NarrateAI 通过构建在 Amazon Bedrock AgentCore 之上的双层架构，为超过 4,000 名 AWS 高管领导者改造业务智能——这是一个可在任意框架或模型下大规模构建、连接和优化智能体的平台。该架构包括用于批量处理的自动化叙事生成层和用于实时交互的对话式 AI 接口层。我们之前的一篇文章涵盖了业务挑战、整体架构、用户体验和企业部署。本文将深入探讨工程层面，展示这五种技术如何在实时流式响应的同时达到约 99% 的数值准确率。本文面向熟悉 LLM API 和流式响应的、正在构建 LLM 应用的工程师和架构师。

从业务愿景到技术实现

本文专注于实时层内的先进质量保证机制。设想高管问："哪些地区没有达到目标，原因是什么？"这五种技术协同工作，确保响应在数值上准确无误、实时送达，同时在并发全球使用量下保持吞吐量，并针对直接用于业务评审进行专业格式化。

图 1 展示了这些五种技术如何形成一个分层依赖链，其中每一层为下一层提供输入，最终将原始查询转化为经过验证的实时响应。自适应管道编排根据数据量路由查询，使大多数查询在单次快速通道中完成，而复杂查询则获得完整并行处理。跨账户多模型故障转移在独立的模型账户配额空间扩展可用推理能力，减少用户可见的限流。实时流式评估在每个段落产生的瞬间立即进行验证，使质量检查与生成过程重叠。复合评估框架对每个段落并行运行多个独立评估器。数据准确性验证通过两级级联捕获数值幻觉——从廉价的精确匹配开始，仅在需要时才升级到语义验证。以下各节按照管道中的出现顺序依次介绍每种技术，从数据检索到生成再到质量保证。

图 1：五种质量保证技术如何分层协同，将原始查询转化为经过验证的实时响应

自适应管道编排

企业知识文档包含大量信息，而查询所需的信息量差异巨大。像"我团队的季度达成率是多少？"这样的聚焦问题可能只需要少量段落（从企业知识文档中检索到的离散块）。而"给我一份完整的区域绩效分析"这样的综合请求则需要跨数百个段落进行综合。用户期望无论哪种情况都有相同的响应时间。这种异质性需要一种路由策略，在不牺牲复杂场景全面性的前提下快速处理常见情况。

没有任何单一的处理策略适用于所有查询，因为正确的方法取决于查询实际需要多少数据。单次传递拼接速度快、成本低，但当聚合段落超过模型的上下文窗口（通常为 200K token）时会崩溃，导致截断和质量损失。固定的多轮批处理可以避免截断，但它在每个查询上都为多次 LLM 调用付出代价，其中约 90% 的查询并不需要这种处理。我们的方法根据查询的总聚合段落量 |D|（其中 D 为检索到的文档段落集合）来路由每个查询：当数据可以容纳时走单次传递，仅在必要时才进行批处理。其结果是一个三阶段管道，对每个查询进行一次分类，然后沿保持质量的最廉价路径进行处理。

三阶段自适应处理

管道最多以三个阶段处理每个查询：模式感知合并（Mode-Aware Consolidation）打包检索到的段落并选择路由；分叉分析（Bifurcated Analysis）执行所选路径，可以是单次快速路径调用或并行常规路径批处理；条件合并（Conditional Consolidation）在需要时合并并行结果。下表总结了两条路径如何穿越这些阶段，随后我们将详细讲解每个阶段。

第一阶段——模式感知合并，对检索到的文档段落进行操作。它应用贪心首次适配打包策略，在保留段落优先级顺序和段落边界的前提下填充上下文窗口至 token 上限。对于较小规模（|D| ≤ θ，其中 θ 为经验校准的字符数阈值）的数据，所有段落被拼接成单个块，这称为"快速路径"。对于大规模数据（|D| > θ），段落被打包成最优批次并尊重文档边界，这称为"常规路径"。阈值 θ 相对于模型的上下文窗口限制设置，校准后使 70–90% 的查询命中快速路径（实际上，如结果部分所示，约 90% 的查询走此路径）。由于执行模式在该第一阶段就已确定，每个下游阶段可以为其特定路径进行优化，而无需同时处理两者。

第二阶段——分叉分析，执行所选路径。快速路径使用完整上下文发起单个 LLM 调用，并将结果直接流式传输到评估管道。常规路径将批次分发到 N 个并行 LLM 调用（其中 N 为第一阶段产生的批次数），独立分析各个块以实现近线性加速。

第三阶段——条件合并，仅在常规路径上运行，将 N 个独立分析综合为统一响应。合并 LLM 接收部分分析结果连同原始问题，并在流式传输最终答案时应用冲突解决启发式算法。快速路径完全跳过此阶段，因为最终响应仅使用一个分析。图 2 展示了完整流程，两条路径在流式响应处汇合。

图 2：三阶段管道的端到端流程，展示了快速路径绕过合并阶段

在生产环境中，这种基于阈值的路由带来了巨大的效率提升。约 90% 的查询走快速路径（单次 LLM 调用，首 token 时间 TTFT 在几秒内，总延迟通常低于 25 秒）。其余 10%（复杂多文档查询）则获得完整的并行批处理（约 50–75 秒，而快速路径低于 25 秒）以应对其复杂度。对于常规路径查询，N=4 为典型批次数，每查询的混合成本约为 1.4 次 LLM 调用。与始终使用多轮策略相比，这减少了 72% 的每查询 LLM 调用次数，同时保持了对复杂查询的完整质量覆盖。团队应根据自身工作负载的查询量分布校准各自的阈值，并将其保持在模型的上下文窗口限制以下。

跨账户多模型故障转移

自适应流水线高效整合了信息，但只有在其背后的模型保持可用时，快速流水线才有用。在高峰审查期间，当数千用户同时运行分析时，一次限流请求就会削弱用户对该工具的信心，并驱使他们退回手动电子表格分析。标准缓解措施——带抖动的指数退避——被证明是不够的。Amazon Bedrock 为每个模型和每个账户分配独立配额。将每个模型-账户对视为其自己的容量空间，可以在不配置新基础设施的情况下成倍增加可用吞吐量。我们不是等待容量释放，而是着手发现从未被争抢过的容量。本节展示如何将每个模型-账户对视为自己的配额空间，在不配置新基础设施的情况下扩展容量。

这一容量其实就在眼前。Amazon Bedrock 配额在两个轴向上相互独立：每个模型有其自己的限制，每个 AWS 账户收到其自己的配额。因此，3 个模型 × 3 个账户的配置提供了九个独立的配额空间。在运行时，系统通过首先尝试排名最高的模型来探索这个网格，并随机排列账户以帮助防止热点问题。实现方式是一个自定义的 Strands 模型提供程序，它是标准 BedrockModel 的直接替代品，在保持与现有智能体代码完全兼容的同时添加了透明容量扩展。图 3 展示了网格以及请求通过它所遵循的级联路径。

图 3：跨 3 模型 × 3 账户配置的故障转移级联，其中每个单元格是一个独立配额空间，请求在耗尽当前层级的账户后才降级模型质量

三机制协调

三个机制协调使这一切成为可能。第一个是模型排名，它建立了质量-速度层级。查询首先尝试排名最高的模型，仅在必要时才级联，因此用户自动获得最佳可用模型。第二个是账户级分发，它通过随机负载均衡帮助防止热点问题。在每次故障转移尝试之前，Python 的 random.shuffle() 通过创建副本并就地打乱来随机化 AWS 角色 ARN 列表的顺序。负载随时间均匀分布在各个账户上，无需复杂的流量整形算法或集中协调。每个请求都获得新的随机化，自然地实现约 1/N 的流量分布，其中 N 是配置的账户数量。这最大化 了跨账户池的 Amazon Bedrock API 配额聚合利用率。第三个是检测和快速恢复，它完全避免退避。ThrottlingDetector 捕获 ThrottlingException、ServiceQuotaExceededException 和 TooManyRequestsException，立即尝试下一个模型-账户组合。AWS Security Token Service (STS) AssumeRole 在 100–200ms 内获取新凭证，与带抖动的指数退避的多秒延迟相比可以忽略不计。

在超过 4,000 名用户的六个月生产部署中，N×M 配额探索（N 是模型数量，M 是账户数量）吸收了流量峰值，并在高峰期间减少了用户可见的限流。改进程度与配置的模式-账户组合数量直接成正比。使用 Locust 框架进行负载测试表明，该系统能够支持 100 多名用户持续并发发送模型请求，没有任何失败请求。以下快照显示了超过 100 个用户请求通过应用程序从 Amazon Bedrock 流式响应的负载测试详情。关键结论是基础设施不需要扩展——配额空间反而扩展了。

图 4：100+ 并发用户通过应用程序流式响应的负载测试结果

实时流式评估

故障转移架构现在可以在配额压力下提供不间断的令牌流。然而，一段可靠传递但包含幻觉收入数据的响应只会让问题变得更糟。没有准确性的可用性是一种负担。我们最初的方法将质量检查实现为顺序后处理步骤。它会生成完整响应，运行评估器，然后传递验证后的输出。虽然这实现了高准确性，但首内容时间（TTFC）超过一分钟，因为用户要等待整个响应生成和评估后才能看到输出。这种准确性和响应性之间的权衡让我们提出了一个关键问题：验证是否需要在完整响应生成之前就开始？本节介绍并行评估架构，它回答了这个问题，并通过使用生产者-消费者并发模式实现了接近零的验证开销。

段落独立性

验证第 N 段输出不需要等待第 N+1 段生成。这种逻辑独立性使得并行执行成为可能。它显著减少了首内容时间（TTFC），即从提交请求到用户看到第一个传递的已评估内容的经过时间。

在顺序流水线中，用户等待所有段落生成，然后等待所有段落评估，之后才能看到任何内容。我们的并行方法在每个段落生成时立即验证它，因此用户只需一个段落生成和评估后就能看到内容，而不是等待整个响应完成。只有第一个段落会在用户看到内容之前产生评估延迟。每个后续段落都与下一个段落的生成并发评估，因此评估成本被吸收在生成窗口内。对于每个后续段落，传递延迟只是执行当前段落评估或生成下一个段落中较长的那个。

在实践中，段落生成需要几秒钟，而确定性检查（敏感词、表情符号）在几十毫秒内完成，提供了宽阔的稳定边界，即使偶尔调用昂贵的基于 LLM 的评估，也能让评估对用户基本不可见。

生产者-消费者架构和性能模型

图 5：协调生产者、有界队列和消费者的生产者-消费者流式架构

实现协调三个异步组件。生产者任务从 Amazon Bedrock 流式 API 接收令牌，并通过可配置启发式方法（markdown 边界的双换行符）将它们累积成段落大小的单元。完整的段落进入线程安全的有界缓冲区，具有互斥阻塞和先进先出（FIFO）排序以保持一致性。一个哨兵值表示完成。消费者任务出队段落，执行顺序验证检查（如数据准确性验证），并将批准的内容作为多词块流式传递，以实现流畅的感知传递。

在实践中，这种稳态行为根据给定段落触发的评估器分为两种不同的状态。

将 λgen 定义为段落生成速率，μeval 定义为评估速率。缓冲区利用率 $\rho = \frac{\lambda_{gen}}{\mu_{eval}}$ 决定均衡行为。鉴于评估方法的性质（确定性或基于 LLM），我们期望 ρ 呈双峰分布，而不是单一平均值。

在快速路径上，仅需要确定性检查（Weasel Word、Emoji）的段落在大约 79ms 中位数内完成评估，ρ ≈ 0.095，远低于 1。在这种状态下，缓冲区几乎为空，因为消费者在等待生成，评估添加的感知延迟为零。在慢速路径上，触发基于 LLM 的数值验证的段落大约需要 2,025ms 进行评估，ρ 中位数 ≈ 21.5，远高于 1。在这里，反压自然地对生产者进行速率限制，有助于防止无界队列增长，同时让消费者追赶。没有内容丢失，一旦段落通过，传递就会恢复。

这种分裂是本文后面讨论的复合评估框架的直接结果。大多数文本在毫秒内通过确定性检查，而包含数值指标的段落会触发更深入的基于 LLM 的验证。

流式评估结果

为了验证这个架构，我们在企业部署环境中使用 Amazon Bedrock 上的 Anthropic Claude Sonnet 对 1,000 个生产查询（约 10,439 个段落）进行了性能测量，平均每个响应超过 10 个段落的商业智能查询。绝对时间值特定于此环境，但相对改进和架构模式可广泛推广到流式 LLM 部署。

并行架构相比顺序评估实现了 86.8% 的延迟降低。与未评估流相比 1.4 秒的差距，仅反映了流水线达到稳态之前首个段落的单次评估成本。

复合评估框架

流式流水线将段落传递给评估消费者，但单一整体验证器只能解决一种失败模式。企业级质量保证需要同时覆盖多个正交维度。该系统中的负责任 AI 是双面的：Amazon Bedrock Guardrails 在生成开始前对每条入站查询进行筛查，复合评估器在每条出站段落到达用户前对其进行筛查。语言客观性、格式规范和数值准确性各自代表单一评估器无法覆盖的不同失败模式。本节介绍一个通过共享接口协调独立评估器的复合评估框架。正式的扩展性约束使流水线与前文描述的实时流式架构保持兼容。

复合框架设计为可持续扩展。如实时流式评估一节所述，每个评估器都对流水线缓冲区利用率 ρ 有所贡献，即评估延迟与生成时间的比值。只要所有评估器的组合 ρ 保持在 1 以下，新增评估器就是有效的，从而保持流式流水线的稳定。在实践中，可在亚毫秒时间内运行的廉价确定性评估器可以无限制添加。昂贵的 LLM 评估器必须仅触发足够小比例的段落，以保持加权贡献有界。

每个评估器实现一个标准接口。它接受段落内容作为输入，并返回通过/失败结果以及检测到的问题和建议的修正。这支持自主操作和流水线无关的集成。只要满足 ρ 准入约束，团队可以添加领域特定的评估器（如毒性检测、合规策略检查或货币格式验证），而无需修改流水线。

三个参考评估器和自动修正器

我们实例化了三个针对商业智能响应中正交失败模式的评估器。

WeaselWordEvaluator 通过正则模式匹配强制客观语言，因为高管报告需要定量陈述（"16% 增长"）而非主观描述（"强劲增长"）。EmojiEvaluator 通过 Unicode 检测过滤会话表情来维护正式演示。DataAccuracyEvaluator 解决数值幻觉，这是商业智能系统中风险最高的失败模式。进入决策工作流的捏造指标会带来严重的合规风险，需要两阶段层级验证来进行全面验证。

评估器针对同一段落并行执行，因此总评估延迟等于触发最慢评估器的延迟。评估器的关键违规触发段落拒绝。可纠正的问题调用配对的修正器。通用段落批准流向用户。

自动修正将检测转化为可操作的修复。流水线按顺序应用修正器。

WeaselWordCorrector 在保持语言流畅性的同时移除主观形容词。

EmojiCorrector 剥离 Unicode 字符。

DataAccuracyCorrector 用"LLM Reasoning"标签标注捏造内容以保持透明度。

顺序很重要。文本修改最先执行，然后是字符移除，最后是注解，这为每个转换保持了稳定的输入。

复合评估结果

在生产环境中，复合框架标记的段落数量显著多于单独运行的单个评估器。关键的是，近四分之一的被标记段落同时触发了两个或更多评估器，这意味着单评估器部署将完全遗漏第二个质量维度中的共现失败。这种多维度覆盖是复合方法的主要优势。扩展此框架的团队只需实现单个接口即可插入新评估器，无需修改流水线，只要总评估时间保持在段落生成窗口内即可。

数据准确性验证

在复合评估框架一节介绍的三个评估器中，DataAccuracyEvaluator 处理最高风险的失败模式。一条语法正确且措辞客观的响应仍然可能幻觉出高管将依据行动的确切数字。在实践中，这意味着报告"4.41 亿美元"而实际数字是"4.14 亿美元"，这种差异足以在任何人发现错误之前导致错误的资源分配决策。这种失败模式需要一个专门的两阶段验证架构，从精确值匹配级联到语义验证。本节介绍该架构，在检测准确性和计算成本之间取得平衡。该验证的第一阶段执行精确匹配以过滤无依据的输出，而第二阶段通过渐进验证应用上下文验证。它先执行字符串相似度分析，然后进行基于 LLM 的语义验证。

层级验证

幻觉检测存在相互竞争的目标。全面准确性需要语义理解，而实时部署需要亚秒级验证。整体式 LLM 验证实现了准确性，但每个段落会产生 2-3 秒的禁止性延迟。纯模式匹配提供速度但牺牲了上下文理解。例如，它能正确提取"4.14 亿美元"却无法检测到不当的语义位置。两阶段架构通过级联验证和渐进计算投入来解决这一问题。

该设计解决了需要不同检测策略的不同错误模式。第一种错误模式是数值捏造，即 LLM 生成源语料库中不存在的指标。例如，报告"4.41 亿美元"而文档中仅有"4.14 亿美元"，或引用"2024 年第三季度收入"而源文档仅涵盖 2024 年上半年。这些错误在第一阶段通过精确值匹配进行确定性检测。第二种错误模式是上下文不匹配，即 LLM 错误应用源文档中存在的指标，例如将收入数字用于成本讨论、将第一季度增长率应用于第三季度查询、或混淆不同业务单元的指标。这些错误需要在第二阶段进行语义验证。层级方法为每个错误类别应用适当的计算努力。它对明显的捏造使用廉价的精确匹配，对需要更深入分析的案例使用 LLM 语义验证。