How an AWS team detects dashboard content failures at scale using Amazon Bedrock

AWS团队如何使用Amazon Bedrock大规模检测仪表板内容故障 | 人工智能

AWS团队如何使用Amazon Bedrock大规模检测仪表板内容故障

设想这样一个场景：任何大规模运行商业智能（BI）系统的组织都可能遇到这种情况——用户在重要会议前几分钟打开仪表板，却发现图表是空白的。所有基础设施监控系统都显示正常，服务器运行良好，API响应及时，数据管道也按计划完成。然而，屏幕上的内容却出现了故障，且没有任何监控系统发出警报。这类故障本质上是“静默”的：它只存在于用户所看到的内容中。这使得它无法被基础设施监控系统发现，只能依赖用户花时间提交报告。我们后续的监控数据显示，这种情况发生的概率低于1%。

仪表板元素（表格、图表和可视化内容）可能会显示空白、过时或错误的数据。常见原因包括上游管道故障、权限变更和临时性基础设施问题。即使每个图表都能正确渲染，数字本身也可能错误。随着组织将仪表板数据输入生成商业领袖叙事的人工智能系统，这种风险会进一步增加。

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

您将了解：

• 内容层监控的缺口，以及为什么仅依赖用户报告无法可靠地发现内容故障。

• 基于AWS托管服务构建的五阶段无服务器验证架构。

• 两种并行的人工智能验证机制，一种用于视觉完整性，一种用于数字一致性，均基于相同的设计原则。

• 生产工程经验：设计时避免误报，以及将LLM与算术运算隔离开来。

为什么内容层验证至关重要

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

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

• 未被发现的数值不一致问题。图表可能渲染完美却显示错误数值。过滤器配置错误、聚合逻辑错误和刷新时机问题会产生仅在渲染输出中出现的差异，数据层验证无法发现这些问题。当AI叙事系统使用这些数据时，风险会显著增加，因为数值错误会直接传播到影响高管决策的洞察结果中。

现有监控工具的适用范围

需要指出的是，Amazon CloudWatch Synthetics 已经能够处理端点监控（页面加载、链接解析、延迟控制），而数据层验证可以捕获上游流水线故障。存在的缺口位于BI展示层。在此层面，即使所有上游检查都通过，过滤器配置错误、聚合逻辑错误或刷新时机问题仍会导致屏幕上显示错误数值。这种最后一步的语义判断正是该解决方案的补充价值。它既补充基础设施监控又补充数据质量验证，但不会取代这两者。

实现方式：使用体验

从仪表板所有者的视角来看，只需进行几次配置即可定义指标和仪表板对比范围。当检测到他们负责区域的可视化内容故障时，会收到Slack通知。通知内容包含受影响区域名称、显示故障的截图、AI置信度评分，以及直接链接到监控仪表板用于调查。

对于数值验证，每次周数据刷新会触发验证周期并生成可读报告。只有被标记的数值差异需要审核人员关注，确认的数据问题会升级到对应团队处理。

解决方案概览

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

图1：最后一步自动化内容验证解决方案概览

该高层视图追踪了从定时捕获到AI分析再到所有者告警的流程。下图将其扩展为端到端处理流水线，包括添加到原始可视化验证结构中的数值验证组件。

图2：展示五个阶段的端到端处理流水线，第三阶段包含两个并行验证机制

该解决方案采用五个处理阶段，每个阶段都基于无服务器和托管AWS服务构建，验证周期之间可自动缩放到零，从而保持成本与实际使用量成比例。

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

阶段2：截图捕获。两种机制以不同方式捕获证据，与各自任务需求相匹配。对于可视化检查，AWS Lambda 函数编排无头浏览器会话，精确渲染每个仪表板区域，如同用户实际看到的界面。对于数值真实值捕获，仅渲染不足以完成任务：代理必须导航仪表板并应用特定过滤器，因此采用代理式浏览器自动化方法（详见阶段3）。

在存储之前，每张截图都会经过脱敏处理步骤：Amazon Rekognition 会检测图像中的文本和数字值。随后管道会将它们替换为经过遮蔽处理的等效内容，文本使用脱敏占位符替代，数字则使用合成值替代，确保存储的截图中不保留任何敏感数据。Amazon Rekognition 预训练的光学字符识别（OCR）和文本检测模型无需自定义训练，且能随 Lambda 调用自动扩展，使脱敏过程既省力又可重复。处理后的截图将存储在 Amazon Simple Storage Service（Amazon S3）中，并通过 Amazon CloudFront 提供低延迟访问以供分析。

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

