AWS团队用Bedrock自动检测仪表盘内容故障，告警时间从数天缩至1小时

想象一个对任何大规模运行商业智能（BI）的组织都不陌生的场景：用户在上会前几分钟打开一个仪表板，发现图表是空白的。所有基础设施监控都报告健康状态。服务器正常运行，API 正常响应，数据管道也按时完成。然而屏幕上的内容是坏的，却没有监控系统标记它。这类故障本质上是静默的：它只存在于用户所看到的内容中。这使得它对基础设施监控不可见，只能依赖用户花时间提交报告。团队后续的 instrumentation 显示，这种情况发生在不到 1% 的案例中。

仪表板元素（表格、图表和可视化）可能显示空白、过时或错误的数据。常见原因包括上游管道故障、权限变更和临时基础设施问题。即使每个图表都正确渲染，数字本身也可能是错误的。当组织将仪表板数据输入生成面向业务领导层叙述的 AI 系统时，这种风险会增加。

在本文中，我们描述了如何构建一个最后一公里的自动化内容验证解决方案。它同时扫描托管在 AWS Insights 应用（由 Amazon QuickSight 提供支持）上的数百个仪表板，以检测缺失或错误的元素。通过这个解决方案，BI 和分析团队可以在用户看到问题之前修复问题。该解决方案通过使用 Amazon Bedrock 上的大语言模型（LLM）主动监控仪表板并对其进行视觉分析，然后在检测到健康问题时实时提醒构建者。这将平均检测时间从最长 72 小时缩短到不到 1 小时。

你将了解到：

内容层监控缺口，以及为何仅靠用户报告无法可靠地发现内容故障。

建立在 AWS 托管服务之上的五阶段无服务器验证架构。

两种并行 AI 验证机制，一种用于视觉完整性，一种用于数字一致性，基于相同的设计原则构建。

生产工程经验：针对误报进行设计，以及让 LLM 远离算术运算。

为什么内容层验证很重要

传统基础设施监控确认服务正在运行且 API 可以响应。然而，健康的基础设施并不能保证用户看到的内容是正确的。我们发现这个缺口表现为两个不同的问题：

静默视觉故障。仪表板部分可能显示空白、显示过时数据或显示错误状态，即使所有上游服务都报告正常运行。自动化监控到位后，30 天的数据量化了这个缺口。它检测到 802 个内容故障实例（行级数据权限错误、过滤器跳过记录、渲染问题等）。不到 1% 有对应的用户报告。如果没有自动化检测，这类退化对被动式支持渠道来说基本上是不可见的。

未检测到的数字不一致。图表可以完美渲染但仍显示错误的数字。过滤器配置错误、聚合逻辑错误和刷新时序问题会产生仅在渲染输出中出现的差异。数据层验证永远不会发现它们。当 AI 叙事系统消费这些数据时，风险会增加，因为数字错误会直接传播到为 executive 决策提供信息的洞察中。

现有监控工具的适用场景

值得注意的是，Amazon CloudWatch Synthetics 已经处理端点监控（页面加载、链接解析、延迟保持），数据层验证可以在上游捕获管道故障。缺口在 BI 展示层。在那里，过滤器配置错误、聚合逻辑错误或刷新时序问题会导致错误的数字出现在屏幕上，尽管所有上游检查都通过了。这最后一公里的语义判断就是这个解决方案所添加的内容。它补充了基础设施监控和数据质量验证，而不是取代其中任何一个。

工作原理：用户体验

从仪表板所有者的角度来看，只需要几个配置来定义指标和仪表板比较范围。当在他们拥有的部分上检测到视觉内容故障时，他们会收到 Slack 通知。该通知包含受影响的 section 名称、显示故障的截图、AI 置信度分数，以及指向监控仪表板的直接链接用于调查。

对于数字验证，每个每周数据刷新都会触发一个验证周期，生成一份人类可读的报告。只有被标记的不匹配项需要审核人员关注，确认的数据问题会被升级到负责团队。

为了应对这些挑战，我们设计了一个 AI 驱动的最后一公里自动化内容验证解决方案。下图展示了这个解决方案工作流程的概况。

这个高层视图追踪了从定时捕获、到 AI 分析、再到所有者告警的流程。下图将其扩展为端到端处理管道，包括添加到原始视觉验证结构中的数字验证组件。

