规则特征基础：特征的定义与分类

聊规则引擎，绕不开一个核心概念——特征。我见过不少团队，规则写得飞起，但性能一塌糊涂。追根溯源，往往是特征这层没打好基础。说白了，特征就是规则引擎的“原材料”。原材料质量不行，再好的厨师也做不出好菜。

特征到底是什么？

特征，是业务数据的结构化表达。举个例子，你在做风控规则，判断“用户是否在深夜登录”。原始数据可能是“2025-03-21 03:15:00”，但规则引擎没法直接理解这个时间戳。你需要把它加工成一个特征——is_night_login: true/false。

我个人习惯把特征定义为：从原始数据中提取的、用于规则判定的可计算变量。它有三个关键属性：

• 可计算性：能在有限时间内求值
• 确定性：相同输入，永远得到相同输出
• 可解释性：业务人员能理解它的含义

特征的分类体系

我在项目中遇到过不少分类方式，但最实用的还是按数据来源和计算复杂度来分。你想想看，不同类别的特征，存储和计算策略完全不同。

分类维度	类别	示例	性能特点
数据来源	基础属性特征	用户年龄、性别、会员等级	直接读取，延迟最低
	行为统计特征	近7天登录次数、月均消费金额	需要聚合计算，可预计算
	关系图谱特征	好友数量、二度关联风险分	计算成本高，需图索引
计算复杂度	实时计算特征	当前IP归属地、设备指纹	每次请求都算，延迟敏感
	预计算特征	用户信用分、历史逾期次数	离线批量产出，读取快

嗯，这里要注意：不要把所有特征都做成实时计算。我曾经接手过一个项目，他们把“用户近30天消费总额”做成每次请求都实时聚合——结果数据库被打爆了。后来改成每小时预计算一次，性能提升了20倍。

特征工程在规则中的作用

特征工程，说白了就是“怎么把原始数据变成好用的特征”。它在规则引擎里扮演三个角色：

1. 降维：把高维原始数据压缩成低维特征。比如把100个商品类目映射成“是否属于高风险品类”这个布尔特征。
2. 增强表达力：通过组合、变换，让特征承载更多信息。比如“登录频率×设备可信度”这样的交叉特征。
3. 标准化：统一数据格式和单位，让规则编写更简洁。比如把所有金额统一为“分”，避免规则里到处写单位转换。

特征与规则的关系

特征和规则的关系，我常用“食材与菜谱”来比喻。特征是食材，规则是菜谱。没有好食材，再好的菜谱也做不出美味。

从技术角度看，它们的关系可以总结为三点：

• 特征是规则的输入变量：规则的条件部分引用特征，比如 if user.age > 18 and user.is_vip == true
• 规则可以产生新特征：规则执行后的结论，也可以作为特征被其他规则引用。这叫“特征级联”。
• 特征的粒度决定规则的复杂度：特征越原子化，规则组合越灵活，但规则数量会爆炸。特征越聚合，规则越简单，但灵活性下降。

特征存储与元数据管理

特征存储，很多人不重视。觉得“不就是存个值吗？”其实不然。特征存储选型直接影响规则引擎的查询性能。

我常用的存储策略是这样的：

特征类型	推荐存储	原因
高频访问的静态特征	本地内存（HashMap/Caffeine）	微秒级访问，无网络开销
低频更新的动态特征	Redis	支持TTL自动过期，分布式共享
大规模历史特征	列式存储（ClickHouse/Parquet）	高压缩比，适合批量读取
实时流式特征	Flink状态后端	支持窗口计算，Exactly-Once语义

元数据管理，是很多人容易忽略的环节。我见过一个团队，特征命名混乱到“f1、f2、f3”这种程度。结果半年后，没人知道这些特征是什么意思，规则维护成本飙升。

一个好的元数据管理系统，至少应该包含：

• 特征ID：全局唯一，建议用业务前缀+语义化名称，比如 risk_user_credit_score
• 特征定义：计算逻辑的详细描述，包括数据源、聚合窗口、空值处理策略
• 特征血缘：记录特征从哪个原始数据来，被哪些规则引用
• 特征版本：特征计算逻辑变更时，版本号递增，保证历史可追溯
• 特征质量指标：覆盖率、准确率、延迟P99等

特征生命周期管理

特征不是一成不变的。它会经历“设计→开发→上线→监控→下架”五个阶段。每个阶段都有对应的性能考量：

1. 设计阶段：评估特征的计算成本和存储开销，避免设计出“理论上很美，实际上跑不动”的特征。
2. 开发阶段：写单元测试验证特征计算的正确性，同时做基准测试，确保单次计算延迟在可接受范围内。
3. 上线阶段：灰度发布，先让1%的流量使用新特征，观察性能和正确性。
4. 监控阶段：持续监控特征的计算延迟、命中率、异常率。我习惯设置三个告警阈值：P99延迟超过50ms告警，命中率突降20%告警，异常率超过1%告警。
5. 下架阶段：不再被任何规则引用的特征，及时清理存储资源。别让僵尸特征占用内存。

特征性能调优的常见误区

最后，分享几个我在项目中踩过的坑：

• 误区一：特征越细越好。不是的。特征粒度过细，会导致规则数量爆炸，规则引擎的匹配效率急剧下降。适当聚合特征，反而能提升性能。
• 误区二：所有特征都放内存。内存不是无限的。我见过一个团队把所有历史特征都塞进内存，结果JVM堆直接撑爆。冷热分离才是正道。
• 误区三：特征计算不做缓存。同一个请求里，一个特征可能被多条规则引用。不做缓存，等于重复计算。加一层请求级别的缓存，性能提升立竿见影。
• 误区四：忽略特征的空值处理。特征值为空时，规则怎么走？是跳过、默认值还是抛异常？这个必须在特征定义阶段就明确，否则线上会出现各种诡异问题。