企业官网建设流程全解析

不知道你有没有遇到过这种情况：模型结构换了好几种，超参也调了一轮又一轮，离线指标就是上不去。前面排查了一遍数据管道，最后发现问题的根源不是模型，而是喂进模型的特征编码方式出了问题。特征编码是推荐系统里最基础、也最容易被轻视的一个环节。

推荐系统的基础链路通常是“数据 -> 特征 -> 模型 -> 排序”，特征编码就发生在“数据 -> 特征”这一步。它的核心任务是把原始日志、用户画像、物品属性这些非结构化的业务数据，转换成模型能直接消费的数值向量。原始数据里大量是“菜名”“口味”“食材”“浏览序列”这类文本或者ID，模型不认识这些，只认识数字。编码方式不同，模型看到的信息结构就完全不同——是保持类别独立，还是表达相似性，是保留原始量纲，还是按区间建模非线性，全靠编码这一步来决定。

这篇文章我从三类最常见的特征（类别特征、数值特征、序列特征）出发，分别讲清楚每种编码方式的原理、适用场景和工程落地时的坑，最后用一个“养生食谱推荐系统”的完整案例把整个过程串起来。适合刚入门的推荐算法工程师，也适合那些已经在跑模型但效果总差口气、怀疑是特征问题的同学参考。

1. 特征编码为什么是推荐系统的“隐形胜负手”

1.1 模型只认识数字，但业务数据是另一套语言

推荐系统拿到的原始数据长什么样？我们看几条典型的“养生食谱”场景日志：

• 用户ID：U123456
• 浏览序列：[“红枣枸杞汤”, “银耳莲子羹”, “山药排骨汤”]
• 食谱标签：“温补”, “润肺”, “甜口”
• 用户年龄：32
• 最近一次购买距今：45天

这些字段里有字符串、有列表、有整数，各自表达的业务含义完全不同。模型（尤其是深度学习模型）的输入必须是固定维度的数值张量，所以我们需要一套规则把这些数据翻译成数字向量。这个翻译过程就是特征编码。

这一步看着简单，实际上它对模型能力的上限有决定性影响。一个很直观的说法是：特征编码决定了模型能“看到什么”，模型结构决定了模型能“学到什么”。如果编码阶段丢了信息，后面网络结构再复杂也补不回来。

1.2 不同的编码方式，给模型传递不同的先验知识

为什么说编码方式会影响模型学习效果？原因在于不同的编码会隐式地告诉模型“这些特征之间是什么关系”。

以类别特征为例：

• One-Hot编码隐含的假设是：所有类别之间相互独立，没有相似性。比如“温补”和“滋补”是两个完全独立的维度，模型无法从“温补”的样本中学到什么信息迁移到“滋补”上。
• Embedding编码隐含的假设是：类别之间存在可学习的相似性。“温补”和“滋补”如果经常出现在相似的食谱上，它们的Embedding向量就会在训练过程中逐渐靠近。
• Hash编码介于两者之间：它把类别随机映射到固定维度空间，如果两个类别的Hash值落到同一个桶里，它们就共享同一个特征维度，在某种程度上产生隐式的特征共享。

数值特征也一样：

• 直接喂原始数值，模型只能学到线性关系。体重80公斤和40公斤的用户，对推荐的影响被简化为“翻倍”的关系。
• 做分桶编码后，每桶对应一个独立维度，模型可以自由学习每个区间的独立权重——这等于给了模型拟合非线性的能力。

所以特征编码从来不是简单的格式转换，本质上是你在替模型做了一部分特征工程。你的先验知识、业务理解，全部藏在这些编码规则里。

1.3 特征编码的三个核心评判标准

我在实际项目里判断一种编码方式好不好，通常看三个方面：

