AI追赶的瓶颈:软件工程能力的重要性

随着的面世,大语言模型AI(如GPT-3)已经成为了热门话题。国内也有很多团队在进行追赶,然而,在实际追赶过程中,AI技术与软件工程能力的结合却成为了AI追赶的瓶颈。

我们最近在网上看到对复旦大学MOSS的采访:

复旦团队发布国内首个类模型MOSS,邀公众参与内测

文中提到:

“目前,MOSS的最大短板是中文水平不够高,主要原因是互联网上中文网页干扰信息如广告很多,清洗难度很大。为此,复旦大学自然语言处理实验室正在加紧推进中文语料的清洗工作,并将清洗后的高质量中文语料用于下一阶段模型训练。科研团队相信,这将有效提升模型的中文对话能力。”

结合文中其他部分的描述和网上其他资料,不难看出,尽管团队对其在深度学习算法和模型上充满信心,但由于数据获取和清洗方面的软件工程能力不足,导致其模型的数据量远低于,无法有效提升任务完成度,比如中文对话的表现不足。

根据分析,数据获取和清洗的问题实际上源于软件能力的缺陷。例如,如果数据清洗的程序需要经常变化,那么开发人员需要具备一定的灵活性,能够快速理解新的需求和业务规则,并对程序进行相应的修改和调整。并且开发人员需要掌握TDD(测试驱动开发)的相关概念和技术,如单元测试、测试框架和测试覆盖率等。因为TDD能够帮助开发人员编写高质量、易于维护的代码。开发人员还需要掌握持续集成和持续交付(CI/CD)能力,因为CI/CD能够帮助开发人员实现代码的自动化构建、测试和部署。

如果没有合适的爬虫程序和清洗工具,就无法获得足够的数据。这使得我们意识到,在AI的发展过程中,软件工程能力的重要性不容忽视。尽管大多数人关注的是训练后的模型,但在训练模型的过程中,需要写很多定制开发的软件。而这些软件是一次性的,用完即扔的,但是这个“一次性”的过程可能长达数年,需要不断调整和演进这些软件。如果这些软件没有持续演进的能力,那么就无法到达终点。因此,软件工程能力的瓶颈限制了AI的成长。

行业普遍能力显著加剧了挑战

中国的软件开发行业数量庞大,但是整体水平并不尽如人意。虽然国内拥有大量程序员,但是很难掌握先进的工程实践和技术,这导致了软件开发的问题和质量不稳定。

例如,XP( )包含的一组工程实践,如TDD(测试驱动开发)、重构等,在中国大型软件开发组织的上下文中难以广泛实现。这些工程实践需要高水平的技术人才和团队协作能力,但是中国的软件开发组织很难招聘到这样的人才,而且组织管理也难以支持这些实践的实施。

因此,中国的软件通常在3-5年内就需要重新开始,这是由于工程实践差导致软件逐渐腐化到无法维护。然而,从另一个角度来看,由于中国的软件工程师数量众多,对于软件的质量要求也没有那么高,因此每3-5年推倒重来的做法也被视为一种解决方案。

但是,在为人工智能配套的软件上,这种做法可能会面临巨大的挑战。为了实现智能化,软件需要更高的精度和更长久的维护,定期的推倒重来可能从效率和质量上都不能满足需求。例如,训练的过程涉及到多个软件组件和工具,包括深度学习框架、分布式训练工具、数据处理和清洗工具等,这些软件组件和工具的更新和维护都是必要的。因此,中国的软件开发者们需要更加重视工程实践和技术的学习和应用,只有这样才能够适应追赶需求,但是这与我们之前所说现状的限制产生了矛盾。

基于的AI定制软件开发方案

我们从文中看到,“复旦团队则采用不同的技术路线,通过让MOSS和人类以及其他对话模型都进行交互,显著提升了学习效率和研发效率,短时间内就高效完成了对话能力训练。”

那么在软件开发方面,我们能否采用类似的思路呢?我们是否可以直接基于现有的进行AI所需的定制软件的开发?尽管这个想法听起来大胆,但实际上是可行的。

