📚 课程目录第3章特征工程概述

特征工程概述：特征的定义、类型与规则关系

聊到行为流和规则引擎，有个东西绕不开——特征。

我见过不少团队，规则写得挺漂亮，流程图也画得花里胡哨，结果一上线效果惨淡。问题出在哪？出在特征没选对。说白了，特征就是规则的「食材」。食材不新鲜，再好的厨子也白搭。

这一章，咱们就把特征这件事掰开揉碎。我会结合自己踩过的坑，跟你聊聊特征到底是什么、有哪些类型、以及它和规则之间那点「暧昧关系」。

核心观点：特征的质量直接决定了规则引擎的上限。好的特征让规则简洁有力，烂的特征让规则臃肿低效。

什么是特征？

特征，就是能从原始数据里提取出来的、对决策有用的信息片段。

举个例子。你在做风控规则，原始数据是一条用户行为日志：用户A在2024-03-15 14:23:05点击了商品B。这条日志本身不是特征，但你可以从中提取出：

用户ID（类别型特征）
点击时间（时序型特征）
商品类目（类别型特征）
距上次点击的间隔（数值型特征）

我个人习惯把特征理解为「数据的投影」。原始数据是多维的、杂乱的，特征就是我们从某个角度打过去的一束光，把有用的信息投射到决策平面上。

一个小技巧：判断一个字段能不能当特征，就问自己一个问题——「这个值变了，我的规则决策会变吗？」如果不会，它就不是特征，只是数据。

特征的三大类型

做特征工程这些年，我总结下来，特征无非三大类。咱们一个一个说。

数值型特征

数值型特征，就是能比较大小、能做运算的特征。比如：

用户年龄
订单金额
登录次数
行为序列长度

这类特征最直观，规则引擎也最喜欢。你写个 金额 > 1000，简单明了。

但要注意一个问题——量纲差异。我曾经在一个反欺诈项目里，直接把「交易金额」和「交易次数」放在同一个规则里做加权，结果金额特征完全主导了结果，次数特征基本没起作用。后来做了归一化才解决。

// 数值型特征在规则中的典型用法
if (transactionAmount > 10000 && 
    loginCountToday < 3) {
    // 触发风控
}

类别型特征

类别型特征，描述的是「属于哪一类」。比如：

用户等级（VIP、普通、黑名单）
设备类型（iOS、Android）
支付方式（、支付宝、银行卡）

这类特征不能直接比大小。你不能说「 > 支付宝」，这没意义。

规则引擎处理类别型特征时，通常用枚举匹配。我见过最坑的写法是把几百个城市名写进一条规则里——又长又慢。更好的做法是先做聚类或编码，把类别映射成数值。

避坑指南：我曾经把一个「用户职业」字段直接塞进规则，结果发现「程序员」和「产品经理」在原始数据里被写成了「程序猿」和「产品狗」。类别型特征一定要先做数据清洗和标准化，否则规则会漏掉大量命中。

时序型特征

时序型特征，是我觉得最有意思的一类。它描述的是「随着时间变化的行为模式」。

比如：

过去7天的登录频率
最近一次交易距现在的小时数
行为序列中的模式（点击→加购→支付的完成率）

时序型特征最难处理，但信息量也最大。为什么？因为它包含了行为流的上下文。

我举个例子。两个用户今天都消费了1000元。用户A是连续30天每天消费的活跃用户，用户B是注册后第一次消费。同样的金额，风险等级完全不同。这个差异，只有时序型特征能捕捉到。

// 时序型特征提取示例
// 计算过去24小时内的行为次数
function countRecentActions(userId, hours = 24) {
    const cutoff = Date.now() - hours * 3600 * 1000;
    return actionLogs.filter(log => 
        log.userId === userId && 
        log.timestamp > cutoff
    ).length;
}

特征与规则的关系

说到这，咱们得聊聊特征和规则到底什么关系。我画了张图，你看一眼就明白了。

你看，整个链条很清楚：原始数据经过特征工程变成特征，特征喂给规则引擎做决策。但这里有个关键点——反馈回路。规则跑出来的结果，反过来会指导我们怎么优化特征。

我举个例子。你写了一条规则：if 登录次数 > 5 then 标记为活跃用户。跑了一段时间发现误判率很高。一查，原来有些用户是脚本刷登录。这时候你就知道，光用「登录次数」这个特征不够，得加上「登录间隔方差」或者「设备指纹」来区分真人还是脚本。

这就是特征和规则的联动——规则暴露问题，特征解决问题。

特征选择的几个原则

说了这么多，到底怎么选特征？我总结了几条经验：

原则	说明	我踩过的坑
相关性	特征必须与决策目标相关	把「用户星座」用在支付风控里，完全没用
稳定性	特征分布不能剧烈波动	「当日UV」在周末和工作日差异巨大，导致规则忽紧忽松
可解释性	业务方能理解这个特征的含义	用了一个复杂的embedding特征，业务方看不懂，出了问题没法排查
时效性	特征能及时更新	用了T+1的离线特征做实时规则，数据滞后导致大量误判

我的习惯：每次新加一个特征，我都会先跑一段时间的离线分析，看看它的分布、缺失率、与目标变量的相关性。确认没问题了，再上线到规则引擎里。别一上来就往生产环境塞，容易出事。

小结一下

特征工程这事，说难不难，说简单也不简单。核心就三件事：

知道特征是什么——数据的投影
知道特征有哪些类型——数值型、类别型、时序型
知道特征和规则的关系——特征是规则的输入，规则是特征的逻辑组合