1. 保序性：原始特征中带顺序含义的信息，编码后不能被破坏。比如用户的会员等级、食材的热量等级，这些是有序的，编码后模型应该仍然能感知到大小关系。
2. 保相似性：语义上相近的类别，编码后距离应该更近。对于推荐系统来说，这一点尤其重要，因为推荐本质上就是“找相似”。
3. 稀疏度可控：编码后的特征不能过度稀疏，否则梯度传播效率会大幅下降，模型训练慢，还容易过拟合。

后面讲到的每种编码方法，都可以用这三条标准去衡量它是否适合你的场景。

2. 类别特征编码：从One-Hot到Hash再到Embedding的选型逻辑

类别特征是推荐系统中最常见的一类特征。用户ID、物品ID、类目、标签、城市、渠道，全是类别特征。这一节我把四种主流编码方式拆开讲清楚，包括它们各自的适用边界。

2.1 One-Hot与Multi-Hot：最直白，但稀疏性隐患不小

One-Hot编码的逻辑很简单：假设一共有N个类别，构造一个N维向量，当前样本属于第i个类别时，第i维置1，其他维度置0。

Multi-Hot是One-Hot在多值场景下的推广。比如一个食谱打了多个标签（“温补”、“润肺”），就把这些标签对应的位置全部置1。

import pandas as pd def one_hot_encode(values, categories): """最简单的一版One-Hot编码实现，实际项目一般直接用sklearn""" vector = [0] * len(categories) for v in values: if v in categories: vector[categories.index(v)] = 1 return vector

这个方案的优点是简单、可解释性极强、上线调试非常方便。但问题也很突出：

第一，维度爆炸。假设食谱库里有一万个食材ID，每个食材一维，这一万维里绝大部分是0。训练时梯度只会在非0维度上更新，其他维度完全闲着，计算和存储都被浪费。

第二，特征之间完全割裂。One-Hot编码的每个类别是独立的超平面方向，模型无法知道“山药”和“淮山”其实是同一个东西（很多用户在菜谱里混着叫）。你必须在编码之前自己做好别名归并和层级归一，让One-Hot才能正常工作。

所以One-Hot真正适合的场景是类别基数小（记不太住一般少于几百）、类别之间关系不重要的特征。比如“性别”、“渠道来源”、“是否会员”这类。一旦类别基数上万，我必须给你后面的方案。

2.2 Hash编码：工程上的维数灾解药，代价是冲突

Hash编码（也叫Hashing Trick）思路很巧妙：用一个Hash函数把字符串类别映射到一个固定大小的整数区间。比如设定桶数为10000，用MurmurHash3算出“山药排骨汤”的哈希值，再对10000取模，得到它落在第几个桶，这个桶的维度就置1。

import mmh3 def hash_encode(value, num_buckets): # MurmurHash3是工业界最常用的hash函数之一，分布均匀且速度快 return mmh3.hash(value, signed=False) % num_buckets

这样一来，不管原始类别有多少个，输出维度固定。Embedding层可以直接建一个[num_buckets, embed_dim]的向量表，训练成本可控，工程实现简单。

但Hash编码有一个必须直面的问题：哈希冲突。两个不同的类别可能映射到同一个桶。这到底是好事还是坏事，争论很多。

从我实际踩坑的经验来看：一定程度的冲突反而是件好事。假设“红枣”和“枸杞”经常出现在同一个养生食谱场景里，如果它们被哈希到同一个桶，模型就会隐式地把这两个特征做共享，某种程度上自动完成了“相似性学习”。这也是为什么很多工业级推荐系统会把Hash当成Embedding的降维前置方案来用。

但冲突率太高的风险在于：某个频繁出现的类别把桶占满了，其他被映射到同一桶的类别完全学不到自己的表征。实操中的解法是：

1. 桶数设置要足够大。经验值一般是类别基数预估的2到4倍，保证冲突率在10%以内。
2. 对高频类别单独做白名单，白名单内的值不参与Hash，直接分配独立Embedding维度。
3. 对极低频类别（出现次数小于阈值）直接统一归入一个UNKNOWN桶，避免Hash噪声。

2.3 低频类别：清洗优先于编码