视觉内容验证。每张截图会结合仪表板区域的上下文元数据进行单次分析。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架构设计：一个代理负责提取和比较数值，另一个判断代理独立验证结果。两者均可访问计算器工具。但实际生产运行中仍偶尔出现错误，这些错误并非出现在基础算术运算中，而是出现在比较逻辑的一致性上。问题主要涉及四舍五入时机、容差范围设定以及单位差异处理等。对于验证系统而言，即使偶尔出现不一致也会削弱所有判断结果的可信度。

将比较阶段替换为确定性代码后，精度从依赖模型的输出变成了设计保证。只要数值提取正确，程序化比较将不会产生任何错误，无论哪个模型执行提取任务。随后的模型升级优化了提取阶段，通过减少误读仪表盘值导致的误报，将召回率从0.88提升至0.95。

这两个验证机制的关键教训是相同的。当设计自己的系统时，应将AI分配给其擅长的语义任务：视觉识别、文本阅读和导航操作。而将确定性代码用于那些单个错误就会破坏信任的判断环节。

实施结果与影响

在视觉验证机制投入生产运行30多天后，系统展现出以下成果：

• 数百个仪表盘持续接受监控。
• 完成153,000次自动化内容检查。
• 检测到802次内容失败（占所有检查的0.52%），相当于系统内容可用率达到99.48%。
• 检测到的失败案例分布于广泛监控区域，而非局限于少数问题仪表盘，这证实了内容层监控需要全面覆盖而非抽查。
• 检测时间从最长72小时缩短至不到1小时：由于验证周期每小时运行一次，最坏情况下的检测时间受扫描间隔限制。

数值验证机制已在生产环境中每周运行超过6个月，每个周期验证50-70个数据点。通过确定性比较设计，匹配值会自动获得批准。截至目前的生产评估中，尚未出现数据问题绕过人工审核被错误批准的情况。在一个生产周期中，系统检测到影响相关指标家族的系统性不一致问题，并在数据传递给下游消费者前完成升级和修复。

未来展望

下一阶段将重点开发三项能力：

• 跨仪表盘一致性检查，用于比较AWS Insights应用中应保持一致的相关部分的数值。

• 一个自动化推荐系统，通过分析错误模式，基于历史解决数据提出补救措施。

• 利用历史故障模式进行预测分析，提前预判可能影响用户的问题。

结论

在本文中，我们展示了团队如何构建主动内容验证系统。该系统通过两种并行的AI机制监控数百个实时仪表板：基于大语言模型的视觉推理用于视觉完整性检查，以及结合确定性比较的智能提取机制用于数值准确性验证。通过自动化检测，您可以在内容故障损害用户信任、影响AI系统和业务领导者之前及时解决这些问题。

此处展示的模式可扩展至大规模运营商业智能体系的组织。这些应用包括基于基础模型的截图内容验证、以浏览器自动化作为真实数据捕获机制、在精度关键阶段使用确定性判断、以及基于所有权的告警路由（通过遥测反馈环支持）。

要开始使用类似功能，可探索Amazon Bedrock获取基础模型访问权限，并使用Amazon EventBridge和AWS Lambda实现无服务器架构编排。如需了解相关的人工智能驱动商业叙事方法，请参阅《How AWS SMGS uses an AI-powered conversational assistant to transform business management with Amazon Bedrock AgentCore》。如需了解我们在遥测层使用的文本到SQL模式，请参阅《Text-to-SQL solution powered by Amazon Bedrock》。如需了解最新动态，请访问《What’s New with AWS》。

致谢

感谢我们的高管赞助人和导师提供的愿景与指导，使这项工作得以实现。AWS全球销售总监Aizaz Manzar，AWS洞察部门总监Sujit Narapareddy，EMEA洞察产品负责人Bernardo Sajonz。

同时感谢以下团队成员的专业技术能力和贡献，他们对产品的成功推出起到了关键作用：商业智能实习生Alfonso Mateos Vicente，可靠性工程负责人Chris Corcoran，高级技术产品经理Kimiya Yokoo，高级数据工程师Matteo Paganotto，业务智能工程师Ryo Okano，数据工程师Vaibhav Yadav，高级洞察与分析负责人Ruben Fondon Alcalde，高级洞察与分析负责人Tatevik Hovhannisyan。

作者简介

'"`