写点什么

机器学习的最小可用产品:人工智能应用的敏捷开发

  • 2017-07-27
  • 本文字数:8058 字

    阅读完需:约 26 分钟

编者按:“范式大学”由第四范式发起,致力于成为培养工程师转型为数据科学家的“黄埔军校”。专栏专注于以人工智能解决具体商业问题。在这里你将会看到,企业如何通过可实施的方法完成 AI 转型;个人如何通过最新的科技工具,快速成为能解决问题的机器学习工程师。

本文是大数据杂谈 7 月 6 日社群公开课分享整理,也是第四范式主题月的第一堂公开课内容。

大家好,我是第四范式的联合创始人田枫,很高兴在这里和大家分享机器学习的 MVP 模型!

我们曾经在公众号上发过一篇文章《年薪百万的机器学习专家,为什么不产生价值?》,文中的机器学习专家花了大量的时间搭建平台,做数据的清洗、处理与机器学习建模,却没有带来公司所期望的价值。问题出在哪里了呢?

基于第四范式在机器学习工业应用方面的大量成功案例和经验,我们今天就来分析一下,想用机器学习提升业务价值,在搭建平台、处理数据、训练算法之前,真正要做的第一步应该是什么?

我们今天不谈技术,不谈算法,不谈平台,但是今天聊的东西却是机器学习产生价值过程中,最关键的步骤之一。

这次分享我们会从几个方面分析这个问题:

  1. 机器学习是不是万能良药?我们首先需要想清楚, 机器学习作为特别牛的技术, 它能解决什么样的问题。
  2. 一个业务问题,可能有各种千奇百怪的坑,假设我们初步判定可以通过机器学习来解决他,那么应该通过怎样的转化,避开这些坑,把业务问题变成机器学习的问题。
  3. 如果有一个好的可以转化成机器学习的问题,我怎么去设计机器学习的开发节奏,估算它的投入产出比,如何分阶段去推动问题的建模和应用。

这就是我今天要介绍的,机器学习的 MVP。

机器学习的最小可用产品

现在的互联网技术,接受的一个概念是最小可用产品,MVP,就是开发团队、设计团队用最小的成本代价,最大程度去验证产品的可行性。这个产品的可行性,是指这个需求是否真实存在,一个产品满足需求的方式是不是对的。

机器学习也是一样的,我们做机器学习的投入是长期的、持续的,带来的收入和回报也是巨大的,在开始之前,我们一定会希望以比较低的成本知道:现在引入机器学习是否可以影响我们所面对的业务,产生价值的潜力有多大。

那么把一个业务真正用机器学习做之前,我么可以用两步,做一个机器学习的 MVP:

第一步:我们要选择正确的业务问题,并不是所有的问题都可以套在机器学习的框架里,有些适合机器学习解决,有些不适合机器学习解决。在任何的技术项目管理中,用差的方法解决好的问题,一定优于用好的方法解决错误的问题。

第二步:当我们找到一个机器学习可以解决的问题后,我如何通过最小的时间和人力代价,去证明机器学习可以解决它,带来满意的投入产出比。

选择正确的问题:从分类器开始

首先我们看看机器学习擅长解决什么问题。我举一个例子,就是周志华老师的西瓜书讲的例子,它很经典,也很简单,还很深刻,这个问题是说我要判断一个西瓜是好的还是不好的。

这个问题的业务场景是什么呢,一个西瓜,我怎么在不交易、不打开的情况下,就知道它是好的还是不好的。如果我知道,我就可以用同样的价钱买到更好的西瓜;而如果我是瓜商,有了一套标准之后,我就可以更好的管理我的货品。

回到这个问题,一个西瓜是好的还是不好的,这是典型的机器学习二分类问题。首先我们要找到,判断这个西瓜好不好有哪些可以用到的数据。我们不能把买卖西瓜之后的数据放进去分析,比如买了西瓜之后,我打开就知道好不好了,那么这个就没有价值。

所以我必须在不破坏西瓜的前提下,这时候能用到的数据是西瓜的产地、西瓜的纹路、重量、比重、敲击西瓜的声音是浑浊还是清脆、西瓜皮的质感等等,这些不打开西瓜的情况就知道的数据。

刚刚我们的目标已经讲得很清楚了,好的还是不好的,好的是 1,不好的是 0,甚至我还可以定义一个评分,0 到 1 之间的一个数,但总体而言我可以设定一个机器学习的目标,我们称之为 Label。

