P4 Gotham

模式识别：让系统替你盯异常

人工盯数据总有看不过来的时候。模式识别把“什么叫异常”写成规则：frequency（时间窗口内事件频次超阈值）与 anomaly（属性值超阈值），评估命中后生成告警级命中记录，再走“确认 → 处置”闭环。看完这 4 个故事，你就能把“30 天 3 起 incident”“金额超 10 万”这类业务直觉变成系统自动盯守的规则。

风控分析师情报分析师 frequency anomaly 命中处置共 4 个故事

能 / 不能速览

✅ 这个主题能做

定义 frequency 频次规则：时间窗口（window_days）内指定事件类型数 >= min_count 触发
定义 anomaly 异常规则：对融合实体 / 时间轴事件属性做 gt / lt / gte / lte / eq 阈值比较，也可用 target=geo 做区域密度、target=graph 做 degree_burst / orphan_burst 拓扑异常评估
单条规则评估（evaluate）与全量评估（evaluate-all），命中自动写 PatternHit
命中列表按状态 / 规则过滤，状态机 open → acknowledged → resolved 走完处置闭环
命中幂等去重：同规则 + 同证据的 open 命中不重复写

⛔ 这个主题做不了

规则类型仅 frequency / anomaly / association 三种，图模式 / 时序 / 组合规则属 V2
geo / graph 目标只对 anomaly 开放：frequency / association 仍仅评估 entity / timeline
AI 图模式异常推理关闭，检测是"规则 + 统计"的确定性逻辑，没有自学习
命中状态流转严格：open 才能 acknowledge；已 resolved 的命中再 resolve 会报非法流转
告警实时推送仅到在线 WebSocket 连接（alert.created 全局广播），无按用户定向通知、不建工单，协同派单属 V2

适用角色

本主题面向两个角色：

风控分析师（核心）：把资金阈值、事件频次等业务直觉固化成规则，评估命中并处置告警，是"规则 → 命中 → 处置"闭环的主使用者。
情报分析师：用频次规则盯事件密度（如 incident 集中爆发），把模式识别结果作为专题研判的输入。

平台管理员负责规则启停与全局视角；决策者消费命中汇总与报告，不直接配置规则。

能力速览（能做什么）

规则管理

pattern_rules 定义 frequency / anomaly / association 三类规则，配置 JSON 化，支持启停与按名唯一。

单条评估

POST /patterns/rules/:id/evaluate 跑一条规则，返回 matched / count / evidence / hit_id，命中即落库。

全量评估

POST /patterns/evaluate-all 遍历全部启用规则，汇总 Total / Hit / Miss / Errors，单条失败不中断批量。

命中管理

PatternHit 记录规则命中，含 target_entity_id、evidence、count、severity，支持按 status / rule_id 过滤。

处置闭环

命中状态机 open → acknowledged → resolved：确认认领、处置关闭，全程留痕可回溯。

调整指南（怎么调整）

改频次阈值：frequency 规则里调 window_days（窗口天数）与 min_count（触发下限），比如"7 天 2 起"比"30 天 3 起"更敏感。
改异常口径：anomaly 规则里改 field / operator / threshold；可加 entity_type 限定只扫 person，或加 entity_id 盯单个对象。
改评估窗口：evaluate 用当前时间为窗口终点向后推 window_days 天；想回看历史窗口可关注服务端注入的窗口语义。
改命中视角：hits 列表支持 status=open / acknowledged / resolved 与 rule_id 过滤，把"待处理"单独拉出来排优先级。
改规则启停：规则禁用后评估会返回"规则已禁用，跳过评估"（matched=false），批量评估也会自动跳过禁用规则。

做得好的场景

模式识别把"异常直觉"变成"可执行规则"，特别适合以下场景：

事件密度预警：30 天内 incident 满 3 起自动触发，替代人工数事件、翻日志的重复劳动。
资金异常扫描：对融合实体金额做阈值比较，张远 20 万、赵敏 12 万一键命中，不用逐条查流水。
批量复检：evaluate-all 把所有启用规则一次性跑完，几秒出 Total / Hit / Miss 汇总，适合每天例行巡检。
处置闭环留痕：open → acknowledged → resolved 每一步都有状态变化，审计可回溯，告警不丢。

限制与不足

以下是明确的边界，使用前先知道：

