• 一文看懂推荐系统:概要01:推荐系统的基本概念


    一文看懂推荐系统:概要01:推荐系统的基本概念

    提示:最近系统性地学习推荐系统的课程。我们以小红书的场景为例,讲工业界的推荐系统。
    我只讲工业界实际有用的技术。说实话,工业界的技术远远领先学术界,在公开渠道看到的书、论文跟工业界的实践有很大的gap,
    看书学不到推荐系统的关键技术。
    看书学不到推荐系统的关键技术。
    看书学不到推荐系统的关键技术。

    王树森娓娓道来**《小红书的推荐系统》**
    GitHub资料连接:http://wangshusen.github.io/
    B站视频合集:https://space.bilibili.com/1369507485/channel/seriesdetail?sid=2249610


    提示:文章目录


    问题的定义:什么是推荐系统?

    如果大家没有用过小红书,不妨装一个小红书子app,这样方便一起学习相关背景,
    如果打开小红书的按默认进入发现页面,这个页面展示推进系统会发给你的内容,
    这个页面展示的内容叫做笔记,都是由用户自己创作的,
    我们把用户创作内容展示给其他用户,形成陌生人社交的社区。
    在这里插入图片描述

    在这个页面上看到的笔记都是推荐系统给你看的推荐系统,
    根据自己过去的点击、点赞、收藏、转发、评论的行为给你推荐,你可能感兴趣的,
    比如我回国之前经常看机票的革命酒店内容推荐,系统就会给你推荐这方面的。
    在这里插入图片描述

    系统把一篇笔记展示给用户,这叫做曝光impression。
    假如用户对这篇笔记感兴趣,会点击它进入这篇笔记。
    如果用户在这篇笔记上只有短暂停留瞬间溜了,就意味着用户是手滑,而不是真的对这篇笔记感兴趣,这不会被算作一次有效点击。
    有效笔记就意味着用户对笔记感兴趣,这将被作为用户不是手滑【停留时间挺长的】,这是真的对这篇笔记感兴趣,这被算作一次有效点击。
    在这里插入图片描述
    为啥给你推荐这个呢?分析的依据是这样的,
    如果用户足够喜欢的这种,可能还会点赞、收藏、转发下面的红心是点赞,
    红星旁边的五角星是收藏,最下面的箭头是转发,用户还可以读评论,

    咱们是小红书,系统转发流程如下:
    在这里插入图片描述

    推进系统决定给用户曝光什么内容,用户自己决定是否点击进去,点击进去是否会滑倒的底。
    评论、点赞收藏转发的网站,手下都会有不同的转化流程,跟产品的设计有关。
    算法工程师应该熟悉自己公司的产品,这对设计特征和模型会有帮助。
    对于绝大多数的公司的产品,前两步都是曝光和点击,比如YouTube、淘宝、快手、知乎都是这种设计,
    但是抖音不太一样,抖音没有曝光的点击,用户下滑,你只能看到一个视频,
    点击之后用户会做设计的动作,包括滑动、到底、点赞、收藏、转发,
    这些动作意味着用户对笔记感兴趣,这些动作都可以作为推荐系统用的信号推荐依据。

    在划到底之后,用户可以评论正面的中心的评论,对社区的氛围很有好处,所以留评论也会推荐系统的一个信号。

    作为算法工程师,我们优化推荐系统是为了提升一些业务指标。
    在这里插入图片描述

    这里列出了几个消费者的指标,这些指标反映出用户对推荐是否满意。

    点击率是一个重要的消费指标,点击率等于点击次数除以曝光次数
    举个例子,每天笔记展示得100个用户,其中有20个用户点击了点击,那么点击的点击率就是20%的,
    点击率越高就说明推荐越精准。

    给用户展示了他感兴趣的内容,虽然点击率是重要的消费指标,
    但也不能把点击率作为唯一的优化目标,否则骗点击的标题就会泛滥。
    不然页面上到处都是美国人吓尿了,日本人震惊了,
    或者满屏都是美女图片片,

    点击其他一些指标也可以反映出用户对笔记的兴趣,
    点赞率等于点赞次数除以击次数。
    举个例子,有100个用户点击进入某些笔记,其中有十个用户点赞个,点赞率就是10%。

    和点赞率的定义非常相似,
    收藏率等于收藏次数除以点击次数,
    转发率等于转发次数除以点击次数,

    阅读完成率稍微有点复杂,阅读完成率等于滑动到的次数除以点击次数,再乘以一个归一化的函数
    归一化的函数跟笔记长度有关。
    这是因为笔记越长,完成阅读的比例就越低。
    如果没有规划的函数对长比较会不公平,
    通常来说,推荐的笔记越符合用户兴趣,那么点击、点赞的行为就会越多。

    做实验的时候,我们希望看到新的配件算法能在这些指标上超越原有的算法。
    我在这里列出的短期消费指标都是有意的,但可能不是评价推荐系统好坏的根本指标,
    一味追求这些短期消费指标是不好的。

    举个例子,如果推荐算法只看用户短期兴趣,为很多用户最近感兴趣的内容,会让这些消费指标上涨,
    但这样的坏处是为竭泽而渔,用户很快被失去兴趣,不再活跃。
    反观,尝试一些用户没看过的话。那么点击率不会上涨,但是会有利于提高用户粘性,留住用户,让用户更活跃。

    刚才讲的点击率、点赞率之类的指标都是短期的消费指标,不是最重要的指标。

    衡量非系统的好坏,最重要的指标叫做北极星指标,有这样几个北极星指标,
    用户规模消费发布北极星指标,意思就是最关键的指标是衡量非系统好坏的根本标准。
    在这里插入图片描述
    在小红书我们就考察这三类北极星指标,第一是用户规模,就是和用户数据和月活用户数mau来衡量
    比如我是个用户,我今天使用一次小红书或者使用十次小红书,今天都算给小红书贡献了一个dau,
    但这个月无论我总共登录了一次小红书,还是每天都登录小红书,都算给小红书,这个月贡献了一个MAUDAU的mau,
    都跟推荐系统的好坏强相关,推荐系统做得好,用户就会越活跃,DAUMAU就会越高。

    第二个北极星指标是消费,包括人均使用推荐的时长、人均阅读笔记数量,
    如果我今天刷了一个小时的小红书推荐,那么我就贡献了一个小时的时长,
    如果我今天看了20个小时的笔记,那我就贡献了20天的阅读量。
    推荐做的越好,用户就会越上瘾,使用小红的时长和阅读数量速度越高。

    这两个指标比点击率、点赞率能反映出推荐过的好不好。
    通常来说,点击率跟时常阅读数量的涨跌是一致的,万一有冲突,要以北极星指标为准
    举个例子,把推荐系统的多样性做好,它对用户的兴趣使得用户使用时长增长。
    但是点击率下去了,这完全OK,这样的策略应该上线北极星指标比点击率更重要。

    还有一个北极星指标是发布,包括发布渗透率和人均发布量,我们希望推荐系统能激励或者发布,
    这样我们的内容是变大优质内容实售的核心竞争力。
    激励发布通常是有东西都要,后面我会专门讲东西的,到时候再解释发布渗透率和人均发布量

    刚才讨论了如何评价推荐系统。
    算法工程师的工作就是对模型、特征、策略系统和改进,提升各种指标,推进系统能否最终上线,要拿实验结果来说话

    实验流程是先做离线实验,表现好的话上线做小量的测试,表现好的话加大流量,最终目的是全流量上线。
    第一步是离线实验,用收集的历史数据做训练和测试,
    离线实验不需要把算法部署到产品中,没有跟用户实际交互,
    因此离线实验很容易做,不需要占用线上流量,也不会对系统的用户产生负面影响,
    有很多评价离线实验的指标,后面课程会讲离线实验的结果有参考价值,能大致反映出算法的好坏,
    但是离线实验并没有线上实验可靠,想最终判断算法的好坏,还是需要做线上实验。

    前面提到的北极星指标都是线上指标,只能通过线上实验获得,做离线实验无法得到这些指标。
    具体做法是开小流量内地测试,把用户随机分为实验组的对照组,实验组用新策略,对照组用旧策略。
    在这里插入图片描述
    这两者的业务指标判断,新策略是否会显著优于旧策略。

    如果新策略显著优于旧策略,可以加大流量,最终推广。

    okay,本文以小红书为例,介绍推荐系统的一些基本概念,后面的课程会用到这些概念。
    下节内容是推荐系统的链路,仍然是一个很广泛的概述,不会讲具体的推荐算法,很轻松可以理解,后续我们会深入讲技术细节的


    总结

    提示:如何系统地学习推荐系统,本系列文章可以帮到你

    (1)找工作投简历的话,你要将招聘单位的岗位需求和你的研究方向和工作内容对应起来,这样才能契合公司招聘需求,否则它直接把简历给你挂了
    (2)你到底是要进公司做推荐系统方向?还是纯cv方向?还是NLP方向?还是语音方向?还是深度学习机器学习技术中台?还是硬件?还是前端开发?后端开发?测试开发?产品?人力?行政?这些你不可能啥都会,你需要找准一个方向,自己有积累,才能去投递,否则面试官跟你聊什么呢?
    (3)今日推荐系统学习经验:算法工程师的工作就是对模型、特征、策略系统和改进,提升各种指标,推进系统能否最终上线,要拿实验结果来说话

  • 相关阅读:
    Python分析物流行业数据
    一篇可供参考的 K8S 落地实践经验
    Cholesterol-PEG-DBCO 胆固醇-聚乙二醇-二苯基环辛炔化学试剂
    Java的集合框架
    (vue)vue导出excel文件打不开,或者文件内容为object object
    后台管理系统通用解决方案
    【手写数据库toadb】数据库planner的整体架构,以及逻辑查询树的设计与实现流程
    排序算法——快速排序(队列和栈实现非递归)
    前端开发:JS的解构
    2.4GHz WiFi速率测试指导及Omnipeek 空口log分析
  • 原文地址:https://blog.csdn.net/weixin_46838716/article/details/126117590