TensorFlow feature_column深度解析：indicator_column与embedding_column对比与选型

做搜索、推荐、广告这类稀疏场景的，对 TensorFlow 的 feature_column 应该都不陌生。用户ID、商品ID、城市、性别、小时段，这些类别特征没办法直接塞给 Dense 层，总得先转成某种数值表达。我在 feature_column 上花过不少时间，印象最深的就是两个 API 老被拿来对比：tf.feature_column.indicator_column（指示列）和tf.feature_column.embedding_column（嵌入列）。名字好懂，一个指示、一个嵌入，但真到了选型的时候，文档翻完还是一头雾水。

这篇文章就是把这两者彻底讲清楚。我会从底层的 categorical_column 讲起，对比 one-hot 式的指示列和低维查找表式的嵌入列，给出适用场景、参数设置、可运行的示例，还有我这几年的实践经验。适合正在用 TensorFlow 做结构化数据建模、推荐系统或者 CTR 预估的读者，尤其是刚接触 feature_column 不久、对这两个 API 差异感到困惑的人。

1. 先搞清楚 feature_column 在模型里的真实位置

1.1 特征处理管线里的“最后一公里”

在动手之前，得先把 feature_column 放在整个训练链路里的位置弄清楚。很多教程上来就讲 API 用法，忽略了这个背景，导致后面一出错就不知道查哪里。我自己的理解是：特征处理通常分成两段。前一段是数据清洗、缺失值填充、归一化，这些操作发生在 DataFrame 或 tf.data.Dataset 里，本质上是原始的取数与加工。后一段才是模型直接消费的结构化输入，也就是把离散字符串、整数 ID 这类语义信息转换成数值张量。feature_column 属于后者，它不算特征工程工具，而是模型输入适配层。

举一个最简单的例子。训练数据里有一列叫 gender，取值是字符串 "male" / "female"。你不能把这个字符串直接喂给神经网络。传统做法是先做 LabelEncoder 变成 0/1，再在模型里做 Embedding 或 One-Hot。feature_column 做的事情和这个过程高度相似，只不过它把转换过程变成了声明式 API。你只需要声明“这列是类别特征，离散取值有哪些”，剩下的转换交给框架完成。

这一步“最后一公里”往往是性能的关键。特征列一旦声明错了，后面模型结构再漂亮，学到的也是错误信号。再加上特征列会参与模型导出和线上 Serving 的输入解析，如果这里埋了雷，排查成本非常高。我在实际项目中见过不少案例，模型离线指标一直上不去，最后发现是特征列类型选错了，该用 embedding 的地方用了 indicator，或者把数值特征误当成类别特征处理。

1.2 indicator_column 和 embedding_column 不是“平级”关系

这是我最想强调的一点。光看名字，总觉得 indicator_column 和 embedding_column 是并列的两种特征列，其实不是。在 TensorFlow 的实现里，它俩都必须包裹在一个 categorical_column 之上。也就是说，它们共用的底座是“类别列”。你得先定义好一个类别列，指示列和嵌入列才有东西可包。

类别列负责把原始输入（字符串、整数）映射成稀疏的类别 ID。比如categorical_column_with_vocabulary_list就是给一份词表，把 "male" 映射成 0、"female" 映射成 1。而 indicator_column 负责把稀疏类别 ID 变成 multi-hot 的稠密向量；embedding_column 负责把类别 ID 通过查表变成低维稠密向量。这一点务必先建立起来，否则后面所有参数都容易理解错。

所以这篇文章真正的讨论对象，是“从类别 ID 到模型输入张量”的两种转换策略。一个偏向传统的 one-hot / multi-hot，一个偏向学习的分布式表示。理解了这层关系，再看两者参数就清楚多了。很多人纠结 indicator_column 和 embedding_column 能不能互换，从数学上当然可以——都是把类别 ID 变成数值向量——但效率和效果差别很大，具体差别下文展开。

2. indicator_column：最接近 one-hot 的落地姿势

2.1 指示列到底在算什么

indicator_column 的行为，本质上就是 one-hot 的“多值版”。如果类别特征是单选，它输出 one-hot；如果是多选，比如用户的兴趣标签列表，它输出 multi-hot。在多值情况下，输出向量的长度等于词表大小，出现过的类别对应位置为 1，其他为 0。

从实现角度看，输入是一个 SparseTensor，每个样本对应若干整数 ID。indicator_column 做的就是根据词表大小，把每个 ID 散到一个定长的稠密向量里。可以拿 numpy 类比去理解：batch_size = 3、词表大小 = 6，三个样本分别包含 {1, 3}、{0, 2, 5}、{4}，输出就是三行 6 列的 0/1 矩阵。这比看十页文档都直观。

