2025上半年,最新 AI实践都在这!20+ 应用案例,任听一场议题就值回票价 了解详情
写点什么

老司机谈电商系统之推荐系统

  • 2020-05-29
  • 本文字数:5944 字

    阅读完需:约 20 分钟

老司机谈电商系统之推荐系统

推荐系统

01 概述

推荐一直是电商平台的重要流量入口。以往在电商平台上,推荐的场景更多的覆盖在交易的各个环节,比如详情页、购物车、订单及支付等。近年来推荐发展逐渐的多样化,场景上逐渐覆盖到各流量入口,推荐的实体也扩展到活动、类目、运营位等。


在电商网站里进行商品推荐,可以提高整个网站商品销售的有效转化率,增加商品销量。通过用户已经浏览、收藏、购买的记录,更精准的理解用户需求,对用户进行聚类、打标签,推荐用户感兴趣的商品,帮助用户快速找到需要的商品,适时放大需求,售卖更加多样化的商品。甚至在站外推广时,能够做个性化营销。


02 推荐系统

商品推荐分为常规推荐、个性化推荐。常规推荐是指商家选择一些固定商品放在推荐位,或者基于商品之间的关联性,进行相关的商品推荐。例如:在用户买了奶瓶之后推荐奶粉。个性化推荐指基于用户购物习惯,根据商品特性来进行推荐。例如"看过此商品后的顾客还购买的其他商品"推荐项。


电商系统中的商品推荐位一般有:首页运营 Banner 最底部的位置(猜你喜欢/为你推荐)、购物车最底部的位置(猜你喜欢为你推荐)、商品详情页中部(看了又看、买了又买、为你推荐等)、用户签到等位置。还有这两年兴起的内容电商,通过社区做内容来提高转化率。

常规推荐

常规推荐的商品不会因为用户不同产生差异,主要是运营配置的活动或固定商品(商品精选)。除了在固定推荐位选定某些商品进行配置,例如选取 N 件固定商品放在签到页进行推荐。还有一些固定规则的动态配置商品,例如图中商品销量排行榜、商品收藏排行榜、某品类的销量排行榜(例如图书会有许多排行榜),这类根据浏览、收藏、销售数据做的商品统计在常规推荐时会经常用到,对用户的消费决策影响也比较大。



在 APP 的盛行的前提下,用户的浏览减少,更倾向于浏览和推荐,但简单的商品列表和标语描述的冲击力已然不够,内容电商将商品嵌入到文案或者视频中,通过详细的描述消费感受和商品特点,激起用户的同理心,这样的购物消费更容易产生冲动性消费,而非计划性消费。在内容电商中,除了平台商家自己产生内容,还应允许用户产生内容(UGC),并且对 UGC 内容进行激励。内容形式有长图文、视频推荐、直播推荐等多种形式,在内容中嵌入商品购买入口,在浏览时可以直达商品,增加购买转化率。对内容进行分类打标,可以缩短用户查找的路径。建立内容社区,提供评论、关注、种草(收藏)、赞赏等多种互动方式,增加用户粘性,提供分享到其他社交平台(微信、微博等)的功能。在内容中尽量推荐统一风格或同一场景的商品,增加商品之间的关联性。

个性推荐

个性化智能推荐最终的目标就是让一个普通访问电商平台的用户,在进入平台页面时,系统能够根据用户日常的行为偏好和习惯,用户心理想要购买的商品,在还没有发生点击行为时,系统能自动推荐到用户访问的页面,提升平台用户下单转化率。即使在用户没有访问平台时,企业通过与用户日常浏览互联网行为轨迹的平台进行联盟合作,在联盟平台推送用户希望购买的商品广告和链接,刺激和引导用户点击购买。即使在用户没有打开电脑时,能够通过信息和邮件的方式,根据用户平常的购买频次和周期,在特定的时间推送到用户手机和其他终端。


