经验分享 – 知乎CTO李大海:谢邀,来分享下内容社区的AI架构搭建与应用

机器之心报道

作者:陈萍

谢邀!知乎 CTO 来分享下内容社区的 AI 架构搭建与应用。

「在信息爆炸的互联网海洋中,有价值的信息仍然是稀缺的」。知乎的诞生源于这样一个非常简单的初心。

而在挖掘真正有价值的信息过程中,知乎很好地利用了 AI 技术。

在今年上海召开的 2020 世界人工智能大会云端峰会开发者日「企业及 AI 架构专场」分论坛上,知乎合伙人、首席技术官李大海老师为分享了知乎作为一个内容社区,在 AI 架构上的搭建和应用。

李大海老师拥有多年的搜索算法经验,曾担任 Google 中国软件工程师,云云网工程总监,并曾担任豌豆荚搜索技术负责人,让豌豆荚成为最早涉足应用内搜索和 Deep Link 的公司。

2015 年李大海以合伙人身份加入知乎,先后负责知乎广告技术团队、数据、算法业务。在出任 CTO 之后,李大海统筹负责包括大数据团队、内容流通、AI 新业务拓展等在内的知乎整体技术业务。

以下为演讲主要内容,机器之心进行了不改变原意的整理:

大家好,我是李大海。很荣幸代表知乎来世界人工智能大会开发者日做分享。特殊时期,以这种特殊的方式跟大家作交流,心情是很复杂的。2020 年上半年是非常不容易的半年,不过我们也很高兴地看到,很多企业通过技术创新应对疫情,帮助大家维持正常的工作和生活。知乎也是其中的一员。

从 2016 年引入机器学习以来,AI 技术已经在知乎社区很多环节扎下根。以前我们讲算法讲得比较多,今天我想重点说一下我们在 AI 架构的搭建和应用上的经验。

在知乎,我们的 AI 架构的不同是由不同的 AI 场景和实践催生的。当然,介绍这些应用场景之前,我们应该先简单了解一下知乎。知乎是一个内容社区,包括问答、热榜、知识服务、圈子、直播等等各种产品功能和业务板块,沉淀了数亿的问题、回答、专栏、电子书等等内容,这些内容每天都在被生产、分享、消费。对于一个平台来说,是一个浩大的工程。为了让内容在社区运转得更高效,知乎引入了 AI 技术。

到目前为止,知乎的 AI 应用已经触及到业务的方方面面,并且在实践的过程中,逐步形成几个不同的算法框架。

基础 AI 架构

首先是基础 AI 架构。2017 年,知乎成立专门的 AI 团队,为各个业务提供一个基础算法能力输出。这个团队基于知乎海量的内容及用户行为数据,通过数据挖掘、机器学习、自然语言处理等技术,精准、全面地理解内容及用户,并将基础算法能力以标准统一的形式输出,为公司各业务赋能。

AI 团队自成立以来,为各种不同的业务提供了非常多的应用。随着时间的推移,也产生了一些痛点。比如说,由于没有统一的系统开发框架,各个业务模块和子项目都是单点作战,只有一个同事清楚业务细节,并且新建一个项目要写很多和业务无关脚手架类型的代码。再比如,有的线上代码没经过代码审核、存在非主干分支发布、个人仓库开发等问题,非常不利于协同和维护。另外,服务和模块的复用性比较低,有些常用的逻辑,比如识别打压大话题,被多人、多项目分别实现。另外,像监控不完善,部分问题发现不及时等等,都是小应用太多带来的问题。

因此,急需统一的系统架构来整合所有资源,搭建稳定的基础架构,加速 AI 技术积累并助力业务创新。

我们首先考虑设计统一的基础服务架构,统一定义基础 AI 算法的工作流和数据流。有了这个统一框架之后,很方便在框架上添加监控、报警等等功能,及时发现可能出现的问题,提高服务质量、稳定性和可用率。

在设计良好的架构和统一代码管理的模式下,方便我们去构建这个场景下的通用代码库,提高基础功能的代码复用率,并解决项目和代码的散乱问题。

在统一的基础服务架构上,团队成员的开发工作模式一致,并且沟通语言都是基于此,一定程度上会提升协作效率和沟通效率。

同时,开发人员更容易理解非自己主导项目的脉络主线,可以极大地降低工作内容调整和交接的复杂度。从另一个角度提升了协作、沟通效率。

