模板生成与待治理清单

2026-10-11 · 用户已确认（第 10 节六条同日定下）· 同日已实施，kb、平台、meta 都在本地 main、未推送；实施记录、实施时定下的细节和下一步见第 11 节 · 范围：静态模板生成、两层模板号、噪音标记、去掉冲突，以及这一阶段的产出——给治理智能体的待治理清单

1. 为什么要改

中债 8 份告警去掉客户模板号、让 kb 自己生成模板号后，在两份以上出现的客户模板共 154 个：91 个每份拿到的模板号都相同，19 个部分沿用，44 个在某一份全换了新号。生成的 520 个模板里有 42 个混进了多个客户模板，覆盖 45% 的告警。

逐个复算后，换号有两类原因。一类是内容本来不同（不同的日志行、不同的巡检项），按静态规则就该分开，靠调参数或治理阶段合并。另一类是代码逻辑的缺陷：

2. 已定的决定（2026-10-10、10-11 用户）

3. 模板生成（算法包 2.0.0）

3.1 变量剔除

1. 受保护的错误码先藏起来，最后原样放回。库设置里的列表 + 语义约定里的「错误码格式」。
2. 按占位符表的顺序逐条替换。
3. 空白合成一个空格。

不再有 <OBJ> 这一步。变体（同一模板下的不同写法）的骨架原来也先去掉本条告警自己的标识，同样去掉（T12）：骨架 = 告警内容里的中文短语（按出现顺序）+ 命中的受保护错误码（去重排序）。已改（2026-10-11 用户，算法包 2.1.0）：变体 = 同一模板下剔除变量后的文本，文本不同就是不同变体，和告警用什么语言写无关（11.2）。

3.1a 全部规则一览（T11）

静态阶段只有下面这些规则，都在「设置 › 模板生成」卡片里展示、可改，内置值预填，代码里不另有判断：

变体的分法也在卡片里写明，本期只展示，不做参数。2.1.0 起变体按剔除变量后的文本分，用的就是卡片上这套规则。

3.2 匹配与模板号

对一批告警：按（告警时间, 行号）排序，同一监控系统内逐条处理
  剔除变量后的文本 t，分词得到 tokens
  候选 = 本监控系统当前代次里不晚于这条告警建的模板
         （库里已有的按创建它的那条告警的（时间, 行号）算 + 本批前面新建的）
  对每个候选 c（代表文本 r，分词 rt）：
      关键词序列不同 → 跳过（开关，默认开）
      相似度 = LCS(tokens, rt) ÷ max(len(tokens), len(rt))
  取相似度 ≥ 阈值里最高的；并列取最早创建的 → 这条告警的模板
  一个都没有 → 新建模板：代表文本 = t，模板号 = s: + sha1(监控系统 + t) 前 12 位

候选很多时，先用「共有词数 ÷ 较长一方词数」这个上界和长度比筛掉不可能的，再算 LCS，结果不变。

确定性保证：一条告警分到哪个模板，只取决于它自己和比它早的告警。所以同一批数据按时间任意切分摄入、同一批数据再摄入一次，每条告警的模板号都和一次性摄入相同。这条写成单测。

只比不晚于本条告警建的模板（实施时定，2026-10-11 用户）：原稿的候选是「当前代次的全部模板」。实测同一批再摄入时，比这条告警晚建、和它更像的模板也成了候选，中债 28618 条里有 108 条换号，不满足 8.1 的 A1。改为只比不晚于本条告警建的模板之后，两种比较都是 0 条不同。分组表为此加 origin_time、origin_row，记创建模板的那条告警的毫秒时间和它在文件里的行号；时间相同时才比行号，只在同一份文件内有意义。

已知限制：先摄入新数据、再补摄更早的数据时，早期告警只能匹配已有模板，不会回头改代表文本；补摄的结果和按时间顺序摄入可能不同。

展示文本：模板页面显示的泛化文本（不同之处记 <*>）由成员样本算出来，只展示，不参与匹配。分组表的 signature 列存代表文本，template_text 存展示文本。

客户数据带模板号时照旧直接用，不走这一节。

4. 参数设置

放在「告警主题 › 设置」页签末尾，新加一张卡片「模板生成」，每个库一份，内置值预填。

参数存在告警主题的设置里（template 一段）。没有保存过的库用内置值；保存后整套存下，页面看到的就是生效的。正则保存前校验能否编译；预览和摄入用同一套代码。

4.1 改参数

改占位符、关键词、阈值，代表文本和相似判定都会变，模板号跟着变，新旧模板之间没有确定的一一对应，所以换一代。流程同全局提取规则的 D3a：

