04 特征工程：推荐系统有哪些可供利用的特征？
你好，我是王喆。基础架构篇我们已经讲完了，你掌握得怎么样？希望你已经对深度学习推荐系统有了一个初步的认识。
从这节课开始，我们将会开启一个新的模块，特征工程篇。
如果说整个推荐系统是一个饭馆，那么特征工程就是负责配料和食材的厨师，推荐模型这个大厨做的菜好不好吃，大厨的厨艺肯定很重要，但配料和食材作为美食的基础也同样重要。而且只有充分了解配料和食材的特点，我们才能把它们的作用发挥到极致。
今天，我们就先来讲讲特征工程，说说到底什么是特征工程，构建特征工程的基本原则是什么，以及推荐系统中常用的特征有哪些。相信通过这节课的学习，能让你更好地利用起推荐系统相关的数据提升推荐的效果。
什么是特征工程
在第一讲中我们学习过，推荐系统就是利用“用户信息”“物品信息”“场景信息”这三大部分有价值数据，通过构建推荐模型得出推荐列表的工程系统。
在这个系统之中，特征工程就是利用工程手段从“用户信息”“物品信息”“场景信息”中提取特征的过程。这个过程说起来容易，但实际做起来其实困难重重。
比如说，一个网站或者App每天收集起来的用户日志，采集来的站外信息，自己公司员工编辑添加的结构化数据那么多，那么庞杂，怎么才能挑出那些对推荐有用的特征呢？
再比如从“推荐模型”的角度来说，一个机器学习模型的输入，往往是一个数值型的向量。那用户性别，用户行为历史这些根本不是数字的信息怎么处理成一个模型可用的数值向量呢？
我们这节课先聚焦第一个问题，“怎么挑出有用特征”，下节课我们再解决第二个问题。都说“理论指导实践”，在展开讲有哪些有用的特征之前，我们先看一看构建特征工程有哪些原则或者规律可以遵循。
构建推荐系统特征工程的原则
我给推荐系统中的特征下了一个比较抽象的定义，特征其实是对某个行为过程相关信息的抽象表达。为什么这么说呢？因为一个行为过程必须转换成某种数学形式才能被机器学习模型所学习，为了完成这种转换，我们就必须将这些行为过程中的信息以特征的形式抽取出来。
我们来举个最简单的例子，用户的性别有三个，男、女、未知。但推荐模型没办法直接认识这三个类别，它是一个只认识数字的“严重偏科理工男”，所以我们就需要把它转换成1、2、3（为了方便你理解，这里我用的是一个最简单的方法，不一定是最合适的）这样的数字代号它才能处理。
但是，这种从具体行为信息转化成抽象特征的过程，往往会造成信息的损失。为什么这么说呢？
一是因为具体的推荐行为和场景中包含大量原始的场景、图片和状态信息，保存所有信息的存储空间过大，我们根本无法实现。
二是因为具体的推荐场景中包含大量冗余的、无用的信息，把它们都考虑进来甚至会损害模型的泛化能力。比如说，电影推荐中包含了大量的影片内容信息，我们有没有必要把影片的所有情节都当作特征放进推荐模型中去学习呢？其实没有必要，或者说收效甚微。
这其实也是我们构建推荐系统特征工程的原则：尽可能地让特征工程抽取出的一组特征，能够保留推荐环境及用户行为过程中的所有“有用“信息，并且尽量摒弃冗余信息。
接下来，我们就结合一个实际的例子，说一说在电影推荐这个场景下，我们该怎么贯彻特征工程原则来挑选特征。
现在，你就可以先把自己当成是一个用户，假设你正在选择看哪部电影。想一想在这个选择过程中，你都会受什么因素影响呢？如果是我的话，可能影响我的因素有6个，把它们按照重要性由高到低排序就是，电影类型我是否感兴趣、电影是不是大片、导演和演员我是否喜欢、电影海报是否吸引人、我是否已经观看过该影片以及我当时的心情。
那站在一个工程师的角度，我们能不能用某些特征把这些要素表达出来呢？我尝试用表格的形式把它们特征化的方法列举了出来：
我们详细来讲一个要素，比如，如何知道一个用户是否对这个电影的类型（动作、喜剧、爱情等）感兴趣。一般来说，我们会利用这个用户的历史观看记录来分析他已有的兴趣偏好，这个兴趣偏好可能是每个电影类型的概率分布，比如动作45%、喜剧30%、爱情25%。也可能是一个通过Embedding技术学出来的用户兴趣向量。
这个时候，我们就可以根据这个电影本身的特征，计算出用户对电影的感兴趣程度了。对于其他的特征，我们也都可以通过类似的分析，利用日志、元数据等信息计算得出。
不过，并不是所有的要素都能特征化。比如，“自己当时的心情”这个要素就被我们无奈地舍弃了，这是因为我们很难找到可用的信息，更别说抽取出特征了；再比如，“电影海报是否吸引人“这个要素，我们可以利用一些图像处理的方法提取出海报中的某些要点（比如海报中有哪些演员？是什么风格？），但想面面俱到地提取出海报中所有的图像要素，几乎是不可能的。
因此，在已有的、可获得的数据基础上，“尽量”保留有用信息是现实中构建特征工程的原则。
推荐系统中的常用特征
前面我以电影推荐为例，讲解了特征工程的基本原则，互联网中的推荐系统当然不仅限于电影推荐，短视频、新闻、音乐等等都是经典的推荐场景，那么它们常用的特征之间有没有共性呢？确实是有的，推荐系统中常用的特征有五大类，下面我一一来说。
1. 用户行为数据
用户行为数据（User Behavior Data）是推荐系统最常用，也是最关键的数据。用户的潜在兴趣、用户对物品的真实评价都包含在用户的行为历史中。用户行为在推荐系统中一般分为显性反馈行为（Explicit Feedback）和隐性反馈行为（Implicit Feedback）两种，在不同的业务场景中，它们会以不同的形式体现。具体是怎么表现的呢？你可以看我下面给出的几个例子。
对用户行为数据的使用往往涉及对业务的理解，不同的行为在抽取特征时的权重不同，而且一些跟业务特点强相关的用户行为需要推荐工程师通过自己的观察才能发现。
在当前的推荐系统特征工程中，隐性反馈行为越来越重要，主要原因是显性反馈行为的收集难度过大，数据量小。在深度学习模型对数据量的要求越来越大的背景下，仅用显性反馈的数据不足以支持推荐系统训练过程的最终收敛。所以，能够反映用户行为特点的隐性反馈是目前特征挖掘的重点。
2. 用户关系数据
互联网本质上就是人与人、人与信息之间的连接。如果说用户行为数据是人与物之间的“连接”日志，那么用户关系数据（User Relationship Data）就是人与人之间连接的记录。就像我们常说的那句话“物以类聚，人以群分”，用户关系数据毫无疑问是非常值得推荐系统利用的有价值信息。
用户关系数据也可以分为“显性”和“隐性”两种，或者称为“强关系”和“弱关系”。如图4所示，用户与用户之间可以通过“关注”“好友关系”等连接建立“强关系”，也可以通过“互相点赞”“同处一个社区”，甚至“同看一部电影”建立“弱关系”。
在推荐系统中，利用用户关系数据的方式也是多种多样的，比如可以将用户关系作为召回层的一种物品召回方式；也可以通过用户关系建立关系图，使用Graph Embedding的方法生成用户和物品的Embedding；还可以直接利用关系数据，通过“好友”的特征为用户添加新的属性特征；甚至可以利用用户关系数据直接建立社会化推荐系统。
3. 属性、标签类数据
推荐系统中另外一大类特征来源是属性、标签类数据，这里我把属性类数据（Attribute Data）和标签类数据（Label Data）归为一组进行讨论，是因为它们本质上都是直接描述用户或者物品的特征。属性和标签的主体可以是用户，也可以是物品。它们的来源非常多样，大体上包含图5中的几类。
用户、物品的属性、标签类数据是最重要的描述型特征。成熟的公司往往会建立一套用户和物品的标签体系，由专门的团队负责维护，典型的例子就是电商公司的商品分类体系；也可以有一些社交化的方法由用户添加。图6就是豆瓣的“添加收藏”页面，在添加收藏的过程中，用户需要为收藏对象打上对应的标签，这是一种常见的社交化标签添加方法。
在推荐系统中使用属性、标签类数据，一般是通过Multi-hot编码的方式将其转换成特征向量，一些重要的属性标签类特征也可以先转换成Embedding，比如业界最新的做法是将标签属性类数据与其描述主体一起构建成知识图谱（Knowledge Graph），在其上施以Graph Embedding或者GNN（Graph Neural Network，图神经网络）生成各节点的Embedding，再输入推荐模型。这里提到的不同的特征处理方法我们都会在之后的课程中详细来讲。
4. 内容类数据
内容类数据（Content Data）可以看作属性标签型特征的延伸，同样是描述物品或用户的数据，但相比标签类特征，内容类数据往往是大段的描述型文字、图片，甚至视频。
一般来说，内容类数据无法直接转换成推荐系统可以“消化”的特征，需要通过自然语言处理、计算机视觉等技术手段提取关键内容特征，再输入推荐系统。例如，在图片类、视频类或是带有图片的信息流推荐场景中，我们往往会利用计算机视觉模型进行目标检测，抽取图片特征，再把这些特征（要素）转换成标签类数据供推荐系统使用。
而文字信息则更多是通过自然语言处理的方法提取关键词、主题、分类等信息，一旦这些特征被提取出来，就跟处理属性、标签类特征的方法一样，通过Multi-hot编码，Embedding等方式输入推荐系统进行训练。
5. 场景信息（上下文信息）
最后一大类是场景信息，或称为上下文信息（Context Information），它是描述推荐行为产生的场景的信息。最常用的上下文信息是“时间”和通过GPS、IP地址获得的“地点”信息。根据推荐场景的不同，上下文信息的范围极广，除了我们上面提到的时间和地点，还包括“当前所处推荐页面”“季节”“月份”“是否节假日”“天气”“空气质量”“社会大事件”等等。
场景特征描述的是用户所处的客观的推荐环境，广义上来讲，任何影响用户决定的因素都可以当作是场景特征的一部分。但在实际的推荐系统应用中，由于一些特殊场景特征的获取极其困难，我们更多还是利用时间、地点、推荐页面这些易获取的场景特征。
小结
这节课我们一起进入推荐系统中一个非常重要的模块，特征工程模块的学习。推荐系统中可用的特征非常多，但它们基本上可被划分到“用户行为”“用户关系”“属性标签”“内容数据”“场景信息”这五个类别，而且挑选特征的方法也遵循着“保留有用信息，摒弃冗余信息”的原则。
就像本节开头说的一样，特征工程是准备食材的过程，准备食材的好坏直接影响到能不能做出好菜。同时，要准备的食材也和我们要做什么菜紧密相连。所以针对不同的推荐系统，我们也要针对它们的业务特点，因地制宜地挑选合适的特征，抓住业务场景中的关键信息。这才是特征工程中不变的准则，以及我们应该在工作中不断积累的业务经验。
从工程的角度来说，除了特征的挑选，特征工程还包括大量的数据预处理、特征转换、特征筛选等工作，下节课我们就一起学习一下特征处理的主要方法，提升一下我们“处理食材”的技巧！
课后思考
如果你是一名音乐App的用户，你觉得在选歌的时候，有哪些信息是影响你做决定的关键信息？那如果再站在音乐App工程师的角度，你觉得有哪些关键信息是可以被用来提取特征的，哪些是很难被工程化的？
欢迎在留言区畅所欲言，留下你的思考和疑惑。如果今天的内容你都学会了，那不妨也把这节课转发出去。今天的内容就到这里了，我们下节课见！
- 朱月俊 👍（106） 💬（3）
选择音乐，哪些因素是我关注的？ 我经常会听五类歌曲： 1.听网络流行歌曲（听大家听的）； 2.听一些我喜欢的风格的歌曲（励志类，空灵类，感伤类）； 3.听一些我喜欢的歌手唱的歌，比如汪峰等； 4.听我看过的电视剧，电影，动漫中的背景音乐； 5.听一些朋友推荐的歌曲； 如果我是音乐app特征提取工程师的话，我会提取哪些特征？ 首先将特征分为文中提及的五类吧。 1.用户行为数据 用户在音乐app上的行为，包括浏览，收藏，评论，点击，播放，时长，次数等。 2.用户关系数据 用户的关系数据。 3.属性，标签类数据 歌曲的多维特征，用户的多维特征。 4.内容类数据 对音乐进行语音识别，提取关键特征。 5.场景信息（上下文信息） 跟小作文几要素差不多。 时间，地点，人物，情节。
2020-10-10 - 张弛 Conor 👍（44） 💬（2）
我在选歌的时候，信息重要性从高到低依次是： 1.听歌的目的。比如是为了放松，冥想，学习还是运动。目的决定了歌曲是安静还是激昂，舒缓还是节奏感强烈。 2.歌曲或歌单是否受欢迎。定下基调后，我一般会选择收藏或播放量较多的歌曲。这样一般不容易采坑。 3.歌曲的旋律与当下状态的匹配度。当下的状态可能是心情，情绪或身体的疲劳程度，而旋律与状态的匹配也很重要。 如果我是一名音乐 APP 工程师， 1.用户听歌的目的很难准确预测，但是可以通过“隐性”数据去推测，比如搜索关键词等。 2.歌曲或歌单是否受欢迎，则可以通过歌曲或歌单的播放量、收藏量去建立特征，而具体到人和歌曲的关系时，还可以进一步具体到单曲循环的次数等来细化特定用户对特定歌曲的喜好程度。 3.当下的状态也很难显性的获得，则可以根据历史听歌记录去推测用户的生理节律，例如夜晚会愿意听舒缓的歌曲，运动会愿意听节奏感强烈的歌曲等等。
2020-10-12 - 逆流向善的阿鱼 👍（22） 💬（1）
音乐App 1.影响我做决定的关键信息： A. 个人主观角度 a.不同时间段【起床刷牙、工作时间、跑步时间、洗漱时间、睡前时间】 喜欢的类型不同 b.地理位置【寝室、办公室、室外、健身房】， 对应不同的状态 c. 心情/ 情绪状态 【 不同情绪状态 会 持续 听 不同类型 的歌曲】 B. 客观角度 a. 最近热议的 新歌 【流行度】 b. 最近热议的电影 的主题曲 【流行度】 c. 朋友最近在听的歌曲【用户关系】 d. 热门歌曲【我自己个人对这类歌曲喜好度偏低】 e. 所在地区大部分人都喜欢的歌曲 作为音乐App工程师的角度的特征 A. 易被工程化： a. 不同时间段 喜欢的 音乐 b. 不同地理位置 喜欢的音乐 c. 热门歌曲【当地热门，全球热门，中国地区热门】 e. 基于社交网络的歌曲推荐【基于用户的协同过滤、基于好友关系的推荐】 B. 不易被工程化： 心情/情绪【或许可以尝试短期内在听歌曲类型去提取？】 特征方面： 用户交互特征: 点击、收藏、点赞、踩、评分、评论【好/坏】、转发、播放完成度、浏览评论时长 用户属性特征：年龄、性别、职业、收入范围、所在地区、地理位置、不同时间段对各音乐类型的偏好度、不同地理位置对音乐类型的偏好度 用户关系特征：好友关系、亲密好友关系、有相同爱好的人群【基于用户协同过滤top K得出】 场景特征：用户当前所处位置、用户当前状态【用户自行设置？】、当前时间段、是否工作日、是否周末、是否节假日、 音乐特征：是否优质音乐【评分】、音乐风格、音乐时长、歌手、专辑、发行年月、所属标签、流行度、被重复播放的中位数 思考： 特征的更新频率： 用户：分为长中短期用户画像、仅保存三个月内活跃过的用户的画像以减少存储？ 音乐：流行度需要按日期更新、热门程度也可能需要跟节假日相关【圣诞节=》圣诞结】
2021-04-24 - 张弛 Conor 👍（20） 💬（1）
老师，想请问一下为什么在用户行为数据中，将评论数据作为隐性反馈行为呢？因为我的理解，显性反馈行为就是用户对物品的直接评价(评分，赞等)，但是评论也算是用户对物品的直接评价，所以我很好奇为什么评论会是隐性反馈呢？（我个人的解释是，在某些场景下，用户的评论并不一定是对物品的评价，比如对于新闻来说，评论可能是对于内容本身的讨论，而不是用户是否喜欢该新闻，但是对于电商类网站，对于物品的评论则可以看做是显性反馈行为，不知道这样理解是否正确呢？）
2020-10-12 - Crystal-clear 👍（15） 💬（2）
选择音乐我关注的点，理性总结来说分为三个方向： 1.歌本身：歌名，歌手，歌曲风格，歌词语言，歌曲发布时间，是否约束vip等 2.个人：心情，在做什么，好友推荐等 3.其他：所处环境，歌在APP内的位置，歌的播放量，评论数等 作为一名音乐推荐工程师，在关注用户历史行为信息的同时，现在更应该在乎用户新的行为变化。这是我自己的经验，我一直喜欢听比较宁静一点的歌，但是有一天我突然想听欢快很多的歌，我面临了很多问题，第一我怎么去搜索，第二搜索结果那么多，我怎么选择，第三在搜索结果中随意选择一首总会让自己失望，第四下一次我又该怎么办呢等等，同时你的搜索结果中依旧会出现原来风格的歌曲，这让自己局限在一个风格的“茧房”里面，很难受很无语。所以用户新行为是在推荐系统已经盛行的时代里面更应该关注的地方！
2020-12-01 - shenhuaze 👍（12） 💬（5）
王老师，在线预测的时候，模型所需的特征是直接从数据库读取，还是在线实时组装？我在想如果只是用户或者物品自身的特征的话，可以从数据库读取，但如果是用户和物品的交叉特征的话，是不是必须实时组装？
2020-10-09 - 金鹏 👍（10） 💬（1）
音乐产品更加依赖场景性和心情，在工作、学习、跑步、睡眠、开车、高兴、优伤等等，希望听到的音乐是不同的。所以市面上的音乐目前主要以歌单的形式来推，可以更好的让用户快速找到符合自己当下场景的音乐，感觉更是个强搜索型的产品，音乐的推荐策略更像是一种补充。 针对我个人而言，听音乐时所处的场景或心情、喜欢的音乐类型、喜欢的音乐明星、音乐新热榜、收藏过的歌单 音乐所处的场景 | 用户位置POI数据、历史时段听音乐歌单 | POI数据与音乐匹配度 心情 | 可以通过近几次搜索数据对推荐做干预 | 搜索关键词语义分析 感兴趣的音乐 | 播放历史 | 音乐相似度（可以是音乐Tag、旋律，现在可以基于旋律做歌曲的归类） 喜欢的音乐明星 | 明星收藏、历史播放、点赞、购买等行为 | 音乐新热榜 | 新内容池、热度内容池 | 多样性探索、新鲜度、热度数据 收藏过的歌单 | 收藏数据 | 收藏相似度
2020-10-09 - 马龙流 👍（9） 💬（6）
像多模态或者是通过其它预训练方法得到的向量，直接加到推荐排序模型作为特征的话，感觉都没有效果。不知道你这边有没有碰到类似问题呢。我理解是预训练学习的目标和排序学习目标并不一致，不知道大佬怎么看这个问题
2020-10-12 - pedro 👍（5） 💬（1）
回答课后问题，按照电影的套路，关联的信息大概有:歌是谁唱的？(比如我的idol)，歌的风格是什么？(比如我超喜欢r&b)，歌的时长(太长的一律跳过)，至少点击过或者单曲循环过？至少听过类似的或者听过该歌手的？ 歌的内容即歌词，旋律，副歌？等等 难以被工程化的是歌词内容，毕竟大家都不是专业音乐人，flow和verse这种东西没法去很好的量化，因此特征提取的关键是该特征是否能被量化，如果可以，那可定是可以用来提取特征的，比如说歌的作者和种类，是否单曲循环等。
2020-10-09 - 夜雨声烦 👍（4） 💬（2）
影响因素：当时的心情，时间，天气，歌名，歌手，歌曲类型，播放量，是否top，好友中有人听过； 工程师角度： 当时的心情(无法获取)、时间(24小时划分成十个时间段表示)、天气(晴、阴、雨)、歌名(Embedding)、歌手(Embedding)、歌曲类型(onehot)、播放量、是否top(onehot)、好友中有人听过(onehot).
2020-10-09 - 李@君 👍（4） 💬（3）
我在选歌的时候主要是听前几十秒，如果觉得好听就会继续，如果不好听，就跳过。这个也是很难被量化的吧。
2020-10-09 - loode_ 👍（3） 💬（1）
懒人笔记： 特征无非三个方面： （1）用户特征，主要是用户画像属性特征，如性别年龄，爱好，收入等； （2）物品特征，可以是物品的标签，内容主题或者所属类型等； （3）用户与物品的交互特征，如点击、分享、观看、购买、收藏等，且对于不同的行为可以赋予不同权重，另一个方向是根据时间来给不同的行为赋予权重，如越近的越能反映用户当前兴趣；此外，交互也可以按显性和隐性反馈来赋予不同的权重。 对于用户属性特征，一般是进行onehot处理，物品特征则可以multi-hot，也通过交互行为来进行word2vec类似的embedding向量化表示。 而交互行为，除了可以word2vec 然后进行pooling处理外，常见的做法是Attention（din）和利用序列化模型来进行模拟（dien中的gru）。
2021-03-24 - Geek_0d974b 👍（3） 💬（2）
请教实际工作中的一个问题，模型训练好上线之后，发现遗漏了一些特征，这个时候除了retraining 还有别的选择吗？
2021-02-18 - 粪进 👍（1） 💬（1）
王老师好，请教一个实际问题，我当前在做信息流中的广告点击率转化率预测。我们当前选取了n天的转化率作为特征，是一个连续值，我们现在用的是等距分桶方法将其离散化。 ①有没有评价分桶结果的方法呢？比如尽量均匀？还是正态分布？ ②有资料说等频比等距好，这也是一定场景下吧？ ③实际工程中老师有什么推荐尝试分桶的方法吗？ 谢谢。
2021-07-08 - Geek_60d933 👍（1） 💬（1）
请问王老师是否可以从特征实时性角度聊聊，哪些特征对实时性有更高的要求？以及在线特征，离线特征的业界使用方法？
2021-06-30