推荐系统 --- 概述

推荐系统通过预测用户与物品间的连接来提供个性化推荐。它们分为机器学习和相似度两大派别,依赖于UI/UE、数据和算法。推荐系统需考虑冷启动问题,如用户、物品和系统冷启动,并平衡探索与利用。同时,安全问题不容忽视,如不准确的推荐可能影响用户体验和品牌声誉。解决冷启动常用方法包括非个性化推荐、用户注册信息和内容信息的利用。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

概述

  • 什么是推荐系统
    • 推荐系统可以把那些最终会在⽤户(User)和物品(Item)之间产⽣的连接提前找出来。
      • 世界的发展趋势是万物倾向于建⽴越来越多的连接;
      • ⼈是这⼀切趋势的意义所在,为⼈建⽴连接是要义;
      • 根据已有的连接预测和⼈有关的连接,就是推荐系统。
  • 目标
    • ⽤已有的连接去预测未来⽤户和物品之间会出现的连接。
  • 你需要推荐系统吗?
    • 第⼀,看看产品的⽬的。如果⼀款产品的⽬的是建⽴越多连接越好,那么它最终需要⼀个推荐系统。
    • 第⼆,看看产品现有的连接。如果你的产品中物品很少,少到⽤⼈⼯就可以应付过来,那么⽤户产⽣的连接肯定不多,因为连接数量的瓶颈在于物品的数量,这时候不适合搭建推荐系统。
    • 第三,⽤户和物品数量在某些⼿段下也变得很多,但是⽤户和物品之间的连接很少,表现就是⽤户的留存回访很低,这时候也不是很需要⼀个推荐系统。
  • 推荐系统中,推荐算法分为两个⻔门派
    • ⼀个是机器学习派
    • 另⼀个就是相似度 ⻔门派
  • 关键元素重要性的认识
    • 概述
      • 权重⼤致是 4-3-2-1
    • UI 和 UE
      • ⼈机交互设计和⽤户体验设计
    • 数据
      • 数据与 UI、UE 是⼏乎同等重要的元素,它是推荐系统的⻝材,巧妇难为⽆⽶之炊
    • 领域知识
    • 算法
      • ⼀种对算法的常⻅误会就是:短期⾼估,⻓期低估。

实现思路

  • 评分预测
    • 目标
      • 想能不能提前预测⼀个⽤户对每⼀个物品会打多少分,找出那些他可能会打⾼分,但是还没消费的物品
    • 评分类推荐存在以下问题:
      • 数据不易收集,我刚才说过,⽤户给出评分意味着他已经完成了前⾯所有的漏⽃环节;
      • 数据质量不能保证,伪造评分数据⻔槛低,同时真实的评分数据⼜处在转化漏⽃最后⼀环,⻔槛⾼;
      • 评分的分布不稳定,整体评分在不同时期会差别很⼤,个⼈评分在不同时期标准不同,⼈和⼈之间的标准差别很⼤
    • 用户反馈类型
      • ⽤户爸爸们给产品施舍的评分数据,我们⼜叫做显式反馈,意思是他们⾮常清晰明⽩地告诉了我们,他们对这个物品的态度
      • 与之相对的还有隐式反馈,通常就是各类⽤户⾏为,也就是另⼀类推荐系统问题:⾏为预测。
  • ⾏为预测
    • 推荐系统预测⾏为⽅式有很多,常⻅的有两种:
      • 直接预测⾏为本身发⽣的概率,和预测物品的相对排序。直接预测⽤户⾏为这⼀类技术,有⼀个更烂⼤街的名字,叫做 CTR 预估。
        • CTR 意思就是 Click Through Rate,即“点击率”。把每⼀个推荐给⽤户的物品按照“会否点击”⼆分类,构建分类模型,预估其中⼀种分类的概率,就是CTR 预估。
        • 优点
          • 数据⽐显式反馈更加稠密
          • 隐式反馈更代表⽤户的真实想法,⽐如你不是很赞成川普的观点,但还是想经常看到他的内容(以便吐槽他),这是显式反馈⽆法捕捉的
          • 隐式反馈常常和模型的⽬标函数关联更密切,也因此通常更容易在 AB 测试中和测试指标挂钩。
      • 这⾥的 C 原本是点击⾏为 Click,但这个解决问题的模式可以引申到任何其他⽤户⾏为,如收藏、购买。

思维模式

  • ⽬标思维
    • 概述
      • 传统的软件产品追求的是稳定和满⾜预期,背后思想强调的是逻辑和因果链条,软件体验上设定好⾏为和响应,软件设计上强调分层以应对⽆⽐复杂的操作逻辑。
      • 反观推荐系统这种信息过滤系统,追求的是指标的增⻓,背后思想强调是⽬标和不确定性:我们并不能很确定地模拟每个⼈将会看到什么,也不能很好地复现⼀些操作过程,充满了不确定性,但是在推荐系统未动的情形下,⽬标先⾏则是常识。
    • 具体
      • ⽬标思维背后是“量化⼀切”的价值取向。最先要量化的就是⽬标本身
      • 接下来要量化的是所有的优化改进动作,
  • 不确定性思维
    • 不确定性思维就是:不⽤因果逻辑严丝合缝地提前推演,⽽是⽤概率的眼光去看结果。
    • 为什么负责推荐系统产品的⼈⼀定要有不确定性思维呢?原因有以下⼏个。
      • 绝⼤多数推荐算法都是概率算法,因此本身就⽆法保证得到确切结果,只是概率上得到好的效果;
      • 推荐系统追求的是⽬标的增⻓,⽽不是⼀城⼀池的得失;
      • 如果去花时间为了⼀个 Case ⽽增加补丁,那么付出的成本和得到的收益将⼤打折扣;
      • 本身出现意外的推荐也是有益的,可以探索⽤户的新兴趣,这属于推荐系统的⼀个经典问题:EE 问题,我也会在后⾯的内容中专⻔讲