规则类型有限：只有 frequency / anomaly / association；图模式匹配、时序、AND/OR/NOT 组合规则属 V2。
geo / graph 目标仅 anomaly 开放：anomaly 可评估 entity / timeline / geo（区域密度 GeoAnomalyConfig）/ graph（degree_burst / orphan_burst GraphAnomalyConfig），frequency / association 的目标仍是 entity / timeline。
确定性检测：规则 + 统计的确定性逻辑，AI 图模式异常推理关闭，没有机器学习自学习。
状态机严格：acknowledge 仅接受 open，resolve 仅接受 open / acknowledged，非法流转返回 GOTHAM_PATTERN_HIT_INVALID_TRANSITION（409）。
全局广播不定向：命中即经 WebSocket 推送给全部在线用户（alert.created 全局广播），但无按用户 / 按项目定向通知、不建工单，协同派单流属 V2。

场景故事

故事 1 风控小何建 frequency 规则："30 天内 3 起 incident 就预警"

场景：频次规则角色：风控分析师耗时：约 6 分钟

背景: 风控小何是玄武集团风控分析师。2026 年 8 月，她发现 7-25 上海货栈异常、8-06 广州港口检查、8-15 华南航线异常——一个月内 incident 事件连发。她要把"30 天内 incident 达到 3 起"这条直觉固化成规则，让系统替她盯，而不是天天翻时间轴数数。

传统做法对比: 以前每周五下班前她要手工翻一遍事件清单数 incident，一次 20 分钟，漏数、重复数都发生过；7-25 那批异常就是翻到第 8 天才发现已连发 2 起。规则化以后，评估一次几秒钟出结论。

角色: 风控分析师（风控小何），拥有模式规则创建与评估权限。

操作步骤

进入"模式识别"页面，点击"新建规则"
选择类型 frequency（频次），目标选 timeline
配置：window_days=30、min_count=3、event_type=incident，严重度选"高"
保存后对该规则发起评估 POST /patterns/rules/:id/evaluate

系统响应

评估返回：

{
  "rule_id": 3,
  "rule_name": "重点区域 incident 预警",
  "pattern_type": "frequency",
  "target": "timeline",
  "matched": true,
  "count": 3,
  "hit_id": 1,
  "evidence": { "event_ids": [...], "event_type": "incident",
                "window_start": "...", "window_end": "...", "min_count": 3 }
}

系统在窗口内统计 incident 事件数达到 3，命中并写入 PatternHit（hit_id=1）。

结果洞察: 窗口内的 3 起 incident（7-25 上海货栈异常、8-06 广州港口检查、8-15 华南航线异常）一次评估全数命中，count=3 与人工数一致。风控小何不用再手动数数，后续这类集中爆发会第一时间出现在命中列表里。

调整建议: 想更敏感就调成"7 天 2 起"；想限定单实体在 config 里加 entity_id；严重度建议跟着业务风险走，被高层关注的规则给"高"，例行巡检给"中"。

动手试一试: 登录：admin / admin1。页面路径：模式识别 → 新建规则。输入内容：pattern_type=frequency、target=timeline、config={"window_days":30,"min_count":3,"event_type":"incident"}。预期结果：评估返回 matched=true、count=3，命中列表出现 open 状态命中。

限制提示: 评估窗口以当前时间为终点向前推 window_days 天，命中与否取决于评估时刻；frequency 规则仅支持 target=timeline / entity；规则名全局唯一，重名创建会报错。

故事 2 建 anomaly 规则"融合实体金额超过 10 万"，张远 20 万一击命中

场景：异常规则角色：风控分析师耗时：约 5 分钟

背景: 玄武集团的演示人员情报源 gotham_demo_personnel 里预置了 5 条人员记录，其中张远挂了 20 万资金属性、赵敏挂了 12 万。风控小何想把"单笔资金超 10 万"变成自动异常检测，一条 anomaly 规则扫全部融合实体。

传统做法对比: 以前要在融合表里写 SQL 加 WHERE amount > 100000，再手动核对每个命中对象是否真的异常，一次约 15 分钟；换口径（比如改成 8 万）还要改脚本重跑。规则化后改阈值只是改一条配置，评估即出结果。

角色: 风控分析师（风控小何），创建 anomaly 规则并对 entity 目标评估。

操作步骤

进入"模式识别"，新建规则，类型选 anomaly（属性异常）
目标选 entity（融合实体），配置 field=amount、operator=gt、threshold=100000、entity_type=person
保存后评估该规则 POST /patterns/rules/:id/evaluate

系统响应

评估返回：