个性化智能推荐系统设计建设由三步构成:第一建立平台用户行为的召回模型,维度基于用户历史行为数据召回、用户偏好召回和用户地域召回来实现,用户历史行为数据召回基于用户历史浏览、点击、购买、评论、分享、收藏、关注等触点,分类推荐在线相关、在线相似、离线相关、离线相似行为;基于用户偏好召回是基于用户归类画像与平台多屏互通融合;基于用户地域召回是基于用户地域的网格化来实现地域行为推荐算法;第二是召回模型匹配算法,利用算法来得出与用户召回行为的匹配商品及广告信息;第三是平台针对匹配模型推荐结果的排序算法,基于用户交互日志通过模型训练特征权重,采用排序算法来实现自动匹配个性化推荐。


个性化推荐的难点


平台前端实现用户千人千面,而后台需要建立复杂的用户行为数据采集、数据存储、数据建模和用户画像过程,单纯采集某一纬度的数据,仅能达到个性化推荐的部分效果,如果要提升个性化推荐的效果,就必须覆盖用户多领域足够全面的行为轨迹,甚至用户线下行为,这就形成了以互联网电商平台为核心的生态系统,要想建立全面的个性化推荐,数据采集的涉及领域需要足够广,足够深。下面从用户画像、数据采集、数据存储、数据建模讲解个性化推荐的难度。

1 用户画像

用户画像是通过用户兴趣、行为、自身属性建立的一个模型。通过对用户的调研、对用户行为的分析,结合业务的需求,将用户分为不同的群体;然后在群体中抽象出一些典型的特征,用结构化的信息记录下来,概括出用户的特征。根据用户画像标签体系,对访问平台的用户计算行为特征值,用户特征提取并不是针对所有的标签维度,对于优先关键标签,如果从用户数据库查询不到特征值,就需要调用 R 函数对其进行计算,最终得出每个标签维度的特征值,依据特征属性值,就可以对用户进行画像处理。


用户画像有其自身的特性和局限性,例如无法 100%地描述一个人,且具有时效性,因此,需要根据用户画像的基础数据持续更新和修正,同时要善于从已知数据中具象化出新的标签使用户画像越来越鲜活立体,发挥其参考指引价值。


用户画像的作用


  1. 精准营销,分析产品潜在用户,针对特定群体利用短信邮件等方式进行营销;

  2. 用户统计,比如热销商品 top100 品牌;

  3. 数据挖掘,构建智能推荐系统,利用关联规则计算,喜欢 X 运动品牌的人通常还喜欢什么,利用聚类算法分析,关注 x 品类人的性别、年龄分布情况

  4. 效果评估,完善产品运营,提升服务质量,其实这也就相当于市场调研、用户调研,迅速下定位服务群体,提供高水平的服务;

  5. 私人定制,即个性化的服务某类群体甚至每一位用户(个人认为这是目前的发展趋势,未来的消费主流)。

  6. 行业分析,业务经营分析以及竞争分析,影响企业发展战略。

2 数据采集

首先需要在网站和移动 App 中进行埋点,在页面埋入『隐形』探针,采集用户行为数据和业务系统操作日志、从数据库中提取业务数据,采集回来存储在数据服务,采集服务器组负责将采集到的日志信息生成文件,落地到存储设备,用户行为数据采集基本上采用 SDK 方式;ETL 服务器负责将日志文件和结构化数据导入数据存储分析集群,并将分析结果导出到数据库;数据解析服务器负责连接数据分析服务器,完成数据分析各项计算;存储服务和分析服务提供数据分布式存储和计算的基础框架。



用户行为数据的处理和分析具有较高的技术门槛:


1、SDK 会采集到大量的"脏数据",包含一些空白区域和特殊符号,甚至根本没有见过的数据类型,这些脏数据的处理和分析具有较大的技术挑战,特别是数据的实时采集和处理。通常技术人员只有经历了海量数据采集和处理,填平了大量"技术坑"之后,才能形成成熟的技术架构。


