做机器学习这几年我发现自己跟别人聊特征工程的时间比聊模型结构的时间还多。很多时候模型效果上不去回头一查不是网络不够深、不是超参没调好而是最基础的特征处理出了问题——该归一化的没归一化该做 embedding 的高基数类别栏位被直接塞进了 one-hot时间特征被当成普通整数丢给树模型结果模型学到的规律全是错的。所以这篇想把「特征类型」这件事系统捋一遍。不是那种教科书式的列表而是我自己在项目里真正用过的、踩过坑的、反复回来查的做法。从数值特征、类别特征、时序特征、文本特征到多值特征每一类我都会聊清楚它们的底层逻辑、常见处理手段、适用场景以及那些只有实际跑过才知道的坑。如果你正在做特征工程或者准备做机器学习项目但不知道从哪下手这篇应该能帮你省不少弯路。1. 数值特征不是所有数字都该直接喂给模型先聊最常见也最容易被轻视的一类。数值特征就是那些本身就是连续量的字段比如用户年龄、商品价格、点击次数、距上次访问的天数。很多人拿到手就丢进模型训练但这里面的门道比想象中多得多。1.1 数值特征的三个基本检查项在我自己的项目实践中拿到数值特征第一件事不是预处理而是先回答三个问题。第一个问题是量纲问题。如果特征A的取值范围是0到1特征B的取值范围是0到100000这两个特征同时进入模型梯度下降类的算法比如线性回归、逻辑回归、神经网络会倾向于把权重更多分配给数值大的特征这不是因为它们更重要纯粹是因为数值大所以梯度大。树模型不受这个问题影响但神经网络和线性模型必须处理。第二个问题是分布问题。很多真实场景的特征是长尾分布的比如用户月消费金额90%的人在几百块上下少数大客户月销几十万。这种偏态分布直接进模型会让模型把大量能力花在拟合那少数极端值上普通样本反而学不好。第三个问题是缺失问题。数值特征的缺失通常不是没有而是不该填0。这个后面专门展开。1.2 标准化和归一化什么时候用什么规范化处理里有两种最常用的思路标准化Standardization和归一化Normalization很多人混着用但适用场景完全不同。标准化是把特征变成均值为0、方差为1的分布公式是 (x - mean) / std。它不改变特征本身的分布形态只是调整了尺度和位置。这种处理适合特征本身大致呈正态分布或至少分布形态不太离谱的情况也是神经网络、线性模型最常用的做法。归一化是把特征缩放到 [0, 1] 区间公式是 (x - min) / (max - min)。它会把整个特征的取值范围压缩到固定区间对分布形态同样不做改变但对异常值非常敏感——如果某个样本的值远超其他样本归一化后其他样本会被压到一个很小的区间。我个人的经验是如果不确定特征分布长什么样优先做标准化。原因是标准化对异常值的容忍度比归一化高因为减去均值再除以标准差极端值的影响会被摊薄而归一化里一个极端值几乎决定了所有其他样本的坐标位置。1.3 长尾分布特征的应对手段回到长尾分布的问题。月消费金额这种特征直接标准化之后依然是长尾的模型照样学不好。最常见的处理手段是对数变换取 log(1 x)。这能把指数级的长尾压缩成接近正态的分布而且是单调变换不改变特征之间的相对大小关系。比如某特征的分布是大部分值在 0-100少数值在 1000-10000极少数在 10000-100000。直接取对数后0-100 映射到 0-4.61000-10000 映射到 6.9-9.210000-100000 映射到 9.2-11.5。你能看到原本占绝对主导的10000以上区间在对数变换后跟其他区间的差距被大大缩小了模型不会再把所有注意力放在区分大额用户上。另一种处理是分箱Binning把连续值切成若干区间变成类别特征。这个后面跟离散化一起讲。提示做对数变换前一定先检查特征有没有0或负值。log(0) 是负无穷这是跑代码时最常见的报错来源。稳妥做法是先用 x1 再取对数或者用 np.log1p。1.4 数值特征可以衍生的高阶特征单个数值特征本身的信息量是有限的但通过跨特征组合能挖出更多信息。我自己常用的衍生思路有几种。第一种是比值类特征。比如浏览商品数 / 下单数这个转化率性质的比值往往比两个原始数值更有业务含义。第二种是差值类特征比如当前时间 - 注册时间 注册时长时间差往往比两个绝对时间点更有用。第三种是分组统计特征比如按用户分组计算每个用户的行为均值然后用当前值 - 该用户均值作为特征这部分我在后面专门讲统计特征时细说。2. 类别特征从硬编码到嵌入的演进之路类别特征在真实业务里出现的频率比想象的更高。用户所在城市、设备类型、支付渠道、商品类目这些字段都是类别特征。处理方式直接决定了模型能不能理解它们之间的远近亲疏。2.1 One-Hot 编码的适用边界One-Hot 编码是最基础的类别特征编码方式一个类别对应一个维度该维度上只有1和0。比如城市特征里有北京、上海、广州三个类别就拆成三个特征是否为北京、是否为上海、是否为广州。One-Hot 的好处是简单、不引入误差每个类别都是独立的模型可以学出每个类别对目标的独立影响。但它的致命问题在于维度爆炸一个取值数量几十万的类别特征比如用户ID、商品IDone-hot 之后特征矩阵会庞大到根本无法训练。即便是取值数量只有几百的类别one-hot 也有信息损失的问题——它把类别之间的任何相似性都抹掉了。比如某服装类目里有T恤、衬衫、Polo衫三个子类one-hot 后它们在模型眼里是三个完全无关的维度但实际上它们对目标的影响大概率是相似的one-hot 无法体现这层关系。2.2 标签编码和序数编码什么时候能直接用标签编码Label Encoding就是把每个类别映射成一个整数比如北京0、上海1、广州2。这种编码方式的问题在于它引入了不存在的序关系——模型会以为上海1介于北京0和广州2之间但实际上城市之间没有这种大小关系。所以标签编码只适合类别本身有自然顺序的场景。比如学历特征小学0、初中1、高中2、本科3、硕士4这种有序关系是真实存在的用整数编码反而是信息量最大、最省空间的做法这一类也叫做序数编码Ordinal Encoding。2.3 计数编码和目标编码One-Hot 之外的工程选择当类别数量中等几十到几千时one-hot 会撑爆维度标签编码又不合理这时候有两个常用替代方案。计数编码Count Encoding是把每个类别替换成它出现的次数逻辑是出现次数越多的类别往往越有代表性。这种编码在树模型里能用在神经网络里也能用但它丢失了类别自身的身份信息——所有出现100次的类别都被当成同一个值了。目标编码Target Encoding把每个类别替换成该类别下目标变量的均值。比如城市特征里北京用户的平均购买额为500元就把北京这个类别替换成500。这种编码能非常好地捕捉类别和目标之间的相关性但极容易过拟合——如果某个类别只有两三个样本平均下来噪声极重。目标编码的正确打开方式是在训练集上计算每个类别的目标均值然后把这个映射应用到验证集和测试集上千万不能用全部数据计算后直接回填否则验证集的信息就泄漏到训练集里了。为了抑制小样本类别的过拟合通常还会做平滑处理公式类似smooth (count * category_mean prior * global_mean) / (count prior)其中 count 是该类别的样本数category_mean 是该类别的目标均值global_mean 是全体目标均值prior 是自己设定的先验权重。当 count 很小时结果趋近于全局均值当 count 很大时结果趋近于该类别的实际目标均值这样就兼顾了信息利用和防过拟合。2.4 高基数类别特征的 Embedding 方案类别数量成千上万甚至上百万时以上所有方法都不好使了这时候该上 Embedding 了。Embedding 的本质是把每个类别映射成一个低维稠密向量维度通常是 16 到 128远小于 one-hot 的类别数。Embedding 最有价值的地方在于它让相似的类别在向量空间里距离更近。训练过程中模型会自动学习类别A和类别B对目标的影响方式相似就让它们的向量更接近。它跟 one-hot 的对比可以用一句话概括one-hot 记录类别的身份embedding 学习类别的语义。从 one-hot 到 embedding 的过渡其实非常平滑神经网络第一层如果输入是 one-hot 向量权重矩阵的每一行干的事情就是把对应的 one-hot 向量映射成一个向量这个向量就是该类别的 embedding。所以很多框架里说Embedding 层其实就是一个查表操作——把类别ID对应到训练好的向量。我自己跑推荐系统的时候用户ID、商品ID这种千万级的类别特征基本全靠 embedding效果比任何手工编码都好。3. 时序特征时间不是数字是规律时间类特征很特别它表面上是个数值时间戳但直接当数值用等于放弃掉了大量信息。推荐系统、金融风控、用户行为预测这些场景里时序特征处理得好不好对整体效果的影响巨大。3.1 时间戳的正确打开方式先看最原始的购买时间这种特征。如果你直接把时间戳比如 1620000000丢给模型模型只能学到时间戳越大某个东西越怎么样这种线性关系而真实世界的时间规律几乎从来不是线性的。正确的做法是把时间拆成多个维度的成分让模型自己学哪种成分在起作用。最简单的拆法是把时间戳转成日期分量。比如2023-05-15 14:30:00拆出年份2023、月份5、日15、小时14、分钟30、星期几周一、是否周末等。其中小时、星期几、是否节假日这些周期性成分的价值通常远大于年份和日期这种单调成分。为什么小时这种成分比年份有用因为商业场景里的行为天然有周期性。外卖订单量在中午12点和晚上7点有两波高峰凌晨2点几乎没人下单通勤类App的活跃度在周一早高峰和周五晚高峰有明显峰值。这些规律用小时特征学得出来用时间戳永远学不出来。第二个要注意的是周期性编码。小时这个特征直接当整数是0到23模型会认为23点和0点离得很远但真实世界23点和0点只差1小时。这个问题可以用 sin/cos 变换解决hour_sin sin(2 * pi * hour / 24) hour_cos cos(2 * pi * hour / 24)这样23点和0点在三角函数空间里确实离得很近因为2pi23/24 和 2pi0/24 的正弦余弦值几乎相同。同样的思路适用于星期几周期是7、月份周期是12。3.2 时间差特征永远别直接用绝对时间我在项目里反复踩过一个坑把用户注册时间、首次下单时间这种绝对时间点直接作为特征喂给模型。这样做的隐患是模型容易学到2023年注册的用户比2022年注册的用户好但这个结论无法泛化到2024年、2025年的新用户。绝对时间点只有在做时间切片训练时有一定的信息量但泛化能力很差。正确的做法是转换成时间差当前时间 - 注册时间 注册时长当前时间 - 上次购买时间 距上次购买天数。这些差值特征才是真正有稳定规律的注册时长越长用户忠诚度越高距上次购买越近再次购买概率越大。还有一类差值特征是从原始时序数据里计算的。比如某用户在一小时内下单5次交易间隔的中位数是3分钟这个行为模式可以用交易间隔均值、交易间隔标准差来刻画。离散程度高的用户可能是冲动型消费间隔稳定的用户可能是习惯型消费。3.3 粘性特征与实时特征的设计思路做用户行为建模时我特别看重涉及一段时间的统计量所谓粘性特征就是用户在某个时间窗口内的行为汇总。举个例子用户的平均每日登录时长这个特征需要你先拿到用户过去7天每天的登录时长然后计算均值。它就是典型的时间窗口统计特征。窗口长度的选择跟业务节奏有关电商看7天或30天的复购行为内容推荐看30分钟内的点击行为风控看3秒到5分钟的异常操作。这个窗口本身也是超参值得多试几种。实时特征则是流式计算场景里的产物——用户从打开App到下单之间点了哪些商品、加了哪些购物车、停留了几秒这些不断更新的特征在推荐模型里作用极大。它们本质上也是时序特征只不过在线系统的实现方式通常是滑动窗口统计比如过去10分钟的行为计数再加上特征更新的时效性要求。4. 文本特征从词袋到语义向量的三种层级文本特征的处理在机器学习里能单独写一本书这里只聊实际项目中最常用的三个层级以及它们各自的适用场景。4.1 词袋模型和 TF-IDF朴素但依然能打最朴素的文本表示是词袋模型Bag of Words统计每个词在文档里出现的次数构成一个词频向量。它的缺点很明显——完全不考虑词序我送你花和花送我你会被当成一样的向量。TF-IDF 在词频基础上加了逆文档频率惩罚出现在太多文档里的常见词如的、了、是权重降低出现在少数文档里的词权重提高。公式是tfidf(t, d) tf(t, d) * log(N / df(t))其中 tf(t, d) 是词t在文档d中的词频df(t) 是包含词t的文档数N 是总文档数。TF-IDF 在处理短文本分类、关键词提取、文本相关性排序这类任务时依然非常可靠。它简单、可解释性强、训练快唯一的限制是对语义的理解停留在词面层面——苹果和iPhone在词袋视角下是毫无关系的两个词但语义上它们紧密相关。4.2 Word2Vec / 预训练词向量引入语义词向量Word Embedding解决的就是词袋模型的语义隔离问题。用 Word2Vec 等方法在语料上训练之后每个词被映射成一个向量语义相近的词在向量空间中距离也近。苹果和iPhone的距离会明显小于苹果和汽车。在实践中有两种用法。一种是直接用预训练好的词向量做文本的向量化——把所有词的向量取平均作为整篇文本的表示。这种做法的优点是不需要额外标注数据直接复用别人在大语料上训练好的词向量。缺点是平均操作会稀释掉重要词的信号长文本尤其明显。另一种是把它作为神经网络第一层的输入让模型在训练过程中微调词向量使其更贴合当前任务。这在分类、匹配、序列标注任务中很常见。4.3 预训练语言模型需要时再上重武器Bert、GPT 这类预训练语言模型在文本特征提取上的效果确实碾压传统方法但代价也很大——推理成本高、迭代周期长、对数据量有要求。我的经验是如果你的任务是短文本分类、关键词匹配这类轻量场景TF-IDF 加一个线性模型往往就够了没必要上大模型如果是长文本理解、语义相似度、跨语言任务那预训练模型基本是绕不开的。工程上还有一种折中方案用预训练模型跑一遍文本提取出句向量Sentence Embedding把提取结果当成普通数值特征存下来下游模型再用这些向量做输入。这样可以把文本理解的重活提前做完节省线上推理成本是工程上非常常见的做法。5. 多值特征列表型数据怎么进模型多值特征在真实场景里到处都是。用户感兴趣的标签列表、一篇文章的类目标签集合、商家的经营范围列表这些字段不是单个类别而是多个类别组成的集合。处理方式跟单独的类别特征完全不同。5.1 多值展开从集合到数值的几种做法最笨也最直接的做法是把列表拆开看成一个多标签的 one-hot。比如用户兴趣标签是[篮球, 足球, 数码]就拆成是否喜欢篮球、是否喜欢足球、是否喜欢数码三个特征。这种做法的好处是信息无损坏处是标签数量多时维度爆炸而且一个用户只有少数几个标签命中矩阵极度稀疏。工程上常用的做法是统计聚合。把列表中元素的个数作为特征比如兴趣爱好数量把列表里元素的某些属性做均值比如感兴趣的类目平均热度。这种做法把列表压缩成了少数数值特征信息量有损失但维度小、稳定、不容易过拟合。5.2 池化方案Embedding 的组合套路如果列表里的元素是类别型且在模型里已经存在对应的 embedding那可以走池化路线把列表里所有元素取 embedding 后做平均池化Average Pooling或最大池化Max Pooling得到一个固定维度的向量作为整体特征。平均池化的含义是取这个用户所有兴趣的语义重心最大池化的含义是取最能代表这个用户兴趣的那个元素。两种池化各有偏重我自己的经验是可以拼接起来用或者同时做两种池化再让模型自己决定权重。注意池化方案需要类别的 embedding 先训练好。如果你的类别数量不大、或者没有合适的预训练 embedding老老实实做统计聚合更稳定。5.3 多值特征在工程落地时的常见坑多值特征最容易在数据清洗环节出问题。第一种情况是列表里元素重复比如用户兴趣标签里出现两次篮球直接映射是有偏的先去重。第二种情况是列表里的元素不在预定义集合中比如新的标签冒出来了这需要在映射表里预留未知类别。第三种情况是空列表——用户没有任何兴趣标签要单独用一个标志位表示无兴趣而不是当作长度0的列表丢掉因为没有兴趣本身就是一个有价值的状态。我在实际项目中遇到过最隐蔽的问题是这个列表的个数差异极大。有人有50个标签有人只有1个标签如果直接用池化方案稀疏列表对应的 embedding 向量会非常不稳定因为平均下来噪声极重。这种场景下先考虑做个数截断只取前N个标签或加权聚合频率高的标签权重更高会稳定很多。6. 实战中的特征统计量与选择策略特征类型总结到这一步已经覆盖了大多数场景的基础类别。但做完类型梳理还不算完怎么把这么多特征组织起来、怎么判断哪些重要、哪些可以舍弃是真正决定模型效果的下半场。6.1 统计特征一阶特征之上的倍增器前面反复提到的分组统计特征值得展开。这类特征的做法是按某个分组维度通常是用户或商品计算组内其他特征的统计量然后把这些统计量作为新特征拼回去。比如按用户ID分组计算该用户的历史平均下单金额、下单次数、最大单笔金额、下单间隔方差。这些统计量刻画的是用户的行为习惯远比单次行为的原始特征稳定。我做过一个复购预测项目加入用户的历史下单间隔均值后AUC直接提升了将近3个百分点这是加任何单条原始特征都达不到的效果。统计特征的实现上要注意两点。一是统计窗口的选择——全历史统计量包含了未来信息的话会造成数据泄漏通常需要限定在预测时刻之前所以工程上要按时间窗口做截止统计。二是统计量的分布——计数类统计量往往长尾跟前面说的一样取个对数或者做开根号处理有利于线性模型和神经网络。6.2 特征重要性评估的实用工具判断特征有没有用我的习惯是先跑模型自带的特征重要性。树模型比如 GBDT 系列自带基于分裂增益的特征重要性业务特征的相对排序完全可以直接拿来排查。但要注意一点特征重要性只代表该特征在当前模型框架、当前超参下的贡献不代表它在所有模型里都重要。两种特征在树模型里重要性接近但一个在神经网络里完全无用、另一个在神经网络里表现优异这种差异经常发生因为树模型学到的是非线性局部规则神经网络则能从全局分布中提取信息。还有一种更严谨的办法是基于置换的特征重要性随机打乱某个特征的值观察模型指标下降多少。下降越多说明该特征越重要。这个做法不依赖具体模型结果更可信但计算开销大我一般只在对候选特征进行精简时用。6.3 特征冗余与共线性的处理经验类别特征 one-hot 之后要检查共线性。线性模型里如果两个特征高度相关权重会被分散导致系数解释性变差。树模型对共线性不那么敏感但高度冗余的特征也会增加不必要的计算量。处理手段无非是几种相关性矩阵里看数值特征的皮尔逊系数过高的保留一个用方差膨胀因子检测多重共线性这个对线性模型友好还有降维的方式PCA 这一类的做法能压缩特征维度但可解释性会大幅下降。我个人的底线是优先保证特征和业务目标之间有明确的因果逻辑而不是纯粹为了降维度去做 PCA。一个能解释为什么有效的特征比一堆看不懂的压缩成分在后续调试里更有价值。6.4 特征上线前需要做的一致性检查最后聊一个工程上最容易被忽略但后果最严重的环节——训练和线上特征的一致性。我在项目里见过这样的惨案训练的时候用的是当日实时特征上线的时候发现线上特征要滞后一天才能拿到模型预测效果直接崩盘。训练窗口和线上特征的时间口径必须完全对齐这是一条铁律。一致性检查要确认的事情包括特征是否在训练和预测时间点都能拿到特征的缺失值处理逻辑线上线下是否一致特征分布的漂移情况——比如线上用户的分布跟训练集的用户分布相差太大模型表现必然下降。这些检查有时比模型本身更影响最终效果因为一个在训练集上完美的模型线上特征对不齐几乎等于白训。我自己的习惯是每个特征都记录一张元数据表特征名、数据类型、计算口径、窗口范围、缺失值处理方式、上线时间任何特征变更前先看这张表。这个习惯看起来琐碎但真的能在关键时刻救你一命。结尾一点个人的体会写了这么多最想强调的一点是特征类型没有绝对的黄金标准只有在某个场景下更合适的方案。同一份数据换一个模型家族、换一种预测目标最优的特征处理方式可能完全不同。我刚入门那会儿总想找到一个万能配方——把所有特征标准化、把所有类别 one-hot然后跑个 XGBoost 就完事。后来碰壁多了才明白特征工程的每一步选择都值得多问一句为什么为什么这个特征要取对数为什么这个类别不能 one-hot为什么这个时间差要用小时不用天想清楚这些问题比套用任何现成模板都重要。最后分享一个我每次做特征处理都会自查的小清单也算是个人的收尾仪式吧一查是否有不该进模型的未来信息二查训练和预测时的特征口径是否完全一致三查每个特征的分布是否跟业务逻辑对得上四查高阶特征是否可解释能不能说清楚它跟目标之间的因果关系。这四个问题过完特征这块基本就稳了。
做机器学习这几年我发现自己跟别人聊特征工程的时间比聊模型结构的时间还多。很多时候模型效果上不去回头一查不是网络不够深、不是超参没调好而是最基础的特征处理出了问题——该归一化的没归一化该做 embedding 的高基数类别栏位被直接塞进了 one-hot时间特征被当成普通整数丢给树模型结果模型学到的规律全是错的。所以这篇想把「特征类型」这件事系统捋一遍。不是那种教科书式的列表而是我自己在项目里真正用过的、踩过坑的、反复回来查的做法。从数值特征、类别特征、时序特征、文本特征到多值特征每一类我都会聊清楚它们的底层逻辑、常见处理手段、适用场景以及那些只有实际跑过才知道的坑。如果你正在做特征工程或者准备做机器学习项目但不知道从哪下手这篇应该能帮你省不少弯路。1. 数值特征不是所有数字都该直接喂给模型先聊最常见也最容易被轻视的一类。数值特征就是那些本身就是连续量的字段比如用户年龄、商品价格、点击次数、距上次访问的天数。很多人拿到手就丢进模型训练但这里面的门道比想象中多得多。1.1 数值特征的三个基本检查项在我自己的项目实践中拿到数值特征第一件事不是预处理而是先回答三个问题。第一个问题是量纲问题。如果特征A的取值范围是0到1特征B的取值范围是0到100000这两个特征同时进入模型梯度下降类的算法比如线性回归、逻辑回归、神经网络会倾向于把权重更多分配给数值大的特征这不是因为它们更重要纯粹是因为数值大所以梯度大。树模型不受这个问题影响但神经网络和线性模型必须处理。第二个问题是分布问题。很多真实场景的特征是长尾分布的比如用户月消费金额90%的人在几百块上下少数大客户月销几十万。这种偏态分布直接进模型会让模型把大量能力花在拟合那少数极端值上普通样本反而学不好。第三个问题是缺失问题。数值特征的缺失通常不是没有而是不该填0。这个后面专门展开。1.2 标准化和归一化什么时候用什么规范化处理里有两种最常用的思路标准化Standardization和归一化Normalization很多人混着用但适用场景完全不同。标准化是把特征变成均值为0、方差为1的分布公式是 (x - mean) / std。它不改变特征本身的分布形态只是调整了尺度和位置。这种处理适合特征本身大致呈正态分布或至少分布形态不太离谱的情况也是神经网络、线性模型最常用的做法。归一化是把特征缩放到 [0, 1] 区间公式是 (x - min) / (max - min)。它会把整个特征的取值范围压缩到固定区间对分布形态同样不做改变但对异常值非常敏感——如果某个样本的值远超其他样本归一化后其他样本会被压到一个很小的区间。我个人的经验是如果不确定特征分布长什么样优先做标准化。原因是标准化对异常值的容忍度比归一化高因为减去均值再除以标准差极端值的影响会被摊薄而归一化里一个极端值几乎决定了所有其他样本的坐标位置。1.3 长尾分布特征的应对手段回到长尾分布的问题。月消费金额这种特征直接标准化之后依然是长尾的模型照样学不好。最常见的处理手段是对数变换取 log(1 x)。这能把指数级的长尾压缩成接近正态的分布而且是单调变换不改变特征之间的相对大小关系。比如某特征的分布是大部分值在 0-100少数值在 1000-10000极少数在 10000-100000。直接取对数后0-100 映射到 0-4.61000-10000 映射到 6.9-9.210000-100000 映射到 9.2-11.5。你能看到原本占绝对主导的10000以上区间在对数变换后跟其他区间的差距被大大缩小了模型不会再把所有注意力放在区分大额用户上。另一种处理是分箱Binning把连续值切成若干区间变成类别特征。这个后面跟离散化一起讲。提示做对数变换前一定先检查特征有没有0或负值。log(0) 是负无穷这是跑代码时最常见的报错来源。稳妥做法是先用 x1 再取对数或者用 np.log1p。1.4 数值特征可以衍生的高阶特征单个数值特征本身的信息量是有限的但通过跨特征组合能挖出更多信息。我自己常用的衍生思路有几种。第一种是比值类特征。比如浏览商品数 / 下单数这个转化率性质的比值往往比两个原始数值更有业务含义。第二种是差值类特征比如当前时间 - 注册时间 注册时长时间差往往比两个绝对时间点更有用。第三种是分组统计特征比如按用户分组计算每个用户的行为均值然后用当前值 - 该用户均值作为特征这部分我在后面专门讲统计特征时细说。2. 类别特征从硬编码到嵌入的演进之路类别特征在真实业务里出现的频率比想象的更高。用户所在城市、设备类型、支付渠道、商品类目这些字段都是类别特征。处理方式直接决定了模型能不能理解它们之间的远近亲疏。2.1 One-Hot 编码的适用边界One-Hot 编码是最基础的类别特征编码方式一个类别对应一个维度该维度上只有1和0。比如城市特征里有北京、上海、广州三个类别就拆成三个特征是否为北京、是否为上海、是否为广州。One-Hot 的好处是简单、不引入误差每个类别都是独立的模型可以学出每个类别对目标的独立影响。但它的致命问题在于维度爆炸一个取值数量几十万的类别特征比如用户ID、商品IDone-hot 之后特征矩阵会庞大到根本无法训练。即便是取值数量只有几百的类别one-hot 也有信息损失的问题——它把类别之间的任何相似性都抹掉了。比如某服装类目里有T恤、衬衫、Polo衫三个子类one-hot 后它们在模型眼里是三个完全无关的维度但实际上它们对目标的影响大概率是相似的one-hot 无法体现这层关系。2.2 标签编码和序数编码什么时候能直接用标签编码Label Encoding就是把每个类别映射成一个整数比如北京0、上海1、广州2。这种编码方式的问题在于它引入了不存在的序关系——模型会以为上海1介于北京0和广州2之间但实际上城市之间没有这种大小关系。所以标签编码只适合类别本身有自然顺序的场景。比如学历特征小学0、初中1、高中2、本科3、硕士4这种有序关系是真实存在的用整数编码反而是信息量最大、最省空间的做法这一类也叫做序数编码Ordinal Encoding。2.3 计数编码和目标编码One-Hot 之外的工程选择当类别数量中等几十到几千时one-hot 会撑爆维度标签编码又不合理这时候有两个常用替代方案。计数编码Count Encoding是把每个类别替换成它出现的次数逻辑是出现次数越多的类别往往越有代表性。这种编码在树模型里能用在神经网络里也能用但它丢失了类别自身的身份信息——所有出现100次的类别都被当成同一个值了。目标编码Target Encoding把每个类别替换成该类别下目标变量的均值。比如城市特征里北京用户的平均购买额为500元就把北京这个类别替换成500。这种编码能非常好地捕捉类别和目标之间的相关性但极容易过拟合——如果某个类别只有两三个样本平均下来噪声极重。目标编码的正确打开方式是在训练集上计算每个类别的目标均值然后把这个映射应用到验证集和测试集上千万不能用全部数据计算后直接回填否则验证集的信息就泄漏到训练集里了。为了抑制小样本类别的过拟合通常还会做平滑处理公式类似smooth (count * category_mean prior * global_mean) / (count prior)其中 count 是该类别的样本数category_mean 是该类别的目标均值global_mean 是全体目标均值prior 是自己设定的先验权重。当 count 很小时结果趋近于全局均值当 count 很大时结果趋近于该类别的实际目标均值这样就兼顾了信息利用和防过拟合。2.4 高基数类别特征的 Embedding 方案类别数量成千上万甚至上百万时以上所有方法都不好使了这时候该上 Embedding 了。Embedding 的本质是把每个类别映射成一个低维稠密向量维度通常是 16 到 128远小于 one-hot 的类别数。Embedding 最有价值的地方在于它让相似的类别在向量空间里距离更近。训练过程中模型会自动学习类别A和类别B对目标的影响方式相似就让它们的向量更接近。它跟 one-hot 的对比可以用一句话概括one-hot 记录类别的身份embedding 学习类别的语义。从 one-hot 到 embedding 的过渡其实非常平滑神经网络第一层如果输入是 one-hot 向量权重矩阵的每一行干的事情就是把对应的 one-hot 向量映射成一个向量这个向量就是该类别的 embedding。所以很多框架里说Embedding 层其实就是一个查表操作——把类别ID对应到训练好的向量。我自己跑推荐系统的时候用户ID、商品ID这种千万级的类别特征基本全靠 embedding效果比任何手工编码都好。3. 时序特征时间不是数字是规律时间类特征很特别它表面上是个数值时间戳但直接当数值用等于放弃掉了大量信息。推荐系统、金融风控、用户行为预测这些场景里时序特征处理得好不好对整体效果的影响巨大。3.1 时间戳的正确打开方式先看最原始的购买时间这种特征。如果你直接把时间戳比如 1620000000丢给模型模型只能学到时间戳越大某个东西越怎么样这种线性关系而真实世界的时间规律几乎从来不是线性的。正确的做法是把时间拆成多个维度的成分让模型自己学哪种成分在起作用。最简单的拆法是把时间戳转成日期分量。比如2023-05-15 14:30:00拆出年份2023、月份5、日15、小时14、分钟30、星期几周一、是否周末等。其中小时、星期几、是否节假日这些周期性成分的价值通常远大于年份和日期这种单调成分。为什么小时这种成分比年份有用因为商业场景里的行为天然有周期性。外卖订单量在中午12点和晚上7点有两波高峰凌晨2点几乎没人下单通勤类App的活跃度在周一早高峰和周五晚高峰有明显峰值。这些规律用小时特征学得出来用时间戳永远学不出来。第二个要注意的是周期性编码。小时这个特征直接当整数是0到23模型会认为23点和0点离得很远但真实世界23点和0点只差1小时。这个问题可以用 sin/cos 变换解决hour_sin sin(2 * pi * hour / 24) hour_cos cos(2 * pi * hour / 24)这样23点和0点在三角函数空间里确实离得很近因为2pi23/24 和 2pi0/24 的正弦余弦值几乎相同。同样的思路适用于星期几周期是7、月份周期是12。3.2 时间差特征永远别直接用绝对时间我在项目里反复踩过一个坑把用户注册时间、首次下单时间这种绝对时间点直接作为特征喂给模型。这样做的隐患是模型容易学到2023年注册的用户比2022年注册的用户好但这个结论无法泛化到2024年、2025年的新用户。绝对时间点只有在做时间切片训练时有一定的信息量但泛化能力很差。正确的做法是转换成时间差当前时间 - 注册时间 注册时长当前时间 - 上次购买时间 距上次购买天数。这些差值特征才是真正有稳定规律的注册时长越长用户忠诚度越高距上次购买越近再次购买概率越大。还有一类差值特征是从原始时序数据里计算的。比如某用户在一小时内下单5次交易间隔的中位数是3分钟这个行为模式可以用交易间隔均值、交易间隔标准差来刻画。离散程度高的用户可能是冲动型消费间隔稳定的用户可能是习惯型消费。3.3 粘性特征与实时特征的设计思路做用户行为建模时我特别看重涉及一段时间的统计量所谓粘性特征就是用户在某个时间窗口内的行为汇总。举个例子用户的平均每日登录时长这个特征需要你先拿到用户过去7天每天的登录时长然后计算均值。它就是典型的时间窗口统计特征。窗口长度的选择跟业务节奏有关电商看7天或30天的复购行为内容推荐看30分钟内的点击行为风控看3秒到5分钟的异常操作。这个窗口本身也是超参值得多试几种。实时特征则是流式计算场景里的产物——用户从打开App到下单之间点了哪些商品、加了哪些购物车、停留了几秒这些不断更新的特征在推荐模型里作用极大。它们本质上也是时序特征只不过在线系统的实现方式通常是滑动窗口统计比如过去10分钟的行为计数再加上特征更新的时效性要求。4. 文本特征从词袋到语义向量的三种层级文本特征的处理在机器学习里能单独写一本书这里只聊实际项目中最常用的三个层级以及它们各自的适用场景。4.1 词袋模型和 TF-IDF朴素但依然能打最朴素的文本表示是词袋模型Bag of Words统计每个词在文档里出现的次数构成一个词频向量。它的缺点很明显——完全不考虑词序我送你花和花送我你会被当成一样的向量。TF-IDF 在词频基础上加了逆文档频率惩罚出现在太多文档里的常见词如的、了、是权重降低出现在少数文档里的词权重提高。公式是tfidf(t, d) tf(t, d) * log(N / df(t))其中 tf(t, d) 是词t在文档d中的词频df(t) 是包含词t的文档数N 是总文档数。TF-IDF 在处理短文本分类、关键词提取、文本相关性排序这类任务时依然非常可靠。它简单、可解释性强、训练快唯一的限制是对语义的理解停留在词面层面——苹果和iPhone在词袋视角下是毫无关系的两个词但语义上它们紧密相关。4.2 Word2Vec / 预训练词向量引入语义词向量Word Embedding解决的就是词袋模型的语义隔离问题。用 Word2Vec 等方法在语料上训练之后每个词被映射成一个向量语义相近的词在向量空间中距离也近。苹果和iPhone的距离会明显小于苹果和汽车。在实践中有两种用法。一种是直接用预训练好的词向量做文本的向量化——把所有词的向量取平均作为整篇文本的表示。这种做法的优点是不需要额外标注数据直接复用别人在大语料上训练好的词向量。缺点是平均操作会稀释掉重要词的信号长文本尤其明显。另一种是把它作为神经网络第一层的输入让模型在训练过程中微调词向量使其更贴合当前任务。这在分类、匹配、序列标注任务中很常见。4.3 预训练语言模型需要时再上重武器Bert、GPT 这类预训练语言模型在文本特征提取上的效果确实碾压传统方法但代价也很大——推理成本高、迭代周期长、对数据量有要求。我的经验是如果你的任务是短文本分类、关键词匹配这类轻量场景TF-IDF 加一个线性模型往往就够了没必要上大模型如果是长文本理解、语义相似度、跨语言任务那预训练模型基本是绕不开的。工程上还有一种折中方案用预训练模型跑一遍文本提取出句向量Sentence Embedding把提取结果当成普通数值特征存下来下游模型再用这些向量做输入。这样可以把文本理解的重活提前做完节省线上推理成本是工程上非常常见的做法。5. 多值特征列表型数据怎么进模型多值特征在真实场景里到处都是。用户感兴趣的标签列表、一篇文章的类目标签集合、商家的经营范围列表这些字段不是单个类别而是多个类别组成的集合。处理方式跟单独的类别特征完全不同。5.1 多值展开从集合到数值的几种做法最笨也最直接的做法是把列表拆开看成一个多标签的 one-hot。比如用户兴趣标签是[篮球, 足球, 数码]就拆成是否喜欢篮球、是否喜欢足球、是否喜欢数码三个特征。这种做法的好处是信息无损坏处是标签数量多时维度爆炸而且一个用户只有少数几个标签命中矩阵极度稀疏。工程上常用的做法是统计聚合。把列表中元素的个数作为特征比如兴趣爱好数量把列表里元素的某些属性做均值比如感兴趣的类目平均热度。这种做法把列表压缩成了少数数值特征信息量有损失但维度小、稳定、不容易过拟合。5.2 池化方案Embedding 的组合套路如果列表里的元素是类别型且在模型里已经存在对应的 embedding那可以走池化路线把列表里所有元素取 embedding 后做平均池化Average Pooling或最大池化Max Pooling得到一个固定维度的向量作为整体特征。平均池化的含义是取这个用户所有兴趣的语义重心最大池化的含义是取最能代表这个用户兴趣的那个元素。两种池化各有偏重我自己的经验是可以拼接起来用或者同时做两种池化再让模型自己决定权重。注意池化方案需要类别的 embedding 先训练好。如果你的类别数量不大、或者没有合适的预训练 embedding老老实实做统计聚合更稳定。5.3 多值特征在工程落地时的常见坑多值特征最容易在数据清洗环节出问题。第一种情况是列表里元素重复比如用户兴趣标签里出现两次篮球直接映射是有偏的先去重。第二种情况是列表里的元素不在预定义集合中比如新的标签冒出来了这需要在映射表里预留未知类别。第三种情况是空列表——用户没有任何兴趣标签要单独用一个标志位表示无兴趣而不是当作长度0的列表丢掉因为没有兴趣本身就是一个有价值的状态。我在实际项目中遇到过最隐蔽的问题是这个列表的个数差异极大。有人有50个标签有人只有1个标签如果直接用池化方案稀疏列表对应的 embedding 向量会非常不稳定因为平均下来噪声极重。这种场景下先考虑做个数截断只取前N个标签或加权聚合频率高的标签权重更高会稳定很多。6. 实战中的特征统计量与选择策略特征类型总结到这一步已经覆盖了大多数场景的基础类别。但做完类型梳理还不算完怎么把这么多特征组织起来、怎么判断哪些重要、哪些可以舍弃是真正决定模型效果的下半场。6.1 统计特征一阶特征之上的倍增器前面反复提到的分组统计特征值得展开。这类特征的做法是按某个分组维度通常是用户或商品计算组内其他特征的统计量然后把这些统计量作为新特征拼回去。比如按用户ID分组计算该用户的历史平均下单金额、下单次数、最大单笔金额、下单间隔方差。这些统计量刻画的是用户的行为习惯远比单次行为的原始特征稳定。我做过一个复购预测项目加入用户的历史下单间隔均值后AUC直接提升了将近3个百分点这是加任何单条原始特征都达不到的效果。统计特征的实现上要注意两点。一是统计窗口的选择——全历史统计量包含了未来信息的话会造成数据泄漏通常需要限定在预测时刻之前所以工程上要按时间窗口做截止统计。二是统计量的分布——计数类统计量往往长尾跟前面说的一样取个对数或者做开根号处理有利于线性模型和神经网络。6.2 特征重要性评估的实用工具判断特征有没有用我的习惯是先跑模型自带的特征重要性。树模型比如 GBDT 系列自带基于分裂增益的特征重要性业务特征的相对排序完全可以直接拿来排查。但要注意一点特征重要性只代表该特征在当前模型框架、当前超参下的贡献不代表它在所有模型里都重要。两种特征在树模型里重要性接近但一个在神经网络里完全无用、另一个在神经网络里表现优异这种差异经常发生因为树模型学到的是非线性局部规则神经网络则能从全局分布中提取信息。还有一种更严谨的办法是基于置换的特征重要性随机打乱某个特征的值观察模型指标下降多少。下降越多说明该特征越重要。这个做法不依赖具体模型结果更可信但计算开销大我一般只在对候选特征进行精简时用。6.3 特征冗余与共线性的处理经验类别特征 one-hot 之后要检查共线性。线性模型里如果两个特征高度相关权重会被分散导致系数解释性变差。树模型对共线性不那么敏感但高度冗余的特征也会增加不必要的计算量。处理手段无非是几种相关性矩阵里看数值特征的皮尔逊系数过高的保留一个用方差膨胀因子检测多重共线性这个对线性模型友好还有降维的方式PCA 这一类的做法能压缩特征维度但可解释性会大幅下降。我个人的底线是优先保证特征和业务目标之间有明确的因果逻辑而不是纯粹为了降维度去做 PCA。一个能解释为什么有效的特征比一堆看不懂的压缩成分在后续调试里更有价值。6.4 特征上线前需要做的一致性检查最后聊一个工程上最容易被忽略但后果最严重的环节——训练和线上特征的一致性。我在项目里见过这样的惨案训练的时候用的是当日实时特征上线的时候发现线上特征要滞后一天才能拿到模型预测效果直接崩盘。训练窗口和线上特征的时间口径必须完全对齐这是一条铁律。一致性检查要确认的事情包括特征是否在训练和预测时间点都能拿到特征的缺失值处理逻辑线上线下是否一致特征分布的漂移情况——比如线上用户的分布跟训练集的用户分布相差太大模型表现必然下降。这些检查有时比模型本身更影响最终效果因为一个在训练集上完美的模型线上特征对不齐几乎等于白训。我自己的习惯是每个特征都记录一张元数据表特征名、数据类型、计算口径、窗口范围、缺失值处理方式、上线时间任何特征变更前先看这张表。这个习惯看起来琐碎但真的能在关键时刻救你一命。结尾一点个人的体会写了这么多最想强调的一点是特征类型没有绝对的黄金标准只有在某个场景下更合适的方案。同一份数据换一个模型家族、换一种预测目标最优的特征处理方式可能完全不同。我刚入门那会儿总想找到一个万能配方——把所有特征标准化、把所有类别 one-hot然后跑个 XGBoost 就完事。后来碰壁多了才明白特征工程的每一步选择都值得多问一句为什么为什么这个特征要取对数为什么这个类别不能 one-hot为什么这个时间差要用小时不用天想清楚这些问题比套用任何现成模板都重要。最后分享一个我每次做特征处理都会自查的小清单也算是个人的收尾仪式吧一查是否有不该进模型的未来信息二查训练和预测时的特征口径是否完全一致三查每个特征的分布是否跟业务逻辑对得上四查高阶特征是否可解释能不能说清楚它跟目标之间的因果关系。这四个问题过完特征这块基本就稳了。
