news 2026/9/2 21:03:23

机器学习特征工程:分类变量的数值化处理方法

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
机器学习特征工程:分类变量的数值化处理方法

编码是机器学习流程里最容易被低估的环节之一,模型没办法直接处理文本形式的分类数据,尺寸(Small/Medium/Large)、颜色(Red/Blue/Green)、城市、支付方式等都是典型的分类特征,必须转成数值才能输入到模型中。

那么问题来了:为什么不直接把 Red 编成 1,Blue 编成 2?这个做法看起来简单粗暴,但其实藏着大坑。下面用一个小数据集来说明。

数据集概述

Feature | Description -------------------|---------------------------------------------------------- customer_id | Unique customer identifier gender | Male or Female education_level | High School → Associate → Bachelor's → Master's → PhD employment_status | Full-time, Part-time, Self-employed, Unemployed city | Customer's city (50+ US cities) product_category | Electronics, Clothing, Books, Sports, Home & Garden, Beauty, Food & Beverage payment_method | Credit Card, Debit Card, PayPal, Cash customer_tier | Bronze → Silver → Gold → Platinum satisfaction_level | Dissatisfied → Neutral → Satisfied → Very Satisfied credit_score_range | Poor → Fair → Good → Very Good → Excellent purchase_amount | Purchase amount in USD will_return | Yes or No (target variable)

Ordinal Encoding

Ordinal Encoding 思路很简单:给每个类别分配一个数字,但是模型会把这些数字当作有序的。

假设对

payment_method

做编码:Cash = 1,PayPal = 2。模型会认为 Cash < PayPal,仿佛 PayPal 比 Cash “更好” 或 “更大”。但支付方式之间根本没有这种大小关系因为它们只是不同的选项而已。

什么时候 Ordinal Encoding 才合适?当数据本身就存在真实的顺序关系时。比如

education_level

:High School < Associate < Bachelor’s < Master’s < PhD。这是客观存在的递进关系,用数字表示完全没问题,模型的理解也是对的。

所以 Ordinal Encoding 的使用场景很明确:只用于那些排名确实有意义的特征。

from sklearn.preprocessing import OrdinalEncoder ordEnc = OrdinalEncoder() print(ordEnc.fit_transform(data[["education_level"]])[:5]) # Output """ [[1.] [2.] [3.] [4.] [2.]] """

One-Hot Encoding

One-Hot Encoding 换了个思路:不用数字而是给每个类别创建一列。

payment_method

有 4 个值,就变成 4 列,每行只有一个位置是 1,其余全是 0。

| payment_cash | payment_credit_card | payment_debit_card | payment_paypal | |--------------|---------------------|--------------------|----------------| | 1 | 0 | 0 | 0 | | 0 | 1 | 0 | 0 | | 0 | 0 | 1 | 0 | | 0 | 0 | 0 | 1 |

这样做的好处是消除了虚假的顺序关系,所有类别被平等对待和线性模型配合得也很好。

那么代价是什么?维度会膨胀。

customer_tier

payment_method

各 4 个值,合起来就是 8 列。如果遇到城市这种特征,50 多个类别直接炸成 50 多列,维度灾难就来了。

