上一页我们看到，IT 系统每天都在记录海量操作数据。但光看这些数据本身，没人能直接告诉你'业务到底是怎么跑的'。过程挖掘要做的事，就是从日志里把真实流程'画'出来。

想象你打客服投诉一单外卖。客服先问订单号，再问"什么时候下的单、中间出了什么问题"——这三项信息凑齐，一条事件日志就成型了。

沿箭头方向读：左上事件日志出发，往右下走完分叉分析，落到可执行流程再回流。

有了事件日志，接下来能做什么？过程挖掘回答了三类问题：流程长什么样、实际跑偏没、还能怎么改。

左输入、中任务、右输出，三条链路横向对比三种任务的输入输出差异。

前几页讲了过程挖掘的几类任务和算法。但这么多算法,跑在哪里、谁来兜底?答案是 ProM——埃因霍温理工大学主导的开源框架。

ProM 启动慢、和 Python 数据栈割裂。要在 Python 里做过程挖掘，PM4Py 是绕不开的——它把三大任务装进 Pythonic API。

ProM 是点鼠标的桌面软件，PM4Py 是写代码的 Python 库——一个让人「看」，一个让人「做」。

5行核心代码,从XES日志直出Petri网模型

『读日志-挖模型-看模型』三步走,Alpha算法封装在一行调用里,把研究代码变成即用工具。

ProM 与 PM4Py 是开源‘框架级’工具，要写代码才能用。企业实战更需要开箱即用、面向业务人员的产品——三个代表性工具登场。

前页我们说过，发现任务的目标是从日志「重构」出流程模型。1999年之前，没人给出过可行的算法——直到Van der Aalst提出α算法，第一个真正能跑的发现方法。

α 算法从事件日志中提炼四种活动关系，逐步过滤出最终模型所需的依赖信息。

上下结构：中心是α算法，向下分「能处理」与「不能处理」两支。

上一页提到 α 算法碰到噪音就乱套——两条活动偶尔错位就可能拼出根本不存在的回路。启发式挖掘换了个思路：与其相信每一次出现，不如看谁出现的次数够多。

α 算法在并发、循环上失灵，启发式挖掘只是近似。我们需要既精确又能驾驭复杂结构的方法——基于区域的算法绕开局部回溯，靠「分块-建模」直击全局。

上一个算法靠复杂的集合运算做区域切割。有没有更直接的方式，对着日志一通"切"，保证产出的模型不会卡死、不会漏活动？——Inductive Miner 就走这条路线。

同一份日志跑不同算法，结果可能天差地别——选型比调参更关键。

前几页我们挖出了过程模型，但都是「基础款」——只覆盖最显著路径。你手里拿着这张图，最近却在街上看到几条新修的路——日志里有，但模型没标。模型增强就是把这些路径补回模型。

前页把流程当静态快照——但同一组织今年的流程和去年可能截然不同。规则在变、组织在调整，漂移是常态。

上一页我们从时间维度看清了流程节奏，但流程终究由人执行——谁是关键角色？哪些人配合最密切？组织结构是怎样的？这些问题需要从日志的资源字段里挖掘。

我们从日志发现模型，又给它加上时间、资源维度。但一个尖锐的问题浮现：发现的模型真的反映了现实吗？就像根据 GPS 轨迹画出城市地图后，还得拿真实路况去比对验证。

真实业务的事件日志远比教科书示例复杂——传感器噪声、流程随业务演进、千万级事件规模，都让算法从论文走向落地时举步维艰。

前面我们学了α算法、Inductive Miner等，它们输出模型形态各异。但有一种"通用语"贯穿整个过程挖掘——Petri网。它既是发现的"靶模型"，也是分析与验证的天然载体。

传统过程发现算法再精巧，最终都交出一张"能看清"的 Petri 网。但当日志高维稀疏、并发海量时，符号算法的天花板就到了。神经网络开辟另一条路：放弃显式模型，换取对复杂模式的拟合能力。

某医院已有标准化就诊模型，团队希望：① 确认实际执行是否按设计进行；② 依据真实数据修正模型偏差。这两个目标分别对应哪两项过程挖掘任务？

• ✓事件日志是过程挖掘的唯一事实来源
• ✓发现·一致性·增强三大任务构成持续优化闭环
• ✓算法选择是工程决策，没有银弹
• ✓前沿方向都在让过程挖掘贴近真实世界
• ✓ProM偏研究探索，PM4Py偏工程落地

先自己琢磨，再对照参考答案。问题没有标准答案，看的是思考路径。