1. 预览：新参数下会分成多少个模板。
2. 显示影响：作废多少分组、多少条已确认的解析规则。
3. 输入库代号，保存后换一代。
4. 自动用保留的上传文件重新摄入近 7 天，新一代不是空的。
5. 已确认的解析规则带到新一代，状态为待确认：旧分组的告警在新一代落到哪个模板，就把规则挂成待确认版本，由人重新确认。

用客户模板号的库只有展示文本会变，不换代。

5. 两层模板号与模板合并

5.1 数据结构

父节点的号在合并确认时生成，m: + 哈希（监控系统 + 合并记录 ID），之后不变。结构固定两层：只在同一监控系统内合并；父节点不能再有父节点；把模板并进已有父节点就是加成员；两个父节点合并时一边的成员挂到另一边，空了的父节点作废。

5.2 作用域：哪里取有效模板号

5.3 发起与审批（T13、T17）

合并记录只有一个创建接口：给出同一监控系统下的几个模板号（可以含已有父节点）、合并依据，可附正则和样本引用作证据。请求带「直接确认」时创建即生效，不带时是一条待确认记录。

• 人：解析规则列表多选模板 →「合并」→ 对话框列出成员的模板号、展示文本、条数，填依据 →「确认合并」。一步完成，不经过待确认。
• 治理智能体：调同一个接口、不带「直接确认」，请求进「待确认 › 模板合并」，人在抽屉里看成员的展示文本和样本、依据、证据，确认或驳回。
• 已确认的合并可以在父节点的抽屉里撤销。
• 成员各有已确认的解析规则时，确认前必须选定保留哪一条（或带上合并后的规则一起确认）。
• 治理智能体的身份只能创建待确认记录，不能直接确认。

6. 噪音

• 去掉「告警主题 › 噪音」页签、待确认里的「噪音」一类、噪音审批和噪音规则表；待治理清单去掉「噪音候选」。
• 解析规则列表和规则抽屉里加「标记为噪音 / 取消」，填一句说明，立即生效、不审批，记下操作人和时间。标在有效模板上，父节点标了等于全部成员都标了。
• 分析时剔除这些模板的告警，结果包里完全不出现，简报也不写（T14）。摄入照旧统计，取消标记后之前的数据还在。
• 标为噪音的模板不进待治理清单。

7. 冲突、「依赖候选」与待确认页签

• 去掉冲突：摄入时不再把标识、关系标为冲突，去掉冲突列表、裁决接口和待确认里的「冲突」页签。中债两个试跑库里的 335 条冲突基本都是假冲突（占位 IP 0.0.0.0 挂在多台主机上；应用集群对象运行在多台主机上）。
• 「依赖候选」改名为「对象关系」（T16），页签保留。现在没有任何代码会产生它，等治理智能体提对象之间的关系后再优化。

待确认的页签（T18）：

8. 待治理清单（这一阶段的产出）

治理智能体经 worklist 读，kb 读取时现算、不存表。改完后的内容：

分组详情另由按分组查询的接口取：样本（每条带全局规则取到的各字段值）、变体、统计。

8.1 功能正确性（有确定的通过条件）

这一节的结果由逻辑决定，每条写明检查方法和通过条件，全部通过才算验收。效果好坏和处理速度现在定不了标准，放在 8.2 只记录。单测只用虚构数据（seed 7 和单测里内联的数据），中债数据只在本机跑，结果写进 daily_task/rca/中债/trial-results.md。

A10 待治理清单的明细（库 B：8 份中债告警去掉模板号、按时间逐份摄入；先人工标 1 个模板为噪音、合并 1 组模板、驳回 1 组的解析规则两次，再取清单）：

1. new 的条目数 = 解析规则列表里「规则状态为仅全局、未标噪音」的有效模板数（父节点折叠成员）。
2. 被合并的成员不单独出现，父节点作为一项出现，带成员模板号；被标噪音的模板不出现；连续驳回两次的那组在 manual 里，不在 new 里。
3. 每项都有：监控系统、模板号、代表文本、展示文本、首末次、告警条数、没有对象的条数、要提取的字段、最近一次驳回说明（没有时为空）、相似模板。
4. 排序：没有对象的条数大于 0 的全部排在前面，各段内按告警条数从多到少；脚本逐项检查相邻两项。
5. 要提取的字段 = 模板层能写的标准字段 − 本监控系统全局规则已覆盖的字段；脚本按库里的全局规则重算后逐项相同。
6. 相似模板：每项不超过 3 个，都在同一监控系统、相似度低于阈值、按相似度从高到低；脚本用同一套参数独立重算后相同。
7. 告警条数、没有对象的条数与该模板在小时统计里的合计相同（注意 35 天保留只算仍在保留期内的天）。

8.2 效果与性能（现在定不了标准，只写内容和方法，结果照实记录）

这些结果取决于参数和数据，现在没有依据定门槛。实施后按下表的方法测，记进本机 trial-results.md，用户看过记录后再定标准或调参数。中债都用重建的库 B（8 份去掉模板号、按时间逐份摄入、内置参数）。