我们发现,在使用进行编程的时候,它可以基本上满足一些简单场景的编程需求。通过一些特定的手法,它可以有效地编写出可用的软件。这里所说的简单,是指需求描述简单,不是指需求本身简单或者实现简单。实际上,现在更擅长于处理许多复杂算法和软件框架的开发,因为这些需求都有专业术语,因此需求本身的描述可以很简单。

经过本人实际测试,使用进行编程可以大大提高开发效率。此外,基于进行编程也会带来一些有趣的生产方式变化。在软件开发的工程实践中,我们通常会采用一种假设:重写比重构更慢。但是,在使用进行编程时,我们会发现重写会更快。尽管测试仍然很重要,因为测试会告诉是否正确重写,但本身也可以根据实现代码推理出需要哪些更多的测试用例。这将形成一个恐怖的飞轮,人类提供简单的测试和需求,让编写出符合测试的实现,然后让根据实现和需求反向推理出需要哪些更多的测试,并给出测试用例和可以执行的测试代码。这样的工作方式与测试驱动开发(TDD)很像,只是其中最耗费脑力的部分:“基于测试改进代码和想出更多测试”变成了AI的工作,而人只需要让AI按照TDD的方式工作并适时纠偏即可。

基于这种生产方式及其可观的收益,我们很容易得出一个结论:可以用于简单小单元的开发,但对于更复杂的系统,它能否提供帮助呢?一般来说,由于算力的限制,输入的文本是有限的,而且自身的封闭性使得自建业务上下文的大语言模型AI是不可能的。然而,我们可以从工程化的角度出发,将复杂系统拆分为小单元,用简单逻辑拼装起来。既然可以完成小单元的编程,并以惊人的效率完成,为何不发明一种架构来充分利用这种生产力的提升呢?

这种架构看起来很像深度神经网络,每一层都是可以互相替换的细分的功能点单元。每个细分的功能点单元都可以封装为一个通用的调用接口,比如抓取不同的网站的逻辑,这些逻辑是可以被封装在代码中的,并且可以用一种DSL来描述。这种DSL可以交给AI来学习,这些DSL不是中文,而是更结构化更形式化的语言,对于AI来说反而很友好。人可以通过TDD的方式修正它的组合结果,最终得到一个可以用于进行复杂系统开发的方式。

虽然这种方式目前还处于畅想中,但逻辑上可以做到的事情,最终一定会发生。这种新的方式一方面降低了对开发人员能力的要求,另一方面又保证了每个节点都按照唯一证明可以保证质量的工作方式:TDD来进行开发。这种方式可以为我们的追赶带来极大的意义。由于中国的软件开发人员能力存在很大的问题,我们可能受限于AI所需的配套定制软件而追赶缓慢。但这种新的方式一方面降低了对开发人员能力的要求,另一方面却恰好保证了每个节点都按照唯一证明可以保证质量的工作方式:TDD,来进行软件开发。于是我们得到了一种既科学又不需要长期训练获得的能力作为运转基础的生产方式。

最终,我们可以得出结论:可以用于简单小单元的开发,而对于更复杂的系统,我们可以采用一种类似于深度神经网络的架构,将复杂系统拆解为小单元,再用AI完成小单元的组合,从而实现复杂系统的开发。这种方式既提高了生产力,又保证了质量,但更重要的是,它为我们带来了一种全新的软件开发思维方式。这种方式不仅仅是一种技术上的创新,更是一种理念上的创新。我们不再局限于传统的软件开发方式,而是采用了一种更为开放、自由和创新的方式来进行软件开发。

在这种开放性的思维方式下,我们可以不再局限于传统的软件开发范式,不再局限于传统的技术框架和工具,而是充分利用现有的技术和工具,灵活地选择和组合,以达到最优的效果。同时,我们也可以吸纳更多的外部资源,比如开源代码、第三方库、人才等等,让它们与我们的系统无缝地融合在一起,形成一个更为强大、更为开放的系统。