这是很多项目最容易忽视的一环。类别的长尾分布非常严重——大量的类别只出现了一两次，这些低频类别无论用Hash还是Embedding都学不到可靠表征。

我的标准做法是先做频次统计，再做编码决策：

这个阈值的设定要结合样本量动态调整。如果全集有1亿样本，频次100只是起步线；如果只有10万样本，那频次阈值可以放宽到5。

2.4 Embedding编码：当类别基数大到需要“学习相似性”

One-Hot的维度太高，Hash的随机映射不可控，那就让模型自己学一个低维稠密向量。这就是Embedding。Embedding本质上就是一个查找表：先给每个类别分配一个编号，然后定义一张[类别数, 维度]的矩阵，训练过程中这个矩阵和其他网络参数一起被梯度更新。

Embedding的适用前提是：类别有足够样本量去支撑向量学习，而且类别之间确实存在相似性结构。用户ID、物品ID这类高基数特征用Embedding几乎是标配。但也别一上来就无脑Embedding，它有两个需要你注意的工程点：

1. Embedding维度怎么定？经验公式是min(100, ceil(log2(类别数)))起步，再按效果上调。类别数10万，设64维就是一个比较稳的起点。
2. Embedding表很大怎么存储？推荐系统全量物品ID动辄千万级，一张百万行乘128维的Embedding表，光存储就好几个GB。常规解法是借助Hash Embedding：先用Hash把千万类别压到百万桶，再做Embedding，然后用辅助Hash把少数冲突列单独分开。

class HashEmbedding(nn.Module): def __init__(self, num_buckets, embed_dim): super().__init__() self.embedding = nn.Embedding(num_buckets, embed_dim) def forward(self, raw_feature): # 先用hash压缩，再查表 buckets = raw_feature % self.embedding.num_embeddings return self.embedding(buckets)

分享一个我的筛选心得：当类别基数小于1万，且业务上“类别间相似性”不是核心关注点的时候，用Hash比Embedding更省事；当类别基数大、且“相似的类别应该靠近”这件事是模型的关键能力时，直接上Embedding。

3. 数值特征编码：归一化只是及格线，分桶才是真正的杀器

类别特征讲完了，接下来是数值特征。数值特征看起来最“省心”——因为本来就是数字，直接喂进去不就行了吗？实际没那么简单。

3.1 为什么直接喂原始数值经常效果不好

直接喂原始数值有两个隐患：量纲问题和线性假设问题。

量纲问题很好理解。“年龄32”和“最近购买距今天数45”不在一个量级，但更麻烦的其实是“最近观看时长3600秒”和“点击次数2”这种差距悬殊的特征。模型在梯度下降时，量纲大的特征会主导损失函数的梯度，量纲小的特征学习被压制。

线性假设问题更隐蔽。用户的购买意愿和“距上次购买天数”之间大概率不是一个线性关系——刚买完1天和买完30天的人，意愿通常差距很大；但买完30天和买完31天的人，差距几乎可以忽略。如果你直接把天数作为原始数值喂给模型，模型只能学到一个全局系数w，这个w要么被第1天的用户带偏，要么被第30天的用户带偏。

3.2 分桶：给模型一把非线性的钥匙

分桶的本质是把连续值离散化成有限个区间，每个区间对应一个One-Hot或Embedding维度。这样模型就能为每个区间学习独立的权重，等于隐式地拥有了拟合非线性关系的能力。

三种主流分桶方式：

• 等宽分桶：按数值范围均匀切分。比如年龄0-100，每10岁一桶。实现最简单，但数据分布不均匀时很多桶是空的。
• 等频分桶：按分位数切分，每个桶的样本量大致相等。这个方法对抗长尾分布非常有效。
• 卡方分桶（ChiMerge）：基于目标变量做有监督分桶，把“对目标影响相似”的区间合并。效果最好，但实现复杂度高，且只在训练集上做。

