g suite基本版使用价值不大

周末花了2天时间认真测试了Google的g suite,包括在google domains买了一个域名,开通了g suite的basic账号,使用了它的企业邮局和网盘,上传了几个G的数据。

g suite的定价分为三档,如下所示:

说实话这玩意对企业才有用,企业可以使用自己的域名,在g suite里进行办公协作、沟通、隐私控制。对普通用户而言,哪怕买了个域名挂上去,也用途不大。

普通用户使用g suite,唯一享受到的好处,大概就是它的无限网盘了(google drive)。但是,只有10美元/月那档订阅,才有无限空间的网盘,如下图:

虽然写着小于5用户,每用户空间1T,但据网友反馈,实际小于5用户,也可以获得无限的空间。

我订阅的是Basic账户,网盘空间才30G,意义不大。有很多更优的竞品存在,比如:

  • iCloud每月6元人民币,有50G存储,性价比相当高。
  • 免费的gmail账户有15G存储(网盘共用),升级到100G,也只要每月2美元。
  • 百度网盘的超级会员,5T存储,速度超快,25元人民币/月。

当然,g suite网盘有自己独特的技术优势,比如上传速度快(我这里直连海外)、搜索能力强(google靠这个起家)、上传文件大(单个文件上限5T)、可以上传文件夹、可以生成下载外链(见此说明)。

但是,这一切优势,只有在你订阅10美元/月的商业版时才有用。5美元的基本版,对个人来说,意义真不大。你想要google网盘,搞多2个免费gmail就好了。

所以,在试用2天后,我果断删除了g suite账号。

产品迭代与用户习惯

懒人博客用的wordpress,一款开源的编辑和发布软件。

最近wordpress升级到5.0,后台操作的体验大改,说实话挺不习惯,方便性大不如前。

具体哪些不方便我就不细列了,估计还要适用一段时间吧。

编辑软件的易用性,大大影响了写作的冲动。在不熟悉的软件上写作,会严重影响心情。比如我最近就不怎么想写博客了。

我写代码的编辑器只用vi,因为太熟悉了。我用vi有20年,已成为它的死忠。但是对不熟悉的用户来说,vi是噩梦一般存在。所以,用户的习惯真的很重要。

我觉得吧,技术升级是好事,但是要尽量兼顾用户习惯。一款软件也好,硬件也好,发布一个新版本,使用习惯大改,这叫老用户情何以堪。

我印象中,微软最喜欢干这样的事。微软有个改名部,它的职能就是把自己产品的名字改来改去,让用户无所适从。

比如,它的邮件最早叫Hotmail,后来叫Live Mail,现在叫Outlook。它的即时通信起初叫MSN,后来改成Live messenger,现在没了。它的网盘以前叫Sky drive,现在改成One drive。它的搜索早期叫MSN搜索,后来叫Live搜索,现在改成必应。它的手机操作系统,更是改名眼花缭乱,最早叫Windows CE,后来改成Windows Mobile,接着改成Windows Phone,现在又改回叫Windows 10 Mobile了。

这样疯狂的改名,除了体现产品的升级,以及内部权利的迭代外,留给用户的,只有无穷的伤害。你看微软上述哪些东西做成了?MSN没了,必应也跟死了差不多,手机OS基本是打酱油。Outlook和Onedrive还有些人使用,只因为google在大陆被墙了,否则这俩货也够悬。

用户习惯往往很难改变,如果无法适应你的产品,就会切换到竞品。在产品迭代升级的同时,请尽量兼容老用户的使用习惯。

还想起一个例子,有一款邮件客户端叫Postbox,我在Mac上用过它很长的时间,是付费用户,每年付一笔费用。后来它升级改版,新版使用习惯大不相同,我很难适用,就彻底放弃了,还不如用免费的Thunderbird。

你看google就很少把名字改来改去,gmail这么多年来就叫gmail,youtube这么多年就叫youtube(换微软估计会改成微软视频)。Android、Chrome、Search、Earth、Maps、ADS,这些广泛使用的产品,我印象中都没改过名吧。改名的也有,将google apps改成g suite,不过google是打算放弃免费的g apps了,所以才推出面向企业的g suite品牌。

当然google也会经常关停一些产品,比如reader、wave。对做的不好的产品,关停也比换个名字,继续糊弄用户好。

