报警响起,
轮机员到现场看一眼。
烟雾传感器报警 → 值班轮机员到机舱确认火情。
判断发生在现场,靠的是人的经验。
PTRANS · 2026—2027PROJECT INTRODUCTION / 项目介绍
从传感器报警,
到机器给出的事故推断。
动态因果链提取与叙事重构
01 / WHO WE ARE · 企业导师
当前职责领导 GIE 的产品愿景与技术战略。
工作经历
ASM(上海),把 AI 工具落地到生产工作流。
教育经历南特综合理工学院(Polytech Nantes)工程师
01 / WHO WE ARE · 企业导师
当前职责统筹 GIE 的数据架构与机器学习落地。
工作经历
Measurable AI(香港),负责数据工程。
教育经历南特综合理工学院(Polytech Nantes)工程师
波尔多大学(Université de Bordeaux)学士
01 / WHO WE ARE · 企业导师
当前职责主持 GIE 的日常工作与项目编组。
工作经历
海思特海事技术(上海),软件开发负责人:负责用户界面的开发与交付,并参与船舶感知系统开发。
英国皇家造船师学会(RINA)准会员
教育经历南特综合理工学院(Polytech Nantes)工程师
上海海事大学工学学士
02 / THE PROJECT
事故发生时,系统要沿着已有的知识回答三个问题,并把依据交给人。
发生了什么从观察推断可能的事故
为什么会发生追溯前提与原因
接下来怎么办给出条件满足的处置动作
场景可以换,工作流不变。先用船舶火灾把链路讲清楚、跑通,再引入更复杂的场景。
03 / THE SCENARIO
烟雾传感器报警 → 值班轮机员到机舱确认火情。
判断发生在现场,靠的是人的经验。
远程控制中心或船载计算机,
要在没有人到现场的情况下判断是否正在发生危险事故。
问题:没有人到现场,谁来把一串传感器读数变成“这可能是一场火”?
04 / TODAY VS. WHAT WE WANT
SD-04 烟雾浓度超限。
传感器只说“超出界限”。
它是什么事故、下一步该做什么,全部交给人来推断。
机舱可能起火:烟雾 + 温度上升。
建议:确认火情 → 评估火势。
机器先沿着因果关系推断事故和可行动作,
再把推断和依据交给人决定。
报警的对象从“一个读数”变成“一个事故”。
05 / WHAT WE ALREADY HAVE
应急手册写的是“发生什么、满足什么条件、然后做什么”。这正是一张图。
读手册文本,
提取事件、顺序与进入下一步的条件。
节点是事件,有向边是条件;
无环,依赖不能绕回自身。
存储图、默认可视化,
给定观察后沿图查询原因与动作。
06 / A CONCRETE EXAMPLE
检测烟雾 → 确认火情 → 评估火势 → 选择处置路径
左右滑动查看完整因果图 →
关键不是画出箭头,而是保留前提约束。
07 / YOUR MISSION
一段海事教材,
生成有效、可见的因果图。
连接同一场景的两张图,
表达关系,并保持无环。
沿着图中的关系,
探索可能原因与处理动作。
先跑通一条可验证的链路,再扩展复杂度。
08 / STAGE 1 · TEXT TO GRAPH
“传感器检测到烟雾后触发报警,
值班轮机员随后到现场确认火情。”
从短文本开始,明确事件、顺序与条件。
节点
e1 检测烟雾
e2 触发报警
e3 现场确认
关系
e1 → e2 → e309 / STAGE 2 · CONNECT THE DOTS
找到连接点不是把所有节点堆在一起
说明连接原因前提、结果,还是补充?
检查合并结果保持无环,保留约束
10 / STAGE 3 · REASON WITH THE GRAPH
哪些前提与事件
可能通向当前观察?
图中有哪些后续动作?
各自的条件满足了吗?
输出需要有路径依据,而不是自由编造下一步。这就是“事故推断报警”。
11 / KEY POINTS
手册文本换成别的领域,同一条“提取 → 连接 → 推断”链路照样走。
不是哪个读数超限,而是可能发生了什么、建议做什么、依据是哪条路径。
Python、RESTful API、Neo4j 默认可视化;示意图不等于模型结果。
12 / WHAT GOOD LOOKS LIKE
输入文本,生成可检查的因果 DAG。
清楚表达跨图关系,不破坏原有约束。
根据图中的关系探索原因与行动。
13 / FIND YOUR PLACE
以下是协作切入点,不是预先固定的岗位分配。
理解输入、标注案例、
构建提取 agent。
定义节点与边、检查无环、
探索连接与推断。
连接 API、复现案例、
评估质量与本地运行。
不必先会所有技术;需要一起把输入、输出和验证标准讲清楚。
DISCUSSION / 一起讨论
先把船舶火灾这条链路跑通。
认识 GIE ↗︎