import pandas as pd # 等频分桶：按分位数切成5桶 ser = pd.Series([1, 2, 3, 4, 5, 6, 7, 8, 9, 1000]) pd.qcut(ser, q=5, labels=False, duplicates="drop") # 输出: 0 0 0 1 1 2 2 3 3 4

我个人的实践经验是：先把特征分布画出来，如果分布接近正态或者均匀，等宽就行；如果长尾严重，优先等频；如果有明确的业务阈值（比如会员等级T1/T2的消费分界线），以业务阈值为准，先手工切分再结合分位数调整边界。

3.3 归一化与标准化的线上线下一一致性坑

分桶并不排斥归一化，两者经常一起用。归一化就是把数值压到[0,1]区间（Min-Max），或者缩放到均值0方差1（Z-Score）。

这里有一个非常常见的坑：很多人用全量数据的均值和标准差做归一化，模型离线效果很好，上线后线上预测值全部偏掉。

原因在于统计量本身存在“数据穿越”：归一化时使用的均值来自全体数据，训练集中每一条样本都“偷看”了全局分布信息。更严重的是，线上的实时数据分布会随时间漂移，训练集的均值和上线后的实际均值对不上，编码结果就系统性偏移。

正确做法是这样的：

1. 只用训练集的统计量做归一化，验证集和测试集都复用同一个统计量。
2. 把训练集的均值、标准差、Min、Max固化成一个独立的统计文件，随模型一起发布上线。
3. 上线后持续监控线上特征分布，如果均值偏移超过阈值，就要考虑重新训练或在训练集中加入近期数据。

# 正确做法：只在训练集上fit，然后对全部分区应用同一个scaler from sklearn.preprocessing import StandardScaler scaler = StandardScaler() train_norm = scaler.fit_transform(train[[feature]]) val_norm = scaler.transform(val[[feature]]) test_norm = scaler.transform(test[[feature]])

3.4 数值缺失的处理顺序：先分析缺失原因再选填充方式

很多项目一遇到缺失值就“均值填充”或者“0填充”，这其实是个懒办法。我踩过坑后的处理顺序是：

1. 先查缺失比例。缺失率超过70%的特征，直接考虑删除或者加一个“是否缺失”的独立标志位。
2. 再查缺失机制。如果是“无购买行为导致的缺失”，你填充0反而是对的，因为它有业务含义；如果是“数据上报链路断了导致的缺失”，0填充就是在引入脏数据。
3. 最后选择填充值。数值型的一般用中位数而不是均值，因为中位数对异常值鲁棒。填充完之后，强烈建议额外加一列“was_missing”标志位，让模型自己学会缺失时的默认行为。

4. 序列特征编码：用户行为的“顺序”里藏着下一单

推荐系统里还有一类特征地位特殊：用户行为序列。这类特征编码的复杂度比前两类高很多，因为要处理的不是一个点，而是一串行为事件。

4.1 序列特征的本质：一张用户兴趣快照

行为序列的一般表现形式是用户在某个时间窗口内交互过的物品ID列表，比如：

behavior_seq = [10234, 10891, 10234, 20567, 30912] # 食谱ID列表

这个序列用最朴素的方式记录了用户兴趣的变化轨迹。用户在推荐系统里留下的每一次点击、收藏、下单，都是兴趣信号；而它们的顺序，则记录了兴趣转移的过程。序列编码的核心任务就是把这串ID变成模型能消费的固定维度特征向量，同时尽量保住顺序信息和上下文关系。

4.2 序列长度不一致：截断、补齐与掩码

用户的交互序列长度天然不同，新用户可能只有1条行为，重度用户可能有几百条行为。但模型的输入维度是固定的，这就需要截断和补齐。

截断策略有一个需要你想清楚的问题：保留最近的还是保留最久的？我建议保留最近的N条，因为推荐场景中用户的近期兴趣往往比长期兴趣对下一单的影响更大。序列长度N如何确定，先统计一下线上用户序列长度的分布，取P80或者P90长度作为截断上限，不是拍脑袋定。

