出家如初,成佛有余

基于lucene实现自己的推荐引擎

Posted in Uncategorized by chuanliang on 2010/09/30

    采用基于数据挖掘的算法来实现推荐引擎是各大电子商务网站、SNS社区最为常用的方法,推荐引擎常用的Content-Based推荐算法及协同过滤算法(Item-Based 、User-based)在电子商务推荐系统入门v2.0 电子商务推荐系统入门基础  中已经有所阐述。但从实际应用来看,对于大部分中小型企业来说,要在电子商务系统完整采用以上算法有很大的难度。

1、常用推荐引擎算法问题

  1)、相对成熟、完整、现成的开源解决方案较少

       粗略分来,目前与数据挖掘及推荐引擎相关的开源项目主要有如下几类:

       数据挖掘相关:主要包括WekaR-ProjectKnimeRapidMinerOrange

       文本挖掘相关:主要包括OpenNLPLingPipeFreeLingGATE 等,具体可以参考LingPipe’s Competition

       推荐引擎相关:主要包括Apache MahoutDuine frameworkSingular Value Decomposition (SVD) ,其他包可以参考Open Source Collaborative Filtering Written in Java

       搜索引擎相关:Lucene、Solr、Sphinx、Hibernate Search等

   2)、常用推荐引擎算法相对复杂,入门门槛较低

   3)、常用推荐引擎算法性能较低,并不适合海量数据挖掘

       以上这些包或算法,除了Lucene/Sor相对成熟外,大部分都还处于学术研究使用,并不能直接应用于互联网大规模的数据挖掘及推荐引擎引擎使用。

2、采用Lucene实现推荐引擎的优势

     对很多众多的中小型网站而言,由于开发能力有限,如果有能够集成了搜索、推荐一体化的解决方案,这样的方案肯定大受欢迎。采用Lucene来实现推荐引擎具有如下优势:

    1)、Lucene 入门门槛较低,大部分网站的站内搜索都采用了Lucene

    2)、相对于协同过滤算法,Lucene性能较高

    3)、Lucene对Text Mining、相似度计算等相关算法有很多现成方案

   在开源的项目中,Mahout或者Duine Framework用于推荐引擎是相对完整的方案,尤其是Mahout 核心利用了Lucene,因此其架构很值得借鉴。只不过Mahout目前功能还不是很完整,直接用其实现电子商务网站的推荐引擎尚不是很成熟。只不过从Mahout实现可以看出采用Lucene实现推荐引擎是一种可行方案。

3、采用Lucene实现推荐引擎需要解决的核心问题

   Lucene擅长Text Mining较为擅长,Lucene在contrib包中提供了MoreLikeThis功能,可以较为容易实现Content-Based的推荐,但对于涉及用户协同过滤行为的结果(所谓的Relevance Feedback),Lucene目前并没有好的解决方案。需要在Lucene中内容相似算法中加入用户协同过滤行为对因素,将用户协同过滤行为结果转化为Lucene所支持的模型。

4、推荐引擎的数据源

    电子商务网站与推荐引擎相关典型的行为:

  • 购买本商品的顾客还买过
  • 浏览本商品的顾客还看过
  • 浏览更多类似商品
  • 喜欢此商品的人还喜欢
  • 用户对此商品的平均打分

    因此基于Lucene实现推荐引擎主要要处理如下两大类的数据

   1)、内容相似度

      例如:商品名称、作者/译者/制造商、商品类别、简介、评论、用户标签、系统标签

   2)、用户协同行为相似度

      例如:打标签、购买商品、点击流、搜索、推荐、收藏、打分、写评论、问答、页面停留时间、所在群组等等

5、实现方案

5.1、内容相似度

    基于Lucene MoreLikeThis实现即可。

5.1、对用户协同行为的处理

    1)、用户每一次协同行为都使用lucene来进行索引,每次行为一条记录

    2)、索引记录中包含如下重要信息:

        商品名、商品id、商品类别、商品简介、标签等重要特征值、用户关联行为的其他商品的特征元素、商品缩略图地址、协同行为类型(购买、点击、收藏、评分等)、Boost值(各协同行为在setBoost时候的权重值)

    3)、对评分、收藏、点击等协同行为以商品特征值(标签、标题、概要信息)来表征

    4)、不同的协同行为类型(例如购买、评分、点击)设置不同的值setBoost

    5)、搜索时候采用Lucene MoreLikeThis算法,将用户协同转化为内容相似度

    以上方案只是基于Lucene来实现推荐引擎最为简单的实现方案,方案的准确度及细化方案以后再细说。

    更为精细的实现,可以参考Mahout的算法实现来优化。