gmail也会迭代升级,包括UI、操作等。但是这种升级不是颠覆式的,用户能很快适应,并能体验到新版的好处。这样的设计理念,是其他互联网产品应该学习的。

很希望有一款产品,我能用上一万年。

闲扯个性推荐

如今做内容分发的App,比如知乎、微博等,用到的重要技术是个性推荐。

所谓个性推荐,是指针对不同的阅读个体,推荐不同的内容,也就是千人千面。这种推荐方式,有别于传统的媒体分发,比如你打开新浪网,整个版面的内容都是固定的,千年不变,谁看都是一个面孔。

个性推荐背后的技术是机器学习,也可以叫做人工智能,因为机器学习本来是AI的一个分支。不过个性推荐一向有自己的领域定位,比如ACM RecSys每年都召开个性推荐学术会议,在业内影响巨大。

早期个性推荐都用的传统机器学习算法,比如逻辑回归、因子分解、随机森林。近两年,以google为代表的更高级的推荐系统,都走向了深度学习,从而越来越与AI总体发展方向趋同。

国内在个性推荐领域做的十分出色的公司包括头条系下的产品(今日头条、抖音),以及知乎、快手等,他们日积月累,搞出了一套先进的推荐系统,吸引了大量用户。可以说个性推荐是这些产品取得成功的至关重要的因素,充分体现了技术影响力。

个性推荐号称千人千面,看起来很美好,但在起步做时,往往十分困难。这个困难倒不在技术层面,而在于业务层面。

首先,要确认推荐目标,不管什么机器学习方法,总要朝着一个目标去优化。这个目标往往在内部并不能达成一致,比如产品希望做留存,运营希望做营收,这就是两个不同的目标。没有一个模型能优化好两个目标,所以技术实现之前,内部各利益方,先要达成一致的推荐目标。

如果实在不能达成一致意见,折中的做法是线上同时跑多套模型,然后对比数据,看哪个模型更好,就用哪个模型。当然在实际中,这个好与坏,要考虑长期影响,太短视的行为,对产品和用户的生态不利。比如,短期内提高了付费率,但是伤害了用户,这是一种杀鸡取卵的行为,也是个性推荐不提倡的。

其次,分发的内容众口难调。就算确认了共同目标,在这个目标下,分发的内容形式,也不一定是各方都认可的。比如,某些同学希望更多的推新领域内容,保持新颖性;另外一些同学希望更多的推熟悉内容,保持用户粘性。在新颖性与熟悉度之间,也要维持一个可以调整的平衡线。

再次,现实中不管运营也好,产品也好,不会完全遵循个性推荐的分发形式,他们总会从不同的角度进行策略干预。比如运营做活动,要重点推活动内容;产品开发了新模块,要重点推荐该模块的内容。所以,淘宝的推荐系统,在排序(ranking)之后加了一层再排序(reranking),允许运营手工干预排序策略。

业务矛盾解决了,技术实现一般还好。技术上的难题一般在于数据管理,包括三方面:

  • 训练数据:用于构建特征工程。用户和内容的各种数据要上报到后台,比如用户画像、内容属性、用户和内容交互的行为数据(观看、评论、付费等)。这些数据是构建机器学习训练样本的基本元素。特征工程里一项重要的工作是从已有数据里挖掘出有效特征,然后进行特征转换,输入给机器学习模型进行训练。
  • 预测数据:模型训练好后,部署到线上进行预测。离线的数据(比如用户与内容属性),实时的数据(比如行为数据),通过离线与实时计算通道,输入给预测服务,这些数据用来推理用户和内容的关系。
  • 数据回流:线上模型影响的任何数据,不管是正反馈(推荐正确的)、负反馈(推荐错误的),还是各种行为数据(观看、付费、订阅),都要上报到统一的后台,数据流形成闭环。

有了正确的数据,就可以组织数据、选择模型,朝着确定的优化目标进行训练了,这个过程不难,一般搞算法的同学都懂。

训练完后,会对模型进行评估。技术指标容易评估,比如AUC等,一眼可知。难在业务指标的评估,比如前面所说的新颖性、熟悉度,业务会衡量这些指标,从而人为影响了模型的可行性。

