机器学习能不能赚钱，关键不是算法 来源｜经授权转载自知乎@吴海波编辑｜DebraAI 前线导读：大多数关注机器学习的同学，更多关注的是算法本身，而机器学习能不能给公司带来价值，需要很多配套系统去支持。对于很多小公司来讲，这块的建设一般比较薄弱，本文来聊聊蘑菇街这几年在这块的工作，并针对研发能力较弱的小公司，给出一些个人建议。 更多干货内容请关注微信公众号“AI 前线”（ID：ai-front）数据链路数据是一切的根本，因此首先要有一套全链路打点系统。蘑菇街设计了两套字段方案，PTP 和 ACM，其中 PTP 负责追踪页面跳转，ACM 负责追踪算法实验标识。PTP 有个事件管理中心，各个业务方可以在此注册事件类型，比如电商有曝光、点击、加购、成交等事件，PTP 必须能保证用户的这些行为交互中，数据链路不会中断。简单来讲，当拿到一条成交日志，要能回溯到用户是在什么地方加购，什么地方点击，哪个渠道曝光的。 ACM 字段和 ABTest 系统对接，算法同学一般会在线上做很多实验，需要追踪实验效果。我们会为每一个实验生成唯一的 acm，基于实验粒度的分析依靠它。 数据链路的稳定性是比较难的，版本变更时，要特别关心打点丢失、不准确等问题。理想情况下，我们可以建立一个打点 schema 管理中心，对其做回归测试，但这个方案会比较影响业务的快速迭代，推动成本较大。目前，我们还是基于一些 test case 来测试管理。 困难点 全链路追踪、链路稳定性 建议 公司内部的方案不能讲的太细，没有接触过这块的同学可以参考友盟、神策等第三方数据分析工具的 SDK，再结合自身的需求设计打点系统。 训练平台机器学习算法是一个试错性很强的领域，因此，算法工程师迭代的速度是重中之重。应该想尽办法提高算法同学迭代的效率，我们经历了单机 R、Python 到 Spark 到搭建了 Tiny+ 训练平台。 整体架构如下： 样子如下图，和阿里的 PAI、第四范式的先知有点像。 一个常见的使用 case 如下： 减少算法同学迭代策略时的代码开发工作，将常见的操作抽象成算子，可以拼拼凑凑地构建模型。前几年的时候，我并不赞同这样做，认为这样的工具会让很多同学不熟悉底层，不利于模型优化。但这两年观点有所转变，前者对团队成员的要求有点高，把算法同学从代码细节中解放出来，更多精力放在特征工程和调参上，确实会有更好的业务产出，这样的工具，对效率提升非常有帮助，特别是团队成员变多后，减少了很多重复工作。 除了训练外，Tiny+ 支持一部分模型评估的功能，包含常见的模型指标，比如 AUC，Group AUC，F1 等，并支持一部分模型分析的功能，比如模型切片分析。 同时，工程同学可以将精力投入到提高算力上，支持更大规模的特征构建和更多数据的训练上。 目前 tiny+ 支持三种任务： 基于 Yarn 的纯 Spark 任务 基于 Spark 的腾讯开源 PS 框架 Angel 任务 基于 K8s+Docker 的 TensorFlow 深度学习任务。 困难点 特征的规模、训练的效率、PS 计算框架下网络通信瓶颈等。 建议 小公司直接用阿里云或者其他大厂的现成服务就挺好的，自研的必要不大。 特征平台特征是模型的核心，在团队合作过程中，提供一个统一的特征平台，除了能够做到统一处理和方便特征复用，减少重复工作外，还能建立特征生命周期管理、状态监控、与上下游系统交互。 我们的基础系统是搜索引擎，搜索引擎有个重要的组件是数据 Dump 系统，里面会管理很多搜索引擎用的字段，用于索引构建。以前我们也把线上需要用到模型字段、特征字段放在这里管理。发现一个是不灵活，一个是非常容易出问题，生命周期也不好管理，字段容易膨胀，给引擎索引构建造成困难。 特征构建一般是基于 Hive 做，需要写很多 SQL。做过阿里比赛的同学应该知道，它们的 ODPS 可以把模型也用 SQL 写出来。但 SQL 有个问题，可读性不如代码，后期维护成本高，很多同学不愿意维护别人的，喜欢自己搞一份特征集，重复工作外还给数据平台的存储增加了压力。 我们的特征平台实现了基础的算子构建，可以拖拽式的完成特征构建。在减少了开发量的情况下，牺牲了一定的灵活性，当算子不支持时，需要提需求给特征平台的同学。当然好处也是明显的，可以针对特定构建逻辑优化效率，算子粒度比 SQL 粗，减少构建工作量，统一了构建流程。 样子如下： 困难点 控制好度，算子设计容易重复造轮子 特征构建性能 建议 小公司可以用 metadata 管理 + Hive + HBase 做到基本可用的特征构建和管理。 ABTestABTest 的第一个问题是分流，业界常见是基于 session 和基于 user 或设备号，前者用户在每一次请求时都有可能命中不同的实验，而后者的用户 AB 分桶是稳定的，即会一段时间停留在一个实验内。在 APP 时代，大部分公司会选择后一种，给用户更稳定的用户体验。当后一种策略由于存在很多黑产及奇怪的设备，会有一部分的用户分流不均，需提前处理。 第二个问题是要能支持灵活的实验。在电商 APP 里面，场景很丰富，大部分的实验是基于场景，需要较灵活的支持在各种不同场景下做实验，并能方便的在系统中看到实验的数据。 第三个问题是实时性，迭代速度是算法同学的核心诉求。有些指标实时数据不置信，比如 GMV，但 CTR 的实时数据置信度高，很有必要支持实时。我们基于 Kafka 收集日志，在 Storm 上开发了实时 ETL 系统。 另外，ABTest 还需支持实验分析功能。将一些常见的分析工具集成在系统里面，比如根据用户群、业务字段等的切片分析，和前面的 Tiny+ 的模型分析配合，类似于 Google 的 TF 的 Extends 提到 TFX。 困难点 实验数据置信度 实验效果分析 建议 ABtest 应该尽量自己做，首先它并不难，开发成本不大，但却能让大家从实践过程中感受数据的细节，特别是其中的分析功能，有助于理解模型和业务，不应该假人之手。 精排系统将搜索推荐业务分层 match 和 rerank 是常见的操作。我们的精排系统基于 Java，类似 TF Servering 的功能，支持各种线上模型服务，不仅限于搜索推荐，还包括图像、NLP、反作弊等。 在线上提供模型服务，除了能支持各种不同的模型外，比如 TF 的模型 load，Spark 的模型 load 外，重点还是要能获取模型预测需要的数据。由于这部分系统对 RT 的要求较高，特征数据的存储性能是很重要的一个问题，我们写了一套自己的存储。 我们还在这里承接业务需求，支持业务对算法结果的干预。系统交互如下： 困难点 在线特征处理和模型训练特征处理代码最好是一套，分开编写除了费人力，也容易出错。 稳定性，很多算法工程师工程素养不高，推个模型把线上系统推挂可不好。 建议 现在的 TF Servering 还比较弱，但他们发展很快，是可以考虑拥抱开源。 User Profile System要做个性化，前提条件是能实时的获取用户在 APP 的行为，我们构建了 UPS 来存储这部分用户数据，包含各种类型的行为数据。它的存储性能也比较重要，支持较好的读写性能、持久化等功能。 一份数据有可能会用于多处系统，故这些系统的底层存储最好是一套，减少数据与系统交互的成本。结构如下： 建议 性能没有到瓶颈之前，Redis 就很好。 搜索引擎这个技术目前已经比较成熟，业界有 Luence，还有基于他们的 Solr、ES 等平台型的解决方案。我们在 15 年自研了引擎，好处和坏处都很明显。好处是我们和容易就在里面支持了向量的矩阵乘，用于优化各种 EMbedding 向量做召回时的性能问题，另外做了一个很奇怪的字段级全量更新。坏处是周边配套工具都得自己搞，而且招人很难。 困难点 太多了，略。 建议 研发力量有限，还是拥抱开源吧，大部分需求 ES 够用了。 推荐引擎这个技术目前已经比较成熟，专栏已经有篇文章写了细节。简单提下，相对于搜索，推荐的召回多种多样，所以该系统主要是针对灵活多样的召回策略设计。架构如下： 困难点 召回需求各式各样，如何能尽量减少代码开发量。 建议 在业务和数据没有上规模前，把各种策略结果存 Redis 顶一顶也可以。 Query Rewriter也有公司叫 Query Parser，负责搜索 Query 的分词、改写、类目预测、相关性预测等等，可说的不多。 困难点 支持配置化 统一调度平台相比于系统，数据链路更难维护，集中在两点： 1. 局部数据污染，没有明显的征兆。 2. 数据出了问题，回滚困难。 有一个统一的调度系统，控制住从特征构建、模型训练、校验、版本控制、推送到线上系统、校验，就显得十分重要。 困难点 调度本身是一件很难的事情，这个部分的预期更多的是管理流程和预警，不应该去涉及资源利用等问题。 灵活性，能支持各式各样的子系统。建议 前期可以人肉一点，设定模板脚本，基于 crontab 工作，用钩子将各个脚本串起来，不过要做好报警。 总 结当然还有一些其他系统没有提到，在蘑菇街四年多，见证了上述系统从无到有的过程，参与了大多数系统初版的设计和开发（专栏的其他文章介绍过其中一些系统），走了不少弯路。比较可惜的是，上述的大多数系统，一开始都是算法同学根据需求自己做了原型，拿到了实际收益后，工程同学才慢慢接手。 现在回想，存在其合理性。当时网上可参考的不多，大家对这些没有共识，互相扯需求的合理性的时间还不如挽起袖子加油干。但其中造成的浪费也是显而易见，算法同学更多是实现了系统，但工程素养不高，后期往往要重写，浪费人力。 希望本文能给后来者一点帮助。 今日荐文点击下方图片即可阅读 AI 立功了！天猫双十一2135亿收官，再创新高 限时福利毫无疑问，MySQL 是当下最流行的开源数据库。凭借强大的性能和易于使用性，它已被 Google、Facebook、YouTube、百度、网易和新浪等大型互联网公司所应用。更有统计，世界上一流的互联网公司中，排名前 20 的有 80% 都是 MySQL 的忠实用户。 前阿里资深技术专家丁奇，在《MySQL 实战 45 讲》中，帮你梳理出学习 MySQL 的主线知识，比如事务、索引、锁等，并就开发过程中经常遇到的具体问题和你分析讨论，并且帮你理解问题背后的本质。 现在订阅，更有以下福利： 福利一：限时优惠￥68，原价￥99，11 月 24 日恢复原价 福利二：每邀请一位好友购买，你可获得 24 元现金返现，多邀多得，上不封顶，随时提现。（提现流程：极客时间 App - 我的 - 分享有赏） 长按识别上图二维码，试读或订阅专栏。 如果你喜欢这篇文章，或希望看到更多类似优质报道，记得给我留言和点赞哦！ 阅读原文