选择正确的问题:真实世界模型

这看起来是一个很简单的场景,好像一旦我们具备了这样的数据,就可以尝试建立机器学习模型了。然而在现实中,当我们想用机器学习来解决实际问题时,也会这么简单么?真实世界中往往是有很多陷阱的。这些陷阱可能有什么呢?

第一,西瓜好不好,是怎么定义的?是大?还是甜?皮厚不厚?瓤脆不脆?如果建立这个模型是为了西瓜的售卖,这些因素可能都会评价的因素之一,模型学习的样本也都需要基于这个标准来建立。如果我们仅仅是基于西瓜大不大来定义样本,而实际的应用场景是综合判断西瓜好不好,那么可能会得不到想要的好的结果。

第二,西瓜好不好,是以什么为标准的?是用科学方法和仪器测量的?还是专家评测?如果是后者,评测者是同一个人么?如果是不同的人,大家对好西瓜的判断标准一样么? 现实情况中,很可能是不一样的,那就要想办法消除 Label 的偏差。

第三,互联网的场景下,往往是需要满足所有人个性化的需求的 ,有些人喜欢甜的西瓜,有些人喜欢脆的西瓜,那将问题定义为分辨好的西瓜是否还合适?因为每个人对好西瓜的定义不一样,这个问题可能就转化为了推荐一个西瓜给一个用户,他(她)会不会喜欢。

第四,真实的应用环境是怎样的?假设我们需要一个在线实时的西瓜分类器,拿到西瓜那一刻马上判断它好不好,那是不是有些当时不能马上拿到的特征就不能用了?如果好瓜的判断标准在不断发生变化,或者瓜本身的特性在不断变化,模型还需要能够跟得上这个变化,基于新的数据和反馈做自我更新迭代,这就是我们搭建模型更新的方法。

可见,即便是简单的问题,我们都需要思考一下业务的方方面面,理清哪些因素,边际,个性化要素和基础设施是要考虑进去的。

选择正确的问题:业务问题的本来面貌

我们从西瓜还原到业务,任何一个业务能不能做机器学习,我们要看三个要素。

第一,这个业务的目标值是什么,它不一定是唯一的,但一定有主次。这个目标是否可以量化、收集反馈、客观观测的。什么叫客观观测,我说甜和你说甜,这个事情就可能不客观,那有没有一个客观的东西可以反馈。

第二,样本应该如何构造, 样本不应该违反因果关系,y=f(x),x 一定是我们业务 场景中所能知道的信息。在西瓜的问题, 就是打开西瓜之前我们能知道的信息, 才可以作为 x。同时,样本应该符合业务场景的真实情况,假设我们的业务是摸黑挑西瓜, 我们看不见西瓜长什么样, 我们只能敲, 那西瓜的颜色就不能作为特征。

第三,样本的每一行代表什么意思,每一行应该代表西瓜的每次测量,然后才是选择哪些数据作为 x,这些我们已经讲得很清楚。

当西瓜的问题说完后,我们来看看真实的业务问题是怎样的。

1、点击率预估

比如说我们看到的推荐系统问题——点击率预估。

一个推荐系统的目标是什么?它的终极目标一定是用户体验,但这个目标很虚幻,我们要把它量化,变成一系列可以测量的数据,比如说点击、观看时长、购买、好评等,这些就是 y。

然后我们看有哪些 x,这些 x 代表的是我做出推荐排序的一瞬间,当客户请求时,在那个瞬间我知道的事情。我能知道客户的属性、特征,我能知道内容特征、上下文特征,但不知道最终这个内容是否有被展现和点击。我可以知道内容在这一瞬间之前被点击了多少次,但一定不是这个瞬间之后被点击了多少次,因为这样就穿越了。

有了 y 和 x,就可以构造样本了。我的样本比如说,我给用户展现了 10 条推荐的内容,这个的反馈可能是点击和观看,那么每一次的样本展现就是一个样本。

这里我们可以思考一个有趣的问题,当我们思考不同的特征对问题的影响时,比如说我们把展现作为一个样本,一个避免不了的问题是,我怎么知道这个内容是否被用户看到。

一种做法是我不去想这件事情,那么模型可能就是有偏的,比如说你认为这个样本没有被点击,但也有可能是没有被看到,但最理想的是把推荐到用户手机屏幕上的作为一条样本。

