一.背景
1. 为什么需要特征分类
主要是为了方便管理、使用以及复用。这样一匹相同类型的特征可能是由同一批人提供和维护,他们也会存储在同一块存储的子模块里,使用查询的时候也可以自由组合,称之为特征集(FeatureSet)。
在线使用的是需要查出用户特征和物品特征来进行在线处理,这个时候不同场景可能需要不同的特征(也可能有部分是相同的特征),这样刚好不同的场景可以去取不同的特征集
2.为什么使用探索新的特征分类标准
最开始划分特征集的时候比较粗糙,主要分为基础特征和统计特征,用户特征和物品特征,这样2乘2。后来有了一,二,三,四等多个业务,随着业务越来越多以及特征的快速增长,原来的特征分类标准不明确的情况下,特征的管理变得困难和混乱,大家增加新特征类型没有依赖的标准,仅根据自己的需求来决定是否要增加新特征。这样导致了部分特征集特别大,分类的粒度太粗,很多场景可能只需要这个特征集的小部分特征但需要一次性全取过来,比较浪费请求耗时。为了规范特征类型的管理和特征存储以及查询的性能优化,这里对特征类型进行统一的标准,后续是否需要增加类型可参考该标准,并且特征类型和特征的上线需要专人审核才能上线。
二.特征分类标准
特征主要分为几大类,新增特征优先按以下标准进行类型定义:
1. 用户侧特征:
●行为类,例如用户点击,分享等,如下图所示,类型相当于每个维度相乘的结果。例如业务类型,业务子业务类型,时间序列数据库存储,序列类特征,首页场景,点击序列为一个类型,其他类似。当然,也并不是一次性给出全部的枚举,而是需要上新特征了再判断是否加新的特征类型id。
a.
b. 基础属性类,例如用户年龄,性别等用户Common基础属性特征只有一个类型,这里的Common是指当时所有接入特征平台的业务可以共用的一匹特征id和特征集id。
●UM,例如DSSM,MIND等模型生成的用户向量。
2. Item侧特征:
●行为类,例如被点击次数,被分享次数等,和用户侧行为类特征一样,只是item的为被动特征。
●基础属性类,例如item类目,标题等基础属性为一类特征。
●模型类,例如DSSM,MIND等模型生成的item向量。向量特征,例如DSSM,MIND等模型特征,向量特征来源不同就分开
●打分特征,例如ctr,cvr等模型打分特征
3. 上下文特征:
●context特征,例如时间等
●业务场景特征,例如场景,刷数等
4. 业务全局特征:
定时计算的一些全局特征
5. 外部引入特征:**,**。
三、后记
这篇特征分类标准是笔者和华明一起整理出来的,感谢华明!
本博所有文章均为博主原创,未经许可不得转载。
https://www.prolightsfxjh.com/article/nb-feature-classification-standard/
Thank you!
------from ProLightsfx
本博所有文章均为博主原创,未经许可不得转载
如经许可后转载,请注明出处:https://prolightsfxjh.com/article/nb-feature-classification-standard/
共有 1 条评论