在统一的基础服务架构下,团队不再需要关心一些通用的细节,只是按需调用 / 复用通用组件,将主要的精力用在解决问题的核心算法 / 模型上,这样一来,加速了团队的技术积累,快速地推进业务的创新。

这张图可以简单的展示知乎基础 AI 架构的体系。

我们的统一框架取名叫 zai,本质上是一个工作流水线。其中的每个部件都是可定制的。workflow 分为三大类:

  • base workflow,通常只包含一种推断服务或预测服务。
  • series workflow ,其可以串联多个不同的 base workflow,形成一个更复杂的服务链,比如关键词服务,需要前序依赖分词服务。
  • parallel workflow ,其可以并联多种 series workflow,形成相对比较复杂的网络,比如监听内容创建 kafka topic,并分别进行多种预测处理。

在这个框架中,我们选择 proto buffer 来进行数据 schema 的定义,满足速率快和存储小的需求。

zai-serving 是预测 / 推荐模块,加载 zai-model 模块训练出来的模型来进行推断服务。模型可以支持传统模型和 NN 模型。其中 NN 模型基于 tensorflow estimator 做了改造和封装,这样具备以下优点:

  • 数据管道和模型分离。
  • 保留足够的模型灵活度,具有模型自定义的自由和模型相关超参调整的自由。
  • 封装了训练、预测、评估、模型输出;只需要关心模型本身。

基础 AI 架构的主要应用场景,一般是各种离线的数据处理场景。在典型的线上推荐场景中,我们也正在形成统一推荐框架。

统一推荐 AI 架构

当越来越多的业务都需要用到推荐服务时,我们开始了统一推荐框架的工作:我们期望通过统一 Ranking 框架,将推荐系统全局排序阶段的技术统一,降低开发和维护成本,提高效率。

知乎的统一推荐框架包括以下模块:

  • 统一的完备的数据 schema,打通各业务线的数据,减少重复特征数据的落地成本,并成为统一推荐框架的标准输入。
  • 统一的特征落盘服务,各业务线可根据业务特点,灵活填充 schema 中的特征字段,减少在特征落盘和训练数据管理部分的开发工作。特定业务还可以低成本的实现跨部门数据复用,打通不同部门之间的数据协同作用。
  • 统一的训练数据流水线。
  • 统一的特征工程框架。
  • 统一的训练代码库。有利于模型结构复用,兼容离线训练和 online learning 训练。
  • 统一的线上预测服务。支持 tensorflow 和 xgboost 的模型;支持模型的自动加载和更新;提供通用的特征、预测分数监控。支持 CPU 或 GPU 部署。优化公共特征计算。

我重点讲一下其中的几个模块。

第一个是特征引擎。

特征数据处理,是要把结构化的特征数据(如用户画像,内容画像等)转换成向量化的训练数据。我们的特征引擎具备以下功能:

  • 特征工程配置化:管理使用哪些特征;增删特征无需改代码。避免了离线数据处理和线上预测服务代码不一致的情况。
  • 特征工程模块化:我们把对特征数据的操作抽象成一个个操作子 (operator)。比如:Echo, OneHot 等。规范了 operator 的输入输出;每个 operator 可以处理不同的特征数据;大部分 operator 和具体的业务无关,代码可复用性大大增强。每个 operator 必须有严格的单元测试,保证了特征工程代码质量。
  • 结构化数据字段获取动态加速,有效的提升效率。
  • 自定义向量化特征数据格式:避免了 parse protobuf 的序列化、反序列化 cpu 开销,比 tensorflow 的 tf record 快很多,典型场景有 10 倍的性能差异。

第二个是特征落盘服务。

为了对特征覆盖率等指标进行监控,并让落地的数据在多个业务之间低成本复用,特征在落地之前需要经过统一落盘处理。落盘服务提供的主要功能有:

  • 流式特征覆盖率统计监控,特征分布统计。
  • 样本数据分流。大的样本数据尽量落成一份,小的特殊业务可以进行灵活的分流。
  • 跨业务的进行特征补全。

未来,知乎的统一推荐框架将在三个方面进行完善和升级:

  • 一站式配置管理、数据流管理、特征监控、指标监控。
  • 通用化 online learning,让更多业务可以直接用在线学习的优势。
  • AutoML,降低业务使用机器学习模型的门槛。

社区治理、反作弊及多媒体 AI 架构

