写点什么

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

  • 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 年 +,为战略布局和业绩提升均带来杰出贡献,是国内个性化推荐的最早实践者。

2017-07-27 17:173100

评论

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

为什么选择美国虚拟主机是你的明智之选?

一只扑棱蛾子

美国虚拟主机

从零开始构建一个电影知识图谱,实现KBQA智能问答[下篇]:Apache jena SPARQL endpoint及推理、KBQA问答Demo超详细教学

汀丶人工智能

人工智能 自然语言处理 知识图谱 智能问答 KBQA

MatrixOne悲观事务实现

MatrixOrigin

数据库 分布式 云原生 矩阵起源

重塑未来的1课:组装式交付新引擎——华为云智能化低代码平台

华为云PaaS服务小智

云计算 低代码 华为云 华为开发者大会

GPT-4被破解!数智时代大突破!低代码开发平台揭秘:AI模型架构演进的利器

不在线第一只蜗牛

人工智能 低代码 模型调参 ChatGPT GPT-4

分布式系统常见问题

互联网工科生

分布式

开启时空大数据新纪元:JNPF快速开发平台引领AI与自然资源融合

EquatorCoco

人工智能 AI 数据 时空大数据

实例分享| anyRTC 部署安徽某市应急实战指挥平台

anyRTC开发者

音视频 快对讲 融合会议 视频监控 综合调度

人工智能的底层逻辑

博文视点Broadview

春去夏来,火热发版:StoneDB-8.0-v1.0.1-beta 版本正式发布!

StoneDB

数据库 StoneDB

码中寻趣:低码专家与开发者的「神秘会议」 ——华为云Astro扫地僧出山

华为云PaaS服务小智

云计算 低代码 华为云 华为开发者大会2023 Astro

【HDC.Cloud 2023】华为云区块链分论坛内容值得再读!

华为云开发者联盟

区块链 后端 华为云 华为云开发者联盟 企业号 7 月 PK 榜

直播预告 | 博睿学院:海量数据实时可信认证

博睿数据

智能运维 博睿数据 数据要素 博睿学院

7.12下午两点开启直播!《数智企业@中国》走进泰开集团

用友BIP

数智企业

北京汽车牵手火山引擎数智平台,探寻车企数字化升级新通路

字节跳动数据平台

数字化 数字化升级 车企 企业号 7 月 PK 榜

方言语音识别数据驱动人工智能的多元文化发展

来自四九城儿

方言语音

软件测试/测试开发丨Selenium环境安装配置

测试人

Python 程序员 软件测试 selenium chromedriver

从零开始构建一个电影知识图谱,实现KBQA智能问答[上篇]:本体建模、RDF、D2RQ、SPARQL endpoint与两种交互方式详细教学

汀丶人工智能

人工智能 自然语言处理 nlp 知识图谱 本体建模

超级应用App的概念及构建思路

Onegun

小程序 小程序容器 超级应用

用友BIP全球司库“五大管家”,助力大型企业一流司库建设

用友BIP

全球司库

谁能真正替代你?AI辅助编码工具深度对比(chatGPT/Copilot/Cursor/New Bing)

快乐非自愿限量之名

工具 ChatGPT AI赋能 AI工具

技术领先、“忠”于业务,用友助力企业实现价值化国产替代

用友BIP

如何在 Ubuntu 22.04 下编译 StoneDB for MySQL 8.0 | StoneDB 使用教程 #1

StoneDB

数据库 StoneDB

三问三答:细数GaussDB迁移的核心技术

华为云开发者联盟

数据库 后端 华为云 华为云开发者联盟 企业号 7 月 PK 榜

火热的低代码和无代码赛道

互联网工科生

软件开发 低代码 无代码 应用开发

Cloud Kernel SIG月度动态:ANCK 5.10-016将落地kABI机制,5.10-015版本规划发布

OpenAnolis小助手

操作系统 内核 anck 龙蜥sig 版本规划

华为云张鹏:华为云盘古大模型及MetaStudio亮相新媒体大会,使能融媒创新

新消费日报

2023年最具威胁的25种安全漏洞(CWE TOP 25)

华为云开发者联盟

安全 华为云 安全漏洞 华为云开发者联盟 企业号 7 月 PK 榜

沉潜蓄势,厚积薄发:StoneDB-5.7-V1.0.4版本正式发布!特性增强,稳定性大幅提升

StoneDB

数据库 版本发布 StoneDB

软件定义汽车场景中的数据流处理

EMQ映云科技

车联网 mqtt 数据流

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