Panasonic用Agentic AI将IFEC诊断从小时级缩至分钟级

Panasonic Avionics Corporation 为全球庞大机队提供机上娱乐与连接（IFEC）系统，服务数百家航空公司，每年为数以十亿计的乘客提供服务。当系统问题在这种规模上影响乘客体验时，工程师必须在上千种独特部署配置中快速诊断根本原因。手动完成这一工作——关联跨多样化机队变体的日志、指标和工单数据——可能需要数小时，并且需要深厚的内部知识储备。

在这篇文章中，你将了解到 Panasonic Avionics Corporation 如何与 AWS 以及 AWS Generative AI Innovation Center 合作，获得架构指导，构建了一个 agentic AI 系统。该解决方案使用 Amazon Bedrock、Amazon SageMaker 和 AWS Glue，显著缩短诊断时间，同时保持高准确性。

挑战：规模化运维的演进

Panasonic Avionics Corporation 的运维数据是监测机队 IFEC 健康状况的关键资产。该公司依赖建立在 AWS 上的数据湖和数据中心系统，存储和组织跨机队收集的运维数据，每日处理海量数据。

尽管拥有强大的数据基础设施，将原始运维数据转化为可操作的诊断仍在大规模场景下带来运维挑战。Panasonic Avionics Corporation 部署服务时会根据个别运维需求定制配置。每个部署都会生成独特的日志模式，这使全机队性能评估变得复杂。团队需要手动审查以关联多个运维数据源之间的指标。

这一流程在运维效率和工程生产力方面存在多个优化机会：

手动分析工作量 —— 跨多样化配置进行关联需要详细的手动调查。这保证了诊断准确性，但也延长了整个分析周期。

平均故障检测时间（MTTD） —— 检测主要依赖工单生成和手动审查，这影响了新模式被识别的速度。

平均故障解决时间（MTTR） —— 解决时间线包括在开始纠正措施之前的大量调查工作，导致端到端解决周期较长。

自动化机会 —— 重复性调查任务和日志审查为智能自动化创造了重要机会，特别是在高峰活动期间。

知识扩展 —— 手动关联流程需要深入的系统熟悉度，这为使用 AI 在工程团队中更广泛地扩展内部知识创造了机会。

资源优化 —— 工程师在诊断活动上花费了重复性的时间，减少了创新、功能开发和长期可靠性改进的带宽。

Panasonic Avionics Corporation 识别到一个明确的机会：在保持诊断严格性的同时，向主动健康监测和全机队模式识别演进。目标是保持分析深度，同时显著改善 MTTD 和 MTTR，使工程师能够更多地专注于解决方案设计、优化和战略性可靠性增强，而不是调查性开销。

Panasonic Avionics Corporation 与 AWS 和 AWS Generative AI Innovation Center 合作，探索生成式 AI 如何增强其机队 IFEC 运维的内部诊断工作流程。这次合作将 Panasonic Avionics Corporation 在 IFEC 运营方面的深厚领域专业知识与通过 AWS 服务提供的生成式 AI 能力相结合，并获得了 Innovation Center 在系统架构设计方面的指导。

下图展示了这个在 AWS 上的诊断架构。该解决方案使用一个多 agent 工作流系统，通过三个不同层级协调处理数据。趋势分析器（Trend Analyzer）通过分析关键性能指标和服务降级指标来识别异常。并行诊断 agents 并行执行特定的诊断功能，包括关联分析、系统检查和日志模式匹配。一个由大语言模型（LLM）驱动的汇总器（Summarizer）将输出整合为连贯的诊断报告，包含根本原因分析和推荐操作。

图 1：AWS 上的多 agent IFEC 诊断架构

系统通过以下五个阶段处理运维数据：

1. 摄取与标准化

系统从整个机队摄取原始运维数据，将其转换为标准化的服务指标，并使用 Apache Iceberg 存储在 Amazon Simple Storage Service（Amazon S3）数据湖仓中。AWS Glue 和 Amazon EMR 处理这些提取、转换和加载（ETL）管道。一个领域本体论——定义机队实体及其关系的共享词汇表——跨机队变体标准化术语。这种一致性使得来自不同配置的数据可以在机队规模上进行比较。该本体论还将性能指标与配置元数据及工单信息关联，创建了跨机队诊断的统一视图。

2. 趋势分析与主动检测

趋势分析器 agent 持续评估关键性能指标、服务级别合规性和降级指标。全机队关系建模可以检测在单独检查单个部署时无法发现的模式，例如仅影响共享特定配置变体的部署的渐进式降级。

这使 Panasonic Avionics Corporation 从通过工单生成的被动检测，转变为主动识别在问题升级之前的潜在问题。

3. 并行诊断调查

当趋势分析器标记出关注点时，并行诊断 agents 同时从多个角度进行调查：

关联分析器（Correlation Analyzer）：检测跨共享配置的部署中的重复模式，判断问题是孤立性的还是系统性的。

