详细内容或原文请订阅后点击阅览
AWS 团队如何使用 Amazon Bedrock 大规模检测仪表板内容故障
即使每个基础设施监视器都报告运行状况良好，商业智能仪表板也可能会悄无声息地发生故障，显示空白、过时或错误的数据。了解 AWS 团队如何在 Amazon Bedrock 上构建由 AI 驱动的自动化内容验证解决方案，该解决方案可扫描数百个仪表板并向所有者发出警报，从而将平均检测时间从几天缩短到一个小时以内。
来源:亚马逊云科技 _机器学习想象一个大规模运行商业智能 (BI) 的组织所熟悉的场景：用户在重要会议前几分钟打开仪表板并发现一个空白图表。每个基础设施监视器都报告健康。服务器已启动，API 已响应，数据管道已按计划完成。然而屏幕上的内容已损坏，并且没有监控系统对其进行标记。此类故障本质上是无声的：它仅存在于用户所看到的内容中。这使得它对基础设施监控不可见，并且依赖于用户花时间提交报告。我们的仪器后来显示，这种情况发生的情况不到 1%。
仪表板元素（表格、图表和视觉对象）可能会显示空白、过时或不正确的数据。常见原因包括上游管道故障、权限更改和暂时的基础设施问题。即使每个图表都正确呈现，数字本身也可能是错误的。随着组织将仪表板数据输入人工智能系统，为企业领导者生成叙述，这种风险就会增加。
在这篇文章中，我们描述了如何构建最后一英里自动化内容验证解决方案。它同时扫描 AWS Insights 应用程序（由 Amazon Quick 提供支持）上托管的数百个仪表板，以检测丢失或不正确的元素。借助此解决方案，BI 和分析团队可以在用户发现问题之前解决问题。该解决方案主动监控仪表板并使用 Amazon Bedrock 上的大型语言模型 (LLM) 对其进行可视化分析。当检测到健康问题时，它会实时向建筑商发出警报。这将平均检测时间从长达 72 小时缩短至不到 1 小时。
您将了解：
为什么内容层验证很重要
传统基础设施监控确认服务正在运行并且 API 正在响应。然而，健康的基础设施并不能保证用户看到的内容是正确的。我们发现这种差距表现为两个不同的问题：
工作原理：体验
对于数字验证，每周数据刷新都会触发一个验证周期，生成人类可读的报告。只有标记的不匹配需要审阅者注意，并且已确认的数据问题会升级到所属团队。
解决方案概述
值得注意的是，Amazon CloudWatch Synthetics 已经处理端点监控（页面加载、链接解析、延迟保持），并且数据层验证捕获上游管道故障。差距在于 BI 表示层。尽管所有上游检查都通过了，但过滤器配置错误、聚合逻辑错误或刷新计时问题会导致屏幕上显示不正确的数字。该解决方案增加了最后一英里的语义判断。它补充了基础设施监控和数据质量验证。它也不会取代。
从仪表板所有者的角度来看，需要进行一些配置来定义指标和仪表板比较范围。当在他们拥有的部分上检测到视觉内容故障时，他们会收到 Slack 通知。该通知包含受影响的部分名称、显示故障的屏幕截图、AI 置信度分数以及用于调查的监控仪表板的直接链接。
为了应对这些挑战，我们设计了人工智能驱动的最后一英里自动化内容验证解决方案。下图概括地说明了解决方案工作流程。
图 1：最后一英里自动化内容验证解决方案概述
这个高级视图跟踪从计划捕获到人工智能分析再到所有者警报的流程。下图将其扩展为端到端处理管道，包括添加到原始视觉验证结构中的数字验证组件。
图 2：显示五个阶段的端到端处理管道，第 3 阶段有两个并行验证机制
该解决方案使用五个处理阶段，每个处理阶段都基于无服务器和托管 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 分析。此阶段运行两个并行验证机制。两者都遵循相同的设计原则：人工智能模型处理需要语义理解的任务，而确定性逻辑处理精度不可协商的决策。
生产工程
首先针对误报进行设计
展望未来
视觉内容验证。每个屏幕截图以及有关仪表板部分的上下文元数据都在一次传递中进行分析。 Amazon Bedrock 上提供的 Anthropic Claude 模型可检测结构异常，例如空白图块、错误状态和缺失的视觉效果。他们还将上下文推理应用于问题的最难部分：区分合法的空状态（真正不返回数据的过滤器组合）和实际内容失败（呈现空白图表的管道错误）。有关按 AWS 区域划分的模型可用性，请参阅 Amazon Bedrock 中按 AWS 区域划分的支持的模型。一些生产控制限制了模型的角色。在分析之前对屏幕截图进行编辑（第 2 阶段）。模型输出仅限于具有置信度分数的结构化判决，而不是自由格式的文本。不明确的结果将转由人工审核，而不是触发自动警报。
数字跨源验证。第二种机制交叉检查相同指标，以确保其出现的仪表板之间的一致性。它使用我们称为混合验证的模式：LLM 处理语义工作，确定性代码处理数字判决。相同的指标很少会在两个仪表板上以完全相同的标签或布局出现，因此识别它需要语义理解。 Amazon Bedrock 上的法学硕士在捕获的屏幕截图中找到每个声明的指标，读取其值和单位，并生成配对读数。法学硕士应用的比较规则不一致：何时舍入、允许什么容差、如何处理不同的单位。因此，确定性代码可以处理单位标准化（$1.2B 与 $1,200M 相比）和小数精度（58.484 与 58.5 相比）。然后，它返回每个指标对（匹配或不匹配）的判断，为审阅者提供明确的行动信号。
第 4 阶段：警报路由。当确认视觉故障时，系统使用 Block Kit 格式生成 Slack 通知。它将通知发送给已注册的版块所有者，并提供视觉证据、置信度分数和可操作的调查链接。对于持续性故障，系统会通过自动创建路由到所属团队的票证来升级。数字不匹配被编译成验证报告以供人工审核。
第 5 阶段：遥测持久性。分析结果将持久保存到 Amazon Redshift，以进行历史趋势和模式分析。Amazon CloudWatch 为监控系统本身提供操作指标。
从原型转向生产过程中得出的两个经验教训适用于构建人工智能驱动的验证系统。
在警报系统中，误报是扼杀采用的故障模式：收到误报的所有者将不再信任通知。最困难的情况不是明显损坏的页面，而是不明确的页面，其中一个部分是空的，因为过滤器组合确实不返回任何数据。优先考虑上下文推理而不是原始速度：接受较慢的每次检查分析可以让您做出判断，您的所有者可以根据这些判断采取行动，而无需事后猜测。对于每小时的监控周期，准确性和可解释性超过了实时要求。
让法学硕士远离算术
数值验证机制最初采用双层LLM设计：一个代理提取并比较值，第二个判断代理独立验证结果。两人都可以使用计算器工具。尽管如此，生产运行还是偶尔会出现错误，不是在原始算术中，而是在比较逻辑一致性方面。这些问题涉及何时舍入、应用什么容差以及如何处理单位差异。对于验证系统来说，即使偶尔出现不一致也会削弱对每个判决的信心。
结论
用确定性代码替换比较阶段，将精度从依赖于模型的结果转变为设计保证。给定正确提取的值，无论哪个模型执行提取，编程比较都不会产生错误。随后的模型升级改进了提取阶段，并通过减少误读仪表板值导致的误报，将召回率从 0.88 提高到 0.95。
两种验证机制的关键教训是相同的。当您设计自己的系统时，将 AI 分配给它擅长的语义任务：查看、阅读和导航。将确定性代码分配给单个错误会削弱信任的判决。
检测到的故障分布在广泛的监控部分，而不是局限于少数问题仪表板，这证实了内容层监控需要全面覆盖，而不是抽查。
平均检测时间从最多 72 小时减少到不到 1 小时：因为验证周期每小时运行一次，最坏情况下的检测时间受到扫描间隔的限制。
数值验证机制已按周生产周期运行了 6 个多月，每个周期验证 50-70 个数据点。匹配的值通过确定性比较设计自动批准，并且在迄今为止的生产评估中，没有任何数据问题因错误批准而绕过人工审核。在一个生产周期中，系统检测到影响一系列相关指标的系统不一致。在数据到达下游消费者之前，问题已升级并得到解决。
预测分析，使用历史故障模式在问题影响用户之前对其进行预测。
在这篇文章中，我们展示了我们的团队如何构建主动内容验证系统。它通过两个并行的人工智能机制监控数百个实时仪表板：用于视觉完整性的LLM视觉推理，以及用于数字准确性的确定性比较的代理提取。通过自动检测，您可以在内容故障侵蚀用户信任之前以及在内容故障到达使用数据的人工智能系统和业务领导者之前解决它们。
此处演示的模式可转移到大规模运营商业智能资产的组织。其中包括使用基础模型进行基于屏幕截图的内容验证、作为地面实况捕获机制的浏览器自动化、精度关键阶段的确定性判决以及由遥测循环支持的基于所有权的警报路由。
致谢
我们感谢我们的执行赞助商和导师的远见和指导，使这项工作成为可能。Aizaz Manzar，AWS 全球销售总监；Sujit Naraparedy，AWS Insights 总监；Bernardo Sajonz，EMEA 洞察产品负责人。
关于作者
君宫横尾
塔特维克·霍夫汉尼斯扬
贝尔纳多·萨洪斯
要开始使用类似的功能，请探索用于基础模型访问的 Amazon Bedrock，以及用于无服务器编排的 Amazon EventBridge 和 AWS Lambda。有关 AI 驱动的业务叙述的相关方法，请参阅 AWS SMGS 如何使用 AI 驱动的对话助手通过 Amazon Bedrock AgentCore 转变业务管理。有关遥测层中使用的文本到 SQL 模式，请参阅由 Amazon Bedrock 提供支持的文本到 SQL 解决方案。有关最新动态，请访问 AWS 的新增功能。
我们还要感谢敬业的团队成员，他们的技术专长和贡献为实现该产品发挥了重要作用：商业智能实习生 Alfonso Mateos Vicente；可靠性工程主管 Chris Corcoran；高级技术产品经理 Kimiya Yokoo；高级数据工程师 Matteo Paganotto；商业智能工程师 Ryo Okano；数据工程师 Vaibhav Yadav；洞察与分析高级 Ruben Fondon Alcalde主管；Tatevik Hovhannisyan，高级洞察与分析主管。
Kimiya 是 AWS 的高级技术产品经理，常驻东京。 Kimiya 专注于多代理系统和人工智能验证，致力于人工智能叙事系统的最后一英里验证代理。
Tatevik 是 AWS 的高级洞察和分析主管，常驻柏林。 Tatevik 领导内部洞察应用程序中面向卖家的分析体验的产品所有权。她目前的重点是人工智能驱动的商业智能。
Bernardo 是 AWS 驻卢森堡的 EMEA 洞察产品负责人。 Bernardo 领导整个欧洲、中东和非洲地区的洞察产品的战略和开发，重点是为销售组织提供可扩展的分析解决方案。