该解决方案使用五个处理阶段，每个阶段都建立在无服务器和托管 AWS 服务之上，在验证周期之间缩减至零，因此成本与实际使用量成正比。

阶段 1：Section 注册表和调度。 Amazon EventBridge 为视觉检查触发每小时验证周期，为数字验证周期触发每周数据刷新。Amazon Redshift 中的配置注册表维护着被监控部分的清单，包括部分标识符、所有者分配和调度偏好。

阶段 2：截图捕获。 两种机制以不同方式捕获证据，与每项任务的需求相匹配。对于视觉检查，AWS Lambda 函数编排无头浏览器会话，按用户所见精确渲染每个仪表板部分。对于数字 ground-truth 捕获，仅渲染是不够的：agent 必须导航仪表板并应用特定过滤器，因此使用了一种 agentic 浏览器自动化方法（在阶段 3 中描述）。

在存储之前，每个截图都会经过一个脱敏步骤：Amazon Rekognition 检测图像内的文本和数值。然后管道用脱敏等效物替换它们，文本用脱敏占位符，数字用合成值，这样存储的截图中就不会保留敏感数据。Amazon Rekognition 的预训练光学字符识别（OCR）和文本检测模型不需要自定义训练，并随 Lambda 调用自动扩展，使脱敏工作低投入且可重复。然后截图存储在 Amazon Simple Storage Service（Amazon S3）中，并通过 Amazon CloudFront 提供服务，以便在分析期间进行低延迟访问。

阶段 3：AI 分析。 这个阶段运行两种并行验证机制。两者都遵循相同的设计原则：AI 模型处理需要语义理解的任务，而确定性逻辑处理精度不容妥协的决策。

视觉内容验证。每张截图都会与仪表板部分的上下文元数据一起在单次 pass 中分析。Amazon Bedrock 上提供的 Anthropic Claude 模型检测结构性异常，如空白瓦片、错误状态和缺失的可视化元素。它们还将上下文推理应用于问题最难的部分：区分合法空状态（过滤器组合真正返回无数据）与实际内容故障（管道错误导致空白图表）。有关按 AWS 区域划分的模型可用性，请参阅 Amazon Bedrock 中的 AWS 区域支持的模型。几个生产控制限制了模型的角色。截图在分析前已脱敏（阶段 2）。模型输出被限制为带有置信度分数的结构化裁决，而不是自由格式文本。模糊结果路由到人工审核，而不是触发自动告警。

数字跨源验证。第二种机制交叉检查同一指标在出现它的仪表板之间的一致性。它使用我们称之为混合验证的模式：LLM 处理语义工作，确定性代码处理数字裁决。同一个指标很少会在两个仪表板上以完全相同的标签或布局出现，因此识别它需要语义理解。Amazon Bedrock 上的 LLM 在捕获的截图中定位每个声明的指标，读取其值和单位，并生成配对读数。LLM 应用比较规则的逻辑不一致：何时四舍五入、允许什么容差、如何处理不同单位。因此，确定性代码处理单位归一化（$1.2B 与 $1,200M 比较）和小数精度（58.484 与 58.5 比较）。然后它返回每个指标对的裁决（匹配或不匹配），为审核人员提供可操作的明确信号。

阶段 4：告警路由。 当视觉故障被确认时，系统使用 Block Kit 格式生成 Slack 通知。它将通知路由到注册的部分所有者，并提供视觉证据、置信度分数和可操作的调查链接。对于持续性故障，系统通过自动创建路由到负责团队的工单进行升级。数字不匹配被编译成验证报告供人工审核。

阶段 5：遥测持久化。 分析结果持久化到 Amazon Redshift 用于历史趋势和模式分析。Amazon CloudWatch 为监控系统本身提供运营指标。

生产工程实践

从原型到生产的过程中，我们发现了两个教训，如果你在构建 AI 驱动的验证系统，这些教训也适用。

首先针对误报进行设计

在告警系统中，误报是扼杀采用的失败模式：收到误报的所有者会停止信任通知。最困难的案例不是明显损坏的页面，而是模糊的页面，在这种情况下，部分为空是因为过滤器组合真正返回无数据。优先考虑上下文推理而不是原始速度：接受更慢的每次检查分析，换来的是你的所有者无需再三思就能采取行动的判断。对于每小时监控周期，准确性和可解释性比实时需求更重要。