模型发布到线上,一般采用A/B测试和灰度发布。A/B测试尤其重要,它对比新模型与旧模型,或者新模型与自然流量的分发效果。当然,分发效果如何量化,又需要大家共同确认量化的指标,比如时长、留存、付费等综合指标。

模型部署运行后,一定要对流量进行监控,及时发现异常流量。一方面模型可能有bug,另一方面模型可能被恶意利用,朝着产品不利的方向发展。在这个情况下,要及时切断模型服务,回滚到上一个版本,或恢复到自然流量。

最后,说一说个性推荐涉及的机器学习技术。目前业界大部分公司,用的深度学习来做个性推荐,结合内容embedding技术。深度学习只要数据够大,拟合能力就更强,泛化能力也很好,模型效果相对于传统机器学习技术,有显著的提升。这里有一份知乎的个性推荐介绍文档,值得一览。

我之前带队做一款流量很大的App的个性推荐,一开始用的深度学习。在推荐系统临上线之前,产品要求模型具备可解释性,我们团队集体晕倒。深度学习是个黑盒子,本身不具备可解释性。无奈之下,一夜回退到逻辑回归,可解释性是增强了,效果自然也弱鸡了许多。

业务研发与基础研发

我有个读者,在互联网公司做基础技术的,自认为不爽,想申请调配到业务开发部门,征询我的意见。

懒人长久以来,在不同的基础研发部门工作。这个部门定位有点尴尬,搞技术的自然懂,但业务方不太理解。

比如说,我以前带中间件团队,业务方理解为,“哦,运维”。

后来带云计算团队,业务方理解为,“哦,运维”。

再后来我搞人工智能,业务方还是理解为,“哦,运维”。

对业务方来说,凡是没有直接从事业务开发的,都是运维。

这里所说的业务方,包括产品、运营、策划、市场等,他们直接面向用户,通常也对公司营收负责。

在不同风格的公司里,占主导地位的业务方也不一样。比如腾讯重产品,产品就代表业务方;阿里重运营,运营就是业务方;游戏研发公司重策划,策划就代表业务需求。

直接为业务方服务的,是业务研发团队,他们负责线上产品开发、运营活动支撑、策划方案落地等。

支撑业务研发团队的,是基础研发团队,他们构建底层的基础设施,保证业务开发的效率、质量与安全。

在一般的IT公司里,同为技术,业务研发部门与基础研发部门,两者地位截然不同,通常前者显著高于后者。

因为,业务方看到的是业务研发团队的努力和成就。比如今天要上线一个什么产品,那是业务研发团队开发出来的;要搞一项什么运营活动,也是业务研发团队在那里支撑。

而基础研发团队,做的都是背后的工作。比如分布式中间件、分布式存储、高可用数据库、弹性计算、负载均衡、监控,这些都是保障性工作,它们在技术体系里重要,但是不直接体现价值。

不能直接产生价值,在业务方眼里就是没有价值。这是大多数做基础技术的同学的悲哀。

基础研发团队,通常要比业务研发团队付出更多的学习精力,技术栈也要广而深得多。从操作系统内核、网络协议栈、计算与存储硬件,到分布式算法、高可用架构、高性能服务、云计算,甚至是人工智能,无所不涉猎。

然而,这改变不了什么,在业务导向的公司里(绝大多数公司是),基础技术地位不如人。

当然,业务技术也有自己的难处。他们要反复改需求,不断跟产品和运营扯皮,赶项目时加班加点,项目做得不成功,项目组随时被撤换,面临的压力比较大。

而基础技术要稳定一些。大多数做基础研发的同学,性格沉稳,不善于沟通。他们潜心于研究技术,对业务不关注,也不愿意扯皮。对他们来说,技术的成功就是个人最大的收益,外部奖励什么的反而不怎么care。

所以,业务研发与基础研发,前者在公司的地位高,但压力也大;后者容易被忽视,但技术成就高,相对稳定。如何选择,取决于个人性格,与形势需要吧。

谈谈AI平台化

最近看了不少AI平台化的案例,包括百度的EasyDL,第四范式的AutoML,Ucloud的UAI,还有两家创业公司oneclick偶数科技

人工智能经过近几年突飞猛进的发展,从上层的算法,到底层的硬件,都取得了极大的突破。单纯拼算力、算法的时代已经过去。只要花点钱,就能在阿里云、腾讯云、google云上购买到想要的计算能力。而在图像识别的三大领域:分类、检测、分割,算法也基本成熟,很多模型可以开箱即用。