除了统一推荐,知乎还有一个很特殊的场景,就是社区治理。除了垃圾信息、有害信息的处理,一些对社区内容建设和人们的需求没帮助的信息,也在知乎的治理范围内,比如答非所问、阴阳怪气等等。这个场景沉淀出来的基础框架,和前面提到的 zai 框架是比较相似的,但是整个框架针对图片、视频等多媒体内容,做了很多特化的优化处理,比如通用的缓存转码之类的。具体细节在这里就不赘述了。

机器学习架构—Jeeves 机器学习平台

除了直接面向业务应用场景的三个框架之外,我们还构建了机器学习平台 Jeeves,用于帮助算法工程师快速构建、训练和部署机器学习任务。Jeeves 将算法工程师从繁重的部署和配置工作中解放出来,专注于高质量模型的开发。

随着机器学习对 GPU 资源的需求快速增加,仅通过算法工程师自行管理、调度,不仅增加了业务部门管理成本,也造成了 GPU 等计算资源一定程度的浪费。具体包括以下几点:

  • 训练前部署难。算法工程师需投入大量精力进行运行环境的配置和资源调配,不便于工程师专注于模型优化和调参。
  • 资源配置优化难。算法工程师难以判断机器学习任务的性能瓶颈在哪种资源上(如 CPU、GPU、内存等),不便于全局优化资源调配。
  • 单机训练瓶颈。纵向扩展成本高、提升小。机器学习需要快速迭代试错,性能瓶颈制约了其最终产出的质量和速度。

Jeeves 将 Tensorflow 容器化,通过容器进行训练资源的调度和管理,并为算法工程师提供方便的资源申请和释放流程。具体来说,Jeeves 提供:

  • 一键部署能力。算法工程师只需要申请资源、载入训练数据和代码,即可一键部署环境并开展工作。
  • 资源消耗监控。监控资源在每个任务的消耗情况,便于识别瓶颈所在,针对性的进行性能优化和资源调配。
  • 算力水平扩展。支持分布式机器学习,支持算力的快速扩展。

下图是 Jeeves 及其学习平台架构。Jeeves 通过容器管理 GPU 集群的资源,底层使用 Docker 来隔离 GPU 资源,并通过 Kubernetes 对 Docker 容器进行调度。并提供训练数据挂载,日志和模型的持久化的功能。同时 Jeeves 还会监测空闲资源并保证其及时回收,提高资源利用效率。

功能层面,Jeeves 主要提供两类功能:一种是「笔记本」,用于在线交互式试验训练代码;另一种是「项目」,用于创建单机或分布式训练。

笔记本为算法工程师提供交互式体验和数据科学可视化的工具,用户可以通过浏览器快速迭代优化训练代码。对于不习惯使用浏览器或者不方便使用浏览器的用户,Jeeves 还提供了 ssh notebook 的功能。

项目分为单机训练和分布式训练两类。单机训练使用一台独立服务器执行训练任务;而分布式训练根据用户申请的资源用量,将任务合理拆分后,交由对应集群执行。项目启动后,Jeeves 会提供 TensorBoard,辅助用户掌握训练过程。

总结

以上是知乎最近在 AI 应用实践中逐步沉淀出来的一些基础框架和提效平台。AI 应用本质上是能够对海量数据进行高效应用的前沿计算机算法系统,因此,过去常规计算机系统在数据规模和业务请求量增大到一定程度后,会遇到的各种问题,AI 应用也同样会遇到。如果解决这些问题,就需要有良好的架构设计,否则再好的数据和模型,也都会受制于系统的计算能力和吞吐能力,不能发挥数据和模型完整的表达能力。所以,在工业界真实的生产环境中,AI 应用必须同时兼顾数据、算法和架构三者的投入。作个不太适当的比喻,这三者的关系就好像食材、菜谱和厨具,要想把 AI 应用的用户体验这道菜做的色香味俱全,三样东西每样都要做好、做足、做精。

通过这些框架的落地和应用,我们也希望知乎这个内容社区,能够在更多的产品细节上,轻松使用各种 AI 技术,成为一个人与技术、人与机器、人文与技术有效融合「智能社区」。

最后,打个广告,欢迎更多对 AI 技术有兴趣和热情的同学加入我们,加入知乎,一起做些更有趣、更有挑战性的工作。我的分享就到这里,谢谢大家。

本文为机器之心报道,转载请联系本公众号获得授权。

正文完