精华内容
下载资源
问答
  • 推荐系统架构

    2021-01-21 22:16:13
     我们从宏观上可以感受到的推荐系统架构如下:通过数据分析得到用户画像,然后通过推荐系统给用户推荐数据。从此图中,我们也可以窥知一个完整的推荐系统至少应该有如下的子系统:用户画像子系统,内容子系统,存储...

    前言

    本文主要介绍推荐系统的基本架构。

    推荐系统架构

    目录

    • 宏观的推荐系统架
    • 细化的推荐系统架构
      • 外围架构图
      • 日志存储系统
      • 推荐系统

    宏观的推荐系统架

    我们从宏观上可以感受到的推荐系统架构如下:通过数据分析得到用户画像,然后通过推荐系统给用户推荐数据。从此图中,我们也可以窥知一个完整的推荐系统至少应该有如下的子系统:用户画像子系统,内容子系统,存储子系统,推荐引擎子系统等

    推荐系统外围架构

    外围架构图

    我们需要知道推荐系统是如何和网站的其他系统联系起来的。一般来说,每个网站都会有一个UI系统,UI系统负责给用户展示网页并和用户交互。网站会通过日志系统将用户在UI上的各种各样的行为记录到用户行为日志中。日志可能存储在内存缓存里,也可能存储在数据库中,也可能存储在文件系统中。而推荐系统通过分析用户的行为日志,给用户生成推荐列表,最终展示到网站的界面上。

    日志存储系统

    在一个推荐系统中,需要对用户的行为数据进行存储分析,得到用户画像,进而为用户推荐符合个人口味的结果。毫无疑问,用户的行为数据量是巨大的。我们需要根据实际的情况采用不用的存储方式来进行存储。才能产生的,而有些行为是所有用户都可以产生的。从规模上看,浏览网页、搜索记录的规模都很大,因为这种行为所有用户都能产生,而且平均每个用户都会产生很多这些行为。购买、收藏行为规模中等,因为只有注册用户才能产生这种行为,但购买行为又是电商网站的主要行为,所以它们相对于评论来说规模更大,但相对于网页浏览行为来说规模要小得多,最后剩下的行为是注册用户里的一小部分人才有的,所以规模不会很大。从实时存取的角度上看,购买、收藏、评论、评分、分享等行为都是需要实时存取的,因为只要用户有了这些行为,界面上就需要体现出来,比如用户购买了商品后,用户的个人购买列表中就应立即显示用户购买的商品。而有些行为,比如浏览网页的行为和搜索行为并不需要实时存取。

    按照前面数据的规模和是否需要实时存取,不同的行为数据将被存储在不同的媒介中。一般来说,需要实时存取的数据存储在数据库和缓存中,而大规模的非实时地存取数据存储在分布式文件系统(如HDFS)中。数据能否实时存取在推荐系统中非常重要,因为推荐系统的实时性主要依赖于能否实时拿到用户的新行为。只有快速拿到大量用户的新行为,推荐系统才能够实时地适应用户当前的需求,给用户进行实时推荐。

    推荐系统

    在先前的文章已经介绍过了,推荐系统是一个联系用户和物品的一个系统。而根据一般的规律,推荐系统联系用户和物品一般有三种方式。如下图:

     

    根据上面的抽象,可以设计一种基于特征的推荐系统架构。当用户到来之后,推荐系统需要为用户生成特征,然后对每个特征找到和特征相关的物品,从而最终生成用户的推荐列表。因而,推荐系统的核心任务就被拆解成两部分,一个是如何为给定用户生成特征,另一个是如何根据特征找到物品。

    如果我们为每一类的特征都准备一种推荐引擎,那么推荐系统需要由多个推荐引擎组成,每个推荐引擎负责一类特征和一种任务,而推荐系统的任务只是将推荐引擎的结果按照一定权重或者优先级合并、排序然后返回。

    那么来看一下推荐引擎的架构

    展开全文
  • 推荐系统架构治理

    2020-09-06 20:17:27
    本文就第四范式在智能推荐系统架构方面的探索实践,聊一聊在应用架构治理方面提升推荐服务开发维护效率,增强系统灵活性和扩展性的新探索。重点探讨在开发推荐系统乃至智能系统领域时遇到的问题,解决方法及未来的...

    导读:在数字化革命和AI赋能的大背景下,推荐场景逻辑越来越复杂,推荐细分场景越来越丰富,对业务迭代和效果优化的效率有了更高的要求。推荐系统业务和技术在传统架构支撑下自然堆砌,变得越来越臃肿,开发维护困难,推荐系统在应用架构上正面临新的挑战。本文就第四范式在智能推荐系统架构方面的探索实践,聊一聊在应用架构治理方面提升推荐服务开发维护效率,增强系统灵活性和扩展性的新探索。重点探讨在开发推荐系统乃至智能系统领域时遇到的问题,解决方法及未来的发展趋势。

    主要内容包括:

    • 推荐系统业务现状、趋势及挑战

    • "治理"的指导思想

    • Flowengine架构

    • 应用Flowengine后推荐的架构

    • 实例演示

    01 推荐系统业务现状,趋势及挑战

    1. 推荐系统业务现状

    从图中我们可以看出,推荐系统大体可以分为三个阶段,最初的探索阶段,早在2010年左右,已经有了千人千面的说法,现在我们在学习推荐系统时,看一些文档或者资料,大都会拿亚马逊基于协同过滤的推荐、豆瓣基于标签的推荐系统做介绍,它们都是早期推荐系统应用在工业界的代表。到了第二阶段 ( 普及深入阶段 ),淘宝、京东以及一些垂直行业开始大范围尝试个性化推荐,此时,工程架构,算法策略层面都有了一些新的发展,比如一些大型推荐系统已经开始向实时特征,实时模型方向进行探索,以提升时效性,从而达到更好的推荐效果。到了第三个阶段 ( 规模化精细化阶段 ),进入移动互联网时代,推荐已经不仅限于PC端的单一场景推荐,出现了移动端及多场景的推荐需求。现今,从拼多多、快手、抖音的推荐,再到百度、头条的信息流推荐,推荐系统已经成为一个网站的灵魂,驱动着各种各样的业务场景,在这一阶段,智能化,工程化,标准化,注重开发效率和成本已成了技术探索的新方向。总体看来,推荐系统的发展趋势是一个从无到有,从有到精的过程,不管是工程,算法或者场景业务都有了深入的发展。

    2. 业务趋势

    推荐系统从业务方面来说,呈现四个趋势:

    ① 场景更丰富:早期做推荐的时候,推荐的开发门槛和成本很高,一个网站集中精力维护好一个场景,那时最经典的场景可能就是主页下方的"猜你喜欢"。到了现在,多端,多个资源位,更多的细分场景都会有推荐需求。举个例子,从进入页面的"猜你喜欢",导航九宫格的推荐,再到列表页或下单页的"看了又看","买了又买",乃至在一个资源位上多个时段都有个性化的需求。在技术层面上,过去一个系统支撑一个场景或者一种模式,或者为了简单,一个架构,一个数据流,一个模型勉强应付多个场景,已无法满足业务精细化运作的需要。现在,一个推荐系统需要支持很多的场景,不同的场景也需要有不同的数据流,业务逻辑,模型来深入刻画;另一方面,早期做推荐系统是一个门槛很高的事情,对工程、算法的要求比较高,且业务逻辑高度定制,很难标准化、低门槛的开发,而现在随着场景越来越丰富,推荐需求的旺盛增加,原来的工作模式已不能满足需要,推荐场景开发需要向灵活化,标准化,规模化发展。

    ② 运营更精细:从简单规则 ( 比如像置顶,置底,黑白名单过滤 ) 向复杂规则转变,通用规则向个性化规则转变;技术主导变为技术+业务联营。推荐系统的效果好坏不再全是技术主导,业务也利用内容物料,规则玩法等运营手段发挥重要的作用。

    ③ 服务更实时:早期推荐模型都是基于历史数据采用离线批量的方式构建,离线的特征,离线的模型,导致系统时效性差,用户实时或近实时行为的影响无法体现在推荐的结果中,用户体验不好。让用户能够更快感受到变化,批量非实时向流式实时闭环推荐发展是推荐效果提升的必然趋势。

    ④ 未来的重要趋势:系统更智能,更知心。早期的一些简单算法或者规则,被更丰富,更复杂的AI算法所替代。推荐系统与AI结合的越来越紧密。推荐系统已经成为AI赋能的重要场景之一,如何构建一套对AI友好的推荐系统,在技术上也是一个很大挑战。

    3. 带来的技术挑战

    ① 当前推荐系统的基本架构

    在前面所讲的业务大趋势下,推荐系统技术层面正面临一些挑战。我们先了解一下当前推荐系统的基本架构,一般分为五个板块:

    • 数据流:推荐系统的特点就是高度和数据流相关,那么技术层面要解决数据怎么来,数据怎么用,数据怎么加工处理,正确性和时效性如何保证等问题。

    • 离线板块:系统内涉及到一些数据加工,任务处理,模型生产,指标报表等离线任务,怎么协调这些任务有序高效进行,并获得正确有效的结果。

    • 在线板块:推荐系统对外提供实时推荐的能力,涉及到诸多的在线处理过程和规则。如何在适应业务快速变化的同时保证可用性和性能是至关重要的。

    • AI:当下推荐系统的重要组成部分,其包含整个AI模型生成到服务的全生命周期。如何从系统层面支撑AI全生命周期以及如何有机集成进系统是一个挑战。

    • 基础设施:推荐系统是一个多领域交叉的综合应用,需要有众多的中间件、基础组件做支撑,如何管理和运维,减少依赖,有效利用是一个重要的命题。

    上面说的五大板块,对照起来实际上就是这张示意图。虚线框是数据流,蓝色框是离线部分,黄色框是在线部分,绿色的是基础组件。相较于简化的示意图,在实际系统中,会变得更加复杂。比如就日志或数据收集这一部分,日志就可能因为来源,收集方式多样,导致开发,维护和管理的复杂度激增。各家公司的推荐系统涉及到大量的应用服务和中间件,它们的技术选型,实现方式,部署方式并不完全一致,但是整体逻辑结构却是可以映射到刚才提到的五个板块内。但是这样的架构存在什么问题呢?我们可以结合四个趋势来看,如果只针对性的支撑一个场景,这样是可以的,但是当场景变得更多,更精细,问题便出现了。比如"猜你喜欢","看了又看",召回物料可能不一样,召回的算法逻辑可能不一样,精排模型可能不同,甚至整个处理流程也可能不一样,而它们却在一个代码模块中,各场景的逻辑必然会形成耦合,互相影响,继而影响系统稳定性。另一方面,因为板块割裂,很多领域逻辑分散在服务或中间件中,比如数据处理一般采用Azkaban/Airflow一类的中间件系统去调度处理任务,这就不可避免的将业务逻辑用大量的胶水代码封装在中间件系统中,如果一个开发者想要了解一个推荐系统的业务流程,就会变得非常困难。随着业务的不断发展,这一现象会加剧,大量的场景规则,服务,运营策略,算法模型越来越多,最终导致系统难以维护,变成谁都不敢动的“老古董”。

    ② 当前推荐系统面临的技术挑战

    我简单的总结了一下,主要有四方面的挑战。

    a. 开发运维部署迁移困难,曲线陡峭,效率低下。因为推荐系统等智能系统,都涉及到大量的基础组件和服务,各有特点,缺乏一体化的管理运维手段,如何把完整系统搭起来并管理,期间中间件或者服务出问题,都可能会导致系统不可用。这对于没有丰富的组件维护经验或者人力不足的团队来讲,是一个巨大挑战。

    b. 这实际上是一个应用治理的问题,服务,流程,规则,策略,数据,产物繁多,组织管理困难。图中任何一个框是一种服务,也可能是若干个服务,这些服务之间的依赖不直观,很难管理。数据流逻辑繁琐复杂,系统有很多的离线数据流,在线的数据流,还会产生大量数据产物,缺乏标准化的管理,极易出错。不同场景的差异化难以组织,不同的服务,策略间相互影响,其中一个可能表现就是在一个服务模块代码中因为要处理不同场景的逻辑而产生大量if分支逻辑。从架构上讲,一个好的场景服务应该是纵向切分的,不同的场景是不同的系统,场景间互相隔离,但这又会导致系统资源浪费,管理上面也很麻烦。因此,需要采取更加系统化的方法去治理它。

    c. 系统涉及到数据/在线/离线/AI各个领域,技术栈割裂,整个推荐流程需要大量的胶水代码来整合集成。而胶水代码的一个特点就是难以复用,不同人之间也难以维护。这样的割裂突出表现在以下三点:

    • 众多领域技术,彼此割裂,难以集成

    • 数据质量难以保证,效果也无法保证

    • 定制性胶水代码驱动,无法复用,迁移

    d. 大量重复程序化工作难以避免。在面临支持多个场景的情况下,表现很突出。落地一个新的场景,可能需要各个系统配合开发,部署,而且这个过程是高度重复和繁琐的,最终导致成本很高。这也是现在大一点的公司,为了效率和标准化,开始推动推荐系统中台化建设的一个原因,其目的是能够在一个平台上低成本的完成场景的快速开发和应用。

    上述这些问题的表现都可以用一个字来总结,那就是"乱"。

    4. 如何戡"乱"

    那么我来讲一讲如何戡乱,首先我们深入分析一下乱的原因。

    ① "乱"的原因:

    a. 智能系统特有的复杂性,涉及到庞大的服务依赖,数据依赖,知识依赖。推荐系统涉及到的服务模块很多,而一个服务又涉及多个依赖,整个服务的依赖关系就会很复杂,从而管理上就需要很大的成本。数据依赖层面,系统涉及到大量的原始摄取数据,中间加工数据,以及最终的结果服务数据,数据的质量对最终的推荐效果影响是至关重要的,而这种依赖又非常的隐含,极易出错还难以排查。最后,特别提出"知识依赖"这一概念,推荐系统一直以来在应用系统中以其技术复杂性著称,其在工程上,策略上,数据处理上,算法模型上,有很多模式经验及潜在技能门槛。但这些知识在系统中是隐性的,存在于架构师、专家的脑袋里面,并没有固化和沉淀到系统内。强依赖架构师凭借自己的认知和经验去构建,驱动整个系统流程。而正是因为是人来主导,那自然会随着人的水平的高低以及偏好,产生实现上的差异,难以沉淀和继承,后期持续演化也会很脆弱。

    b. 领域架构缺失 现有的框架都在解决局部问题,需要抽象出一层专门解决推荐场景应用开发领域自身的问题。比如Airflow是做离线任务调度领域的平台工具,Flink是做数据处理领域相关的框架,这两者都是各自领域很优秀的框架或平台,但是要解决推荐领域的问题,他们都只能解决其中部分子领域问题,缺失一个面向推荐领域的一体化平台或框架,其结果就是从业务问题直接穿透到子领域层,在实现上,缺乏抽象和隔离,使用胶水代码将下层服务拼接在一起完成逻辑实现。虽然子领域框架能够解决了一些局部问题,但它们之间如何协同,管理,以及在其之上更有序的解决推荐领域层面的业务问题成为了如何让架构更好服务场景业务的关键。所谓戡乱,就是需要形成一个中间推荐场景开发的领域层,承接服务依赖,数据依赖,知识依赖,并协调子领域服务更有效工作。

    ② 这一层应当如何做?

    a. 统一的场景开发和管理接口。对于上层来讲,开发一个"看了又看","买了又买"等不同的场景,开发过程和接口应该是相似的,只需要面向这一层开发,无需关注下层细节。

    b. 统一的底层架构和集成标准。下层非常复杂,涉及到众多子领域,作为开发者,常常在选型和集成上犯难,也无法将它们协调起来,那么我们需要这一层能够把复杂度给屏蔽掉,开发者面对的是统一的数据结构和接口规范,而无需关注具体的执行层选型和实现。

    c. 领域内要素治理:

    • 合适粒度的领域实体抽象及实现。在推荐服务中,有大大小小的服务,规则,策略及数据,我们称之为领域资源要素,它们需要有合适的领域抽象和粒度,粒度不能太大,也不能太小。是一个规则那么我们就用规则去承载,如果是一个服务,那么我们就应该用一个服务来承载。这样能够在提供灵活性的同时,控制整体复杂性

    • 统一灵活的管理方式。我们需要针对领域要素有统一灵活的管理方式,领域的业务逻辑通过统一的编排管理方式来构建。

    • 成熟可复用的单元。资源要素的载体是成熟可复用的单元,组件、策略等避免重新开发,产生重复的成本,应该通过复用让使用者更低成本使用。

    有几个指导思想,来指导我们具体应该如何将这一层做好。

    02 推荐系统"治理"的指导思想

    1. "治理"的指导思想

    ① 声明式 ( Declarative ): 解决复杂系统,复杂流程管理的灵丹妙药。早期在没有k8s的时候,微服务运维管理是一个复杂的过程,需要人工编写很多的脚本完成应用的部署更新扩缩容等工作,使用者必须明确描述其所有操作细节。因为相对于声明式,这种过程命令式的运维脚本,需要使用的人要能够掌控过程执行所有细节,这对于大型复杂系统来讲是一个很大挑战。声明式编程的思想流行会使这样的工作大大简化,服务负责内部自身复杂运行逻辑,上层使用者只需要声明出自己的目标即可,系统自动帮你完成,无需关注其达成目标的具体过程。就像SQL一样,之所以大家用着觉得简单,其很大原因是SQL就是一个声明式的编程语言。这一思想已经逐步成为架构师解决复杂系统管理的推荐思路。比如,当下很热门的运维部署框架Ansible,运维人员只需要按要求编写安装部署剧本,系统就会自动安装和部署相应的服务。

    ② 框架平台:在目标定位上,是开发一款工具,还是开发一个框架平台,会直接影响到我们的系统设计决策。工具的特点是被集成,可以为使用者提供更灵活有效的手段解决具体问题,但对于使用者本身有比较高的要求,最终结果如何,高度依赖使用的方式。而对于框架来讲,将实现过程让渡给框架,开发者无需了解全过程,只需要按照框架提供的规范进行开发即可,这一定程度约束了开发者的行为,也降低了上手门槛,这实际上是依赖反转思想的体现。我们提到的知识依赖,就可以通过框架或平台把它们沉淀下来。而使用者自然会在框架的帮助下,使其开发的系统是相对可靠的。比如web开发框架Spring,亦或是持续集成平台Jenkins,它们的作用就是提供一个领域业务模式或流程,能够使得初学者只需要掌握平台或框架的使用便能在其领域达到一个比较高的水平,获得方法论指引,避免前人的错误。

    ③ 组件化:其特点是标准化,复用性和灵活性。框架和它是依存关系,是它的契约,组件是按照契约去实现及被集成。

    ④ 低代码 ( LowCode ):特点是简单,快速。当下比较热门的概念,一个框架或者平台,不需要写代码或者少写代码就能够完成开发,是基于框架开发基础上的更进一步,能够将业务过程,核心逻辑封装成一些低代码的模块,这对于简单化业务过程,降低使用门槛有很大的帮助。

    2. FlowEngine

    基于上述的挑战及解决思路,第四范式研发了这样一个声明式的、低代码的、组件化的智能场景开发和管理的框架平台。在这个框架基础上可以快速开发和管理推荐等智能场景。

    03 Flowengine架构

    接下来简单介绍一下Flowengine架构,它位于场景业务服务和子领域执行层之间。它的出现其目的便是将我们缺失的领域层补充上。

    1. 表现

    Flowengine提供了一套声明式API,可用来创建,管理智能场景 ( 推荐 ),表现为以下方面:

    • 场景沉淀,迁移,快速构建。在框架无状态的前提下,将应用逻辑,业务规则和服务依赖保存成一个方案文件,从而做到可以在不同的Flowengine平台下无痛迁移分享。

    • 领域要素 ( 组件,JOB,FUNC等 ) 的管理,集成,更新。提供要素的开发,发布,集成,运行等全生命周期管理,使得其能够在明确的标准下被集成和管理。

    • 业务逻辑编排 ( 批/流/在线pipeline )。场景业务逻辑是对领域要素的逻辑编排,这就使得其天然具备敏捷性,业务上也能做到垂直切分隔离,却共用相同的执行底层。在业务隔离和资源共享层面达成了统一。

    • 预置核心组件及标准流程方案。简单的业务可以通过已有方案自动的生成推荐服务,达到开箱即用的目的。如果存在场景差异也可以在此基础上进行修改和完善,但修改过程仅仅发生在方案场景层面,从而有效的控制了修改风险蔓延,做到了框架与方案的分离,从而在易用性,规范性与灵活性,差异性上达成了统一,这个在传统架构上是一个不可调和的矛盾。

    • 标准化的底层集成方式,上层简单,下层开放。标准化的底层集成方式,均采用业务组件或技术组件的方式集成,对上层呈现为可被pipeline编排的资源要素,使用者无需关注执行层差异。这样就保证了上层是接口简单,下层是开放的。

    2. 构成与基本实现

    简单说一下它的构成:

    • Flowengine-Hub:用于存放方案,组件,FUNC/JOB等资源要素的仓库。

    • EngineManager:用来管理和监控引擎并作为适配层屏蔽下层复杂度。

    • EngineKernel:单个引擎的核心,用于管理当前引擎领域实体,业务流程,并提供运行环境及通信支持。

    • Flowengine-Data:一个AI/BI为一体的数据服务,用于管理引擎数据、元数据及对外提供统一的数据流服务。

    基本实现:

    • 基于k8s微服务管理。从大的架构上看,Flowengine是一个CloudNative架构,通过利用k8s的能力,实现了引擎内微服务的管理及动态化。一个引擎是由一个或者多个微服务共同组成,运行组件的标准格式是在docker镜像基础上再封装而来,天然容器化友好。另外,在Docker和k8s的支撑下,框架对于基础环境的复杂性有了很好的适应能力。

    • 在计算引擎层面,集成了Spark,Flink以及自研的模型训练 ( GDBT ) 等框架,通过进一步的集成优化,使得开发者无需关注这些框架的使用细节,通过统一的编程接口便能够完成开发。

    • 批流一体的数据流管理及元数据管理,引入数据摄取,加工,服务三个过程,抽象出一,二,三级表的抽象表概念,开发者无需关注数据的存储和计算细节,采用统一的方式完成数据流开发,从而降低开发的复杂度及分散性。

    • 业务编排框架。提供批,流,在线三大可视化业务编排能力,使得业务逻辑开发变成了无代码的拖拉拽操作。另一方面,通过集中的编排管理及任务分发,解决了场景业务逻辑散落在各个执行组件中的问题。在引擎层便能够管理业务全过程,这对于后期开发维护都大有帮助。

    接下来我们介绍一下应用Flowengine之后的架构是什么样子的。

    04 应用Flowengine后推荐的架构

    1. 业务分解与技术映射

    业务分解:如图,业务上一个推荐的场景大体是这样的,它包含在线的业务流程,这一个流程大体可以分为召回,过滤,粗排,精排等几个部分,这里通常会因为业务过程的变化而变化。另一块是数据处理及离线处理,这里会有数据怎么获取,加工,以及提供给在线服务使用的逻辑。它也会随着业务变化而变化。最后一部分,对于智能推荐,人工智能的作用举足轻重,它包含数据接入处理,特征工程,模型训练,模型服务等多个过程,这其中也包含了离线和在线等诸多服务模块。

    技术映射:那么,对于上述分解出的三大业务部分,在Flowengine框架上如何映射呢?转化到Flowengine上面,我们用引擎的概念来映射,一个推荐场景就是一个引擎,如图,这个引擎我们可以起名叫reco-engine,这个引擎里存在一个在线编排的pipeline叫reco-func-pipeline,而它就具备把推荐服务流程通过编排表达出来形成在线服务能力。Flowengine-Data支持数据的接入,它提供数据的摄取和服务的能力,比如说是kafka数据引入,ES或者Mysql的服务输出,并提供数据表之间的处理能力,开发者只需要关注数据流本身的处理逻辑,而无需关注数据的存取和调度。而对于AI模型服务来讲,它也是一个引擎,在引擎内部便能完成AI模型从开发到部署的全流程。场景引擎reco-engine只需要在需要模型服务时调用该AI引擎的服务即可。这样我们一个推荐的场景就变成了一个主场景引擎及若干AI模型引擎构成,而它们的底层资源管理和调度都无需场景开发者关心。和我们之前讲的传统架构比,结构上清晰了许多,而这一切都归功于必要的领域层抽象。

    2. 带来的价值

    接下来我们总结一下应用了Flowengine之后带来的价值:

    • 面向Flowengine声明业务过程,简单,统一。声明元数据,声明编排过程。我们不需要管理执行层的具体细节,使得复杂度大大降低,业务过程也变得更加标准化。

    • 服务及中间件数量减少,资源消耗减少,维护方便。推荐系统因为业务上的发展,会增生很多小服务,这些服务管理麻烦,还占用资源。比如说推荐系统一般会一个兜底的服务,定期生成静态的推荐结果,用来在正常推荐响应失败时降级出推荐结果。在Flowengine的支持下,可以通过创建一个离线的pipeline解决这类需求,那么这样的小服务就可以避免。

    • 逻辑分层,合适的拆分粒度。服务,策略,脚本,配置都能够合理安排,体现最小知识原则,其灵活性,复用性更强。

    • 减少大量胶水代码和重复代码,串联流程基于编排框架,无需再自己管理流程,声明配置即可,低代码,效率高,好管理。开发方案和使用方案分离,分工会更加清晰,也便于经验及方法论传递。

    • 场景纵向隔离,便于业务差异化发展,业务不能绑架技术,技术更不能绑架业务。在引擎层面做到相互隔离,一个引擎就是一个场景,开发,升级,变更都能够互不影响。

    • 服务运维,环境迁移部署更便利,CloudNative架构,无状态设计,方案可导入导出。从解决思路上讲,Docker解决了单一服务的迁移问题,而Flowengine解决场景的迁移问题。

    最后给大家做一些实例的展示。

    05 实例演示

    Flowengine支持页面、SDK和CLI多种操作方式。左侧是引擎Web管理界面和CLI截图。右侧是一个应用方案包结构,包含了应用的定义meta_info.yaml以及依赖组件的定义。

    下图是Flowengine-data 的管理界面,可以管理数据表及数据摄取,加工,服务的处理过程。

    最后是业务编排的操作界面。它包含离线编排,在线编排,流式编排。

    06 总结

    随着智能场景越来越多,原来项目式,单点式的场景开发维护,必然导致整体研发成本的爆炸性增加。正如十来年前,web应用的大发展,催生了大量优秀的web开发框架一样,智能场景应用的大发展也将会重演这样的历史。Flowengine正是我们在这一领域的探索,以我们对智能应用的架构理解,构建一套加速开发和运维过程的框架平台,跟进未来的发展趋势。

    今天的分享就到这里,谢谢大家。

    展开全文
  • 推荐系统架构前言实践
  • 推荐系统架构

    推荐系统架构

    在这里插入图片描述

    展开全文
  • 推荐系统架构详解

    千次阅读 2020-11-28 00:54:36
    之前对推荐系统进行学习的过程中,发现自己只是拘泥于其中的一小部分进行学习,没有一个全局系统的认知,经常容易陷入困惑,因此借分享会机会,将推荐系统架构梳理一遍,在梳理的过程中才对推荐系统有了更加清楚的...

    推荐系统全貌

    一、导论

    之前对推荐系统进行学习的过程中,发现自己只是拘泥于其中的一小部分进行学习,没有一个全局系统的认知,经常容易陷入困惑,因此借分享会机会,将推荐系统架构梳理一遍,在梳理的过程中才对推荐系统有了更加清楚的整体认知,并知道了自己还有哪些没学到,也相当于给自己后续的学习提供了方向。

    二、推荐系统介绍

    推荐系统出现的原因:

    • 信息过载
    • 个体个性化表达的需要
    • 在特定场景下,个人对自己的需求不是那么明显

    推荐系统解决的问题:

    本质是在用户需求不明确的情况下,从海量信息中为用户寻找感兴趣信息的技术手段。结合用户的信息(构建用户画像),物品(广告)画像,利用机器学习/深度学习技术构建兴趣模型,为用户提供精准推荐。

    推荐系统应用领域:

    • 电商(阿里,淘宝,京东)
    • 视频(Netflix,优酷,YouTube等)
    • 音乐(网易云等)
    • 社交(Facebook)
    • 新闻(头条,天天快报等)
    • 生活服务类(美团、携程等)

    如果将推荐系统简单拆开来看,推荐系统主要是数据,算法和架构三方面组成。

    • 数据提供了信息。数据储存了信息,包括用户与内容的属性,用户的行为偏好、历史行为记录等。

    • 算法提供了逻辑。数据通过不断的积累,存储了巨量的信息。在巨大的数据量与数据维度下,人已经无法通过人工策略进行分析干预,因此需要基于一套复杂的信息处理逻辑,基于逻辑返回推荐的内容或服务。

    • 架构解放了双手。架构保证整个推荐自动化、实时性的运行。架构包含了接收用户请求,收集、处理,存储用户数据,推荐算法计算,返回推荐结果等。有了架构之后算法不再依赖于手动计算,可以进行实时化、自动化的运行。例如在淘宝推荐中,对于数据实时性的处理,就保证了用户在点击一个物品后,后续返回的推荐结果就可以立刻根据该点击而改变。一个推荐系统的实时性要求越高、访问量越大那么这个推荐系统的架构就会越复杂。

    三、推荐系统的整体架构

    推荐的框架主要有以下几个模块:

    1、协议调度:请求的发送和结果的回传。在请求的过程中,用户会发送自己的ID,地理位置等信息。结果会回传返回推荐给用户的结果。

    2、推荐算法:算法按照一定的逻辑未用户产生最终的推荐结果。

    3、消息队列:数据的上报与处理。根据用户的ID,拉取用户的性别,之前的点击,收藏等用户消息。而用户在APP中产生的新行为,例如新的点击将会存储在存储单元里面。

    4、存储单元:不同的数据类型和用户会储存在不同的存储单元中。

    四、用户画像

    4.1 用户标签

    标签是我们对多维事物的降维理解,抽象出事物更具有代表性的特点。例如:我们永远都无法深入的了解一个人,但是可以通过一个一个标签来刻画,所有的标签最终会构建一个立体的画像,一个详细的用户画像会更有利于我们理解用户,进而推荐更加适合的内容。

    4.2 用户画像分类

    1、原始数据

    原始数据一共包括4方面

    • 用户数据:性别、年龄、渠道、注册时间等。
    • 内容数据:商品的品类,商民的描述,标签等。
    • 用户与内容的交互:基于用户的行为,了解用户喜欢的商品类别,关键词等。
    • 外部数据:单一的产品只能描述用户的某一喜好,外部数据标签可以让用户更加立体。

    2、事实标签

    事实标签可以分为静态画像和动态画像的属性。例如用户的自然属性,比较稳定,具有统计性意义。

    • 静态画像:用户独立于产品场景之外的属性
    • 动态画像:用户在场景中所产生的线性行为或隐性行为。
    • 显性行为:
    • 隐性行为:这两个都很熟悉了所以不打算再赘述。

    3、模型标签

    模型标签是由事实经过加权计算或是聚类分析所得。通过一层加工处理,标签包含的信息量得到提升,在推荐过程中效果更好。

    • 聚类分析:例如根据用户的活跃度进行聚类,及那个用户分为:高活跃-低活跃-中活跃三类
    • 加权计算:根据用户的行为将用户的标签进行加权计算,得到每一个标签的分数,用于之后推荐算法的计算。

    五、内容画像

    内容画像:例如对文章中的新闻资讯类推荐,需要采用NLP技术对文章的标题,正文等提取关键词。找到对应的标签。视频除了对于分类,标题关键词的抓取之外,还以来图片处理的技术。

    环境变量:对于推荐系统来说,环境画像也十分重要。例如在短视频推荐场景每用户在看到一条视频所处的时间,地点以及当时浏览的前文内容,当天浏览的内容,时间等都是十分重要的变量。

    六、算法构建

    6.1 推荐算法构建

    推荐算法本质上是一种信息处理逻辑,当获取了用户与内容的信息之后,按照一定的逻辑处理信息后,产生推荐结果。最简单的是根据据热度排行榜。

    6.2 推荐算法的步骤

    1、召回

    a、召回目的

    召回是推荐系统的第一阶段,主要是根据用户和商品部分特征,从海量成品库里,快速召回一小部分用户潜在感兴趣的物品,然后交给排序环节。这部分处理的数据量非常打,通常要求使用的策略,模型和特征都不能太复杂。

    b、召回方法(传统的是采用多路召回模式)

    传统的标准召回结构一般是多路召回,如上图所示,如果我们根据召回路是否有用户个性化因素存在来划分,可以分为两大类:一是无个性化因素的召回路,比如热门商品/热门文章/历史点击率高的物料的召回;二是有个性化因素在内的召回路,比如用户兴趣标签召回,主题召回等。

    传统召回模式向着embedding演变:若重新理解上述的个性化召回路,可以把某个个性化召回路看作是:单特征模型排序的排序结果,即可以把某路召回,看成是某个排序模型的排序结果,只不过这个排序模型只使用单一特征进行排序。

    如果使用上面角度看待个性化因素召回路(即没一种召回都是单一特征某一模型排序结果),那么在召回阶段引入模型,无非是把单特征排序,拓展成多特征排序的模型;而多路召回,则可以通过引入多特征,被融入到独立的召回模型,找到它的替代品。(所以,随着技术的发展,embedding基础上的模型召回,必然是符合技术发展潮流的方向)

    • 热度召回(热门):根据item的曝光量、点击量,已经点击做筛选,三者均满足要求的item进入item热度池,作为热度召回的来源,热度池需要实时维护更新。

    • 标签召回:对于不同标签的item,按照标签,时间等进行召回,每个类别召回n个items,作为召回候选集。

    • LDA主题召回:根据item(例如是新闻的)主题召回,结合用户近期画像。

    • 探索类召回:随机选取两个用户从没看过的类别作为探索类召回候选集。

    • 基于内容召回(CB召回):使用item之间的相似性来推荐用户喜欢的item相似的item。

    • 协同过滤(召回)(CF):同时使用query和item之间的相似性来推荐。

    • 时间召回:将一段时间内最新的内容召回,在新闻视频等时效性的领域常用。是常见的几种召回方法之一。

    • 基于FM模型召回:FM是矩阵分解的推荐算法,核心是二阶特征组。

    • 基于深度神经网络召回:利用深度神经网络来生成相应的候选集。

    c、更多召回模型
    • YouTube DNN 召回
    • DSSM语义召回
    • TDM深度匹配召回

    2、过滤(又可以叫做粗排)

    粗排作用:粗排是为了进一步减少召回的item数量,减轻精排压力,同时不损失线上效果。

    双塔DNN模型做推荐系统粗排
    1、理论

    双塔DNN结构

    2、工程实践

    3、精排

    排序是推荐系统的第二阶段,从召回阶段获取少量的商品交给排序阶段,排序阶段可以融入较多特征。使用复杂模型,来精准地做个性化推荐。排序所强调地是快和准,快指的是高效地反馈结果,准指的是推荐结果准确性高。

    具体来说,在生成候选对象之后,另外一个模型会对生成地候选对象进行打分和排序,得到最后要推送到Item列表。推荐系统可能具有是哟不同来源地多个召回队列,例如:

    • 矩阵分解模型的相关item。
    • 根据各类标签下的用户item。
    • “本地”与“非本地”项目,即需要考虑地理位置/
    • 热门或流行item
    • 社交网络
    a、精排模型
    • 精排的不同类别

    • 精排模型的基本原理

      - 其他精排模型

    4、混排

    5、强规则

    七、算法衡量的标准

    • 硬指标:对于大多数的平台而言,推荐系统最重要的作用是提升一些“硬指标”。利润也新闻推荐中的点击率,但是单纯以点击率提升为目标,最后容易成为一些低俗内容,“标题党”的天下了。
    • 软指标:除了硬指标,推荐系统还需要很多“软指标”以及“反向指标”来衡量除了点击等之外的价值。好的推荐系统能够拓展用户的事业,发现那些他们感兴趣,但是不会主动获取的内容。同时推荐系统还可以帮助平台挖掘被埋没的优质长尾内容,介绍给感兴趣的用户。

    7.1 获得推荐的效果

    主要可以通过离线实验,用户调查,在线实验三种方法。

    • 离线实验:通过反复在样本数据进行实验来获得算法的效果。方法比较简单,明确,但是由于数据是离线的,基于过去的历史数据,不能够真实反映线上效果,同时还需要时间窗口的滚动来保证模型的客观性和普适性(即:每隔一段时间进行新的离线实验)
    • 用户调查:当
    • 在线测试(AB Test)
    展开全文
  • 今日头条推荐系统 架构设计实践
  • 今日头条推荐系统 架构设计实践 pdf
  • 今日头条推荐系统架构设计.
  • 7 推荐系统架构设计

    2020-04-19 17:56:55
    7.2:常见的推荐系统架构。 7.3:常用软件,供进行架构设计时选用。 7.4:一些常见问题 7.1推荐系统基本模型 本质上推荐系统是监督学习 监督学习分学习和预测 学习系统利用给定的训练样本, 训练得到模型,模型随后会被...
  • 淘宝推荐系统架构ppt,讲述了淘宝的推荐系统架构,可以作为参考。
  • 本文贡献如下:(1)介绍了区块链、推荐...(2)提出了一个基于区块链和社会计算的推荐系统架构,解决用户移动性带来的问题和用户隐私保护问题;(3)设计了用户可自定义推荐比例的功能;(4)分析评估了该架构的优势。

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 6,297
精华内容 2,518
关键字:

推荐系统架构