正因为输出是 0/1 的稠密向量，它天然不引入可学习的参数，梯度不会反传到特征表示上。这个特性在特征维度可控时是优点——简单、稳定、可解释；在词表很大时就是灾难——输出维度会爆炸，模型参数数量直接跟着涨。

2.2 一套代码看穿 indicator_column 的输出

直接跑一段代码观察输出，比任何解释都直观。我用两个特征列做例子，一个是 vocabulary_list 词表列，一个是 identity 整数 ID 列。

import tensorflow as tf # 词表列：字符串映射成 ID color = tf.feature_column.categorical_column_with_vocabulary_list( key="color", vocabulary_list=["red", "blue", "green"] ) color_indicator = tf.feature_column.indicator_column(color) # identity 列：整数 ID 直接使用，0-23 表示 24 个小时 user_hour = tf.feature_column.categorical_column_with_identity( key="user_hour", num_buckets=24 ) hour_indicator = tf.feature_column.indicator_column(user_hour) # 用 DenseFeatures 把转换列变成稠密张量 feature_layer = tf.keras.layers.DenseFeatures([color_indicator, hour_indicator]) inputs = { "color": tf.constant([["red"], ["blue"], ["green"]]), "user_hour": tf.constant([[8], [14], [23]]) } result = feature_layer(inputs) print(result.shape) # (3, 27)

输出 shape 是 (3, 27)，其中 color 贡献 3 维，user_hour 贡献 24 维，DenseFeatures 会把这俩拼接成一个整体向量。color 那一段是标准的 one-hot，user_hour 那一段也是 one-hot，整个向量的含义非常清晰。

这里有个容易被忽略的细节：DenseFeatures 拼接时，列的顺序就是你传入列表的顺序。调试的时候，可以根据这个顺序去对应结果向量的不同分段，定位哪一段特征出了问题。比如你在排查 user_hour 维度，直接看 result.numpy() 的后 24 位就行了。

2.3 什么场景选 indicator_column

什么时候毫不犹豫地用 indicator_column？我的经验是：当类别取值数量小且稳定时。几个典型例子：

• 星期几，取值 0-6
• 性别，男/女/未知
• 常用城市，Top50 以内
• 商品类目，几百个以内
• 用户历史行为标签，数量可控且需要强可解释性

一般词表大小在几百以内，indicator_column 都是划算的。原因很简单：one-hot 输出维度不大，模型参数增加有限，而且每个类别独立学习权重，在样本量充足时往往更直接有效。还有一个隐形的优势是调试友好。你看到一个样本的向量，一眼就能看出哪些特征位置被激活了，这在排查特征链路问题是很有用的。

边界也很明显。词表上万时，输出维度过大，全连接层接上来参数量是词表大小乘隐层维度。10 万词表接一个 128 维隐层，光这一层就是 1280 万参数，训练和推理成本都明显上升。另外，对于取值不断增长的类别，比如新用户 ID 不断出现，indicator_column 的 vocabulary 方式也会失效，需要配合 hash bucket 或者直接换 embedding。真到了这一步，就该切到第三章的内容了。

3. embedding_column：把高维稀疏压成低维稠密

3.1 为什么需要 embedding：从维度爆炸说起

embedding 这个概念大家都不陌生，NLP 里到处是 word embedding。本质上是把稀疏的高维 one-hot 表示，映射到一个低维稠密的连续向量空间，让语义相近的类别在向量空间里距离也近。feature_column 里的 embedding_column 做的就是这件事。

它和模型里自己写一个tf.keras.layers.Embedding有什么区别？这是个很实际的问题。从结果来看几乎是一回事——embedding_column 底层维护一个形状为 (vocab_size, dimension) 的查找表，根据输入的类别 ID 去取对应的行向量。区别在于你不需要手动管理 ID 映射和查表逻辑，而且它和 DenseFeatures 配合时能自动处理多值特征的合并，方便很多。

这里有个很重要的认知：embedding 向量不是天生语义化，而是通过训练任务学出来的。同一个类别特征，在 CTR 二分类任务里学到的向量，和在多分类任务里学到的向量，表达的含义不一样。所以先别指望预训练，大多数业务场景下，随机初始化、跟随主任务训练反而更直接。

3.2 参数详解：dimension、combiner、trainable

embedding_column 的签名长这样：

tf.feature_column.embedding_column( categorical_column, dimension, combiner="mean", initializer=None, trainable=True )