退一步,还有一个办法,就是把展现的位置补充回来,作为一个特征。然后请求的时候虽然没有这个特征,但是这个特征吸收了位置对于展现和反馈的偏差。

2、简历匹配

再举一个场景的例子 —— 简历匹配。简历匹配是什么意思?它其实想预测的是,我给企业推荐了一个简历,这个人有没有被企业聘用,这看起来是个简单的机器学习问题。但是回到业务场景思考,这个问题有没有这么简单?对于内容推荐来说,用户有没有点击这个内容,点击后看多久,都是用户单方面的选择。

但是简历有两个选择,第一个选择是企业通过面试、简历的选择,判断这个人是否适合企业。第二个选择是应聘者,他会不会去企业面试,而即便拿到了企业的 offer,会不会被打动加入企业。

所以这就变成了多点、双向的问题,在这样的情况下,就需要对问题进行拆解。我们可以不直接做个人被企业招聘的事情,而是分开来做,比如说企业会不会邀请这个人去面试,以及这个人会不会接受企业的面试邀请,这样就能把问题做的更好。

总结一下我们刚刚所介绍的 MVP 第一步:做机器学习,首先不是着急去建机器学习的模型,而是认真思考这件事情的业务场景到底是怎么样的。

解决正确的问题:小结

总结下来一个机器学习能解决的业务问题,有这么几个点:

第一它是否能转化成分类 / 回归的问题

第二目标是否是容易获取、客观无偏差的数据。

第三是问题的预测目标,因果关系是什么,因果关系越简单越好,如果是多因多果,或者说描述“因”的相关信息不方便获取,那是否可以拆分成多个模型。特征往往是因的数据,或者是一些不是直接原因的数据,只要它不破坏这个因果关系。

第四是我们刚刚没具体去描述的, 就是这个问题是不是一个真的业务需求。

一个真的业务需求是指,在我们用机器学习做出预测后,业务能否可以根据这个预测结果而受到影响?这个影响点是否足够清晰、有效?因为业务人员会用对业务影响的结果来评估我们项目的效果,如果我们预测的结果并没有有效影响业务,即使这个模型再好,也不会发挥作用。

比如说推荐系统,我预测了新的点击率后,可以按照点击率倒排来影响业务结果。但如果是游戏呢?如果我们预测这个人明天有 30% 的几率付费,我该如何影响到他,我能不能影响他?

所以你一定要思考,你的预测结果会怎么在业务中使用,这个使用会不会对业务产生提升。如果你发现提升本身是很难的,那这本身就是个伪需求。然后你还需要思考,现在没有用机器学习的业务,它是用了什么方法和数据,现在的方法和数据有什么缺陷,哪些是机器学习可以帮到的。

当以上的问题都有清晰的回答后,这时候你就可以提出一个好的问题了。这时候你就成功 80% 了,而剩下的问题都相对简单了。

机器学习的投入

这是我们 MVP 的第二步:在可控的人力、金钱投入下,构建一个有效的机器学习模型。

那什么是可控呢?1-3 人月的投入,更多就会风险太高。我们会期望获得什么提升?Case by case,不同的业务不一样,有些业务比如说广告,1% 的收入就是好几百万,而有些问题可能要提升好几倍才有商业价值。

在机器学习成本分配中,最大比例在机器学习本身,调参、特征工程、模型评估、模型上线这些工程的事情占了大量的时间,而问题的定义、数据的采集占的时间非常小,我们认为这是有问题的。我们认为一个机器学习的项目,无论通过合作还是使用第三方平台的方式,应该把大钱花在采集好的数据,定义好的问题上去,甚至这要超过一半的时间。而另一半的时间,才是真正做机器学习模型的时间。

降低数据的成本

那我们怎么降低数据的成本呢?我给大家一些思考。

第一,除非必要,只使用采集好的数据。因为数据采集是一个有成本的事情,当一个公司的体系越复杂,它采集数据的成本就越高,所以除非这个数据采集起来很轻松,或者已经有了,你才会去考虑。

第二,如果你要开发新的数据,首先要考虑的是成本。开发新的数据源是有风险的。机器学习最怕的是说不清楚这是算法的问题,还是数据问题,还是问题定义的问题,所以让 MVP 环节中能出问题的环节越少越好。

前面我们介绍了问题定义的问题如何避免,而算法一般是不太容易出问题的,除非用错,而数据其实是很容易出问题的,所以我们尽量用简单、可靠、成熟的数据。