当然,这种思维方式也面临着很多挑战。比如如何确保代码的质量和安全性,如何协调不同的开发者之间的合作,如何处理不同的利益冲突等等。但这些挑战并不是无解的,实际上它的解法就在XP( ,极限编程)方法中。例如测试驱动开发、持续集成、重构等实践都有助于确保代码质量。只是XP中的实践在这个时代如何与AI更好地协作需要进一步的探索。我们可以通过不断的探索和实践,逐步发展出一套成熟的软件开发流程和治理机制,来保证整个开发过程的质量和效率。

chatgpt 开发全过程_开发过程怎么写_开发过程中遇到的问题

总之,作为一种新兴的AI技术,为我们带来了很多的机会和挑战。作为追赶者的我们却可以充分利用它的生产力,来进行我们追赶所需系统开发。在追赶的同时我们还会得到一种全新的开放性思维方式,它可能打破传统的软件开发模式,进一步的释放生产力。(正文完,翻页为人类作者问答环节)

人类作者问答环节

Q:为什么会产生这样的想法,做这样的尝试?

仝键:带来的这波浪潮,我们看很多人都在畅想未来,我们觉得,畅想未来不如活在未来。如何能应用好这类AI其实也是有相当多学问的,而几乎全世界的人都在同一刻起跑,我们没有时间等待别人研究的成果。必须要做第一批在正式工作中使用的人。所以我们在工作的所有场景下,都试图用它来提高我们的生产力,所以写这样一篇文章对我们来说也不过是这一策略的延续,它是很自然发生的,没有特别针对写文章这件事专门想过。写起来之后,我们发现,这事好像还挺酷的。

Q:如何“启发式提问”,能否举例?

仝键:其实很简单,我们之前看到了这篇新闻,在微信上进行了一些讨论,我们把新闻链接和讨论的内容直接扔给了new Bing——众所周知,new Bing就相当于可以联网的(虽然现在也限制了联网获取内容的功能)——问它如果我们要写一篇文章阐述这些观点,建议怎么布局谋篇。于是它建议我们分成三部分来写,每一部分写什么内容。然后我们再基于每一部分的主题,一部分一部分的让他去写。

第一遍由AI写出来的内容可能并不让我们满意,因为大都是片汤话,缺乏洞见。这个时候我们就把我们的不满意直接说出来,并给它一些洞见,问它在逻辑上这些洞见是否有道理,有没有什么补充,然后让它把这些洞见和他写的内容编织在一起。

熊节:有时候它生产的内容也是会偏离我们想要表达的方向。比如说在写这篇文章的过程中,AI把瀑布方法当成一个靶子来打,但那不是我们想要说的重点。这个时候就需要明确告诉他,那个不是我们要讨论的重点。毕竟虽然XP 提供了一些不错的实践,这些实践最终也会被重塑成一个完全不同的样子。所以我们并不关注传统意义上的软件开发方法的对比,更关注整体而言软件开发能力面临的挑战。

Q:做了哪些细节编辑?

仝键:后续的修改还是比较少的。有一些对原文的引用是我们自己手动加进来的。很不喜欢直接引用原文,哪怕你告诉它引用原文,它都会重新加工一遍。还有几处用词上的微调也记不太清了,不是很重要的修改。一般我们都不去直接修改它,如果觉得写的不好,就改改输入让它重写,跟我们后面提到的写代码的方法一样。因为担心直接修改生成的内容可能会在哪里造成了逻辑不通顺的地方而没注意到,所以我们更愿意让它重写一遍。

Q:“经过本人实际测试”这句是后加的吗?确实测试过吗?

仝键:是我们先向描述了一些工作方法,它把这句话保留了下来。这里提到的整个方法都是我们实际测试过的。我们在推出之后一直在考虑怎么用它来辅助软件开发,最近终于在一个稍微复杂点的需求上实现了100%由编码完成。不过这个案例更多是可行性证明性质的试验,实际意义不大。大多数与它结对完成的代码,是95%由它完成,5%由我们自己完成。

熊节:在与结对编程的过程中,人的主要作用是提出颗粒度合适的任务,然后验收给出的代码。有时候需要做少许微调,就是仝键说的那5%由自己动手完成的代码。因为思路正确的情况下,给出的代码一般都相当准确。有一些不够准确的细节,与其费劲去命令它纠正,不如自己顺手改了。