逐一来说。categorical_column 是要包裹的底层类别列，这个前面已经强调过。dimension 是嵌入向量的维度，最影响模型容量的参数。combiner 是多值特征的合并策略，很多人会忽略它。当一个输入样本对应多个类别 ID 时，查找表取出来的多行向量需要合并成一个固定长度的向量。mean 是取平均，sum 是求和，sqrtn 是按 L2 范数归一化后求和。

trainable 是控制 embedding 是否随训练更新的开关。冻结时，它相当于一个随机初始化且固定的特征映射，一般很少用，但在某些增量训练或多任务场景下会用到。initializer 决定初始化方式，默认用随机均匀分布，一般不需要动，除非你有预训练向量要加载。

看一个基础示例：

user_id = tf.feature_column.categorical_column_with_hash_bucket( key="user_id", hash_bucket_size=10000 ) user_emb = tf.feature_column.embedding_column( categorical_column=user_id, dimension=16, combiner="mean" ) feature_layer = tf.keras.layers.DenseFeatures([user_emb]) inputs = {"user_id": tf.constant([["u123"], ["u456"], ["u789"]])} result = feature_layer(inputs) print(result.shape) # (3, 16)

输出 shape 是 (3, 16)，每个 user_id 被映射成一个 16 维的稠密向量。这 16 维到底代表什么，没人能直接解释，但通过训练，它会把行为模式相近的用户放到向量空间中相近的位置。

3.3 embedding 维度到底怎么定

这是所有新人最爱问的问题。先说经验结论：维度通常在 4 到 64 之间，具体取决于样本量和类别实际复杂程度。常见做法之一是把词表大小的 4 次方根作为参考起点。词表 10000，4 次方根大约是 10；词表 100 万，4 次方根是 31 左右。这个经验公式不算严谨，但作为起点，比我当年拍脑袋定 128 要好用得多。

还要考虑业务信号本身能不能支撑高维表达。如果这个特征和预测目标关系很弱，你给它 64 维，学出来的很可能就是一堆噪声参数。数据量大、特征重要，维度可以往 32 或 64 走；数据量小，8 或 16 反而更稳。我自己见过的推荐模型里，user_id、item_id 这类核心特征用 32-64 维，其他辅助特征 8-16 维，是相对合理的配置。

实践里我会用多组维度做小规模对比。同一个模型分别试 [8, 16, 32, 64]，看验证集指标变化。维度越大，训练越慢、越容易过拟合，收益到一定程度就平了，这时候就该收敛到平台期的维度上。这个对比实验的成本不高，但能避免拍脑袋带来的无效算力浪费。

3.4 和手写 Embedding 层相比，feature_column 的 embedding 好在哪

有些同学已经习惯了自己搭 Embedding 层，觉得 feature_column 只是换了个写法。实际工程里，feature_column 的价值主要在两点。第一是自动处理多值特征。手写时你得自己维护一个 SparseTensor 再套 embedding，然后做池化；embedding_column 配合 DenseFeatures，直接把这些逻辑封装好了，代码量少很多。

第二是训练与线上推理的一致性。模型导出为 SavedModel 后，原始字符串输入进来，特征列会自动完成映射和查表。这就意味着线上不需要再额外部署一套 ID 映射服务。手写 Embedding 层的话，你需要自己保证训练时的 ID 映射和线上请求时的映射完全一致，稍有不慎就出数据偏差。

不过这也不意味着 embedding_column 永远优于手写层。如果你的模型结构特别定制，比如要做双塔或者序列特征拼接，手写反而更灵活。feature_column 的 API 相对封闭，自定义行为不如直接写层来得直接。我的习惯是：能用 feature_column 就用 feature_column，遇到它搞不定的结构，再局部手写。

4. 从 categorical_column 到 indicator/embedding 的完整实操

4.1 底层类别列的选型：identity、vocabulary、hash_bucket

在组装 indicator_column 或 embedding_column 之前，必须先定义 categorical_column。TensorFlow 提供了几种常用类别列，选错会影响整体效果。

选型原则其实就一句话：能枚举的用 vocabulary，不能枚举的用 hash bucket。identity 适合输入本身就是连续整数编号的场景。hash bucket 会引入碰撞，bucket 大小一般设为预期取值数量的 2-4 倍，能有效降低碰撞概率。比如线上用户量约 500 万，bucket 可以取 1000 万到 2000 万。

4.2 多特征组装：DenseFeatures 的输出怎么拼接

实际模型不会只用一两个特征，得把多个转换列合成一个大的输入向量。DenseFeatures 承担的就是这个职责。组合示例：

