-
算法
[纯技术] 工作职位推荐系统的算法与架构
Indeed.com 每个月有两亿不同的访客，有每天处理数亿次请求的推荐引擎。在这篇文章里，我们将描述我们的推荐引擎是如何演化的，如何从最初的基于Apache Mahout建立的最简化可用行产品，到一个在线离线混合的成熟产品管道。我们将探索这些变化对产品性能指标的影响，以及我们是如何通过使用算法、架构和模型格式的增量修改来解决这些挑战的。进一步，我们将回顾在系统设计中的一些相关经验，相信可以适用于任何高流量的机器学习应用中。
从搜索引擎到推荐
Indeed的产品运行在世界各地的许多数据中心上。来自每个数据中心的点击流数据以及其他应用事件被复制到我们在奥斯丁数据中心的一个中心化的HDFS数据仓库中。我们在这个数据仓库上进行计算分析并且构建我们的机器学习模型。
我们的职位搜索引擎是简单而直观的，只有两个输入：关键字和地点。搜索结果页面展示了一个匹配的职位列表，并基于相关性进行了排序。搜索引擎是我们的用户发现职位的主要方式。
我们决定在搜索引擎之上加入职位推荐作为一个新的交互模式是基于以下几个关键原因：
Indeed上所有搜索的25%只指定了一个区域，并没有搜索关键字。有许多的求职者并不确定在他们的搜索中应该用什么关键字
当我们发送有针对性的推荐时，求职者的体验是个性化的
推荐可以帮助甚至最复杂的用户来发现额外的未被搜索所涵盖的职位
推荐为亚马逊带来了额外35%的销量为Netflix75%的内容阅览。很显然，推荐能提供额外的价值
推荐职位与推荐产品或者是电影有很显著的区别。这里列举了一些我们在构建推荐引擎时仔细考虑过的因素：
（职位）库存快速增长：我们每天要聚合计算几百万新的职位。可以推荐的职位的集合在不断变化
新用户：每天有几百万新的求职者访问我们的网站并开始他们的职位搜索。我们想要能够根据有限的用户数据生成推荐。
流动性：在indeed上一个职位的平均生命周期是30天左右。内容的更新十分重要，因为老的职位的需要非常可能已经被满足了
有限的供给关系：一个发布的职位通常只招一个的应聘者。这和书籍或者电影很不一样，并不是只要有库存就可以同时推荐给很多用户。如果我们过度推荐一个职位，我们可能会让雇主收到到上千个应聘申请的轰炸。
如何理解推荐算法
推荐是一个匹配问题。给定一个用户集合和一个物品集合，我们想要将用户匹配到他们喜欢的物品上。有两种高层次的方法可以达成这类匹配：基于内容的和基于行为的。它们各有优缺点，此外也有将两者结合起来从而发挥各自优势的方法。
基于内容的方法使用比如用户偏好设置、被推荐物品的特性之类的数据来决定最佳匹配。对于职位推荐来说，通过职位的描述中的关键字来匹配用户上传的简历中的关键字是一种基于内容的推荐方法。通过一个职位的关键字来找到其他看上去相似的职位是另外一种基于内容的推荐的实现方法。
基于行为的方法利用了用户的行为来生成推荐。这类方法是领域无关的，这意味着同样的算法如果对于音乐或者电影有效的话，也可以被应用在求职领域。基于行为的方法会遇到所谓的冷启动问题。如果你只有很少的用户活动数据，就很难去生成高质量的推荐。
Mahout协同过滤
我们从建立一个基于行为的推荐引擎开始，因为我们想要利用我们已有的求职用户和他们的点击数据，我们的首次个性化推荐尝试是基于Apache Mahout提供的基于用户间的协同过滤算法的实现。我们将点击流数据喂给一个运行在Hadoop集群上的Mahout构建器并产生一个用户到推荐职位的映射。我们建立一个新的服务使得可以运行时访问这个模型，且多个客户端应用可以同时访问这个服务来获取推荐的职位。
产品原型的结果和障碍
作为一个产品原型，基于行为的推荐引擎向我们展示了一步步迭代前进的重要性。通过快速建立起这个系统并将其展示给用户，我们发现这种推荐对于求职者来说是有用的。然而，我们很快就遇到了一些在我们的数据流上使用Mahout的问题：
模型构建器需要花大约18个小时的时间来处理Indeed网站2013年的点击流数据，这个数据量要比今日的数据小了三倍。
我们只能一天执行一个模型构造器，这意味着每天新加入的用户直到第二天为止看不到任何推荐。
几百万新汇总的职位在模型构造器再次运行之前是不能作为可见的推荐的。
我们产生的模型是一个很大的映射，大约占了50吉字节的空间，需要花费数个小时将其通过广域网从其生成的数据中心拷贝到全球各地的数据中心。
Mahout的实现的提供露了一些可配置参数，比如相似度阈值。我们可以调节算法的参数，但是我们想要测试整个不同的算法这样的灵活性。
为推荐实现最小哈希
我们先解决最重要的问题：构建器太慢了。我们发现在Mahout中的用户间相似度是通过在n^2复杂度下的用户间两两比较的来实现的。仅对于美国的网站用户来说（五千万的访问量），这个比较的数量将达到15 * 10^15次，这是难以接受的。而且这一计算本身也是批量处理的，新加一个用户或者一个新的点击事件就要求重新计算所有的相似度。
我们意识到推荐是一个非精确匹配问题。我们是在寻求方法来发现给定用户最相近的用户们，但是我们并不需要100%准确。我们找了一些估算相似度的方法，不需要准确的计算。
主要贡献者戴夫格里菲思从一篇谷歌新闻学术论文上看到了最小哈希方法。最小哈希（或者最小独立序列）允许近似计算杰卡德相似度。将这一方法应用到两个用户都点击过的职位上，我们发现两个用户有更多共同的职位点击，那么他们的杰卡徳相似度就越高。为所有的用户对计算杰卡徳相似度的复杂度是O(n^2)，而有了最小哈希后，我们可以将复杂度降到O(n)。
给定一个哈希函数h1, 一个项目集合的最小哈希被定义为将集合中所有项用该哈希函数分别哈希，然后取其中最小的值。由于方差太大，单个哈希函数不足以计算近似杰卡徳相似度。我们必须使用一个哈希函数族来合理地计算近似的杰卡徳距离。通过使用一个哈希函数族，最小哈希可被用来实现可调节杰卡徳相似度阈值的个性化推荐。
“挖掘海量数据集”，一个最近的由斯坦福大学教授莱斯科维克、拉贾罗曼和厄尔曼讲解的Coursera课程，非常详细的解释了最小哈希。他们书的第三章——“挖掘海量数据集”，解释了最小哈希背后的数学证明原理。
我们针对推荐的最小哈希的实现涉及到以下三个阶段：
1. 签名计算和集群分配
每一个求职者被映射到一个h个集群的集合，对应了一个哈希函数族H（下面的伪代码展示了这一过程）：
H = {H1, H2, ..H20}
for user in Users
for hash in H
minhash[hash] = min{x∈Itemsi| hash(x)}
这里H是一个包含h个哈希函数的族。这一步的最后，每一个用户被一个签名集合所代表，也即一个由h个值组成的集群。
2. 集群扩展
共享相同签名的用户被认为是相似的，他们的职位将为被互相推荐。因此我们从每一个在集群中的用户开始，用其所有的职位来扩展每个集群。
3.生成推荐
为了给一个用户生成推荐，我们将h个用户所在的集群中的职位并起来。然后我们除去任何用户已经访问过的职位，从而得到最后的职位推荐。
为新用户推荐职位
最小哈希的数学属性使得我们可以解决为新用户推荐职位的问题，并且可以向所有的用户推荐新的职位。当新的点击数据到来的时候，我们增量地更新最小哈希签名。我们也在内存中维护新职位和他们的最小哈希族的映射。通过在内存中保留这两部分数据，我们就可以在新用户点击了一些职位后为他们推荐职位。只要任何新发布的职位被点击访问过，它就可以被推荐给用户。
在转移到最小哈希方法后，我们有了一个混合的推荐模型，由一个在Hadoop上的构建的离线每日被更新的组件和一个由当日的点击数据组成、在内存缓存中实现的在线组件。这两个模型被整合起来用以计算每一个用户的最终推荐集合。在我们做了这些改变之后，每一个用户的推荐变得更加得动态，因为它们将随着用户点击感兴趣的职位的同时发生变化。
这些改变中我们认识到，我们可以在性能和准确度上做出权衡，用小的误差增加来换大的性能提升。我们也认识到可以将较慢的离线模型通过在线的模型进行补充，从而得到更新的推荐结果。
工程基础设施的影响
包含每一个用户到他们的推荐的映射的推荐模型是一个相当庞大的文件。由于职位对于每个国家来说都是本地的，我们首先尝试将我们的数据基于大约的地理边界进行分片。我们在每一块区域运行模型构造器，而不是在整个世界运行一个。每一个地区都有多个国家组成。举个例子，东亚地区包括为中国、日本、韩国、香港、台湾以及印度的推荐。
但是在分片之后，一些区域产生的数据仍然十分庞大，需要花好几个小时才能通过广域网从欧洲数据中心拷贝到奥斯丁的Hadoop集群。为了解决这个问题，我们决定增量的传输推荐数据，而不是一天一次。我们重用了连续先写日志(sequential write ahead logs)的方法，通过日志结构合并树来实现。这一方法已经在Indeed的其他大型产品应用中得到验证，比如我们的文档服务。
我们修改了我们的模型构建器，将推荐数据存储成小的分段，而不是产生一个单独庞大的模型文件。每一个段文件使用顺序输入输出，并且为快速复制做了优化。这些分段在远程数据中心运行推荐服务时将被重新组装成一个日志结构合并树。
这一基础架构的改变使得用户可以比之前快数个小时在远程的数据中心上看到他们新的推荐。从我们的A/B测试的结果来看，由用户更快的得到新职位推荐带来了30%的点击量提升。
这一改进展示了工程基础设施的改进与算法的改进带来的影响不相上下。
改进A/B测试的速度
建立起计算和更新推荐的管道只是一个开始。为了改进覆盖率和推荐质量，我们需要加快我们的A/B测试的速度。我们为了调整最后的推荐集合做了很多决策。这些决策包括，相似度阈值，每一个用户的推荐包含的职位数量，以及各种不同的用来过滤掉低质量推荐的方法。我们想要调节和优化计算推荐的各个方面，但是这需要逐个对算法的每个改进都构建新的模型。测试多个改进想法意味着处理用户请求的服务器上多倍的磁盘以内存占用。
我们开始通过传输计算推荐的单独组件而不是最终的结果来改进我们的A/B测试。我们改变了推荐服务来执行最后的计算，即通过将碎片整合起来，而不是简单的读取模型返回结果。重要的推荐子组件是每个用户的集群分配，从每一个集群到这个集群中的职位的映射以及一个对于每个用户来说包含不应该推荐给他们的职位的黑名单。我们修改了我们的构建器，来产生这些组件，并且修改了我们的服务，将他们在收到请求时组合起来从而返回最终的推荐列表。
通过实现这种架构上的改变，我们只传输那些在每一个A/B测试中改变的子组件。比如说，如果测试只调节了什么样的职位会从一个用户的推荐中除去，那么我们只需要传输这个测试组的黑名单。
这一改变改进了A/B测试的速度的数量级。我们能够在很短的时间内测试并验证多个可以改进推荐质量和覆盖率的想法。之前，由于设置环境的开销较大，我们平均每个季度只能测试一个模型中的改进，
我们的经验表明A/B测试的速度应该在设计大型机器学习系统时就被考虑进去。你能越快地将你的想法放在用户面前，那么你就能越快地在上面迭代。
这篇文章总结了我们在构建我们的推荐引擎时做出的一系列算法和架构上的改变。我们迭代地构建软件，我们从一个最简单原型开始，从中获取经验，并不断改进。这些改变带来的成果是职位推荐的点击增加从2014年初最简原型时的3%增长到了14%。
我们将继续精炼我们的推荐引擎。我们正在使用Apache Spark建立一个原型模型，建立一个模型集成组合，并精炼我们的优化参数来应对流行偏见问题。
Preetha Appan
Preetha Appan是Indeed的高级软件工程师，是高性能推荐搜索分布式系统的专家。她对Indeed的职位和简历搜索引擎的贡献包括，文本切分改进、查询扩展特性以及其他重要的基础设施和性能改进。她乐于并享受解决机器学习和信息检索方面的挑战性的问题。
来源：OReillyData
-
算法
这个算法告诉你，公司谁要离职了
每一个老板都想猜透员工的心思，想找出那些身在曹营身在汉的员工，可每每都会有员工出其不意地给老板送上一份辞呈。
对于人才密集型的行业而言，人才外流恐怕是管理者最头疼的事之一，如果能够提前洞悉到员工的行为和想法，就能够在员工丢下一纸辞呈前采取措施进行挽留。
华尔街日报披露了一种有趣的方法，包括沃尔玛、瑞士信贷集团和 Box 正在通过大数据“算”出最有可能跳槽的员工。
这些公司的 HR 部门会收集员工的工作任期、员工调查、沟通模式甚至性格测试等一系列数据，这些数据往往能够揭示员工去留的动机，从而分析判断员工的离职倾向性。
没有一种单一的数据可以预测员工去留。离职背后的动机通常很复杂，收入多寡、同事关系、公司前景、职业规划等等，在不同公司，这些变量的影响力又有很大的差异。
比如在 Box 公司，一名员工的收入和与上司的关系重要性远不如对于团队的感觉。而在瑞士信贷，员工的表现和团队规模又显示出强大的影响力。
人力资源软件公司 Ultimate Software Group 公司就在为它们的客户做这样的分析。根据不同公司的特点和环境，Ultimate Software Group 公司的数据科学家结合测试等一系列变量建构一种算法，从而对哪些员工可能会在近期辞职。类似于信用评分，每名员工都有一个留任预测的指数。
对于公司管理者而言，准确的信息是判断和决策的依据。同理，大数据预测算法的核心取决于数据是否准确、追踪是否全面、算法是否科学。
VoloMetrix 是一家总部位于西雅图的销售、生产力及人力管理初创企业，他们做的是员工活动跟踪解决方案，方法是在不侵犯员工隐私的基础上，通过日历、电子邮件等接口收集和分析数据，从而获得有关主题、时间、协作类型以及参与者的角色和地理位置等信息。这些数据经过分析汇总最终可以形成整个公司的沟通和协作行为全景图，并可以对每一位员工的效率做出科学的评估。
对于大部分雇主而言，通过算法分析的目的并不在于驱赶有离心的员工，而在于挽留人才以及搞清楚背后的动机，解决公司弊病。但这并不意味着算法绝对可靠，更多时候它只能作为一个参考，让雇主多一个心眼。
“我们绝对不会说找员工谈话的唯一理由是算法让我们这样做的。”AOL 人力分析主管 John Callery 表示，AOL 想提高留任指数还为时尚早，测试预测模型就需要至少一年时间。
大数据的预测并不仅仅局限于离职倾向性的分析中，很多模型都可以为人力资源提供参考。比如沃尔玛就通过数据分析预测哪些员工可以晋升，从而有计划地组织和安排员工的岗位的替换和交接。这家零售商巨头每年就会晋升 16 万-17 万名员工。
凡事预则立不预则废。正如沃尔玛负责人员分析的全球副总裁 Elpida Ormanidou 说：
“如果我们能够提前三个月，我们就能够尽快地组织招聘和培训，没有人希望职位一直空缺着。”
来源：爱范儿
//
扫一扫，关注“HRTechChina”,聆听人力资源科技的声音！
-
算法
Google想出了一个决定人员晋升的算法，然后就没有然后了......
Prasad Setty 是 Google People Analytics 团队的副总裁。7 年前 Google 成立的这支团队的职责是收集和利用数据来支撑公司的管理实践。其使命很简单，即基于数据和分析做出所有的人事决定。在今年 10 月举行的Google re:Work大会上，Setty 介绍了这支团队用科学来进行人力资源管理的一些做法。其结论是，算法虽好，可不能滥用，人事决定终归要有人来决定。
Google 是一个由工程师成立的公司，目前也仍然由工程师统治。这家成千上万的大公司每年都要做出许多的人事决定：应该招谁？提拔谁？最好的人应该给多少薪水？通常 Google 会找 4、5 个资深工程师组成委员会，由每个委员会审查一堆提名，经过很多次的对话后做出决定。Google 的这个人员晋升评审流程相当复杂，要审查的材料和召开的会议太多，以至于连 Google 的会议室都不够用，所以要跑到附近的万豪酒店去开会。
因此，为了帮助减轻审查委员会的工作负担，早期时 People Analytics 团队开发出了一个算法来简化人员晋升的决策流程。这个算法是一个计算晋升可能性的公式，如下图所示，里面考虑了平均绩效、经理推荐以及个人推荐（Google 允许员工自我推荐）三方面的因素（各赋予不同的权重，平均绩效权重最，其次是经理推荐，最后是个人推荐）。
通过与最后的晋升结果比较发现，该算法相当可靠，后台的测试结果很好，经历过多周期后仍表现稳定，其中 30% 的提拔案例决策准确率达到了 90%。团队成员都很兴奋，以为自己因此能够节省委员会 1/3 的工作，让他们腾出时间专注于最困难的决定。
但是结果是那帮人根本不买账，不想用这个模型。因为他们不希望躲在黑箱背后，而是希望自己做出决定。因此这个算法从来都没有用来做过提拔决策。
Setty 得出的教训是人事决策必须由人来决定。不过 People Analytics 仍然可以发挥作用，即用更好的信息辅佐决策者（用模型来检验自己的决策过程），但是不能用算法来替他们做出决策。
而且，这一洞察还帮助推动了 Google 人力资源和管理的办法改进。People Analytics 在很多方面根本性的重塑了 Google 的招聘机制。比方说，现在 Google 已经不再强调 GPA（盖氏人格评估）与毕业学校，而是更看重一些软性的特质，如“谦逊”、“学习能力”等。
People Analytics 还通过数据分析总结出了伟大经理的 8 项特质：
1） 是一位好教练
2） 给团队授权，不做微观管理
3） 对团队成员的成功和个人幸福表达兴趣/担忧
4） 富有效率/结果导向
5） 好的沟通者—懂得倾听和分享
6） 帮助团队成员的职业生涯发展
7） 对团队有清晰的愿景/策略
8） 有重要的技术技能，可帮助团队提供建议
此外，Google 还在内部寻找志愿者开展长期研究，设立了许多数据点来跟踪其数十年的职业生涯中工作表现、态度、信仰、问题解决策略、面临的挑战与抗压性等。尽管尚未确定能有什么发现，但是收集数据研究肯定是利用科学方法来研究人力资源问题的第一步。
[消息来源：qz.com 文章：36氪]
-
算法
聘宝：用算法＋人工打造的一款推荐为导向的招聘工具
对于某些企业及其职位需求，如果无法获得足够的曝光，就难以获得足够多、匹配的简历（及人才）。另一方面，即便候选人没有投递行为，也很可能对某职位或公司很来电。
聘宝创立于 2013 年 9 月，据知，他们的目标是成为招聘领域最高效便捷的第三方推荐服务，更智能、高效地对接企业和人才。在美国，Jobr 与聘宝异曲同工——前者上线数月，就拿到了 200 万美金天使投资。
“我们做的是推荐型的招聘产品，而不是搜索。”
我觉得这像极了通用类知识引擎的发展思路。
推荐与搜索类的招聘产品，有着相似的出发点：更快地找到信息。区别呢？搜索的场景 ＝ 你明确知道一个要求，用该要求进行信息筛检。 与此相比，推荐的场景 ＝ 你只知道需求范围，得阅读相关信息进一步明确需求。同时，推荐与个性化几乎是天生一体。相同的需求输入，不同用户获得的推荐结果不尽相同。
聘宝调研后发现：招聘方在 Po 出某些岗位时，其实很难决定，嗯，这个工作需要你有 “三年以上” 或者 “两年以上” 的相关经验——2.5 年的你要还是不要呢？或者在某些公司（比如：BAT）有从业背景——在某知名创业公司工作过的，你觉得会不会输给 BAT 出来的呢？当筛选条件过于严苛（而死板），企业就很可能错失优质的候选人。求职者方面，则往往难以确定适合的行业——是电商、PM、还是运营？
而据聘宝方面介绍，他们的推荐系统则在了解招聘需求的同时，根据用户行为不断修正推荐结果。推荐会愈发接近使用者偏好，同时提供探索性内容。
具体怎么做？
企业登录聘宝，进行简单的勾选，就能完成招聘需求录入
聘宝收到招聘需求后进行解析、匹配，并将算法认为匹配的候选人推荐给该企业的某条招聘需求
每次仅推荐 3～5 份候选人简历，以确保推荐准确
企业收到推荐时，可选直接下载联系，或发送求职意向确认
候选人收到企业的意向邀请邮件时，可选择“感兴趣，愿意进一步接触” 或 “不感兴趣”
同时，聘宝会记录用户行为、分析用户喜好，以便下次推荐更符合用户需求（HRTECH编编认为，通过将信息解析，匹配后推荐候选人或者推荐企业的方法的确会给我们用户带来方便，省去了时间。据小编所知，有几家招聘网站也有类似的过程，但匹配度总是差强人意，所以要做好这一步非常不容易，如果做得好，无疑直接会增强用户的体验感。）
聘宝的原始数据来自于自身的 IT 猎头团队，同时还创造了“人才伙伴”的独立角色——上传闲置人才，推荐成功则获得其他简历的下载额度。
为了更快地切入 C 端，聘宝预计 12 月上线微信版本。求职者能匿名录入部分信息、获得工作推荐。当对某一份工作确认求职意向时，再录入完整信息。（HRTECH编编认为，虽然这样的创意不错，如果求职者想跳槽，匿名也一定程度上避免了让熟悉的人看到，毕竟很多人在想要跳槽的初期并不想让太多的人知道；但是问题来了，如何确保求职者在求职初期匿名的时候填写的信息是真实的？HRTECH编编认为这是要需要解决的）
同时，我们得知聘宝方面也在考虑对接第三方语音录入接口，尽可能简化移动端用户的信息录入。”
谈谈聘宝的技术
聘宝的算法 ＝ 大数据＋人工优化——人工中的招聘经验和知识体系是基础：
首先，建立行业招聘的 “人工智慧”。
每开通一个行业，会先邀请这个行业有猎头经验或 HR 经验的顾问，来共同讨论、建立原始模型和知识库。聘宝团队内部还全职招募了 2 名前 IT 行业猎头。
其次，算法设计比较深入、全面。更好的“理解”需求和文本简历是机器算法的基础——聘宝的匹配算法不仅是纯文本的包含关系匹配，还扩展到知识体系、薪资测算等数十个环节。
再次，聘宝算法的目标是做到 “大规模定制化”。当用户行为数量足够多时，算法能更快了解用户偏好——从而做到同样的招聘需求文案，不同招聘方得到的推荐结果会依据偏好差异而不同。
（对于一个刚上线不久的产品来说，目标还是值得赞的！希望聘宝能早日实现目标）
聘宝将自己不光定义成是一样互联网产品，也是一项服务
作为一项“服务”，聘宝希望无论用户处于何种场景，都能便捷地获得人才或工作推荐。
想象一下这样的使用场景：当 HR 工作时，收到一份业务部门发送的招聘要求。接下来，HR 只要将招聘要求邮件转发给聘宝，后者就会迅速开始匹配人才，再回复邮件将匹配结果发给 HR。另一方面，求职者能通过微信方便地获得匹配的工作推荐。
聘宝内测版已于去年 12 月上线，邀请了少量用户参与体验。今年 6 月正式对外发布，据聘宝方面告诉记者，不到半年已获得 1500 名企业用户。
扫一扫 加微信
hrtechchina