{
  "rule_id": 4,
  "rule_name": "融合实体大额资金异常",
  "pattern_type": "anomaly",
  "target": "entity",
  "matched": true,
  "count": 2,
  "hit_id": 2,
  "target_entity_id": "gotham_p_001",
  "evidence": { "field": "amount", "operator": "gt",
                "threshold": 100000, "matched": 2, "value": 200000 }
}

系统扫出 2 条超阈值记录（张远 20 万、赵敏 12 万），首条命中实体为张远。

结果洞察: 除了预期中的张远（20 万），赵敏（12 万）也被一并命中——这正是自动扫描的价值：人查容易漏，规则不会。风控小何把这条命中的两条实体放进关联核查清单，结合图上的 transferred_to 边看资金去向。

调整建议: 想只看单个人在 config 加 entity_id 限定；想更严格把阈值调到 15 万就只剩张远；想扫时间轴事件把 target 改成 timeline（属性在事件 Properties 里）。

动手试一试: 登录：admin / admin1。页面路径：模式识别 → 新建规则。输入内容：pattern_type=anomaly、target=entity、config={"field":"amount","operator":"gt","threshold":100000,"entity_type":"person"}。预期结果：评估 matched=true、count=2（张远 20 万 + 赵敏 12 万），首条命中 target_entity_id=gotham_p_001。

限制提示: anomaly 支持 target=entity / timeline / geo / graph（geo=区域密度、graph=degree_burst / orphan_burst 拓扑异常），但 frequency / association 仍只支持 entity / timeline；threshold 比较只认数值属性，字符串金额需先转数值；属性缺失或非数值的记录按不命中处理。

故事 3 evaluate-all 全量评估，命中列表一眼看清当天风险

场景：批量评估角色：风控分析师耗时：约 3 分钟

背景: 模式识别页面上已经挂着"高频事件预警"（frequency，30 天 3 起 incident）和"大额资金异常"（anomaly，金额超 10 万）两条演示规则，加上风控小何自己刚建的两条。她决定用批量评估把所有启用规则一次跑完，生成当天风险清单。

传统做法对比: 以前每条规则要单独跑、单独记结果，4 条规则来回切换 4 次，汇总还要复制粘贴到表格；现在一次 POST 全部评估完，命中 / 未命中 / 报错自动分门别类。

角色: 风控分析师（风控小何），执行批量评估并查看命中列表。

操作步骤

在"模式识别"页面点击"全量评估"
系统遍历全部启用规则逐条评估 POST /patterns/evaluate-all
查看命中列表 GET /patterns/hits，用 status=open 过滤待处理项
逐条核对规则名与 target_entity_id，确定当天处置优先级

系统响应

批量评估返回汇总：

{ "total": 4, "hit": 3, "miss": 1, "errors": 0 }

命中列表返回 PatternHit 数组：

[
  { "id": 1, "rule_id": 1, "count": 3, "severity": "高", "status": "open" },
  { "id": 2, "rule_id": 2, "target_entity_id": "gotham_p_001", "count": 2, "severity": "中", "status": "open" },
  { "id": 3, "rule_id": 4, "target_entity_id": "gotham_p_001", "count": 2, "severity": "中", "status": "open" }
]

errors=0 表示没有单条评估失败中断批量。

结果洞察: 4 条规则 3 命中 1 未命中：频率类两条都命中（时间轴 incident 连发），异常类张远 / 赵敏命中；有一条新规则未命中说明当前数据还没到阈值。风控小何按 severity 从"高"到"中"排了处置顺序，3 条 open 命中当天处理。

调整建议: 命中幂等去重：同规则 + 同证据的 open 命中不重复写，重复评估不会刷屏；用 rule_id 过滤看单条规则的命中史；把全量评估固定为每日例行操作，结果存档对比趋势。

动手试一试: 登录：admin / admin1。页面路径：模式识别 → 全量评估。输入内容：POST /patterns/evaluate-all。预期结果：返回 total / hit / miss / errors；GET /patterns/hits 按 status=open 过滤可看到全部待处理命中。

限制提示: evaluate-all 只遍历 enabled=true 的规则，禁用规则自动跳过；单条评估失败计入 errors 不中断批量，但 errors 不为 0 时需逐条排查；命中列表默认 limit 100，可分页。

故事 4 命中确认与处置：open → acknowledged → resolved 闭环

场景：处置闭环角色：风控分析师耗时：约 4 分钟

