2. 冲突类型分类
在特征工程与规则引擎的联合开发中，冲突并非单一形态。根据冲突产生的根源与表现形式，可将其归纳为三大核心类型：数据冲突、逻辑冲突与时效冲突。准确识别冲突类型是制定处理策略的前提。
2.1 数据冲突：特征值不一致
数据冲突是最常见的冲突类型，指同一实体在不同数据源、不同处理链路或不同时间窗口下，其特征值出现不一致。这种冲突直接破坏规则引擎的判定基础。
| 冲突子类 | 典型场景 | 示例 |
|---|---|---|
| 源系统不一致 | CRM 与订单系统的用户等级字段不同 | CRM 标记“VIP”，订单系统标记“普通” |
| ETL 管道偏差 | 实时流与离线批处理对同一特征的聚合口径不同 | 实时近 30 天消费金额 vs 离线 T-1 全量汇总 |
| 缺失值填充策略 | 不同特征工程模块对空值的默认值不同 | 模块 A 填充 0，模块 B 填充均值 |
关键指标：数据冲突通常可通过特征值交叉比对发现，建议在规则引擎入口处设置特征值校验层，对关键特征进行一致性断言。
2.2 逻辑冲突：规则矛盾
逻辑冲突指规则引擎内部或规则与特征之间的判定逻辑存在直接矛盾，导致同一输入条件下产生互斥的输出。这类冲突隐蔽性强，往往在线上运行时才暴露。
- 互斥条件：规则 A 要求“年龄 > 30 且 收入 < 10000”触发优惠，规则 B 要求“年龄 > 30 且 收入 < 10000”拒绝交易，两条规则同时命中时产生矛盾。
- 优先级覆盖：高优先级规则未完全覆盖低优先级规则的所有分支，导致部分场景下优先级反转。
- 特征依赖循环：规则 A 的输出作为特征 B 的输入，特征 B 又反向影响规则 A 的判定条件，形成逻辑死锁。
避坑提示：逻辑冲突无法通过数据校验发现，必须依赖规则依赖图（Rule Dependency Graph）进行静态分析。建议在规则部署前执行全量组合测试。
2.3 时效冲突：新旧规则/特征版本不匹配
时效冲突源于系统演进过程中，特征版本与规则版本的生命周期不同步。当新规则引用了已废弃的特征，或旧特征被新规则错误依赖时，冲突随即产生。
| 冲突子类 | 产生原因 | 典型后果 |
|---|---|---|
| 特征版本滞后 | 规则已升级到 v2，但特征仍使用 v1 的生成逻辑 | 规则判定依据过时特征，准确率下降 |
| 规则版本超前 | 新规则引用了尚未上线的特征字段 | 运行时特征缺失，规则降级或报错 |
| 灰度期错配 | 部分流量使用新特征，部分流量使用旧规则 | 同一用户在不同请求下得到矛盾结果 |
最佳实践：建立特征-规则版本映射表，每次规则发布时自动校验所依赖的特征版本是否在有效期内。推荐使用语义化版本号（SemVer）进行关联管理。
2.4 冲突类型全景图
下图展示了三种冲突类型在特征工程与规则引擎交互链路中的产生位置与影响范围。
2.5 冲突类型对比总结
| 维度 | 数据冲突 | 逻辑冲突 | 时效冲突 |
|---|---|---|---|
| 根因 | 特征值不一致 | 规则判定矛盾 | 版本生命周期错配 |
| 发现时机 | 运行时 / 数据校验 | 测试阶段 / 静态分析 | 部署时 / 灰度期间 |
| 影响范围 | 单条规则判定结果 | 多条规则组合结果 | 全量规则与特征匹配 |
| 修复成本 | 低（修正特征管道） | 高（需重构规则逻辑） | 中（版本回滚或升级） |
| 预防手段 | 特征值校验层 | 规则依赖图 + 全量测试 | 版本映射表 + 部署门禁 |
核心结论：三种冲突类型并非孤立存在。实际项目中，数据冲突可能诱发逻辑冲突（特征值错误导致规则误触发），时效冲突则可能同时引发数据与逻辑层面的连锁反应。建议建立统一的冲突分类与追踪体系，在特征工程与规则引擎之间设置冲突检测网关。