AI今后的发展,就是一个工具集,不管分类也好、回归也好,就是工具集里的一个工具。用户随手拿起一个工具,稍加锻造(小数据集训练),就能真正为我所用、得心应手。

在此发展过程中,很多公司看到了机会,推动AI平台化进展。所谓AI平台化,就是AI与环境的一个整合过程,面向用户提供高度集成的AI生产和运行环境,隐藏了算法、算力、存储、网络细节,使得AI更容易使用。

AI平台化实现起来,很有挑战,涉及的面非常广。借用其他公司的一张图来说明:

底层的那一套资源管理机制,负载均衡、弹性扩容、容灾、资源分配等,实际是个私有云环境。底层要负责好三块的资源供给:算力、存储、网络。

在算力调度上,目前业内做法都是容器化,通过docker生成任务实例,以支持机器学习框架(tensorflow等)的分布式训练。

在存储机制上,HDFS、Ceph都是比较成熟的解决方案,可以使用HDFS的专用客户端来完成存储读写,也可以使用Ceph的分布式块存储来进行集成。

在网络上,大容量、高吞吐量的网络(25gbps)是必选,因为在图像类训练任务里,网络吞吐量很大。如果要保证隐私和资源隔离,还要实现SDN(虚拟私有网络)。

在我们自己的解决方案里,使用K8S管理静态资源,比如HDFS、Hadoop、Zookeeper、web service,使用Yarn来管理docker容器,比如生成新的任务实例。算力分配通过docker进行,包括GPU、CPU分配。共享存储使用HDFS,网络带宽是25gbps。由于任务实例是docker,因此里面可以集成任何机器学习框架,包括tensorflow、caffe等。

这个图里描述的只是训练部分。实际上,一个完整的机器学习任务,包括数据处理 -> 模型训练 -> 模型部署的过程。

数据处理工作十分复杂,例如结构化数据的特征工程(数据清洗、分析、特征转换),图片数据的标注等。它们都需要相应的系统支持,比如结构化数据存储和计算,一般用到Hadoop、Spark这类系统,规模十分庞大。而非结构化数据(图片、视频)的存储和计算,也需要用到很大的集群。

模型部署到线上进行预测,或者发布到移动端SDK,也涉及到复杂的工程工作。

部署到线上后,要考虑后续的监控、扩容、容灾问题,而且机器学习任务的计算量很大,通常调度的机器也就更多。我们做的一项AI业务,在线上部署了100多台物理服务器在跑,对这么多硬件进行管理和调度,本身就不简单。现在很多AI业务部署是基于容器,一方面轻量化了部署过程,另一方面也不可避免的面对容器自身管理的复杂性。

移动端SDK面临的压力主要是性能优化。iOS还好,可以通过Apple自己的开发框架来调度手机的GPU,但Android阵营就复杂了,各种机型和GPU千差万别,如何适配不同手机的GPU是个大难题。另外,模型自身还要做压缩、裁剪、量化,以提升移动端计算性能。在AI平台里,一个好的移动端推理框架集成进来,会给平台大大加分。

上述描述的是AI平台的资源环境管理工作,AI平台对计算、存储、网络等硬件环境进行整合和集成,更好的适应AI开发和运行任务。而好的AI平台,还要对算法进行包装和抽象,以最大的便利性,支撑用户的模型开发任务。

这方面做得最好的是Google的AutoML,只要上传训练数据、指定任务目标,AutoML就帮你自动设计神经网络结构、自动训练和评估模型效果,用户不用关注底层的算法和工程实现,平台帮你把一切都做好了。百度的easyDL基于迁移学习,也是类似效果。

总结起来,一个好的AI平台,解决的不止是底层的工程实现问题,还解决了上层的算法封装问题,用户甚至可以零学习成本使用AI平台进行业务开发。我相信这样的平台会越来越多,AI开发的门槛也会越来越低,这对AI的普及来说,是个好事。

当然,这不意味着算法人员就没有用途了。专业的算法人员,可以投入到更高级的研究方向上,比如神经架构搜索、强化学习、神经芯片等,这些基础技术,会让AI更容易普及,更好的造福社会。将来AI在社会生活的各个领域,推动生产进步,改进生活质量,就充分体现了科研人员的价值。