背景: 全量评估后风控小何手里有 3 条 open 命中。8 月 15 日上午她逐条处置：先确认"高频事件预警"这条是真实风险（认领），再核查"大额资金异常"里张远的 20 万资金去向，确认已纳入专项调查后关闭。整个流程要在系统里留下状态轨迹，审计可查。

传统做法对比: 以前异常靠 Excel 清单 + 微信口头确认，谁认领、谁处置、什么时候关闭全凭记忆，出了争议对不上账。现在每条命中有独立状态机，流转一步记一步，回看历史一目了然。

角色: 风控分析师（风控小何），对命中执行确认与处置；管理员可查看全部命中与状态轨迹。

操作步骤

在命中列表选中 open 状态的高频事件命中，点"确认"
确认后状态变 acknowledged（已认领），POST /patterns/hits/:id/acknowledge
核查张远 20 万资金去向与 incident 事件详情，确认已处理
对该命中点"处置"，状态变 resolved，POST /patterns/hits/:id/resolve

系统响应

确认返回：

{ "code": 0, "data": { "id": 1, "status": "acknowledged" } }

处置返回：

{ "code": 0, "data": { "id": 1, "status": "resolved" } }

再次 GET /patterns/hits?status=resolved 可查到已关闭命中及其 severity / count。

结果洞察: 3 条 open 命中 2 条确认后处置关闭（resolved），1 条保持 acknowledged 待继续跟踪。状态机让"谁在何时确认 / 处置"全程留痕，月底复盘直接把 resolved 列表拉出来就是一张处置台账。

调整建议: 误报的命中不要直接 resolve 了事，保留一条记录说明原因更利于复盘；确认后想改回 open 不支持（状态机单向），但可以新建命中继续跟踪；用 rule_id + status 组合过滤做"单条规则的处置达成率"。

动手试一试: 登录：admin / admin1。页面路径：模式识别 → 命中列表。输入内容：POST /patterns/hits/1/acknowledge 再 POST /patterns/hits/1/resolve。预期结果：状态依次返回 acknowledged、resolved；hits?status=resolved 列表出现该命中。

限制提示: 状态机严格单向：acknowledge 仅接受 open（其他状态返回 409 GOTHAM_PATTERN_HIT_INVALID_TRANSITION），resolve 仅接受 open / acknowledged；已 resolved 的命中不可再流转，需要重开就新建命中。

常见问题

规则命中会重复刷屏吗？

不会。命中写入有幂等去重：同一条规则 + 同一份证据（evidence JSON）的 open 命中不重复写，重复评估返回已有 hit_id。确认或处置后的命中不再参与幂等比较，可重新产生新命中。

frequency 和 anomaly 怎么选？

frequency 看"数量"：时间窗口内某类事件出现的次数（如 30 天 3 起 incident），目标是时间轴事件；anomaly 看"数值"：某个属性是否越过阈值（如金额超 10 万），目标是融合实体或事件属性。两个可以搭配用，一个盯频次、一个盯金额。

命中评估会改数据吗？

评估只读数据、只写命中记录（PatternHit），不会修改图、融合表或时间轴里的原始数据。命中记录本身带 evidence 快照，证据是什么、统计了多少条都留在命中里。

规则为什么不支持"图模式"？

当前是"规则 + 统计"的确定性检测。要注意：anomaly 现已可对图做拓扑异常评估（target=graph 的 degree_burst / orphan_burst，即"统计性图异常"），frequency / association 也仍覆盖主要告警场景；真正"图模式（motif）匹配"、时序组合、AND/OR/NOT 组合规则以及 AI 图模式异常推理才属 V2。

命中告警会自动通知吗？

会实时推送给在线用户：命中创建即发布 alert.created 事件，经 WebSocket 全局广播（{"type":"alert","data":...}），所有在线连接实时收到。但广播是全局的（不区分用户 / 项目），也没有工单与定向派单，协同处置工作流属 V2 范围。当前闭环是"评估 → 命中 → 确认 → 处置"四步。

主题小结

一句话：模式识别的用法是"把业务直觉写成规则 → 单条或批量评估 → 命中进列表 → 确认处置走闭环"。记住三个边界：规则类型只有 frequency / anomaly / association、anomaly 的目标已扩到 entity / timeline / geo / graph（geo / graph 仅 anomaly 开放）、命中状态机单向严格。会建规则、会跑评估、会处置命中，你就能让系统替你 24 小时盯异常。