第三,我们讲到在建模的过程中,尽量使用成熟的工具。真正在数据处理,特征计算,和算法训练的这些过程中,大量的工作是可标准化,甚至可以用算法自动优化的,大量的坑其实也是可总结,或者说可以在产品引导中避免的。我们一直在研发的第四范式先知建模平台,就是在努力将建模过程中的 know-how 封装到产品中,让用户操作更简单,而且少踩坑,更有效的获得好模型。

总结一下,这一步总的思想是,能不制造新的风险点,就不制造风险点,能降低不确定性就降低不确定性。

如何 Review 机器学习的模型?

好了,做好了前面介绍的两步,我们已经有了机器学习的 MVP,机器学习对业务的影响已经初见结论,如果业务有明显提升,那么祝贺你,找到了新的价值增长点,优化后一定还会有更大的提升潜力;而如果效果不明显,我们这里再给大家一些关于如何 review,如何检查 MVP 的建议:

首先要 Review 问题的方向是不是对的,模型的效果是否符合预期,模型的优化目标是否有明显的变化,比如优化的目标是西瓜好不好,优化之后是不是买到的西瓜好的变多了。如果不是,那就是这个问题没有解决。那还会有什么原因?是不是指定了错误的目标,用在了错误的环境,或者数据有问题。其实说白了,要么是目标有错,要么是模型用错,要么是数据有问题,基于这 3 点来检查。

在现实业务中,解决了一个问题,有时也会带来新的问题。比如说新闻推荐的系统,现在点击的人多了,那么是不是由于推荐,新闻变得更加娱乐化了,是不是新闻的点击变得更集中化了,这可能并不是业务上非常希望的,需要继续想办法来优化。

第二步是 Review 数据,这些数据里面哪些起了关键作用,哪些数据是经验上认为会有作用的,但实际上没有的。那么重新检查这些数据,看是不是数据质量的问题,使得没有发挥应该发挥的作用。还可以看下一步我们可以引入哪些新的数据,数据最好一批一批引入,我加入一批,一次性开发结束。

第三步,当我 Review 上面的事情后,我要制定下一步的方案,往往是我会有新的、更多的数据。我也可能会调整目标,有可能是目标错了要改,也可能是增加目标,原来一个目标不够了,我要加入好几个新的指标,使模型变得更平衡。还有就是在工程上,看性能能不能优化等。

这就是我们这次分享的内容,我们怎么去推动一个机器学习的项目,问题如何定义,风险如何管理等等。

答疑环节

Q1:请问第二目标是否是容易获取、客观无偏差的数据?

田枫:首先我觉得第一个问题,是数据就会有偏差,完美的数据是不存在的。你要知道偏差的数据是哪个?什么原因导致的偏差?比如说一般来讲 x 有偏差都是有办法可以处理的,可以通过正则化等方法来最大程度降低偏差的影响,y 有偏差就很严重,说明你的目标就有问题。

第二,存在偏差的可能性不代表数据就一定不可以用,可以用一些基本的统计方法,看数据的分布是否正常,是否有人为的痕迹,到底偏差的原因是什么,偏差的比例有多大,能否定位出来?比如说我们之前做过一个新闻推荐系统项目,每到半夜点击率暴涨,最后我们知道是半夜有竞争对手的爬虫来点击新闻。我们知道以后就可以对这部分数据进行处理。

第三,在大数据环境下,当数据量大到一定程度的时候,偏差可能会因为大量的样本以及超高的维度而不再重要。比如说做广告的人可能知道,点击率是会被位置所影响的,这个数据是有偏差的,那把位置本身也作为一个特征,并且利用一些特征工程的手法,可以把这个偏差吸收掉,得到一个无偏的模型。所以有偏差不要紧,想明白原因是什么,大多数情况总有方法解决他。

Q2: 针对数据不平衡问题,在应用中比较好的解决方法是什么呢?

田枫:对于机器学习问题,样本的数据分布跟现实的数据分布保持一致是最好的,如果极度不平衡,例如说正样本极少,影响了建模,那么也是有一些策略可以用的:1. 比如说过采样,就是把 label 中占比少的样本通过随机的方式多采样一些到训练样本中。2. 欠采样,就是把 label 中占比多的样本通过随机的方式采样一部分,这样可以平衡样本,同时还能加快训练速度,在一些较大的数据集上可以使用这种方法进行初步的探索。3. 通过欠采样多份训练样本,分别训练模型再做集成学习的方式,能够充分利用全部数据信息,同时避免了过于倾斜的样本对于模型训练的影响,是一种比较好的方法。