from sklearn.preprocessing import OneHotEncoder oneEnc = OneHotEncoder() print(oneEnc.fit_transform(data[["customer_tier", "payment_method"]]).toarray()[:5]) [#output](#output) """ [[0. 1. 0. 0. 0. 1. 0. 0.] [0. 0. 0. 1. 0. 0. 1. 0.] [0. 0. 1. 0. 0. 0. 0. 1.] [0. 1. 0. 0. 0. 1. 0. 0.] [1. 0. 0. 0. 1. 0. 0. 0.]] """

Target Encoding

面对高基数特征(比如 City 有 50 多个值)One-Hot Encoding 会把特征空间撑得太大,Target Encoding 的做法是:用每个类别对应的目标变量均值来替换。也叫 Mean Encoding。

举个例子,目标变量是

will_return

(Yes = 1,No = 0):

| City | will_return | |-----------|-------------| | Austin | 1 | | Austin | 1 | | New York | 1 | | New York | 0 | | New York | 0 | | New York | 0 | | New York | 1 |

计算每个城市的目标均值:Austin → (1 + 1) / 2 = 1.0,New York → (1 + 0 + 0 + 0 + 1) / 5 = 0.4,这样得到的编码结果就是:

| City | Encoded Value | |----------|----------------| | Austin | 1.0 | | New York | 0.4 |

这里有一个坑,Austin 只出现了 2 次而且刚好都是正例,编码值直接变成 1.0。模型可能会 “学到” 一个规律:看到 Austin 就预测 will_return = Yes。

但这个 “规律” 完全是数据量不足造成的假象。样本太少均值就很不可靠。

Smoothing 的思路是把类别均值往全局均值方向 “拉” 一拉。公式:

Encoded Value = (w * Category Mean) + ((1 - w) * Global Mean)

其中 Category Mean 是该类别的目标均值Global Mean 是整个数据集的目标均值,w 是一个和样本量相关的权重。样本越少w 越小,编码值就越接近全局均值;样本越多类别自己的均值就越占主导。这能有效抑制小样本带来的过拟合。

另一个问题就是 Data Leakage。如果用全量数据计算编码值再把这个编码喂给模型,模型等于直接 “看到了” 答案的统计信息。比如模型发现 City = 0.34 对应的样本大概率是 will_return = Yes,那它干脆走捷径,不从其他特征里学东西了。

所以就要引入交叉验证,以 5 折为例:把数据分成 5 份,对第 1 份的数据,用第 2 到第 5 份来计算编码;对第 2 份的数据,用第 1、3、4、5 份来计算编码;以此类推。每个样本的编码值都来自于它 “没见过” 的数据,泄露就切断了。

但是副作用是同一个城市在不同折里的编码值会略有差异:New York 在 Fold 1 里可能是 0.50,在 Fold 2 里是 0.45。但这反而是好事,这样可以让模型被迫学习更一般化的模式而不是死记某个精确数值。

Target Encoding 的优点:避免维度爆炸,适合高基数特征,还能把目标变量的统计信息编进去。

但用的时候得小心:必须加 Smoothing 防止小样本过拟合,必须用交叉验证防止数据泄露。

from sklearn.preprocessing import TargetEncoder data["will_return_int"] = data["will_return"].map({"Yes": 1, "No": 0}) tarEnc = TargetEncoder(smooth="auto", cv=5) # Those are the default value print(data[["city"]][:5]) print(tarEnc.fit_transform(data[["city"]], data["will_return_int"])[:5]) """ city 0 Houston 1 Phoenix 2 Chicago 3 Phoenix 4 Phoenix [[0.85364466] [0.69074308] [0.65024828] [0.74928653] [0.81359495]] """

总结

三种编码方法各有适用场景,选择取决于特征本身的性质。

实际操作中可以这样判断:特征有天然顺序就用 Ordinal Encoding;没有顺序、类别数量也不多就用 One-Hot Encoding;类别太多就上 Target Encoding,记得配合 Smoothing 和交叉验证。

真实项目里,一个数据集往往会同时用到这三种方法。

https://avoid.overfit.cn/post/eeabb03fba684a88a6ccce132f4852b0

作者: adham ayman

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/8/25 15:24:10

三星研究院MeKi:手机ROM存储空间赋能大模型高效运行

这项由三星研究院中国和韩国团队联合完成的突破性研究于2026年1月发表在AI Model TF期刊上&#xff0c;论文编号为arXiv:2602.03359v1。有兴趣深入了解的读者可以通过该编号查询完整论文。研究团队提出了一种名为MeKi&#xff08;Memory-based Expert Knowledge Injection&…

作者头像 李华
网站建设 2026/8/30 0:32:08

HTML新春烟花

系列文章 序号目录1HTML满屏跳动的爱心2HTML五彩缤纷的爱心3HTML满屏漂浮爱心4HTML情人节爱心5HTML蓝色爱心射线6HTML跳动的爱心7HTML跳动的双爱心8HTML粒子爱心9HTML蓝色动态爱心10HTML橙色动态粒子爱心11HTML旋转爱心12HTML爱情树13HTML元素周期表14HTML飞舞的花瓣15HTML星空…

作者头像 李华
网站建设 2026/8/25 23:46:50

腾讯混元团队:AI智能体如何学会真正的“深谋远虑“?

这项由腾讯混元团队主导的研究发表于2026年2月6日&#xff0c;论文编号为arXiv:2602.05327v1&#xff0c;感兴趣的读者可以通过这个编号查询完整的研究论文。说起人工智能助手&#xff0c;我们经常会发现一个有趣的现象&#xff1a;它们在解决简单问题时表现出色&#xff0c;但…

作者头像 李华
网站建设 2026/8/26 2:26:58

移植Google Gemini Nano到RK3588 NPU,实现高效边缘推理

引言 在嵌入式 AI 开发中,大家常常会遇到模型在硬件平台上运行时出现性能瓶颈的问题,比如推理速度慢、功耗过高,这严重影响了应用的实时性和稳定性 ,导致性能瓶颈,无法满足如智能安防、工业检测等场景的实时性需求。为了解决这些问题,我们可以将轻量模型移植到具有强大算…

作者头像 李华