Q:文中的“但逻辑上可以做到的事情,最终一定会发生”这句话也是AI写的吗?您认同它描述的情况“一定会发生”吗?

仝键:这句话就类似于前面说的那5%人工输入的部分,是我们加入了自己的主观判断。有趣的是,似乎并不完全认同我们的主观判断。加完这句话之后我们也问了他怎么看这句话所表达的观点,它说:“作为一名人工智能,我认为这个问题需要考虑多个因素,包括政治、经济、技术和文化等方面的影响。虽然技术上可能实现,但实际情况可能会受到其他因素的制约。”

熊节:也许最后事实会证明,我们就不应该画蛇添足去加入自己的主观判断,或许AI的判断比我们更准确。

Q:您认为用这种新方式,是否有助于弥补我们在软件工程能力方面的不足?

仝键:我认为一定程度上是有可能的。正如我们在文中所说,它使我们能以一种既科学、又不需要长期训练就能获得的能力来生产软件。工业化也是符合这个范式的,它使得更广泛的人群以一种高效高质量的方式参与进了社会大生产。而软件工程之前虽然一直被叫做工程,但是业界的一个普遍共识是:软件工业与其说是现代化的工业,倒是更像手工业。我们认为,这类AI 有可能极大地降低从业者进行高质量生产的门槛,从而真正将工业化带到软件开发领域。

Q:用引导式提问的方式完成这篇文章,在工作量上与正常写作相比,如何?

仝键:这个文章从开始写到完成只花了3个小时,虽然我们之前的讨论已经有了一些输入了。工作量上要轻很多,以我个人的体验效率提升了可能10倍不止。平时我写一篇文章大概要一周,因为主要是业余码字,加上灵感缺失、行文上的卡壳都导致时间拖长。虽然我们对最后的成文质量还不是特别满意,但是考虑到它的效率,这种程度的质量也是可以接受的。我们都开始考虑要不要做个业余但日更的写手,挑战一下罗振宇、波士顿圆脸的生活节奏。

Q:您认为以这样的形式完成这篇文章,有什么样的意义?

仝键:虽然可能有点勉强,我觉得有点像当年马车与蒸汽机车赛跑的意义。知识工作者的工业化浪潮来临了,每个人只有不断奔跑才可能安全上岸。我们在交流这一波AI浪潮的时候,总会有人想探讨AI会不会产生智能。而我的态度是,我现在就像站在泰坦尼克号船头的一个人,看到了一座巨大的冰山向我撞来,这一刻我想的是怎么逃生上岸。我不关心那个冰山会不会产生智能。无论它产不产生智能,灰犀牛已经出现,没有谁可以逃避。虽然我们可以说人有人的用途,我也相信这最终会成为社会共识,但我更关心走向这个社会共识的过程。

Q:在《流浪地球2》中550在短时间内就完成了对一系列设备的重新编程,大语言模型在编程上的应用是否有助于实现上述“科幻”?对于弥补现实中中国工业软件的短板,实现万物互联,是否有实际意义?

仝键:550的一个情节对于我们还是有一定的启发的。作为常年从事软件开发的从业人员,当电影演到500C接入那个情节的时候,我下意识的反应就是,那么多的烂代码,你处理的过来吗?结果550C说,“生成底层操作系统”。那一刻对我还是比较震撼的。对呀,可以完全重写啊,维护什么旧代码?所以也激发了我后续去思考以结构化的重写来替代重构的开发方法。所以从我个人角度来讲,我是很有信心的。这种颠覆性的生产方式对于我们弥补工业软件的短板是有实际意义的。

而且,根据我的体验,我感觉越是这类系统软件、领域软件,AI能发挥的威力越大。因为受制于算力限制,它现在适合处理需求描述相对简单且结构化、而实现相对复杂的场景,而这恰恰是系统软件的特征。相反企业里的业务软件,往往是需求描述复杂且模糊,实现反而相对简单,这点上反而是AI的弱项。但是这个弱项也是暂时的,我相信随着发展,这些问题也是可以被解决的。比较起来,我更担心我们在这个强大的工具方面被卡脖子,那可能会造成我们在软件生产方面的代差。