Q3: 先知支持深度学习和 GPU 运算吗?

田枫:针对金融等领域的结构化大数据,一个“宽”的模型(特征维度特别高)更有利于在比较低的门槛和代价下获取好的效果。因此先知目前主要的算法是高维机器学习算法,包括超高维 LR。和大规模 GBDT,以及衍生的低门槛免于复杂特征工程的算法 HE-Treenet 和 LFC 和大规模 GBDT,以及衍生的低门槛免于复杂特征工程的算法 HE-Treenet 和 LFC。对于深度学习这种“深”的模型,一方面,提供支持可自定义层数和节点数目的 DNN 网络的分布式训练算法。另外一方面,在先知产品路线上,还有“宽”和“深”结合的低门槛高维深度学习算法,也将逐步向公众开放。在对 GPU 的支持上,先知平台底层的 GDBT 机器学习框架对计算做了很好的抽象,因此可以通过对接 GPU 计算库的方式获得 GPU 的加速能力。

Q4: 老师在开始提到了核心也是最重要的首先要考虑的,到底有没有必要上机器学习平台?后续才是考虑技术细节的事情。我看到第四范式提供了先知平台还能免费使用,这个很棒!那么后续我们所在企业关于实际业务需求是否需要上机器学习平台,我们可以从哪得到专业的指导?第四范式提供这种咨询吗?

田枫:我们有个先知机器学习培训平台, 在这里会有我们最新的知识库沉淀,大家可以在这里学习。另外第四范式是提供企业机器学习咨询的。

Q5: 您好,您说“开发新的数据,首先考虑成本问题”,那除了成本,还有哪些考虑呢?

田枫:时间和风险,归根结底,项目管理就是消除项目中的不确定性。互联网思维讲求的是快,如果速度太慢,会失去市场的机会。所以我们一再强调的是,在可控的范围内,尽快做出一个有效果的机器学习模型。

同时,因为我们谈的是开发机器学习的 MVP 模型,一般会出问题的其实是 y 的选择,数据即便不够多,其实也能够验证。如果开发新数据,会把大量时间都花在了新数据开发上,这对于 MVP 是不合理的。

另外开发新数据是有风险的,如果最后模型没有效果,那到底是数据的问题,还是模型的问题?例如说很多数据看起来开发好了,但是有些地方有很多异常值,这可能会导致最终结果出现问题,但很难找到原因。所以有效控制变量,对于 MVP 也是很重要的事情。

Q6:田老师,讲了一个西瓜好坏分类管理的例子。公司电商项目中,对供应商好坏有也有个传统方法。就是经验设定几项指标评分,判断供应商好坏直接按分来分类管理。请问这问题用机器学习与传统方法根本区别是什么,价值是什么。谢谢。

田枫:由指标生成评分的公式也是一种模型,但是是一种维度比较低的模型。因此如果数据较大的情况下,这种维度低的模型无法充分利用到所有的信息。我们所说的机器学习可以通过利用算法和计算能力,使用大的数据生成一个高维模型,从而能够在指定的业务目标上更准确的判断“好坏”这种分类,大数据 + 高维模型带来的准确率提升就是最终可以获得的价值。

Q7:请问,机器学习项目如何排期?团队之间需要如何协作?比如说一个推荐模块的优化,不同成员怎么分工

田枫:首先这件事情取决于您的团队组成,以及机器学习建设到什么程度,是否已经有机器学习平台基础(包括高维机器学习模型训练和在线实时预估系统)。因为建设平台和在线系统本身是一件成本很高代价比较大的工作。这里以使用我们先知平台建设推荐系统的客户来说,主要工作包括:1- 对原有的推荐系统进行开发改造;2- 积累一段时间的历史样本,一般至少积累一个周期的数据如一周;3- 基于积累的数据进行模型训练与优化;4 模型线上试验。

第四范式提供互联网推荐解决方案,直接帮你快速建立推荐系统,欢迎联系我们 bd@4paradigm.com 了解。

作者介绍

田枫,第四范式联合创始人,产品负责人。毕业于北京大学计算机系,曾在百度、360 商业广告体系任数据科学家,及 BA 团队负责人,在机器学习应用、策略研发、以及数据商业智能相关领域深耕 10 年 +,为战略布局和业绩提升均带来杰出贡献,是国内个性化推荐的最早实践者。