9. 影响面

10. 原未决问题的结论（2026-10-11 用户）

11. 实施记录与交接（新会话从这里开始）

11.1 已实施（2026-10-11，都在本地 main，未推送）

本机部署：迁移前快照 .runtime/backups/kb-20261010T231656Z（UTC 时间命名），kb 迁到 0092，清空全部 21 张 tb_sem_* 和旧语义库的存储目录，平台前端重新构建。当前的中债库 B 是 zz-gen-20261011：8 份去掉模板号、按时间逐份摄入、内置参数，只有静态处理的结果，没有任何确认、合并、标记。端到端用例跑三遍留下 6 个虚构库（3 个 sem-ui-*、3 个 sem-ro-*），都已停用，照惯例保留。库 ID 在本机 daily_task/rca/中债/v2/results/state.json。

验收：8.1 的 A1–A11 全部通过，8.2 的 B1–B5 已测完，数字记在本机 daily_task/rca/中债/trial-results.md 第 5 节。汇总：

• A1：中债 28618 条，逐份带已有模板处理、合成一份一次处理、kb 库 B 逐份摄入、同一批再摄入一次，四种做法每条模板号都相同。
• A2：58 次换号都能用规则解释（相似度低于阈值 36 次，关键词序列不同 15 次，匹配到更像的另一个模板 7 次）。
• A10：在纯静态的库 B 上，独立脚本直接读 kb 的表重算清单，539 项逐项一致。
• B1：两份以上出现的客户模板 154 个，每份号都相同 / 部分沿用 / 全换新号由 91 / 19 / 44 变为 103 / 23 / 28；生成模板 539 个（改前 520）；混进多个客户模板的生成号 41 个、覆盖 41.6% 的告警（改前 42 个、45%）。阈值 0.6–0.9 的对照在 B3。
• B5：3 月那份 9056 条摄入 67–71 s（改前 99 s）；设置卡片预览 3–6 s；换代到 8 份重新摄入做完约 170 s。确认解析规则、确认合并的耗时属于治理阶段，记在 docs/semantic-confirm-and-merge-flow.md。

测试：kb semantic 单测 159 passed（63 个 PostgreSQL 专用用例在 sqlite 下跳过），PostgreSQL 回归 63 passed，平台 semantic 单测 57 passed，端到端用例 2 passed。

变体改口径（2.1.0，11.2）之后：kb semantic 单测 163 passed（65 个在 sqlite 下跳过），PostgreSQL 回归 64 passed，平台 semantic 单测 58 passed。库 B 先拍快照 .runtime/backups/kb-20261011T055546Z，删掉后按同样做法重建（代号不变）：变体 1997 个，和离线算的一致；模板号与离线逐条比 0/28618 不同，A10 清单 539 项独立脚本 0 处问题，和改口径前相同。数字在 trial-results.md 5.3 节。

去掉通用目标抽取（2.2.0，11.2）之后：kb semantic 单测 164 passed（65 个在 sqlite 下跳过），PostgreSQL 回归 64 passed，平台 semantic 单测 62 passed。合成数据里三处调用失败（URL、target=、jdbc:）改由规则的 relations 写明，测试改走规则这条路。库 B 拍快照 .runtime/backups/kb-20261011T064917Z 后删掉重建（代号不变）：模板 539、变体 1997、样本 3955、对象 2941，和 2.1.0 相同；未解析目标由 363 个变为 0，调用失败关系 0（2.1.0 也是 0）；模板号与离线逐条比 0/28618 不同，B1 仍是 103 / 23 / 28，A10 清单 539 项 0 处问题。

11.2 实施时定下的细节

标「用户」的由用户在实施中决定（2026-10-11），其余是方案没写、按方案意图定的缺省做法。

11.3 已知问题与下一步

• 确认规则、确认合并超过代理超时（治理阶段）：确认规则约 96 s、确认合并约 86 s（保留 8 份文件时）。流程、耗时拆分、问题和可选改法见 docs/semantic-confirm-and-merge-flow.md，第 2 期治理工具接批量确认之前要定。
• ops-skills 里的算法包副本还是 1.2.0。kb 现在导出的快照是 2.2.0，副本按主版本不一致拒用快照（major_mismatch）。第 4 期同步副本前，本地按快照处理用不了。
• 导入带 template 一段的配置。库里有 kb 生成的模板时会触发换代、要库代号；导入的差异预览（dry-run）没有提示这一点。
• 补摄更早的数据（3.2 已知限制）照旧：已经分好的晚期告警不会回头改。
• W1 文档同步已做完（2026-10-11）：数据标准、设计、总纲、流程稿（4.5、4.8a 节）、语义管理界面方案（文首「2026-10-11 同步」）、交接文档文首。下一步是第 2 期，见交接文档。