补齐策略一般用0作为padding值。注意这里有个容易被坑的点：padding出来的0和其他真实物品ID混在一起，模型会误以为“0”也是一个真实的物品。所以序列输入必须配套一个mask，让模型知道哪些位置是真实行为，哪些是padding出来的。

# 序列截断 + padding，同时输出mask def pad_sequence(seq, max_len): if len(seq) > max_len: seq = seq[-max_len:] # 保留最近的 mask = [1] * len(seq) seq = seq + [0] * (max_len - len(seq)) # 0是padding位 mask = mask + [0] * (max_len - len(mask)) return seq, mask

4.3 序列Embedding化：从平均池化到注意力加权

有了截断、补齐和mask之后，序列可以做Embedding化。最朴素的做法是：把序列里每个物品ID查表得到Embedding，然后做平均池化，得到一条定长的用户兴趣向量。

平均池化有个潜在问题：序列里的行为权重被平均了。“看了三秒就划走”和“反复看了十遍”是同一个权重。更进阶的做法是引入注意力机制，让模型自己学习每个行为的重要性。

我在实际项目里发现一个规律：序列嵌入的收益在某些场景特别明显，但有些场景用了反而跌点。一个典型的反例是“新手引导类推荐”中，用户序列极短，平均序列长度只有2-3，这个时候学出来的序列嵌入非常不稳定，单纯用用户画像特征反而更稳。所以如果你的场景用户行为稀疏，不要强行上序列模型。

4.4 序列特征里的“时间衰减”细节

除了物品ID序列本身，我一直会加一个时间衰减因子。原理很简单：离当前越远的行为，参考价值越低。具体落地时用不着复杂的模型，一个指数衰减系数就够了：

decay = exp(-alpha * (current_time - event_time))

把这个系数乘到每个行为的Embedding上，再做池化，就能让模型“更关心最近的行为”。alpha的取值一般参考业务节奏：对生鲜/食品这类快消品，alpha可以设置得大一点（比如0.01），让近3天的行为主导兴趣；对耐用消费品，alpha要小得多，用户三个月前的偏好仍然有效。

5. 完整实战：养生食谱推荐系统的特征编码落地

前面四节把三类特征的编码原理讲完了，这里我用一个“养生食谱推荐系统”的案例，把整套编码流程串一遍，方便你完整落地。这个场景的好处是特征类型齐全：有画像、有内容属性、有用户行为序列，覆盖了推荐系统的大部分典型字段。

5.1 业务场景与数据概况

场景设定：一个面向中青年用户的养生食谱App，首页需要给每个用户推荐可能感兴趣的热菜谱。候选池有约5万道食谱，每道食谱有标题、食材、功效标签、口味类别、制作难度、预计耗时等属性；用户侧有性别、年龄段、常驻地区、健康偏好；行为侧有点击、收藏、下单长短期序列。

这个场景的特征编码选型，直接决定推荐效果的上限。下面是我最终的选型表：

5.2 编码实现过程中的三个典型坑

这套编码在一次实际落地中踩过的坑我记录一下，都是可以直接避免的典型错误。

坑一：食谱的“食材列表”和“功效标签”直接拼接成一个Multi-Hot，导致模型无法区分“红枣”是食材还是功效来源。解决办法是把两类特征分别编码后再拼接，而不是简单把ID合并。

坑二：用户ID的Embedding在冷启动场景下严重过拟合。新用户只有1-2条行为记录，学出来的Embedding基本是噪声。我的处理方式是：对于行为数少于10的用户，直接不参与ID Embedding训练，用一个统一默认向量代替，等行为积累够了再动态切换。

# 冷启动用户：模型内做embedding替换 def get_user_embedding(user_id, behavior_count, embedding_layer): if behavior_count < 10: return DEFAULT_USER_VECTOR # 全局统一冷启动向量 return embedding_layer(user_id)