系统检查（System Checks）：针对工单工作流验证元数据和服务状态，确定已知的维护活动是否解释了观察到的行为。

日志分析器（Log Analyzer）：使用基于规则和模式的检测，将当前日志模式与先前已识别故障模式的库进行匹配。

Amazon SageMaker 使用 LangGraph（一个用于管理有状态 AI 工作流的开源框架）编排这些 agents。Strands Agents SDK——一个用于构建 AI agents 的开源 Python 框架——提供 agent 实现和执行能力。它们共同并行运行这些 agents，将 Panasonic Avionics Corporation 内部测试中的调查从数小时的手动审查缩短到数分钟的自动化分析。

4. 知识检索与历史关联

系统查询存储在 Amazon Relational Database Service（Amazon RDS）中作为向量表示的过去事件和解决产物，使用 pgvector（一个用于向量相似性搜索的 PostgreSQL 扩展）。语义搜索可以检索相似的模式及其解决方案，即使症状不完全相同，赋予系统可在整个工程组织中扩展的内部记忆。

5. 诊断汇总与自动化行动

Amazon Bedrock 上的 Anthropic Claude 将关联分析器、系统检查和日志分析器的发现综合成结构化诊断报告。每份报告包含根本原因假设、跨受影响机队段的影响分析，以及优先排序的修复建议。

系统按严重级别对报告进行分类。对于关键发现，系统自动创建告警、优先处理事件，并将它们连同推荐的解决操作路由到相应的工程团队，减轻手动分类工作，同时保留工程监督以进行修复决策。

AI 生成的建议使用检索到的运维数据和对历史事件进行 grounding，结合确定性业务规则进行验证，并附带支持证据呈现。人类工程师审查诊断发现，并为运维重要的事件批准修复操作。系统还维护 agent 决策和建议的可追溯性，以支持审计和持续改进。

基础设施设计

跨这五个阶段，构建机队级诊断系统需要随需求增长的基础设施。AWS Glue 和 Amazon EMR 的无服务器数据处理、Amazon Bedrock 的模型灵活性，以及 Amazon SageMaker 的受治理 agent 运行时，使 Panasonic Avionics Corporation 能够专注于诊断逻辑而不是基础设施。

从概念到生产

Panasonic Avionics Corporation 在 AWS Generative AI Innovation Center 咨询团队关于事件驱动设计模式、并行处理策略和生产可扩展性性能优化技术的指导下验证了该解决方案。

尽早建立严格验证：Panasonic Avionics Corporation 实现了针对真实数据的交叉验证，达到了在整个测试过程中始终超过要求的准确性。

为模块化和透明度而设计：设计原则强调原子化 agent 操作、提示和逻辑的透明度，以及人在回路（human-in-the-loop）审查能力。这种模块化方法允许独立更新 agent，而无需在解决方案扩展时进行系统级更改。

战略性地优化 AI 组件：指导强调使用调优的参数配置以获得确定性输出和集中响应。团队将 LLM 的使用限制在汇总和错误推理任务上，在这些任务上生成能力可以带来明确价值。

通过持续反馈迭代：只有在自动化操作与手动专家评估一致后，解决方案才进入生产阶段，因此系统在缩短解决时间的同时保持了诊断准确性。该系统现在每天生成覆盖活跃机队的诊断报告。

成果

Panasonic Avionics Corporation 在 AWS 上的 AI 驱动诊断系统在关键运维指标上取得了可衡量的改进。手动分析工作量显著减少，同时平均故障检测时间（MTTD）和平均故障解决时间（MTTR）均有所改善。在目标用例中，该系统展示了 20–40% 的运维效率提升。支持团队确认重复性调查负担显著减轻，因为系统现在处理了以前需要数小时手动工作才能完成的任务。独立诊断的工程能力有了实质性提升，团队可以诊断和解决以前需要升级才能处理的问题。随着系统增长，这些改进从根本上改变了运维模式，团队可以通过 AI agents 处理增加的规模，减少成本和运维风险。

相关资源

要探索 AWS Generative AI Innovation Center 如何帮助您的组织构建类似解决方案，请访问 AWS Generative AI Innovation Center。有关本文使用的服务的更多信息，请参阅 Amazon Bedrock、Amazon SageMaker 和 AWS Glue。对于航空特定用例，请访问 AWS for Aerospace and Satellite。

有关在 AWS 上进行多 agent 编排的更多信息，请参阅以下文章：

• Build Strands Agents with SageMaker AI models and MLflow.
• Build a serverless conversational AI agent using Claude with LangGraph and managed MLflow on Amazon SageMaker AI.

免责声明：本文描述了 Panasonic Avionics Corporation 与 AWS 合作的一个内部计划。所描述的架构和方法反映了一个特定实现。实际结果可能因数据特征、运维上下文和系统配置而异。