Advertisements

互联网产品线管理模式思考4:团队培养

Posted in Uncategorized by chuanliang on 2010/09/23

    继续互联网产品线管理模式思考3:产品平台研发“弱产品、强技术”困境 思考产品平台技术维护团队培养与成长问题,重点是思考怎样保证产品平台维护的核心团队稳定性,但同时避免“大厨式研发”、“牛人研发”问题;以及产品人员、技术人员等平台维护人员职业发展通道问题。

    产品平台的维护对于喜欢追求新技术、新挑战的技术人员而言,其实挺乏味的,尤其是日复一日的各种投诉问题处理、小需求修改、小规模的代码重构,这些日常平台维护任务对于刚毕业毫无经验的技术人员、产品助理倒是一种快速熟悉业务、提升解决问题能力一种行之有效的手段,但对于那些有工作经验的人员而言,并没有太多的挑战,长期以往只能消磨掉这些员工的工作激情。典型现象:

   1)、开发技能要求不高。既然已经是一个运营维护期的产品平台,一般都有一整套相对成熟的技术框架、开发模式、业务模式,因此本质上对于大部分的日常维护技术要求并不高,只要熟悉了平台的开发模式及业务实现后,剩下的大部分开发维护工作就是Copy-Paste,并不需要广泛的知识面。

   2)、专业化分工,技能要求单一。一般平台化产品的运营维护分工比较明确。产品设计、架构设计、开发、测试、系统、网络、DBA、运营、网络营销等都有专职的人员兼顾,相对于那些几十号的公司而言,全方面锻炼的机会有限,专业技能要求是做深而非做广。但正如1)中提到的,平台维护开发技能要求并不高

   3)、新项目的机会有限。持续有新项目做,对于技术人员、产品人员倒是一种激发兴趣的手段,但对于大部分运营型公司而言,天天有新项目做的几率基本上很小。

   4)、职业发展通道有限:尽管每一个公司的平台维护人员的职业发展通道都无比美好、无比多样化,可以有技术通络、产品通路、管理通路等。例如初级软件工程师/初级产品经理->中级软件工程师/中级产品经理->高级软件工程师/高级产品经理->架构师/行业产品经理->高级架构师/技术总监/行业产品总监->总首席架构师/CTO/行业专家。但对于大部分公司而言,由于专业化分工的需要,晋升的通道并没有传说中那么多样化,而且由于团队规模的扩大,所谓的职业发展规划对于大部分互联网公司而言还只能停留在理念阶段或是对于个别重点员工而已。

    5)、公司变大后不可避免的官僚体制及公司政治

  上述现象只是描述典型的问题,并不是说每一个平台型公司都会面临,也没有否认平台型公司具备的各种优势。

  关于产品线管理模式下团队培养的初步思考,后续持续总结、更新。

Product line,Product platform,产品线,产品平台,产品管理,产品经理

 

互联网产品线管理模式思考3:产品平台研发“弱产品、强技术”困境