公众号推荐:

跳进 AI 的奇妙世界,一起探索未来工作的新风貌!想要深入了解 AI 如何成为产业创新的新引擎?好奇哪些城市正成为 AI 人才的新磁场?《中国生成式 AI 开发者洞察 2024》由 InfoQ 研究中心精心打造,为你深度解锁生成式 AI 领域的最新开发者动态。无论你是资深研发者,还是对生成式 AI 充满好奇的新手,这份报告都是你不可错过的知识宝典。欢迎大家扫码关注「AI前线」公众号,回复「开发者洞察」领取。

2017-07-27 17:172906

评论

发布
暂无评论
发现更多内容

Vue进阶(贰零捌):ES6 对象解构

No Silver Bullet

ES6 5月月更 对象解构

什么是时序数据库

领创集团Advance Intelligence Group

VPN的应用场景

源字节1号

小程序开发

企评家,企业成长性评价系统怎么用?

企评家

企业成长性分析 企评家 企业投资价值评价

一份优秀的产品帮助文档怎么写?

小炮

UniqueMergeTree:支持实时更新删除的ClickHouse表引擎

字节跳动数据平台

Clickhouse 表引擎 实时

【等保测评】2022年北京正规等保测评机构新名单公布

行云管家

等保测评 北京

编程,不止有代码,还有艺术

华为云开发者联盟

数据库 倒排索引 GaussDB(for Influx) hint

A New ETL Language -- Easy SQL

Bright

数据开发 ETL 大数据开发 EasySQL

固态硬盘和机械硬盘的区别(7大区别,简单易懂)

源字节1号

软件开发 前端开发 后端开发 小程序开发

给小白的 PG 容器化部署教程(上)

RadonDB

postgresql 容器化 数据库·

MSVC编译多个C程序文件

Loken

音视频 5月月更

易周金融分析 |“一参一控一牌”落地;两家支付机构更名

易观分析

金融 银行

实验室信息管理系统如何工作?

低代码小观

低代码 实验室管理系统 企业管理系统 LIMS实验室信息管理系统 企业管理软件

【直播预告】研发效率百倍提升的秘密,这些破圈思路了解一下!

FinClip

小程序 finclip 直播预告

硬之城获阿里云首批产品生态集成认证,携手阿里云共建新合作

阿里巴巴云原生

阿里云 云原生 合作伙伴 合作

揭秘华为云GaussDB(for Influx)最佳实践:hint查询

华为云开发者联盟

数据库 倒排索引 GaussDB(for Influx) hint 单时间线

直击中小企业转型通用痛点 联想百应推出智能会议解决方案

Geek_2d6073

基于边缘计算的云游戏场景实践

火山引擎边缘云

最佳实践 边缘计算 实时音视频 云游戏

对象存储 S3 在分布式文件系统中的应用

焱融科技

对象存储 存储 分布式存储 云存储

MSVC编译静态库

Loken

5月月更

直播回顾|携手 Opentelemetry 中国社区,走进可观测性

Daocloud 道客

云原生 可观测性

ZooKeeper 在阿里巴巴的服务形态演进

阿里巴巴云原生

Apache zookeeper 阿里云 开源 云原生

Kubernetes下Stdout日志白名单最佳实践

观测云

可观测性 可观测

【等保测评】等保测评师怎么考,前景怎么样?

行云管家

网络安全 IT运维 等保测评 等保测评师

艾莫尔研究院基于Karmada的落地实践

华为云开发者联盟

云原生 Karmada 自动化集群管理

git bisect:让你闭眼都能定位疑难 bug的利器

华为云开发者联盟

开发 bug git bisect 二分法定位

大咖说·图书分享|阿里官方为你分享内部测试之道

大咖说

阿里巴巴 测试 开发

中科大脑知识图谱平台建设及业务实践

NebulaGraph

图数据库 知识图谱

精彩回顾|KubeCon EU 2022 Kubernetes Batch + HPC 专题日

Daocloud 道客

Kubernetes 云原生 HPC batch

PostgreSQL 15 新特性解读 | 墨天轮优质文章合集

墨天轮

数据库 sql postgresql 新特性

机器学习的最小可用产品:人工智能应用的敏捷开发_研发效能_田枫_InfoQ精选文章