2024年9月20日至22日，由全国知识图谱与语义计算大会 2024（China Conference on Knowledge Graph and Semantic Computing，CCKS 2024）和知识图谱国际联合会议 2024（International Joint Conference of Knowledge Graph，IJCKG 2024）联合主办的全国知识图谱与语义计算大会暨知识图谱国际联合会议（CCKS-IJCKG 2024）在重庆市举办。文因互联执行总裁余姗分享“大模型和知识图谱在航空领域的应用”。
CCKS-IJCKG 2024参会代表合影
北京文因互联科技有限公司余姗作工业界报告
以下内容为文因互联执行总裁余姗在会上的演讲整理，内容有删减。
很高兴和各位一起讨论“大模型在航空领域的应用”。文因互联一直是一家做企业级知识管理的公司，过去十年深耕金融知识图谱领域。这两年，我们已经全面拥抱大模型，并探索新的领域。目前我们已经有 30% 的营收来自航空领域。
文因互联怎么就突然从金融领域转到航空方向了呢？其实我们做的是同样的事情。【Quality】【Asset】【Operation】，底层的算法是共通的。
第一个部分是Quality（质量）：在金融领域，我们会做各种投行材料的合规检查、质量检查。航空是非常注重安全的领域，所以相应的我们会做FOQA系统、航前/航后风控检查、飞行员全生命周期管理（PLM），这些其实都是合规检查。
第二个部分是Asset（资产）：在金融领域，资产就是各类金融产品管理，例如我们做过不良资产的智能化处理。在航空领域，最重要的就是固定资产——飞机，所以我们会做发动机的预测性维修，提升发动机的在空时长。
第三个部分是Operation（运营）：就是提高运营的智能化程度，在金融领域我们做的是流程自动化、托管自动化、数字员工。而航空公司的运营成本很高，比如燃油开支，所以我们会给航司飞行器的数据分析、燃油节能分析。除了航空，延伸到其他工业领域也是一样的逻辑，明年期待能在这里和大家来分享我们在更多工业领域的探索。
航空专家系统的瓶颈被大模型突破
航空的业务分析，本质上是构造专家系统，而专家系统最难就是行业know-how。文因互联一直在做领域知识建模，我们在金融领域深耕十年，在业务领域积累了十年的基础。同样，当我们迈入航空领域的时候，我们的航空业务分析团队同样也是拥有十几年的领域经验。
首先要成为“专家”，才能够去构造专家系统。专家系统已经存在几十年了，它的瓶颈在于如何把知识灌入计算机里面，之前我们这样做的成本非常高。有了大模型后，我们做了一些探索，如何降低整体的成本？
航空领域的特殊性在于场景多样性，而且容错率无限的接近于零。航空的数字化工作都是围绕“安全”展开的，比如LOSA（航线运营安全监测）、PLM飞行员全生命周期管理、SMS安全管理系统。
以LOSA（航线运营安全监测） 为例，民航局对每一个航司有非常严格的要求，有上千甚至上万条的安全规章制度，从而保障每一架飞机飞行员的操作是完全安全合规的。我们要帮助航司做监测，就需要把这上千甚至上万条的规章制度写入系统，这其实用知识图谱和大模型就可以解决。
航空领域是一个知识密集型的领域，它的知识密集型体现在三个方面。
第一个知识来源：
手册文化
首先就是“手册文化”，手册文化可以说是民航安全文化的重要体现，其中包括了各种规章、手册、乃至行政制度。这些手册，或者说标准，蕴含着大量的知识。
在航空的百年历史中，以空客、波音和商飞为核心飞机制造商，建立了非常完善的手册制造体系，所以像飞机制造商、发动机制造商、民航局、空管和航空公司，他们都属于知识密集型的企业。所以航空领域有各种管理手册、维修手册、运行手册、技术手册，另外包括国际航天航空会IATA、中国的民航局的很多规章制度要求。
第二个知识来源：
运营数据
当我们去看一架飞机的时候，不要把它只当成一架飞机，本质上它是一个“数据工厂”，每一架飞机上面都有 3000到20000个传感器，每一秒钟都能收集大量的数据，根据ARINC 429总线协议实时记录的数据参考，每个航班有约1000万个信息数据点，每架飞机每年能生成100亿个数据点。如果大家用过航旅纵横APP，那么其中有一些我们服务的航司起落数据，就是用的系统对传感器数据译码以后，通过数据链路提供给航旅纵横。
大家都知道飞机上有一个黑匣子（FDR），可以看到黑匣子其实是红颜色的。黑匣子里的数据是不可读的，因为它的用处是飞机事故发生时保障数据安全的。但是有另外一个非常重要的数据叫做QAR数据（快速存取记录仪数据），它基本是黑匣子数据的复制，在飞机降落之后我们可以把它取下来使用。
QAR数据包含了大量的飞行过程数据，例如发动机数据、起落架数据、飞控系统数据，还有飞机上各种舱音数据、驾驶数据等等，这些都是我们分析飞机航线运营、操作规范的数据基础，这些数据也构成了另外一部分知识来源。
举个具体的例子，大家在飞机上能感知到飞机颠簸，但是地面上的空管和航司是如何感知呢？这就需要用到传感器数据来帮助判断了。飞机有水平加速度仪和垂直加速度仪，通过这两个加速度G值的快速变化，形成一个超限事件（异常事件）判断后，地面就可以了解飞机是否有颠簸了。
我们通过各种数据的组合，建立飞行过程的全视角，这就是其中一个知识来源。
第三个知识来源：
维修体系
第三个数据来源就是维修体系。因为飞机真的很贵，所以它会有非常完善的维修体系，包括维修手册（MM）、持续适航维修方案（CAMS）、工作卡/工单、维修日志、技术通告/服务通告（TB/SB）、适航指令（AD）、标准操作程序（SOP）等。而且，飞机上每一个零件它都有自己的编码，如果从传统的知识表现的角度来讲，它就是一个ontology，所以我们对飞机上的每一个零件都会有标准的描述方法。
整个航空的专家系统的建设，包含了基础的手册数据、机器运营数据以及维修数据，我们用他们一起构成了整个航空的专家系统的原始数据。
航空知识图谱构造
下面我们用一个实际的例子来和大家分享一下，如何用大模型辅助构造航空知识图谱，以及如何用知识图谱来进行故障诊断。
这是一个联合研究课题，我们构造一个关于全球空难的知识图谱，来更好地对航空事故进行致因分析。这个知识图谱的来源是各种航空事故的报告，我们收集了几万份各种空难相关事故的报告，这是一个典型的英文事故报告的例子。我们需要把这种人读的报告转化成机器可以理解的具体的知识点。
我们对这些报告做了一下词频分析，从英文报告的词云可以看到，词的分布规律性还是很强的。我们同时对中文报告也做了一个词频分析，可以看到跟英文的词云也是类似，通过这个词云大概能体会到就是在事故报告里面的这些最常见的概念有哪些。
知识表示与建模：
基于事故数据分析的建模形式
以项目为例，我们继续来做知识图谱的构造拆解。
在飞机放行之前会有一个典型的测试，来判断能否放行。测试最开始会有一个自然语言描述，来说明飞机状态，比如右上侧会有完成与电源相关系统各项测试并测试右发FADEC带转正常，双发慢车测试正常后飞机放行。
我们需要从自然语言的描述当中，把它抽取出两个triples，<右发FADEC，测试，正常> <双发慢车，测试，正常>。
此外，我们还可以定义本体关系，如右发FADEC和双发慢车都是“电源系统”的实例。实例关系，也就是instanceOf关系，也是一种三元组。在这个项目中，我们还是采用了RDF图的方式，因为它可以支持逻辑推理，这对后续的事故归因分析很重要。
知识获取：
结合大模型做实体和关系抽取
如果从传统的知识表现的角度来说，它是一个实体抽取、事件抽取的过程，核心的抽取有很多传统方法，但现在我们基本只要用大模型底层，再加上一组提示词prompt，把它组合就可以了。但这个prompt需要有很多组成部分，比如首先要有一个in context learning（上下文学习），还需要告诉它是一个什么样的角色，以及它它需要什么样的schema，这个schema它需要一个schema列表和数据字典，然后是正面样本、负面样本，最后构成非常工业化的一个prompt。
知识融合：
知识图谱知识融合与消歧
同样，我们从不同的角度把数据梳理出来之后，还要进行对齐。比如对于波音的数据和空客的数据，我们都要对齐，这边涉及到了本体融合、知识融合、ontology Mapping，大量的工作。最后，知识里面还是有推理的，因为ontology最核心的点，它跟数据最大的区别就是它是有隐含的推理关联关系的。
比如A320的自动油门在任何模式下都会自动驾驶，但是波音777的自动油门空闲模式下不会自动驾驶，这些来自不同手册的描述，我们就要对齐。
再重申一下，知识图谱和大模型不是相互替代的关系，知识图谱在大模型的加持之下成本能够降低。我们有了知识图谱之后能去做一些推理的工作。如果只用大模型的话，像航空中非常复杂的业务逻辑和数据之间的关系，很多显性知识的分析过程就没办法完成。所以，大模型和知识图谱在我们实际的项目落地过程中，是互补的关系。
当我们做完这些之后，就可以对航空事故做更加全面的致因分析。
航空事故调查致因分析
有了知识图谱之后，就可以用它去做一些推理的分析。如果只用大模型来的话，复杂领域知识的应用还是非常困难的，当你有了知识图谱的时候，就可以做更多这种显性的explicit knowledge的分析过程。所以大模型和知识图谱是一个相互补充的关系。
当我们做完这些，最后可以对航空事故做更加全面的致因分析。
航空事故原因大部分来自人为失误
据IATA统计，47%的事故来自可控飞行撞地（CFIT），也就是说很多事故中飞机本身可控性良好，但由于人为操作问题导致事故产生。各种人为事故加在一起，占到所有事故件数的77%，死亡人数占比超过90%。通过事故的具体归因分析，可以帮助飞行员减少出错概率的。近20年，随着数据的应用越来越广泛，至少在北美和东亚地区，飞行已经越来越安全了。
航空事故核心原因的知识图谱构建
事故的原因一层一层的分下去，就是变成了事故原因的分类树，或者说是本体（ontology）。
例如人为因素里，可分为驾驶员误操作、机务维修差错、机场安保错误、空中管制员错误等。这些顶层概念，就构成了一个上层本体（upper ontology）。一直分下去最多大概是200类不同的事故的原因，那我们如何建立一个模型呢？
如果说我们要建立200个模型，这件事情就太复杂了，所以我们尽可能用一个统一的模型来建立分析模型。本体就是对领域数据约束条件的一个正式的描述，来降低我们分析的困难。
这是我们构造的航空事故本体的一个树形表示。一层层细分下去，这个本体一共分了五级概念。到了第四级，每个概念都有个二位码，第五级概念每个都有个四位码。
这个码本身，也是国际标准ATA 100通用编码，由美国联邦航空局所发布。对于每一个事故事件，就是在空难的前置其实会有大量的指标超限事件，每一个典型的事件本身也是被编码的，这是另外一组庞大的ontology，我们要把这些知识从手册变成知识图谱。
飞机故障排除手册是另外一组原始的数据，每个飞机厂家都会提供给我们，图中的例子是波音737的FIM手册，Fault Isolation Manual。我们需要把手册中的关键描述、名词、代码全部提取出来，如果没有大模型帮忙，这会是一个非常浩繁的工程。当我们有了这些本体之后，我们就开始对它进行事故归因的基本的逻辑判断。
事故调查致因分析的基本逻辑
在基本逻辑判断中，关键步骤可以总结为如下：
1、首先输入事故经过、原因的原始文本，这个步骤通常是由航司的安监人员来完成，这也是一段自然原文本。
2、对输入的事故描述进行信息过滤，特别是总结出事故相关联的关键零件和事件的构建，用这些作为故事分类的依据。事故的分析其实是一个典型的分类问题，所以我们要基于知识图谱，把这些关键的决策点建立起来。而分类标准以ATA100文档作为基础的知识，因为它是一个PDF文件，我们会通过抽取文档建立所有标准化编码的图谱。
3、做进一步的分析前需要通过对事故描述文本数据的分析，把它映射到ATA的某一种分类码上面去。在非唯一确定原因场景，我们还会用RAG检索增强的技术，匹配原始描述和ATA100事故表述，返回最接近的K个结果。
这就是整个事故原因分析的核心的过程。总结来说，我们有了知识图谱之后，可以对航空事故归因做更好的处理。我们看到了大模型的两层作用，那么第一个作用是在抽取的过程，第二个是在分类的过程。
航空专家系统的其他应用场景
应用案例1：
业务专家用自然语言生成FOQA分析业务规则
FOQA系统是一个强制要求实施的信息系统，它会收集和分析日常飞行中飞行数据，用于安全管理，提高飞行机组的操纵品质，改进标准操作程序、完善飞行训练大纲、优化空中交通管制（ATC）程序、减少运行和维护成本等。
比如飞行过程当中“接地过载”是一个特别严重的事情，因为接地过载可能导致起落架断裂，所以会被严格监控。接地过载数值超过1.8G就会有触发飞行事件的风险。如果超过2.0G，就会被民航局处罚。在这背后也有业务逻辑，我们拿到数据之后，要判断飞机是否出现接地过载，就要通过接地时刻的垂直载荷、风向风速、飞行员收油门高度，三个具体指标来对事件进行分析。
其实，查询“接地过载”数据，本身就是一个业务规则，怎样去写出这些业务规则呢？航空领域每个具体的业务分析点，都有繁多的业务规则。在没有大模型的时候，我们的航空事业部的业务团队都是用手写代码的方式去做的。去年，我们在航空这个方向做了一个review，因为我们发现它有很强的业务属性和规律性。我们把这些年的积累的代码，变成微调的语料，做了一个专门针对航空领域的业务规则生成器。
先拿一个数据schema，整个schema是由上千个不同的指标组成的，最终结果可以从数据的测试集中看到是成功的。在这中间是我们要想建立的业务规则也就是推理机内部跑的代码，是规则系统用Python语法来写的。大模型在整个过程中，提高了业务分析团队，从业务逻辑分析到代码编写的工作效率。
应用案例2：
LOSA 数字化解决方案
LOSA数字化解决方案结合领域大模型能力，为航空业带来深远影响。LOSA（Line Operations Safety Audit）是一种航线运营安全审核方法，它通过详细观察和数据分析来提高航空安全。我们的数字化解决方案通过数字化和自动化LOSA流程，提高效率和准确性。
在安全监控和风险预测方面，可以通过分析飞行数据和机组行为，识别潜在的安全隐患和操作失误飞行安全。这种分析可以包括飞行路径偏差、天气条件变化、机械故障预兆等，实现对飞行安全的全方位监控。并通过分析飞行品质监控数据，帮助航空公司及时发现和改进潜在的安全隐患和操作质量问题，提高对可控因素和人为因素的监控和管理能力。
在运管提升和智能维修方面，通过引入 AI 算法模型，对过往LOSA项目沉淀的数据进行统计分析与机器学习建模，挖掘其中的规律特征并应用于 EBT 等环节，并预测潜在的故障和维修需求，实现预测性维护，提升运管水平。
在偏差事件分析方面，可以通过仪表回放辅助分析飞行员操作，通过3D可视化展示飞行过程，辅助关键飞行阶段变化动态的直观展示比对及分析，快速调取偏离SOP标准的不当操作的关联场景。并通过大屏看板全方位展示飞行质量，高效掌控风险态势，提前预警并快速反应。通过各相关主题统计与分析，对薄弱环节充分定位与剖析，支撑运营复盘与改进，构建良好飞行安全闭环。
应用案例3：
故障维修方案自动生成与推荐依据溯源
最后一个案例，是从海量的历史维修记录中匹配当前故障报告相似数据，推荐维修方案。本质上还是个知识库应用，系统架构并不复杂，这里就不多说了。
虽然我们在航空领域里探索的时间不长，只有两年的时间，但是我们发现航空作为非常典型的专家系统的场景，大模型真的帮我们解决了专家系统里面最核心的一个问题，就是知识瓶颈问题。
我们可以通过自然语言的交互，从大量的业务专家的脑子里面把知识灌输到系统里面去。我们也可以通过大模型所带来实时的数据处理能力，把大量的知识从各种各样的手册里面、SOP里面、维修记录里面也灌到了机器里面去，从而带来专家系统的新时代。
往
期
推
荐