让 LLM 远离算术运算

数字验证机制最初使用双层 LLM 设计：一个 agent 提取并比较值，第二个 judge agent 独立验证结果。两者都可以使用计算器工具。尽管如此，生产运行揭示了偶尔的错误，不是在原始算术中，而是在比较逻辑一致性中。涉及的问题包括何时四舍五入、应用什么容差以及如何处理单位差异。对于验证系统来说，即使是偶尔的不一致也会削弱每个裁决的置信度。

用确定性代码替换比较阶段，将精度从模型依赖的结果变为设计保证给定正确提取的值，程序化比较不会产生错误，无论哪个模型执行提取。随后模型升级改进了提取阶段，并将召回率从 0.88 提高到 0.95，减少了因误读仪表板值而产生的误报。

两种验证机制的共同关键经验教训是相同的。当你设计自己的系统时，将 AI 分配到它擅长的语义任务：看、读和导航。将确定性代码分配到每一次错误都会侵蚀信任的裁决中。

实施结果和影响

在视觉验证机制的生产运行 30 天中，系统展示了以下结果：

• 数百个仪表板处于持续监控之下。
• 执行了 153,000 次自动化内容检查。
• 检测到 802 个内容故障（占所有检查的 0.52%），相当于 99.48% 的系统内容可用性。
• 检测到的故障分布在广泛的被监控部分中，而不是局限于少数问题仪表板，这证实了内容层监控需要全面覆盖，而不是抽查。
• 平均检测时间从最长 72 小时缩短到不到 1 小时：因为验证周期每小时运行，最坏情况下的检测时间受扫描间隔限制。

数字验证机制已在每周生产周期中运行超过 6 个月，每个周期验证 50-70 个数据点。匹配的值通过确定性比较设计自动批准，在迄今为止的生产评估中，没有数据问题作为误批准绕过人工审核。在一个生产周期中，系统检测到影响一系列相关指标的系统性不一致。该问题在数据到达下游消费者之前被升级并解决。

下一阶段侧重于三个能力：

跨仪表板一致性检查，比较在整个 AWS Insights 应用的相关部分中应该一致的数值。

自动化推荐系统，分析错误模式，根据历史解决数据建议补救操作。

预测分析，使用历史故障模式来预测问题，在它们影响用户之前。

在本文中，我们展示了团队如何构建主动内容验证系统。它通过两种并行 AI 机制监控数百个实时仪表板：用于视觉完整性的 LLM 视觉推理，以及用于数字准确性的 agentic 提取与确定性比较。通过自动化检测，你可以在内容故障侵蚀用户信任之前解决它们，也可以在它们到达消费数据的 AI 系统和业务领导之前解决。

这里演示的模式可以转移到大规模运营商业智能的组织。包括使用基础模型的基于截图的内容验证、浏览器自动化作为 ground-truth 捕获机制、精确关键阶段的确定性裁决，以及由遥测循环支持的所有者基础告警路由。

要开始使用类似功能，请探索 Amazon Bedrock 获取基础模型访问，以及 Amazon EventBridge 和 AWS Lambda 实现无服务器编排。对于 AI 驱动的业务叙述的相关方法，请参阅 AWS SMGS 如何使用 AI 驱动的对话助手与 Amazon Bedrock AgentCore 转变业务管理。对于我们的遥测层使用的 text-to-SQL 模式，请参阅由 Amazon Bedrock 驱动的 Text-to-SQL 解决方案。最新动态请访问 AWS 新增功能。

我们感谢我们的执行发起人和导师的愿景和指导，使这项工作成为可能。Aizaz Manzar，AWS 全球销售总监；Sujit Narapareddy，AWS Insights 总监；Bernardo Sajonz，EMEA Insights 产品负责人。

我们还要感谢才华横溢的团队成员，他们的技术专长和贡献对将这个产品变为现实发挥了重要作用：Alfonso Mateos Vicente，商业智能实习生；Chris Corcoran，可靠性工程负责人；Kimiya Yokoo，高级技术产品经理；Matteo Paganotto，高级数据工程师；Ryo Okano，商业智能工程师；Vaibhav Yadav，数据工程师；Ruben Fondon Alcalde，高级 Insights 和分析负责人；Tatevik Hovhannisyan，高级 Insights & 分析负责人。