2、采集的数据都是以渠道、日期、地区统计,无法定位到具体每个用户,计算统计出的数据都是规模数据,针对规模数据进行挖掘分析,无法支持,数据无法支撑系统做用户获客、留存、营销推送使用。


所以,要使系统采集的数据指标能够支持平台前端的个性化行为分析,必须围绕用户为主线来进行画像设计,在初期可视化报表成果基础上,将统计出来的不同规模数据,细分定位到每个用户,使每个数据都有一个用户归属。将分散无序的统计数据,在依据用户来衔接起来,在现有产品界面上,每个统计数据都增加一个标签,点击标签,可以展示对应每个用户的行为数据,同时可以链接到其他统计数据页面。

3 数据存储

用户行为数据采集后,需要存储在数据仓库,对采集的原始数据进行 ETL 加工处理,首先需要处理掉存储的无效重复数据,对于用户行为没有影响或重复数据,对非结构化数据和半结构化数据进行结构化处理,并对数据进行补缺、替换、数据合并、数据拆分、数据加载和异常处理。

4 数据建模

用户模型的表示方法有 4 类: 协同过滤模型、行为规则的模型、基于概念的用户兴趣模型与向量空间模型。向量空间模型(VSM)是最为常用的用户模型表示方法之一, 通常使用一组向量值描述用户特征, 向量的每一个维度代表用户感兴趣的一个主题。




维度的提取往往与网站系统的数据特征有关: 在标签系统中, 特征维度往往由用户提供的标签表示; 在检索系统中, 特征语词来自分析系统页面后所得到的关键词; 在协同过滤系统中, 可以把项目认为是描述用户特征的维度。使用 VSM 构建用户行为模型的困难是, 数据中并没有明确表示信息行为的词语, 所以在构建描述信息行为的维度时, 需要从数据中抽象出描述信息行为的维度。



浏览路径能够在一定程度上反映用户浏览行为特征。根据用户的浏览路径(包括页面停留时间)计算用户之间的相似性。但此方法仅适用于网站页面类型较少的情况, 如果页面较多或者包含较多的动态页面, 会使构造矩阵过于稀疏, 导致用户聚类不准确。有研究依据用户访问路径创建页面序列, 使用关联规则挖掘页面跳转规律; 或将用户访问的页面分类, 计算用户在这些页面之间跳转的概率以描述用户信息行为。由于访问日志中只记录用户访问的页面, 没有标识出用户信息行为, 使得用户的行为序列信息没有被充分挖掘。

03 推荐流程

个性化推荐系统一般有三大环节:预处理 -> 召回 -> 排序 。


注:也可以认为是两层(召回 -> 排序)


预处理


第一个环节是预处理,预处理指的是对各种数据源的数据进行特征提取和特征构建,例如:内容特征提取,用户行为画像构建。


召回


第二个环节是召回,召回就是把预处理产生的特征作为输入参数,训练出推荐模型,然后使用推荐模型得出候选集合的过程。常用的召回方式有:基于内容推荐、基于协同过滤推荐等。


排序


第三个环节是排序,简单来说就是将候选集合根据一定的规则,例如:点击预估、匹配关联度、人为权重等进行调整,从而影响最后的推荐顺序。


推荐数据流



以上是一个简单的推荐猜你喜欢实现,首先算法离线训练好与该商品的相似商品集,当在线用户请求过来的时候,有一个用户实时点击过的相似商品召回策略,该策略先获取用户实时点击过的商品列表,再取每个商品的相似商品。从而得到一个候选集。再通过在线排序进行点击率预估。取其中 top 商品从而得到一个推荐结果集。实际的场景中,将在离线训练、召回策略、排序策略等环节不断优化。召回策略中,除了支持实时个性化外,还可以不断发掘新的策略,进行策略,引入强化学习进行意图识别等。在线排序中支持 LR、GBDT 等模型外,还需要平衡性能与特征维度,支持模型的在线学习等。


概念


LR:逻辑回归模型(Logistic Regression, LR)


GBDT:梯度提升决策树(Gradient Boosting Decision Tree,GBDT)