坑三：点击序列里存在大量“无效短点击”。用户点开食谱详情页不足3秒就退出，这种行为的兴趣信号极其微弱。我做序列清洗时的规则是：过滤掉停留时长小于3秒的点击；对同一天内对同一道食谱的重复点击，只保留最近一次。这一步清洗之后，序列特征带来的离线AUC提升明显更稳定。

5.3 离线评估对比：不同编码方案的差异

这套编码做完以后，我用同一份训练集和同一个DeepFM模型，对比了三组特征编码方案的离线效果。结果很能说明问题：

可以看到，只是把特征编码从方案A升级到方案B，AUC就有接近3个点的提升——这一步完全不需要改模型结构。方案C的额外提升主要来自序列特征和ID类特征的Embedding化。

6. 上线之前必须自查的5个特征编码细节

线上效果经常和离线评估对不上，原因很多都出在“线下编码逻辑”和“线上编码逻辑”不一致。我整理了一份自查清单，每次上线前按着过一遍。

6.1 训练集与线上预测的编码一致性

这是第一号杀手。训练时很多新手会用全部数据一起fit编码器，然后切分训练集测试集；线上预测时单独加载一个模型，编码逻辑完全另起炉灶。这就直接导致了离线很好、线上崩盘。

正确的做法是：编码器的参数（Hash桶数、分桶边界、归一化统计量、Embedding映射表）全部在训练阶段固化，序列化成一个独立的“特征编码配置”文件发布。线上服务加载这个配置，用同一套规则做编码。训练和预测用到的每一个类别的映射关系，都应该能在同一个配置里找到。

6.2 编码表的版本管理与回滚

特征编码配置是有生命周期的：业务新增类目后，Hash桶的统计边界会变化；Embedding表会随模型重训而更新。所以编码配置也要和模型一样做版本管理。

我的做法是把“编码配置版本号”作为模型产物的一部分，和模型参数一起打包。每次重训生成一个新版本，线上同时保留上一版本，一旦新版本出现指标异常，随时可以回滚到旧版本。如果编码逻辑和模型参数分开管理，回滚时还要同时处理两份产物，出问题的概率会大很多。

6.3 特征穿越：用未来信息编码当前样本

特征穿越是指样本的某个特征里面包含了它不该看到的信息。最常见的情况是：用全量数据的统计量做归一化或分桶边界，训练集里每一条样本都“偷看”了全局分布，包括未来数据的分布。这一点在第3节已经重点讲过。

另一个容易忽略的场景是序列特征：用“用户整个周期的行为”做序列，而不是用“截至当前样本发生时刻之前的行为”。这在离线构造训练样本时极其常见，看似的确用了用户行为，实际上混入了未来信息。必须按时间切分，构造训练样本时只取该样本发生时间之前的行为，这个检查一定要做。

6.4 空值处理要分特征类型，不要全量“填0”

不同特征的空值含义完全不同。用户“未登录”导致ID为空，和一个合法ID不存在，对业务的影响是不同的。我的建议是：每一类特征单独制定空值方案，并增加“是否缺失”标志位。在代码层面，空值可以在特征签名里明确标记，防止线上和线下走了不同的分支。

6.5 监控特征分布漂移，而不是只盯线上AUC

特征编码上线后不是一劳永逸的。用户行为习惯在变，食谱内容池在更新，任何变化都会导致线上特征分布和训练集的分布逐渐偏移。比如：新上了几十道“秋冬润燥”食谱，它们的功效标签高频出现，导致某些Hash桶的点击率发生明显变化。

我现在的做法是每天对Top特征做分布监控，和训练集基线对比。如果某个分桶的样本占比偏移超过阈值，或者归一化后的均值漂移超过3倍标准差，就会触发告警。告警之后人工判断是重新训练还是调整规则。

我自己在实际项目里养成了一个习惯：每次拿到一个新数据集，先花半天把特征分布画一遍，做频次统计和缺失分析，再开始动手搭模型。特征编码的部分看起来不“高级”，但它往往才是决定模型最终效果的那块短板。希望这篇整理能帮你少走一些我走过的弯路。