Posted in Uncategorized by chuanliang on 2010/09/18

    继续思考一下产品线管理模式下产品平台的维护策略,除了在互联网产品线管理模式思考2:产品平台的维护策略 中提到从统一架构、统一变化入口、定期重构、管理支撑等手段外,尚有很多现实的问题没有得到有效解决,尤其是研发体系相关的问题,先记录下来,慢慢思考,例如:

   1、怎样避免产品平台运营过程中“弱产品、强技术”的困境,最熟悉平台产品细节的人员不是产品人员而是技术人员,最终导致平台的运营是技术驱动而非产品驱动、市场驱动。

   2、产品平台技术维护团队培养与成长问题,怎样保证产品平台维护的核心团队稳定性,但同时避免“大厨式研发”、“牛人研发”问题。以及产品人员、技术人员等平台维护人员职业发展通道问题

   3、产品平台中技术支持的定位、扮演的角色,怎样发挥出技术支持作为客户代言人的核心价值,而不是停留在低层次的技术答疑上

   4、产品平台团队知识持续积累并传承问题,怎样营造学习型组织气氛

   5、矩阵式组织机构在产品平台管理模式下优化问题,怎样达成职能专业化与跨功能整合之间的平衡

   6、产品平台维护中敏捷性与整体规划下的流程化的平衡

  这里先思考比较典型的问题1,其他有空慢慢思考。

  导致问题1的主要原因主要如下:

      1)、没有建立起适合自己公司实际需要的产品研发体系,尤其是针对产品线模式下的研发体系相应的调整。或是僵化生搬硬套CMMI、RUP,但最终因繁琐而导致流程流于形式,或是以所谓的“敏捷开发过程”来为自己的无规划、无设计、无文档、无注释、无评审找理由(此种精神很符合party按照自己的需要来定义所谓的国际惯例、中国特色,可以称之为“和谐版本的敏捷开发过程”)。

      2)、在战略层面及产品层面对产品平台及产品没有合理的规划过程,所谓的战略家们画上几个ppt忽悠一遍就说产品思路已经很清晰了,只差产品细节设计了。而产品人员与战略家们飘在空中的思维始终搭不上界。战略与产品实现始终是两层皮,产品成功了是战略的成功,产品失败了是产品研发的问题

      3)、产品经理能力较弱,对产品需求并没有完整的规划和分析过程,只停留在简单的需求传递上。或是没有需求文档或是只言片语的需求描述,对于产品具体实现细节并不清楚,产品实现基本上由技术人员代劳。

      4)、技术没有明确的分析设计过程,相关的产品设计文档缺失,对于业务实现细节只有程序员查代码才知道,所谓“代码是最好的注释和文档”

      5)、QA没有对产品明确的业务测试用例,即使有也只是停留在简单的功能性测试上。每一次上线都是技术人员告诉测试要点和测试步骤,测试只是重复一遍技术人员的测试过程。

      6)、在日常运营中,由于没有相关的产品支撑工具,例如使用文档、产品销售工具包、接入文档、二次研发指南、产品FAQ、产品知识库等,所有的问题只有技术才能最终排查清楚,于是乎销售人员、技术支持、产品人员、运营人员等都养成了对技术人员的依赖症,所有的问题都直接交给技术来处理。产品人员对于产品状况不是很清楚,对于用户的痛苦没有切身的感受,于是乎也没有动力和压力去持续优化产品。而技术人员在新功能开发与日常的维护支持中挣扎,也没有精力去优化产品、完善相关支撑工具

      7)、对产品没有持续规划和持续重构的心理预期,战略家们指望一次性的规划和一次性的研发能够做出完美的产品,无法理解和容忍一个产品需要持续不断的重构和规划。其实对于互联网产品而言,持续有序的规划、反思和重构是敏捷响应市场需求有效的竞争手段。对于大部分公司而言,在严重缺少优秀的战略人员、产品人员、研发人员、运营人员的情况下,可以通过持续规划和持续重构来降低单次研发风险。其实问题的核心不在于一次还是多次规划或重构,而在于规划和重构过程是否有序、是否符合产品研发内在的节奏、是否能够持续改进

    综上所述,问题1的出现并不单纯只是技术人员、产品人员的问题,而是整个公司产品研发体系不畅的问题,在如上每一个环节如果能够做到位都可以弥补因“弱产品、强技术”导致的各种问题。对于产品线模式下的研发体系继续思考中。

 

互联网产品线管理模式思考2:产品平台的维护策略

Posted in Uncategorized by chuanliang on 2010/09/04

    在互联网产品线管理模式思考1:产品线管理策略 中按照Software Product Line的框架介绍了产品平台整体的管理策略,继续就产品平台日常的维护策略进行思考。

1、导致平台维护混乱的典型问题

  • 平台没有统一规划,各产品按照自己需求对平台进行修改
  • 对产品需求变化没有有效控制,任何人都可以平台进行修改
  • 平台中的共性和可变性边界模糊,共性需求按照可变性来做
  • 架构耦合度太高
  • 缺少专职的支撑组织及制度,没有按照生命周期对平台进行管理
  • 产品文档缺少,只停留在个别人头脑中,人员流动导致知识的遗失

  其他的典型问题,在《研发困局》中倒有比较详解的阐述

2、平台维护核心思路

  对一个产品平台日常的管理维护核心的思路包括:

  • 统一架构
  • 统一变化入口
  • 定期重构
  • 管理支撑

具体的思路说明,参考下图:

Product line,Product platform,产品线,产品平台