04 系统架构

推荐系统的整体工程架构如下图,从下至上包括离线计算层、实时计算层、在线服务层,另外是后台配置管理系统和数据调度服务。


  • 在线服务:排序系统、推荐引擎、ABTEST 实验、推荐投放等;

  • 实时计算层:根据用户实时行为,提取用户实时特征、在线模型训练。

  • 离线计算层:根据用户历史行为,进行相关性训练、商品初排分、离线特征提取等



在线服务


系统分成推荐投放系统、排序系统、推荐引擎、abtest、字段补全服务等。


  1. 推荐投放:推荐统一接口,负责召回规则、abtest、埋点、字段补全。

  2. 排序系统:点击率预估,各打散置顶等业务层排序。

  3. 推荐引擎:离线算法训练的结果集存储。

  4. 字段补全:商品等正排信息补全,比如价格、标题等。


推荐投放


投放框架的功能如下:


  1. 提供统一的推荐接口。

  2. 各个场景的召回策略规则,可热部署。

  3. 提供通用数据源接口、工具类,方便算法推荐规则编写。

  4. 算法实验以及埋点统计。

  5. 推荐辅助工具。


推荐投放架构图



服务 API 调用统一投放接口获取推荐数据,投放接口解析请求参数,组装成下游推荐策略参数,对返回的推荐结果,拼装打点参数。为了实现推荐算法的在线对比,接口实现中接入了 AB 实验系统,它根据指定策略将上游请求按指定比例进行分流,通过实验配置,灵活控制不同流量的实验策略,算法工程师在线试验多个算法效果,极大的提升了推荐算法的迭代速度,优化推荐效果。


推荐策略模板是整个推荐投放服务实施的核心,监听动态配置服务,通过配置参数变更来驱动各类模板更新,迭代业务。推荐策略流程:入参补全 -> 数据召回 -> 精排 -> 格式化 -> 推荐数据补全。入参扩展模板,对入参做补充、修改,简化业务逻辑实现;业务模板,实现推荐策略主逻辑,由各类召回组件模板和精排调用组成(可选),一个业务模板中可以包含多个召回组件模板,组成数据召回链(实时点击偏好 -> 离线偏好 -> 店铺偏好 -> 类目偏好 -> …);数据组件模板,通过配置从不同的数据源召回和过滤数据;数据补全模板,按业务模板召回的推荐数据项 ID 补全详细的字段值;格式化模板,根据展现层样式需求,将推荐结果封装成展现层可加载渲染的数据格式。对于已实现的推荐策略和能够使用现有模板组装的推荐策略,都可以在动态配置服务平台上通过配置发布快速实现业务迭代和新增,一定程度上实现了代码简化,提高业务开发迭代效率。


推荐策略


推荐策略是整个推荐逻辑的核心,比如猜你喜欢场景,有用户实时特征做相关性的召回策略,也有用户离线特征的相关性召回策略。并且按照一定的配比 merge 出结果集,再调用排序系统的 lr 模型做点击率预估,这些都是需要写在策略脚本里。


推荐存储


主要承载了用户特征以及离线推荐结果集,存储系统对读写性能要求非常高。


  1. 整条推荐链路希望在 50ms-100ms 内完成。一次复杂的推荐请求会请求上百次(以存储中的 key 为单位)存储数据,存储需要在 1ms 内返回。

  2. 对时延要求比较高,比如需要收集用户的曝光行为数据做降权,同时曝光数据的量非常大,对内存有挑战。


排序系统


排序系统的职责是对候选集进行排序,其中核心点在于模型和特征,理想情况下系统尽可能支持多的模型和特征,但是在线计算需要较小的时延,这就要求系统要平衡效果和性能,前期推荐系统可以支持 LR 和 GBDT 两种排序模型。


线性模型公式