import tensorflow as tf gender = tf.feature_column.categorical_column_with_vocabulary_list( key="gender", vocabulary_list=["male", "female", "unknown"] ) item_id = tf.feature_column.categorical_column_with_hash_bucket( key="item_id", hash_bucket_size=5000 ) weekday = tf.feature_column.categorical_column_with_identity( key="weekday", num_buckets=7 ) gender_ind = tf.feature_column.indicator_column(gender) device_ind = tf.feature_column.indicator_column(weekday) item_emb = tf.feature_column.embedding_column(item_id, dimension=12) feature_layer = tf.keras.layers.DenseFeatures([gender_ind, device_ind, item_emb]) inputs = { "gender": tf.constant([["male"], ["female"], ["unknown"]]), "weekday": tf.constant([[1], [5], [0]]), "item_id": tf.constant([["i_1001"], ["i_2002"], ["i_3003"]]) } out = feature_layer(inputs) print(out.shape) # (3, 22)

这里 3 维来自 gender 的 one-hot，7 维来自 weekday 的 one-hot，12 维来自 item_id 的 embedding，拼接成 22 维输出。用 DenseFeatures 的好处是，不同类型的列可以混搭，拼接顺序由你传入的列表控制。调试时要知道每个分段的起止，这样才能定位是哪一段特征的值出现了异常。

4.3 可运行的 CTR 模型 demo

下面给一个能直接跑的完整示例。模拟一个二分类场景，特征里有字符串类别、整数类别和高基数类别，分别用 indicator 和 embedding 处理。

import numpy as np import tensorflow as tf # 1. 特征列定义 gender = tf.feature_column.categorical_column_with_vocabulary_list( key="gender", vocabulary_list=["male", "female"] ) hour = tf.feature_column.categorical_column_with_identity( key="hour", num_buckets=24 ) city = tf.feature_column.categorical_column_with_hash_bucket( key="city", hash_bucket_size=500 ) item_id = tf.feature_column.categorical_column_with_hash_bucket( key="item_id", hash_bucket_size=10000 ) features = [ tf.feature_column.indicator_column(gender), tf.feature_column.indicator_column(hour), tf.feature_column.embedding_column(city, dimension=8), tf.feature_column.embedding_column(item_id, dimension=16) ] feature_layer = tf.keras.layers.DenseFeatures(features) # 2. 构造模拟数据 N = 1024 data = { "gender": np.random.choice(["male", "female"], size=N), "hour": np.random.randint(0, 24, size=N), "city": np.array([f"c_{i % 300}" for i in range(N)]), "item_id": np.array([f"item_{i % 9000}" for i in range(N)]), } labels = np.random.randint(0, 2, size=N).astype(np.float32) ds = tf.data.Dataset.from_tensor_slices((data, labels)).batch(64).shuffle(N) # 3. 模型 inputs = { "gender": tf.keras.Input(shape=(1,), name="gender", dtype=tf.string), "hour": tf.keras.Input(shape=(1,), name="hour", dtype=tf.int64), "city": tf.keras.Input(shape=(1,), name="city", dtype=tf.string), "item_id": tf.keras.Input(shape=(1,), name="item_id", dtype=tf.string), } x = feature_layer(inputs) x = tf.keras.layers.Dense(64, activation="relu")(x) x = tf.keras.layers.Dropout(0.3)(x) out = tf.keras.layers.Dense(1, activation="sigmoid")(x) model = tf.keras.Model(inputs, out) model.compile(optimizer="adam", loss="binary_crossentropy", metrics=["accuracy"]) model.fit(ds, epochs=3)

这段代码可以直接跑。注意tf.data.Dataset.from_tensor_slices传入的是 dict，key 必须和特征列的 key 完全一致。训练时 DenseFeatures 会自动从 dict 里取对应字段做转换。实际数据里你会遇到稀疏取值不均匀的问题，随机生成的 demo 数据只是演示链路，不代表真实分布。

4.4 训练与导出时最容易忽略的问题

训练只是第一步。模型要上线，经常需要导出 SavedModel 并写 serving 输入签名。feature_column 的优势在于：只要保存模型时使用的特征列和训练时一致，导出后的模型在推理时也能自动完成特征转换。用户传原始字符串进来，模型内部先做映射再预测。这让线上特征处理逻辑和训练保持了一致，省去了单独部署特征服务的麻烦。

不过坑也在这里。线上请求如果出现训练时没见过的取值，行为会分几种情况。vocabulary_list 类的列，未登录词会被映射到默认的 OOV 位置；hash_bucket 会照常 hash，只是可能碰撞；identity 列如果取值超过 num_buckets 范围，会直接报错。所以线上特征校验特别重要。我的习惯是在入口对取值做合法性校验，尤其是 identity 列，越界值提前拦截，避免推理时抛异常。

5. 常见问题与排查技巧实录