⼏个常⻅顽疾

  • 冷启动问题
    • 分类
      • 用户冷启动
        • 用户冷启动主要解决如何给新用户做个性化推荐的问题。
      • 物品冷启动
        • 物品冷启动主要解决如何将新的物品推荐给可能对它感兴趣的用户这一问题。
      • 系统冷启动
        • 系统冷启动主要解决如何在一个新开发的网站上(还没有用户,也没有用户行为,只有一些物品的信息)设计个性化推荐系统,从而在网站刚发布时就让用户体验到个性化推荐服务这一问题。
    • 解决思路
      • 提供非个性化的推荐
        • 非个性化推荐的最简单例子就是热门排行榜,我们可以给用户推荐热门排行榜,然后等到用户数据收集到一定的时候,再切换为个性化推荐。
      • 利用用户注册信息。用户的注册信息分3种
        • 人口统计学信息:包括用户的年龄、性别、职业、民族、学历和居住地
        • 用户兴趣的描述:有一些网站会让用户用文字描述他们的兴趣。
        • 从其他网站导入的用户站外行为数据:比如用户通过豆瓣、新浪微博的账号登录,就可以在得到用户同意的情况下获取用户在豆瓣或者新浪微博的一些行为数据和社交网络数据。
      • 选择合适的物品启动用户的兴趣
        • 解决用户冷启动问题的另一个方法是在新用户第一次访问推荐系统时,不立即给用户展示推 荐结果,而是给用户提供一些物品,让用户反馈他们对这些物品的兴趣,然后根据用户反馈给提供个性化推荐。
        • 一般来说,能够用来启动用户兴趣的物品需要具有以下特点:
          • 比较热门
          • 具有代表性和区分性
          • 启动物品集合需要有多样性
      • 利用物品的内容信息
      • 发挥专家的作用
        • 首先,它让专家对电影进行标记,每 个电影都有大约50个基因,这些基因来自大约1000个基因库。
        • 然后,在专家标记一定的样本后, Jinni会使用自然语言理解和机器学习技术,通过分析用户对电影的评论和电影的一些内容属性对 电影(特别是新电影)进行自己的标记。
        • 同时,Jinni也设计了让用户对基因进行反馈的界面,希 望通过用户反馈不断改进电影基因系统。
  • 探索与利⽤,⾏话⼜叫做 EE 问题。假如我们已经知道了⽤户的喜好,⼀般有三种对待⽅式:
    • 全部给他推荐他⽬前肯定感兴趣的物品
    • ⽆视他的兴趣,按照其他逻辑给他推荐,如编辑推荐、随机推荐、按时间先后推荐等等;
    • ⼤部分给他推荐感兴趣的,⼩部分去试探新的兴趣,如同⼀边收割⻓好的⾲菜,⼀边播种新的⾲菜
  • 安全问题:推荐系统被攻击的影响⼤致有以下⼏个
    • 给出不靠谱的推荐结果,影响⽤户体验并最终影响品牌形象
    • 收集了不靠谱的脏数据,这个影响会⼀直持续留存在产品中,很难完全消除
    • 损失了产品的商业利益,这个是直接的经济损失
### Flink 大数据处理优化技巧与最佳实践 #### 调优原则与方法概述 对于Flink SQL作业中的大状态导致的反压问题,调优的核心在于减少状态大小以及提高状态访问效率。通过合理配置参数和调整逻辑设计可以有效缓解此类瓶颈[^1]。 #### 参数设置建议 针对不同版本下的具体特性差异,在实施任何性能改进措施前应当充分理解当前使用的Flink版本特点及其局限性;同时也要考虑特定应用场景的需求特征来定制化解决方案。这包括但不限于并行度设定、内存分配策略等方面的选择[^2]。 #### 数据流模式优化 采用广播变量机制可作为一种有效的手段用于降低主数据流转过程中所需维护的状态量级。当存在一对多关系的数据集间需频繁交互时,将较小规模的一方作为广播状态保存下来供另一方查询匹配使用不失为明智之举。此方式特别适用于维表Join操作中,其中一方变动相对较少但又必须保持最新记录的情况[^3]。 ```sql -- 创建临时视图以支持后续JOIN操作 CREATE TEMPORARY VIEW dim_table AS SELECT * FROM kafka_source; -- 定义Temporal Table Function以便获取指定时间点上的历史快照 CREATE FUNCTION hist_dim_table AS 'com.example.HistoricalDimTableFunction'; -- 执行带有时态条件约束的JOIN语句 SELECT o.order_id, d.product_name FROM orders o LEFT JOIN LATERAL TABLE(hist_dim_table(o.event_time)) AS d ON o.product_id = d.id; ``` 上述代码片段展示了如何利用Flink SQL实现基于时间戳的历史维度表连接功能,从而确保每次都能准确捕捉到事件发生瞬间对应的最恰当的产品名称信息。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值