企业官网建设流程全解析

标签收进体系之后，挖掘的第一个大规模消费方登场——规则挖掘引擎。它的定位很明确：挖掘漏斗的第一层过滤器。业界做 corner case 挖掘的主流范式是「规则先验粗筛 + 模型不确定性细筛」两级漏斗：先用低成本的规则从海量数据里圈出候选，再让昂贵的模型去精挑。华为 ADS 的数据闭环同样以规则挖掘作为第一层过滤器，控制下游算力开销。

本篇拆解这套引擎的三件事：规则怎么定义（规则即数据）、规则有哪六大种类（附真实示例）、规则怎么跑（批流双模执行链路）。

一、规则即数据：配置也是湖仓资产

第一个设计决策是「规则即数据」：规则配置存在挖掘平台的 MySQL，经 Flink CDC 实时同步入湖（ods_mining_rule_config）。规则不是散落在代码里的 if-else，而是与业务数据一样可查询、可追溯、可审计的湖仓资产——谁在什么时候改了什么规则，一查便知。

规则的表达与管理能力：

• 双模式表达：SQL 条件 + 可视化配置——工程师写 SQL，业务同学拖配置，产出的规则等价；可组合标签、GPS 范围、时间、传感器信号、模型输出等多类条件；

• 全生命周期管理：创建 / 修改 / 禁用 / 优先级 / 版本，变更全程留痕；

• 优先级驱动下游：rule_priority 不只是排序字段——它直接决定 Embedding 与存储分级，高优先级规则命中的数据优先进入向量化队列，与前面讲的成本分级打通；

• 执行追溯：每次执行记录执行时间、扫描范围、命中数量、写入标签量，回写 dwd_mining_task_detail——规则的效果可度量，而不是配完就黑盒。

二、六大种类：真实规则长什么样

规则按条件来源分六大种类，覆盖从静态标签到实时信号的完整谱系。挑几条代表性的看：

注意两个设计细节：所有命中统一经标签服务打标，携带 rule_id 血缘——规则挖掘的产出自动继承上篇讲的字典映射、去重与审核体系，不需要规则引擎自建一套标签写入逻辑；执行模式跟着条件来源走——静态标签与时空条件走 T+1 批，车辆信号与事件流走准实时，不是一刀切。

三、批流双模：执行与调度链路

执行链路一图看懂：规则配置经 CDC 入湖后，分两条腿跑，命中结果汇合：

• T+1 批处理：Spark SQL 直接在 Paimon 表上执行，亿级以下数据 4 小时内跑完；复杂规则挂自定义 UDF，表达力不受限；

• 准实时流：事件类规则以 Flink 消费触发事件流，近实时打标——接管、AEB 这类事件不用等第二天；

• 增量扫描：基于 _ingest_time / update_time 水位做增量，避免每次全表回扫——规则天天跑，成本不爆炸的关键；

• 结果双写：命中结果一律经统一标签服务写入标签表（完成字典映射与去重），同时写 dwd_mining_result_detail 供回补闭环消费。

链路里还有一条隐藏的联动：事件命中会异步触发补抽帧——这正是前面抽帧篇讲的「事件抽帧依赖规则结果」的闭环：规则识别出接管事件，事件抽帧引擎立刻回头对前 15 后 5 秒窗口加密采样，两个引擎经湖仓表解耦协作，谁也不阻塞谁。

四、规则挖到了，然后呢

把规则挖掘放回全景看，它的价值在漏斗位置：规则先验粗筛 → 模型不确定性细筛 → 检索相似性扩散。规则引擎以几乎为零的边际成本扫完全量元数据，把「疑似高价值」的候选圈出来；VLM 推理再对候选里信息密度最高的帧做语义确认（下篇讲）；语义检索最后把相似场景扩散成完整数据集。三级之后，才轮到昂贵的训练集构建。

📌 本篇要点回顾：① 规则即数据——配置经 CDC 入湖，可追溯可审计；② 六大种类规则覆盖标签组合到实时信号，命中统一经标签服务打标；③ 批流双模：T+1 Spark SQL 扫存量、Flink 准实时接事件，水位增量防全表回扫；④ 规则是第一层过滤器，与模型细筛、检索扩散组成三级漏斗。

规则引擎再强，也有够不着的地方：「施工区锥桶摆放混乱」「行人撑着花伞」这类语义级场景，结构化条件写不出来——这正是大模型推理挖掘的领地。下篇讲 VLM 推理引擎：选帧打分、双输出（标签 + caption）、Ray + GPU 调度与断点续跑，长尾场景的标签它来补。