5.1 DenseFeatures 输出形状对不上

最常见的现象：feature_layer 输出的维度和自己手算的对不上。原因多半在于 categorical_column 定义和实际输入不匹配。比如 identity 列设置 num_buckets=24，但输入数据里出现了 25 以上的值，框架可能直接抛 OutOfRange 错误。另一种可能是 DenseFeatures 没有把所有转换列传进去，漏掉列是最容易犯的错。

排查方法很固定：先打印 feature_layer 输出 shape，手工算一遍每个列贡献的维度，加起来对一下。如果对不上，逐个列单独用 DenseFeatures 包起来输出观察。这种二分定位法，绝大多数形状问题十分钟内能解决。

5.2 词表太大用 indicator 导致内存和训练成本飙升

这个我踩过。早期有个实验，把用户历史浏览的商品子类目做了 indicator_column，类目大约 2 万个，每个用户平均有 30 个类目标签。one-hot 输出维度直接 2 万，第一层全连接参数量到了千万级。训练倒没崩，但显存和耗时明显上涨，指标提升非常有限。

后来换成 embedding_column，16 维，参数量、训练速度、离线指标全面改善。从那以后，超过几千的取值我基本只用 embedding。这个阈值不一定通用，但至少给你一个参考线。特征维度小、需要可解释性，indicator；特征维度大、需要泛化性，embedding。

5.3 hash bucket 碰撞与 bucket size 的选择

hash_bucket 的好处是不需要维护词表，坏处是碰撞。两个不同的字符串如果 hash 到同一个桶，模型看到的就是同一个特征。碰撞率做不到 0，但可以控制。假设真实取值数量是 V，bucket 大小 B，碰撞率大致和 V/B 正相关。经验上 B 取预计取值数量的 2-4 倍比较稳妥。

具体到代码，如果你统计出训练集有 800 万不同的 item_id，hash_bucket_size 就可以往 2000 万以上设。太小了碰撞严重，太大浪费内存。另外要注意，hash 函数在不同进程中通常是稳定的，但换了 TensorFlow 版本之后，内部 hash 行为可能有差异，做版本升级时记得回归验证特征效果。

5.4 多值特征 combiner 怎么选

一句话总结：大多数情况下先试 mean。它对不定长的多值输入有归一化效果，数值范围稳定。sum 在特征强度带权重的场景下有优势，比如“用户对某类目点击了 5 次”这类计数信息，sum 能保留数量差异。sqrtn 介于两者之间，用 L2 归一化避免长列表把数值撑得过大。

我在实际项目里踩过 combiner 的坑。某个模型里用户历史兴趣标签是多值特征，用 sum 时 embedding 输出的数值直接翻了好几倍，后续 Dense 层输入分布被拉得很大，模型不容易收敛。换成 mean 之后，指标立刻回归正常。所以如果特征后面还拼接其他维度的特征，优先 mean，避免数量级忽高忽低影响后续层的稳定性。

5.5 TF2 下 feature_column 的几个隐藏坑

在 TF2 的 Keras 模型里用 feature_column，有几个点很容易踩。

第一，DenseFeatures 层在 model.fit 时可以自动从 Dataset 的 dict 里取数，但如果你手动构造了 Keras Input，必须保证 dict 的 key 和特征列的 key 完全一致，大小写、空格都不能错，否则报错信息还很隐晦。

第二，feature_column 定义在函数内部时，每次调用会重新创建变量，容易出现“变量已存在”的报错。尽量把特征列定义成模块级常量或类属性，在初始化阶段就创建好。

第三，embedding_column 的初始化随机种子默认不固定，复现实验时要设置全局种子，否则两次训练的初始化结果不同，在小数据集上很容易得出错误的对比结论。

第四，和 tf.keras.layers.DenseFeatures 一起用时，特征列列表的顺序会影响输出拼接顺序，也影响模型输入层的顺序，导出模型时接口参数顺序必须和训练时保持一致。

这类问题在文档里都不显眼，但遇到时非常花时间。记录一下，能省不少调试的功夫。

我在自己的项目里已经形成了一套固定习惯：能枚举且数量小的，用 vocabulary_list 加 indicator_column，保留可解释性；开放集合的大词表，用 hash_bucket 加 embedding_column，稳定且省内存；多值特征一律配 combiner="mean"。这套组合在多个 CTR 实验里都表现稳定。当然，没有放之四海而皆准的配置，最重要的还是理解 indicator_column 和 embedding_column 各自在做什么——一个把 ID 铺平成稀疏向量，一个把 ID 压进低维空间。把这一步吃透了，后面的调参、排错、上线都会顺很多。