本文详细介绍 Cleaning Logs for Downstream Tasks (Registered Report) ，重点放在论文提出的 LogPurifier 方法、依赖分数计算、聚类式日志清洗流程，以及作者计划如何验证该方法对下游任务的影响。
1. 论文基本信息
| 标题 | Cleaning Logs for Downstream Tasks (Registered Report) |
| arXiv | 2606.27000v1 |
| 类别 | cs.SE |
| 作者 | Zahra G. Yazdi, Van-Hoang Le, Nyyti Saarimäki, Donghwan Shin, Domenico Bianculli, Lionel Briand |
| 核心问题 | 真实日志中混入大量与系统功能行为无关的 free-standing messages，这些消息会干扰模型推断和异常检测等下游任务。 |
| 核心方法 | LogPurifier：一种基于日志模板间依赖关系的任务无关日志清洗方法。 |
| 论文性质 | Registered Report。论文主要给出方法和实验计划，而不是完整实验结果。 |
➡️ 非官方复现进行中：https://github.com/HolgerZhang/LogPurifier
2. 研究动机
论文关注一种特定的日志噪声：free-standing log messages。它们不是执行工作流的一部分，而是独立出现的运行状态、心跳、资源状态等消息。典型例子是周期性的 memory OK。它们可能被夹在正常业务事件之间，破坏日志序列结构，让模型推断学到错误状态转移，或让异常检测模型看到不稳定的事件组合。
| 消息类型 | 含义 | 对下游任务的影响 |
|---|---|---|
| regular messages | 描述系统功能行为和执行流程 | 应保留，用于恢复状态转移、判断正常/异常模式 |
| free-standing messages | 不依赖前驱或后继事件，常表示运行状态或运维信息 | 可能随机夹入业务序列，使模型看到伪转移、伪模式或额外计算负担 |
作者希望日志清洗不绑定某一个下游任务，因为模型推断和异常检测使用日志的方式不同。LogPurifier 因此只依赖日志模板之间的结构关系，不使用源代码、任务标签或异常标签。
3. 方法总览：LogPurifier
LogPurifier 的输入是日志集合 L 和日志模板集合 T，输出是移除 free-standing 消息后的清洗日志 Lcl。方法的关键直觉是：regular template 往往与其他模板形成稳定的前后依赖，而 free-standing template 随机插入，和其他模板之间的依赖分数较低。
| 阶段 | 输入 | 输出 | 目的 |
|---|---|---|---|
| 依赖分数计算 | 日志集合 L、模板集合 T | 每个模板的 mScore | 衡量模板是否至少与某个其他模板稳定相关 |
| 聚类式分割 | 所有模板的 mScore | free-standing 模板集合 Tfs | 自动找到低依赖模板簇 |
| 日志清洗 | 原始日志 L、Tfs | 清洗日志 Lcl | 删除独立插入的模板消息 |
4. 步骤一：依赖分数计算
4.1 为什么要看双向依赖
论文不只判断模板 x 是否经常跟在 y 前面，也判断 x 是否经常跟在 y 后面。前者称为 forward dependency，表示 x 可能是 y 的原因；后者称为 backward dependency，表示 x 可能是 y 的结果。这样能覆盖“x 导致 y”和“x 由 y 引出”两种关系。
4.2 first-following log entry
给定模板 x 的一次出现 ex，论文寻找模板 y 在 ex 之后、下一次 x 出现之前的第一次出现 ey。这个 ey 称为 ex 的 first-following log entry。这个定义避免了无限向后搜索，也让相邻业务转移更容易得到高分。
4.3 co-occurrence score
如果 ey 存在，则 co-occurrence score 定义为 1 / distance(ex, ey, l)。距离越近，分数越高；如果不存在 first-following entry，则分数为 0。这样，立即跟随的事件会得到 1，隔得越远依赖越弱。
| 概念 | 定义 | 作用 |
|---|---|---|
| cScore(ex, ey, l) | 1 / distance(ex, ey, l)，无 ey 时为 0 | 衡量两次日志事件在同一条日志中的接近程度 |
| dScoref(x, y, L) | 所有 x 出现对应的 cScore 平均值 | 衡量 x 被 y 跟随的稳定程度 |
| dScoreb(x, y, L) | 等价于在反转日志上计算 forward score 即dScoref (x, y, rev(L)) | 衡量 x 被 y 前置的稳定程度 |
| dScoreCalc(x, y, L) | 依赖分数，max(dScoref, dScoreb) | 取双向依赖中较强的一侧 |
| mScore[x] | x 与所有其他模板依赖分数的最大值 | 判断模板 x 是否至少与某个模板强相关 |
论文选择最大值，因为一个 regular template 只要与至少一个模板形成稳定依赖，就不应被判为 free-standing。相反，free-standing template 通常与所有其他模板都缺乏稳定关系，因此最大依赖分数也偏低。
5. 步骤二：聚类式模板分割
得到每个模板的 mScore 后，LogPurifier 使用 Mean-Shift 聚类。作者不预先设定簇数，因为 regular templates 本身也可能形成多个分数层级。如果使用固定二分类阈值，容易受系统规模和日志结构影响。Mean-Shift 能根据 mScore 分布自动形成簇。
聚类完成后，方法选择 mScore 最小的簇作为 free-standing templates。理由是：这些模板与其他模板之间最不稳定，最符合“独立插入”的噪声特征。最后，算法删除所有属于这些模板的日志消息。
| 设计选择 | 论文动机 |
|---|---|
| 使用 Mean-Shift | 不需要预设簇数，适合不同日志系统中未知的分数分布 |
| 选择最低 mScore 簇 | free-standing 模板应与其他模板依赖最弱 |
| 删除整类模板消息 | 清洗结果保持简单，直接减少下游任务输入中的独立噪声 |
6. 与已有方法的区别
| 方法 | 噪声定义 | 是否任务相关 | 关键差异 |
|---|---|---|---|
| LogSed | 基于时间加权控制流图识别异常诊断相关信息 | 偏异常诊断 | 只建模单向依赖，需要用户设置阈值和窗口参数 |
| LogBoost / LogCleaner | 围绕异常检测中有益/无益事件做筛选 | 任务相关 | 优化目标绑定异常检测，不一定适合模型推断 |
| LogAssist | 面向摘要的重复事件和共现子序列压缩 | 任务相关 | 重点是总结和压缩，不是保留执行行为结构 |
| LogPurifier | 结构上独立、与执行行为弱相关的 free-standing templates | 任务无关 | 双向依赖 + 自动聚类，无需下游任务标签或源代码 |
7. 实验设计
由于本文是 Registered Report，重点是预注册的评估方案。作者计划从有效性和效率两个方面评估清洗前后的差异。
7.1 研究问题
- RQ1：使用 LogPurifier 清洗日志后，下游任务工具的有效性如何变化？
- RQ2：使用 LogPurifier 清洗日志后，下游任务工具的效率如何变化？
7.2 模型推断任务
模型推断部分使用 MINT，从至少 11 个公开 FSM 系统模型生成日志。原始生成日志只包含 regular messages，作者再随机插入 free-standing templates 作为可控噪声。噪声率从 0.1 到 0.9，且每个系统重复 30 次，以减少随机生成和噪声注入带来的偶然性。
| 工具 | MINT |
| 数据 | 由公开 FSM 模型生成的执行日志 |
| 噪声构造 | 随机插入 free-standing templates，对应噪声率 0.1 到 0.9 |
| 有效性指标 | 推断模型的 cumulative precision 与 cumulative recall |
| 效率指标 | MINT 执行时间 |
7.3 异常检测任务
异常检测部分使用 BGL、Thunderbird、Spirit 等真实系统日志。作者计划使用 Drain 解析日志模板，用固定时间窗口切分序列，并测试 60、100、120、300、600、1800、3600 秒七种窗口大小。异常检测工具包括 invariant mining 和 one-class SVM，通过 Loglizer 实现。
| 工具 | Invariant Mining、OC-SVM，基于 Loglizer |
| 数据 | BGL、Thunderbird、Spirit，可能加入更多公开数据集 |
| 预处理 | Drain 日志解析 + 固定时间窗口切分 |
| 清洗方式 | 在训练集上识别 free-standing templates，再从训练集和测试集同时删除这些模板 |
| 有效性指标 | precision、recall、F1-score |
| 效率指标 | 训练时间 |
8. 统计分析计划
作者计划对 MI 和 AD 分别分析，每个结果指标单独建模。由于同一系统会在多个配置下反复测量，并且清洗前后是一组配对观测，论文将使用线性混合效应模型。系统作为随机效应，是否清洗作为主要固定效应，噪声率、窗口大小、工具类型等作为额外固定效应。如果 LMM 假设不满足，作者会考虑数据变换或广义模型。
对于效率，作者还计划做探索性中介分析，估计运行时间变化中有多少可以由输入模板数量减少解释。这一点很关键，因为清洗可能同时改变数据规模和数据结构，运行变快不一定完全来自模型更容易学习。
9. 方法优势与局限
| 方面 | 说明 |
|---|---|
| 优势 | 黑盒、任务无关、不需要源代码、不需要人工阈值，适合先作为日志分析前处理步骤。 |
| 方法假设 | free-standing templates 与其他模板依赖弱，regular templates 至少与某些模板存在稳定前后关系。 |
| 潜在风险 | 某些低频但关键的业务事件可能被误判为 free-standing；某些周期性业务行为也可能表现为低依赖。 |
| 验证限制 | 论文明确不直接评价 LogPurifier 是否完美识别 free-standing messages，因为任务无关的 ground truth 很难定义；它评价的是清洗后下游任务是否受益。 |
10. 对 AIOps / 日志研究的启发
这篇论文把日志噪声问题从“异常标签是否正确”转向“日志序列本身是否夹杂与执行行为无关的信息”。它适合作为日志分析 pipeline 的前处理模块，尤其适合模型推断、序列异常检测、流程挖掘这类依赖事件顺序的任务。
对后续研究来说，值得进一步探索的问题包括：free-standing template 的判别是否能结合语义信息；是否能保留某些对运维诊断有用但对行为建模有害的消息；以及清洗策略是否应根据下游任务目标做可控调节。
总结：LogPurifier 把日志模板之间的前后共现关系转成依赖分数，用 Mean-Shift 自动找出低依赖模板簇，并删除这些疑似 free-standing messages，从而让下游日志分析工具面对更接近系统功能行为的序列。
思考
1. LogPurifier 使用 Mean-Shift 聚类之后，怎么选最小的簇？
Mean-Shift 是在一维数轴上聚类。聚类完成后，每个模板会被分配到一个簇，每个簇对应一个中心。LogPurifier 选择的是簇中心最小的那个簇，也就是 mScore 最低的一组模板。
2. 一维聚类会不会有问题？是否存在重叠或边界模板被误删除的情况？
LogPurifier 使用一维 mScore 聚类，本质上依赖一个假设：free-standing templates 的 mScore 明显低于 regular templates。如果这个假设不成立，确实可能出现边界模板被误删的情况。
理论上，一维 Mean-Shift 得到的最低簇应该对应 mScore 最低的一段连续区间。因此，如果出现 mScore 为 0.31 的模板被删除，而 mScore 为 0.29 的模板被保留，就说明实现或聚类结果不符合 LogPurifier 的语义。更稳妥的做法是根据 cluster center 生成删除阈值，删除低于该阈值的前缀模板，而不是机械相信可能交叉的 cluster label。