x 是特征,θ是权重,一个模型通常有几十维特征,这些特征的计算和存储就成为系统最大的挑战。


  1. 控制候选集数量在千级别,候选集增长整体计算就比较慢,rt 也会上升。

  2. 实体(商品)特征本地存储,每次需要排序特定数量商品,本地存储可以极大缓解网络压。

  3. 针对内存瓶颈,将用户相关特征迁移到远程,考虑每次查询只会查几次用户特征数据,开销不大。

  4. 并行计算,复杂模型下,组装特征和计算还是比较费时,为了提升 rt 系统进行并行计算,充分利用 cpu 的资源,在系统容量不变的情况下提升 rt。


总结


个性化推荐所取得的成就是一个“意料之外却情理之中”的结果。个性化用户体验将是大势所趋,从搜索走向发现(推荐),通过搜索满足用户主动表达的需求,通过推荐挖掘满足用户的潜在需求。市场营销的核心是用户体验,而用户体验的极致是个性化,满足每一位用户的不同需求,以人为本的电子商务才能够真正获得用户的青睐。


2020-05-29 15:295441

评论

发布
暂无评论
发现更多内容

微博评论系统的高性能高可用计算架构

阿卷

架构实战营

12个iOS技术面试题及答案总结

原来是泽镜啊

ios 程序员 架构师 ios开发

做一个小程序到底要多少钱?都有哪些费用?

源字节1号

开源 前端开发 后端开发 开发小程序

【建议收藏】Kafka 面试连环炮, 看看你能撑到哪一步?(上)

王江华

大数据 kafka 面试 中间件 消息队列

RENO: Netflix的快速事件通知系统

俞凡

架构 netflix 大厂实践 3月月更

关于云端应用开发语言选择

穿过生命散发芬芳

3月月更

【Vue】整合tinymce富文本编辑器

TaurusCode

Vue tinymce 富文本编辑器

模块化编程及LCD1602调试工具

謓泽

3月月更

持续集成工具篇:Jenkins与流水线管理

自动化 持续集成 jenkins 持续交付 构架

面向智能合约、区块链、Web3、以太坊开发工具指南

devpoint

Ethereum infura Solidity Web3.0 3月月更

ModelArts框架入门开发(完成物体分类、物体检测)

DS小龙哥

深度学习 3月月更

【CAD】快捷键大全

謓泽

3月月更

小程序大未来

源字节1号

微信小程序 开源 前端开发 后端开发

实用机器学习笔记二十六:NAS

打工人!

学习笔记 NAS 机器学习算法 3月月更 神经网络架构搜索

口腔数字化时代:AI牙医的防御基建与攻坚

脑极体

低代码实现探索(三十八)业务场景封装

零道云-混合式低代码平台

[算法练习]3 三数之和

暖蓝笔记

3月月更 38妇女节

Shell速查手册

陈新卫

Vue3 企业级网站建设

源字节1号

小程序 开源 前端开发

《软件开发的201个原则》思考:1.质量第一

非晓为骁

个人成长 软件开发 软件质量 工程师文化

微博评论的高性能高可用计算架构

AragornYang

架构训练营 架构实战营

在线JSON转toml工具

入门小站

工具

Spring cloud 之 CircuitBreaker篇

邱学喆

Spring Cloud circuit break Resilience4j

IntellJ IDEA诺依开发部署文档

北极的大企鹅

开源 开源技术

Linux之telnet命令

入门小站

Linux

LeetCode刷题笔记:数组中重复的数据

OpenHacker

JavaScript 算法 LeetCode

八个Docker的真实应用场景

hongfei

Docker 容器

《减压脑科学》有田秀穗

xujiangniao

读书

基于开源组件打造Kafka自治集群

俞凡

架构 Slack 大厂实践 3月月更

Web 键盘输入法应用开发指南 (7) —— 开发实战(二)

天择

JavaScript 键盘 实战 输入法 3月月更

JavaScript 基础(二):函数

devpoint

JavaScript 作用域 函数绑定 3月月更

老司机谈电商系统之推荐系统_文化 & 方法_技术琐话_InfoQ精选文章