智能化软件开发微访谈·第二十四期大模型时代的智能化软件生态（讨论汇编）...

CodeWisdom

“智能化软件开发沙龙是由CodeWisdom团队组织的围绕智能化软件开发、数据驱动的软件开发质量与效能分析、云原生与智能化运维等相关话题开展的线上沙龙，通过微信群访谈交流等线上交流方式将学术界与工业界专家学者汇聚起来，共同分享前沿研究进展与业界实践，共同探讨未来技术发展方向。”

大模型时代的智能化软件生态

智能化软件开发微访谈·第二十四期

背景介绍

ChatGPT和GPT-4的横空出世以及所掀起的热潮标志着大模型时代的到来。大模型以交互式对话的方式实现了多领域任务完成能力，表现出了很高的通用智能水平。与此同时，大模型的出现也创造了全新的智能化软件生态，以大模型为智能基座按需融合各种信息、服务、接口、工具乃至机器人和各种物理资源正在成为一种新的技术和产业发展方向，由此带来了智能化软件应用及系统的“iPhone时代”。近期涌现出来的LangChain、HuggingGPT、AutoGPT、Prompt Sapper等技术初步展现了基于大模型的智能化软件应用构造新途径。在这一新的时代背景下，智能化软件系统的形态及构造方式将会发生什么样的变化？当前涌现出来的各种方法各自体现了什么样的技术思路？已有的方法和技术在真实应用中还存在哪些不足、面临哪些挑战？大模型时代的智能化软件生态将向什么样的方向发展，存在哪些人工智能、软件工程、系统工程等方面的研究问题？

针对这些问题，我们邀请了来自学术界与工业界的专家进行交流，围绕大模型时代的智能化软件生态这一主题展开讨论，希望能初步厘清技术与生态发展的脉络及未来方向。

主持人

彭鑫

复旦大学教授

嘉宾

邢振昌

Senior Principal Research Scientist and Science Leader of the SE4AI Team at CSIRO’s Data61

澳大利亚国立大学副教授

王昊奋

同济大学百人计划，特聘研究员，博导

邱锡鹏

复旦大学计算机学院教授

鲍捷

文因互联董事长

冯大为

国防科技大学副研究员

陈碧欢

复旦大学副教授，博导

李辰

阿里巴巴达摩院语言技术实验室高级算法专家

刘焕勇

360人工智能研究院算法专家、“老刘说NLP”公众号作者

访谈主题

大模型时代的智能化软件生态

能否描绘一下大模型时代的智能化软件系统的形态以及相应的技术和产业生态是什么样的？目前在学术研究以及产业发展上已经展现出了哪些迹象？

GPT-4和MOSS等大模型已经支持各种插件，LangChain、HuggingGPT、AutoGPT、Prompt Sapper等相关技术也层出不穷。能否总结一下当前基于大模型的智能化软件应用构造有哪些典型的方式方法？各种方式方法的技术原理是什么？

当前各种基于大模型的智能化软件应用构造方式和方法分别有什么特点或优缺点？分别适合于什么样的应用场景？在实践应用中效果如何？

很多人都认为大模型带来了智能化软件应用及系统的“iPhone时代”，您是如何理解这样的一种“iPhone时代”的？面向软件开发人员以及普通用户的智能化软件应用开发各自会向什么方向发展？当前阻碍其发展和广泛应用的主要技术和非技术挑战有哪些？

大模型时代的智能化软件生态未来将向什么样的方向发展？存在哪些人工智能、软件工程、系统工程等方面的研究问题？对于相关学术研究和产业发展有哪些建议？

Q&A记录

Question 1

主持人：能否描绘一下大模型时代的智能化软件系统的形态以及相应的技术和产业生态是什么样的？目前在学术研究以及产业发展上已经展现出了哪些迹象？

邢振昌：

基础模型国内外赛道火热，应用层初创企业雨后春笋，百家争鸣。学术和产业都受到很大冲击，要生存就要与时俱进。但我认为模型的巨大潜力和应用层创新想法之间存在巨大鸿沟，需要新型的软件环境和工具跨越这道鸿沟。这也是我们研发Prompt Sapper的动机。

王昊奋：

大模型时代的智能化软件系统有两个不同的方向。一方面是传统软件的改造和重塑，最直观的例子就是ChatXXX，即伴随着ChatGPT的发展，通过LLM大模型来提供LUI的接口，通过聊天对话的方式来使用原有的软件或更高效的产出实际的内容和分析相关的数据等，典型代表包括ChatPDF，ChatDoc，ChatDoctor，ChatBI等；另一方面，其实是伴随着LLM的兴起，各种围绕LLM的软件系统也慢慢发展起来，除了提供基础的大模型训练如mosaic、lightning等，推理如beam、BANANA等、部署优化OctoML等LLMOps工具平台之外，我们都知道大模型的交互都是通过提示来展开的，所以围绕提示自动化构建与评估如HumanLoop、HoneyHive、WHYLABS等，以及各种应用编排等面向Developer的各种工具。除了面向模型的AI工具，还有大量面向数据的工具，比如知名的包括Snorkel、fastdup等，同时在模型训练或推理加速等方面包括colossalAI，以及Anyscale等公司的出现；以及为LLM增加memory的向量数据库如Pinecone、Milvus和Jina.AI等也迎来了爆发期。基于此，模型Hub公司Huggingface所形成的生态也越来越繁荣和巩固。

王昊奋：

目前研究的发展围绕几个方向在开展。

1）各种基于特定Foundation Model的instruction-tuning（尤其是self-instruct），催生出了包括Alpaca、Vicuna、BELLE等各种低成本微调模型，以及领域大模型的初现（如金融领域的BloombergGPT）；

2）围绕着ALM（Augumented LM）尤其是使用工具能力、复杂推理能力、以及与物理世界交互行为能力等方面，产生了非常丰富的研究工作，也为后面的插件生态以及Copilot的产生奠定了基础；

3）各种提示工程层出不穷，从思维链（Chain-of-Thoughts，CoT）及其变种，程序指导语言模型（Program-Aided LM，PAL），推理执行结合（Reasoning-Act，ReAct），迭代提示、分解提示、提示优化、提示集成等各种工作。与此同时，各种优质提示词也变得越来越受到追捧，从而形成了围绕提示的社区和市场如Promptbase，Promptsource等。

4）从任务表达到目标表达的升级，形成了更加自主智能体的雏形，如AutoGPT，AgentGPT，ToolMatrix.AI以及babyAGI等具有更强任务规划、模型和工具选择、自主执行和反馈优化的闭环，并初步具备了自主思考的过程，也为更智能的RPA（Robotic Process Automation）奠定了基础。

鲍捷：

其实在10多年前我就在想，软件系统非常的僵化，所以当时我在想一种新的软件工程的方式叫data oriented software。就是系统各个组件之间，他应该是相互之间可以自由的去组合，然后随着应用它不断的去变化，就是软件应该可以去适应未被预料的场景。所以在这个过程中数据是第一公民，所有的代码本身它也应该是数据。因为它是数据，所以它有元数据，所以它就是可以被查询，可以 portable，他就具备了自由组合的能力，所以在07年开始，我就在尝试基于semantic wiki构造这样的软件架构。我当时投个大概四五年的时间吧来研究这种新型的软件，我自己写了很多给自己用的，感觉非常的酷，但是很困难，别人都不愿意用。因为代码本身是数据这个概念，其实大家是非常难以接受的。由于当时的一系列软件工具的缺失，所以这种开发模式也很难被推广到更广泛的场景去。

现在大模型出来之后，我感觉到这种新的范式出现了曙光了。以前最主要的困难就是代码本身的这种作为一个基础的单元如何去理解它？以及如何让他们之间能够产生相互调用，就是实现这种分发或者，让另外一个程序去实现它的编排。因为软件模块的编排本身也是一组指令，所以它是一个序列的符号，它本身也是一个数据。在semantic wiki里，这些东西都会表现成一系列的模板，模板本身因为它是数据，所以可以很自由的去组合。现在有了大模型之后，这种模板本身的生成，模板之间的编排其实就极大的可能去自动化了。尤其是底层的非结构化数据的理解能力大幅提升之后，我们能够进行内容的自动化的组合的处理，变得比以前更加的容易。所以我10多年前的这些理想，我觉得现在是有可能实现了，而且这是一种可以进化的软件，终于能够实现当初语义网领域里面的一个愿景，就是为未知的应用设计软件

观点讨论

@彭鑫：鲍捷老师的回答让我想起了Gartner这几年推崇的“超级自动化”（Hyper Automation）。基于大模型所实现的智能基座，我们有望实现数据驱动的软件应用智能化按需自动化构造，其中既包括功能API、软件服务、专用模型、专有的数据库和知识库等

邱锡鹏：

大模型时代，智能化软件系统的形态发生了重大变化，技术和产业生态也呈现出新的特点。大模型时代的智能化软件系统高度依赖数据。这些系统通过不断学习海量数据，提高自身的预测和推理能力。同时，数据的质量、多样性和可用性也对系统性能产生重要影响。大模型具备更强大的学习能力和泛化能力，能够在多种任务和场景中取得很好的表现。

陈碧欢：

就我们的调研而言，大模型时代的智能化软件系统的形态大致可以分为三种：1）以代码为中心的智能应用，大模型在其开发过程中提供代码生成、测试、调试等辅助；2）以服务为中心的智能应用，根据用户的任务描述由大模型进行任务分解与规划、外部服务组合与调用，目前已经出现了很多工具，包括Semantic Kernel、TaskMatrix.AI、HuggingGPT、AutoGPT、Prompt Sapper等；3）以多智能体为中心的智能应用，根据用户的目标任务由大模型进行角色扮演生成多个智能体，多个智能体合作完成任务分解与执行，目前已经有多智能体框架CAMEL、李戈老师的Self-Collaboration框架等。

观点讨论

@朱少民：@陈碧欢更多体现了大模型在软件开发中发挥不同的作用？1. AIGC 2.大模型做规划 3.大模型做协调？

@陈碧欢：嗯，也可以这么理解。2和3还包括运行态了，可以直接给结果了。

冯大为：

大模型时代的智能化软件应用可能会存在如下几种形态：1）围绕基础大模型的线上应用生态，例如围绕GPT-4构建的系列软件生态应用；2）以基座大模型为基础，通过微调等手段训练出系列领域大模型，围绕领域大模型服务构建领域相关应用，如金融、医疗等领域智能软件应用；3）基于小模型构建的智能软件应用，由于在成本等方面的明显优势，小模型将会继续成为智能化软件的基础，尤其在端、边应用场景，继续发挥智能的作用。

观点讨论

@朱少民：同意，这就是我之前分享的：水平实践路径/模式、垂直实践路径

李辰：

在大模型时代，智能化软件系统的形态和技术将更加灵活和高效。这些系统将能够利用大量数据和计算能力，以更精确和快速的方式解决各种问题。在大模型的支持下，智能化软件系统将能够实现更高的准确度和可靠性，同时也具备更好的扩展性和灵活性。智能化软件系统依赖的foundation model，不仅依赖算法开发，也需要更多的算力支持，云厂商会扮演很重要的角色。

刘焕勇：

大模型时代的智能化软件系统的形态可能会变成：系统组件大模型化、系统运行大模型主控化两个主要形态。

所谓系统组件大模型化，指的是后面这些软件系统中的很多组件都会见到使用大模型来实现的场景。系统运行大模型主控化指的是，整个软件的智能之处，可以使用大模型进行运维决策。

Question 2

主持人：GPT-4和MOSS等大模型已经支持各种插件，LangChain、HuggingGPT、AutoGPT、Prompt Sapper等相关技术也层出不穷。能否总结一下当前基于大模型的智能化软件应用构造有哪些典型的方式方法？各种方式方法的技术原理是什么？

王昊奋：

根据应用任务的类型可以分成2大类。第一类主要针对端到端的感知类任务、创造性任务和探索性任务。这类可以通过自然人机交互界面，通过提示工程和微调等方式来调用非确定性计算系统（即多模态大模型）；第二类主要针对强调数据可靠、结果确定、计算精准的任务。这类任务仍然通过自然人机交互界面进行访问，但是除了非确定性计算系统，需要通过插件或中间层来桥接确定性或经典计算系统（数据库系统、大数据系统、知识图谱系统或检索系统等）。

对于第一类，主要基于大模型的软件构建主要依靠对预训练模型的调整、集成、组合等技术手段来实现定制化功能,同时发挥大模型的跨领域迁移学习优势。直接使用包括：1）模型提示(Model Prompting)：通过输入提示来定制大模型的输出,无需改变模型本身。技术原理是利用自然语言提示来激活模型与任务相关的知识和能力。2）多模型集成(Model Ensemble)：将多个模型的输出组合起来,以实现更强的功能。技术原理是通过模型输出的组合策略(如平均、投票等)综合多个模型的预测结果。定制包括：1）模型微调(Model Fine-tuning)：在大型预训练模型的基础上进行任务定制化的微调。技术原理是固定预训练模型大部分参数,仅优化与目标任务相关的一小部分参数。2）适配架构(Adapter Architecture)：在大模型上添加适配层以迅速适配到新任务。技术原理是在模型的某些层上添加新的适配参数,通过微调这些适配参数来适配模型到新任务,而不改变原有的模型参数。典型案例是AdapterHub的语言模型适配器。

对于第二类，也可以进一步分为：1）插件模式，在大模型上通过添加额外的神经网络模块或通过服务注册经典计算系统，如添加记忆力模块（增加Context Window size），结果验真、引证、溯源模块（其他Fact Checking和Provenance管理），类似前面提到的ALM引入额外的工具、服务等的调用；2）Copilot模式即+LLM，除了1所描述的，还将承担多模态异构数据的统一知识表示与建模，作为智能网关提供统一的访问接口和编程模型等。1是对大语言模型能力进行外延，从而形成诸如ChatGPT Plugins等，也称为LLM+，而Copilot则是将LLM作为一个组件与其他系统一视同仁，进行有效的组织和编排来为各种智能应用提供服务，也称为+LLM。

邢振昌：

我觉得一端是人主导的chatbot，然后通过传统软件开发方法集成chatbot提供的知识和代码。另一端是autonomous agents，希望以最少或不要人参与，有AI自主完成human intention。在这两端之间存在巨大human-AI collaborative intelligence空间需要支持，Prompt Sapper希望能够填补这个空白。

观点讨论

@陈碧欢：Prompt Sapper是少数提供这种human-AI交互能力的工具

邱锡鹏：

插件化通过将不同的外部工具连接起来，形成一个处理流程。每个工具处理一部分任务，然后将结果传递给下一个工具。这样可以将复杂的问题分解为多个可管理的小问题，从而提高处理效率和结果的准确性。以后的智能化软件应用构造也可以通过任务分解的方式来构造复杂的任务。其中核心的能力是任务任务理解和拆解能力，需要大模型拥有比较高的逻辑和推理能力。

后面可以分化为以模型为中心，和以需求为中心。

像前面碧欢说的，以代码为中心的智能应用，大模型在其开发过程中提供代码生成、测试、调试等辅助；2）以服务为中心的智能应用，根据用户的任务描述由大模型进行任务分解与规划、外部服务组合与调用。

鲍捷：

对这块不是很熟悉。但我至少能看到他对于之前的低代码平台的一系列想法会带来冲击。而现在又开始兴起了新的在大模型之上的低代码平台。各种copilot，肯定将来会成为标配。未来的IDE肯定会跟今天非常的不一样。软件开发的门槛将大幅下降。非常有可能随着提示工程的低代码平台的普及,大多数的软件将是由非技术人员开发的。

陈碧欢：

基于大模型的智能化软件应用构造主要由两种方式：1）面向开发人员的构造，利用大模型实现代码生成、测试、调试等开发任务，对应于问题一中以代码为中心的智能应用；2）面向终端用户的构造，利用大模型做任务分解与规划、外部服务组合与调用，对应于问题一中以服务和多智能体为中心的智能应用。

冯大为：

是的，邱锡鹏老师总结的很全面。具体的，在langchain等工作中，大模型主要实现意图理解，langchain等工具充当大模型与外部服务的中间件框架，框架主要实现的特性包括：

* 任务分解、规划与执行管理

* 访问外部服务和工具，如搜索引擎、订餐等

* 长期和短期内存管理

* 根据工具结果生成面向用户的文本

因此，此类框架实现的是控制器或调度器的角色。

刘焕勇：

基于大模型的智能化软件应用构造主要包括三种方式：1、基于问答的形式，将各类智能化软件的应用以简单的chatbot方式进行问答；这种方式的原理在于将任务形式处理成qa，然后通过问答的方式完成推理。

2、基于集成插件的形式，使用大模型作为中控和调度室，将各类技能交给性能较高的其他模型来实现；这种方式的原理在于将llm作为中控大脑，针对特定任务做相应规划、拆解以及编排。

3、基于多模态交互的形式，将语音、图像、视频、文字等不同模态之间的数据进行关联和对齐，实现统一输入和处理。这种方式的原理在于各个模块之间特征的对齐以及交互。

李辰：

邱老师讲的很好，可以通过任务分解来构造复杂的任务。我想直接提一个问题，在开发插件的时候，如何确定插件本身的能力范围和复杂度，插件应该面面俱到，还是尽可能简单通用？包括结合插件的自动化程度，插件更适合做自动驾驶，还是需要与人进行更多交互，成为Copilot

观点讨论

@彭鑫：@李辰插件越小通用性和被重用的机会越高，但相应的组装难度也会高一些

@李辰：看到openai里的不少插件，背后对应的是一整套互联网服务，和我们想象的通用插件仿佛有些差异

@刘焕勇：使用插件这种方式，不能太将其托付大模型本身，但插件很多，并且插件之间的区别很小的时候，这种插件的分类实际上效果并不会太好。

@冯大为：关于插件这块，最近在思考一个问题，会不会出现一种“自然编程语言”？极大降低编程的用户门槛

@李辰：@冯大为想到一个大模型的段子，现在排名第一的编程语言是英语了

@彭鑫：@冯大为对于基本能力已经实现服务化封装，编程主要是任务拆解、方案规划的应用，自然语言编程应该是合适的

@冯大为：@李辰形象、生动

@彭鑫：@冯大为这也符合计算机编程语言的发展路径：越来越远离机器，而靠近人的思维方式，从机器语言、汇编语言、高级语言、面向对象语言……到自然语言

@邱锡鹏：@李辰这个问题很好。就像现在使用神经网络代码，是调用layer级模型还是基础算子，可能要根据需求

@陈碧欢：任务拆解与规划也不容易，目前几个工具的效果都不太好

@朱少民：@陈碧欢这是难点，包括多智能体和多个人的协作，估计是未来要攻克的领域

Question 3

主持人：当前各种基于大模型的智能化软件应用构造方式和方法分别有什么特点或优缺点？分别适合于什么样的应用场景？在实践应用中效果如何？

邢振昌：

通过聊天方式构造软件需要人有一定背景知识，知道怎么和AI聊，至少能表述清楚需要或不需要什么，能判断AI输出有效性和给出反馈，这样能够逐步引导AI达到目的。所以这种方式主要是让人获得信息知识的方式更便捷，我不认为他本质上降低了对人背景知识和能力的要求。网上又很多“惊艳”的演示，说几句话，几分钟就开发了个小应用或游戏。我个人觉得这种演示一方面展示了AI会带给我们的未来，但另一方面可能引起对AI不现实的期望或恐惧。

通过autonomous agents假设AI能够做好任务分解，并把子任务映射到大模型能力或传统APIs。这对有common structured workflow的任务是可以胜任的，或是网络上常见的应用。比如让AI自主写出俄罗斯方块游戏，我并不感到什么惊讶。十有八九GPT已经见过并背下了相关代码，所以他可能只是记忆力好，而并非真正具有开发能力。尤其是对开放性的软件开发，必须要有人的参与决策，尤其是requirements，task decomposition, and acceptance test。当然人也不会像以前那样全部亲力亲为，而是在AI辅助下在重要节点做出若干决定即可，人和AI就像司令官和参谋长那样协作。

这也是我上面提到的希望Prompt Sapper能填补的现有两种方式之间的空白。

王昊奋：

其实上面的分类已经描述了各自使用的应用场景。具体到第一类中的各种手段来说，

1）模型提示:

特点：通过自然语言提示来激活和定制模型，无需模型调优。优点：使用简单，不需要改动模型架构和训练模型。缺点：效果可能不如模型调优手段，适应性较差。

2）多模型集成：

特点：综合多模型优势，降低单一模型缺陷。优点：可综合不同模型的优势，如提高安全性、可解释性等。缺点：模型组合策略难以优化，容易过拟合；部署和计算开销大。适用场景：需要综合多能力的复杂任务。

3）模型微调:

特点：在大模型基础上精细调优，适配特定任务。优点：可以实现较高的定制精度和效果。缺点：微调难度大，参数易过拟合；可迁移性和泛化能力减弱。适用场景：需要高精度定制的核心任务。

4）适配架构：

特点：通过添加适配层快速适配新任务。优点：适配速度快，不改变原模型架构。缺点：适配效果可能不如微调，过于依赖原模型。适用场景：有大量新任务需要快速适配的场景。

对于第二类中的两种模式，插件模式易于开发，但是在具有私有数据和有数据隐私保护考量的场景就不适用，更多作为LLM流量入口的一个应用选择；Copilot模式能适用于接入私有业务数据并极大程度保护用户隐私，但是开发难度更高。

观点讨论

@李辰：@王昊奋结合王昊奋老师的介绍，我引出一个通用和专有模型的成本和效果的对比。通用模型可以使用更多训练资源、在推理测降低成本；专有模型为了降低训练成本，可以基于通用底座的微调的方式来减少训练成本，但是可能出现通用训练预料的污染、知识幻觉等问题，导致在专有场景上效果降低。

陈碧欢：

对于面向开发人员的构造，相对而言可能更适合于复杂智能应用（因为难以想象AutoGPT能自动做出一个无人驾驶系统），但仍需要依赖于开发人员的经验来应对复杂性并进行代码审查，大模型主要起到辅助作用，其生成代码的质量可能难以保证。

对于面向终端用户的构造，相对而言可能更适用于简单任务型智能应用（如找到关于中国软件大会的最新消息，并发送摘要），但即使对于这类应用，HuggingGPT、AutoGPT的任务分解不理想、成功率不高。

我们试用了HuggingGPT，其多模态效果比较惊艳，通过HuggingFace平台直接调用和运行AI模型，使用方便，对于图像、文本、音频等的处理和转换方面的简单任务，HuggingGPT基本都能生成合理结果，但是对于需要较多模型组合的复杂任务，HuggingGPT对任务的分解和结果的整合比较生硬，导致结果经常不是很准确。

我们也试用了AutoGPT，除了一些特别简单的任务（几个命令就可完成）可以自动完成，对于大部分任务，都会在某个执行阶段陷入循环或是完成基本流程但没有正确输出。在迭代的过程中总是会分化出一些额外的细节，容易偏离用户意图。在遇到错误并继续迭代时，容易陷入循环或不断进行没有有效产出的反思。自我优化能力的缺陷特别体现在GPT 3.5上，GPT 4虽远好于GPT 3.5但也存在上述问题。另外，使用时有token限制，且OpenAI API的开销较大。

观点讨论

@王昊奋：结合前面李辰@李辰问的那个问题，我觉得粒度，数量，以及任务复杂性都会影响最后的性能和效果，目前demo层面总能挑出不错的例子

@刘焕勇：是的，我最近测试下来的感觉也是这样，其很依赖于基础模型对复杂指令的理解

@王昊奋：可能可以对于这种开发范式，也定义一下类似的复杂度指数，完成指数等

@邢振昌：我们体验也是这样...感觉还是要人机协作，而非完全依靠AI

@刘焕勇：我可能要破泼点冷水，因为hugginggpt, autogpt等都是用LLM作为controller，演示的例子较简单，所以还好。

@邢振昌：这算事实，不算冷水

@刘焕勇：我们可以说它是一个趋势，但大模型搞插件编排是个挑战极高的事情，调用插件，少量的还好，多了就基本很乱，通过大模型作为中控本身就不是完全可控。

@王昊奋：@刘焕勇你又说了大实话

@陈碧欢：@刘焕勇是的，在特定领域效果确实还行，领域多了杂了就不太行了

@彭鑫：大模型给出的规划可能可以作为一个基础，但要得到一个可行可靠的方案，最后一公里可能还要结合一些传统技术，例如软件测试与修复等

@冯大为：@刘焕勇这也算是一种累积误差放大

@刘焕勇：所以，还是之外的传统方式该做的还是要做。我们做开发落地的，需要我也兜底方案。

@王昊奋：潮退了之后大家也会进入理性选择

@刘焕勇：或者，我们更多情况下，用外挂有监督分类器，也不失为一种做法。

@彭鑫：跟大模型生成代码差不多，最后一公里还要靠传统技术（测试、调试）以及人（把关+背锅）

@王昊奋：@刘焕勇有不少尝试了，包括super ICL，将专用小模型作为外挂或插件

冯大为：

没有直接的应用开发经验，但从基于大模型的智能化软件应用使用体验来看，当前对大模型的利用主要有两种方式：1）直接利用大模型的文本生成能力，比如写作、问答、语义检索、对话系统等；2）利用大模型的任务分解与规划能力，并调用外部工具。确实如碧欢所说，大模型任务分解与规划效果还不行，这可能是专门的数据训练还不够的原因。而在直接利用大模型生成能力方面，其实真实落地场景还有限，例如在处理含有模棱两可语义或特定领域专业知识的问题时，模型会产生错误的答案。这一块需要基于领域数据对模型进行微调训练，以满足特定应用场景的需求。经常生成的答案难以满足准确性要求。

观点讨论

@邢振昌：因为各种插件系统都没开源，从软工角度，我一直很困惑LLM是如何决定用那个插件的，如何确定输入中那些是插件需要的参数及传递给插件。请@刘焕勇@王昊奋两位老师给解惑一下？

@刘焕勇：就是prompt

@王昊奋：@邢振昌目前就是prompt + config的做法，其实和真正的Orchestration有比较大的差别

@邢振昌：很难想象到什么样prompt可以准确完成确定插件，从input提取参数，调用插件...插件需要开放调用接口？还是统一自然语言入口？

刘焕勇：

> Entering new AgentExecutor chain...

-------------------

[StringPromptValue(text='Answer the following questions as best you can. You have access to the following tools:\n\nSearch: A search engine. Useful for when you need to answer questions about current events. Input should be a search query.\nCalculator: Useful for when you need to answer questions about math.\n\nUse the following format:\n\nQuestion: the input question you must answer\nThought: you should always think about what to do\nAction: the action to take, should be one of [Search, Calculator]\nAction Input: the input to the action\nObservation: the result of the action\n... (this Thought/Action/Action Input/Observation can repeat N times)\nThought: I now know the final answer\nFinal Answer: the final answer to the original input question\n\nBegin!\n\nQuestion: 美国总统的年龄加5是多少？\nThought:')]

I need to know the current age of the US President

Action: Search

Action Input: Age of US President

Observation: 80 years

Thought:-------------------

I need to add 5 to this number

Action: Calculator

Action Input: 80 + 5-------------------

> Finished chain.

比如，这个就是一个prompt，用来计算美国总统的年纪。

观点讨论

@李辰：一个观察：langchain写prompt的水平很高

@邢振昌：就是prompt

@王昊奋：prompt也分为内置的，和user prompt，同时还可以有prompt tuning等（soft优化形式），所以用户其实关心的就是user prompt部分，其他部分如何结合，以及如何写，对大家来说是透明的

@邢振昌：不好意思，再问一下，这个是人写的调用插件的prompt？

@王昊奋：人就提出question，其他属于inner thought（添加结合特定的plugin的使用和特点，以及期望要求concat上去的）

@狄鹏：插问一下各位老师，pldi22 prompting is programming 这篇paper，用语言编程手段约束gpt输出，大家觉得是一种prompt的未来趋势吗？会影响llm的发展方向吗？

@彭鑫：@狄鹏简要介绍下这篇文章的思想？

@狄鹏：简单说，是为prompt设计一种 query语言，修改模型的encoder decoder来约束模型的输出。其实我理解是把自然语言又规范化了。

@彭鑫：@狄鹏受限的半结构化语言？

@狄鹏：是的

Question 4

主持人：很多人都认为大模型带来了智能化软件应用及系统的“iPhone时代”，您是如何理解这样的一种“iPhone时代”的？面向软件开发人员以及普通用户的智能化软件应用开发各自会向什么方向发展？当前阻碍其发展和广泛应用的主要技术和非技术挑战有哪些？

王昊奋：

“iPhone时代”意味着大模型将使得智能化软件应用和系统变得更加易用、便捷和智能，就像iPhone带来的智能手机革命一样。我的理解是:

对软件开发人员来说,“iPhone时代”意味着:

1）低代码或无代码开发工具盛行，开发者可通过简单的设置、组装和微调就能构建出智能应用。

2）开发效率和生产力大幅提升，极大缩短产品周期。

3）开发者更加关注任务适配和业务落地，而不仅仅是技术实现。

对普通用户来说,“iPhone时代”意味着:

1）更加便捷和通用的人工智能体验，智能功能嵌入各个场景，使生活更加智能化。

2）更加个性化和定制化的服务，大模型可深入理解个人兴趣和需求。

3）人工智能"消失"在用户视野中，变成一种无感知的自然体验。

当前的主要技术挑战有:

1）大模型的部署和推理效率。

2）模型个性化和定制的难度。

3）开发工具和框架的不足。

非技术挑战主要有:

1）用户和行业的 AI 素养尚待提高。

2）监管环境和政策仍需完善。

3）商业模式仍在探索中。

总之,大模型为智能软件带来了许多新的机遇与挑战。要真正实现“iPhone时代”,还需要技术社区和产业界共同努力。但未来前景乐观，大模型必将催生出更多创新，让AI产生深远影响。

邢振昌：

在研发Prompt Sapper过程中在这个方面做过些思考，我觉得基础模型确实带来了AI平台化或操作系统效应，就像PC时代的Windows, Linux，移动时代的iOS, Android。

AI操作系统（基础模型）可以让更多的人“开发”或组装AI服务。我在开发加了引号，因为此开发与现有软件开发应该有很大不同。也就是我们需要重新定义“开发”和“程序员”。Andrej Karpathy发了推特说他认为自然语言编程会让“程序员”增长到15亿，现在专业程序员只有几千万吧。当然“开发”具体不同在哪里，新型“程序员”都是谁，能干什么，如何支持他们仍需大量思考和探索。

同时，与传统操作系统不同，AI操作系统（基础模型）没有明确定义的APIs，而是所谓涌现的，通过prompt激发的。这也要求我们重新思考在这样没有明确APIs，能力是涌现的AI操作系统上软件开发是什么样的，这很可能需要我们对开发环境，流程，人机交互的质变有颠覆性的尝试。我们最近提出的Prompt Sapper算是这种尝试的抛砖引玉，为大家趟趟雷吧。

观点讨论

@彭鑫：“iPhone时代”还意味着一种新的生态的出现，可以围绕大模型产生很多下游应用，同时创造很多新的机会

@王昊奋：对的，natural language instruction as general purpose interface以及各种argument的binding等，其实是将歧义性引入到精确性问题中，虽然可以解决很多集成和编排的成本，同时自动化规划是大家指着他能带来的一个优势吧

邱锡鹏：

iPhone将通话和许多功能合二为一，并可以通过安装APP来使用个性化的用途。同样，大模型可以将多种AI能力融合在一个模型中，极大地提高了应用的可能性和效率，并也可以通过使用外部工具来增强其能力。

技术层面的阻碍，模型的理解和生成能力仍有限，它们可能无法理解或处理一些复杂的、抽象的或特定领域的问题。在非技术方面，数据隐私和安全性问题，因为模型需要访问大量的用户数据来进行训练，并消除歧义性。

陈碧欢：

如果说ChatGPT对应于iPhone，那么 LlaMA、MOSS等可能就对应于Android。iPhone和Android推动了庞大的应用生态系统的形成，吸引了开发者和创新者的参与。类似地，大模型也将促进一个庞大的智能化软件生态系统的发展，将成为一个基础设施。

对于面向开发人员的构造，现在的一些demo大都是算法/数据结构编程、或者是小型应用系统开发，对于企业级应用系统的支持基本还是未知数。因此，需要在深入理解和结合企业开发实践及流程的基础上，利用大模型实现需求、设计、编码、测试、运维等全生命周期的全方位支持。此外，为了保护企业数据的隐私，本地化部署与微调也很重要。

对于面向终端用户的构造，1）Semantic Kernel、TaskMatrix.AI、HuggingGPT等基本都是“一锤子买卖”，缺少与终端用户的交互能力，而AutoGPT、Prompt Sapper等提供了交互能力；2）Semantic Kernel、TaskMatrix.AI、HuggingGPT、AutoGPT等的外部服务库规模非常有限，极大地限制了智能应用的丰富程度；3）这些工具基本都是不计代价，完成一个任务需要频繁调用大模型；4）除了Prompt Sapper，这些工具构造的智能应用都是一次性的，难以复用，即使下次有同样的任务，还是会重新构造一遍，而Prompt Sapper提供了服务市场，支持复用。因此，需要在交互能力、外部服务库构建（实现万物皆服务）、代价感知（更进一步，质量感知）、服务复用等方面进一步发展。

阻碍其发展和应用的主要技术挑战包括可解释、隐私、安全、算力、数据更新等，而非技术挑战包括许可证、大模型滥用等。

观点讨论

@王昊奋：不计代价说的好，暴力美学

@彭鑫：@陈碧欢 @王昊奋所以看到有针对LLM应用的运维工具出来了，cost是一个主要的监控指标

@陈碧欢：@王昊奋用一次，就好几美元，心疼

@王昊奋：是的，LLMOps是一个很重要的东西，也包括各种ALM和整体的生态，以后cost-based optimization也是一个热点

李辰：

相比iphone moment，我比较关注谁会成为下一个android。目前看起来langchain起步很快，但是最近huggingface也推出了HfAgent。在生态上，huggingface以及hosting的模型有得天独厚的优势，大模型starcoder的发展也很快，加上space里的各种gradio应用开发的繁荣，很有可能成为大模型时代的android

观点讨论

@王昊奋：同意，所以让子弹再飞一会，agent其实就看本身的生态，不仅是foundation model的效果，也涉及到相关的工具和外挂的丰富程度，以及结合组织的便捷性和调用规划的高效性与精确性

冯大为：

智能化软件应用及系统是人类社会的基础设施，大模型无疑会通过这一基础设施载体对人类社会产生深远影响，这一影响如同Windows操作系统或者iPhone一样，是开创性的。

从智能软件开发的角度来说，应用开发的门槛将进一步降低，编程语言的抽象化层次将更高，将会出现类似“自然编程语言”，使得更多的大众可以参与智能软件应用开发。从智能软件应用的角度来说，用户使用各类软件的门槛也会大幅降低，举个例子，使用PhotoShop P图由于软件操作过程的复杂性，当前仍然是一种少数人掌握的工具，大模型的到来使得此类应用软件的门槛将大幅降低，用户将不需要再学习复杂的软件操作，这些知识都将被模型化。当前的挑战主要有：

技术挑战：

1. 模型输出结果的质量保证方法

2. 大模型的可持续学习与优化方法

3. 数据隐私和安全

非技术挑战：

1. 模型偏见与公平性问题，训练数据是有偏见和公平性偏差的，如何在模型的输出端减少甚至抹平这其中的偏见与不公平，如何对此进行监管？

2. 大模型的主体责任问题，谁对模型的输出负责

3. 开源大模型的安全利用问题

观点讨论

@刘焕勇：“iPhone时代”，简单理解就是新的时代，一个手机装下所有，这个是iphone；一个模型来cover住更多场景，统一范式，这是大模型的iphoe时代。

@朱少民：是，所以人们提“大模型时代” ，包括本次讨论的主题

鲍捷：

iPhone时刻它的本质其实是界面的改变，因为智能手机其实在iPhone之前都已经有了，所以iPhone的核心价值不是有了新的更牛逼的功能，而是通过更加简洁的使用界面，让用户的使用量急剧增大。我觉得最好的类比其实是电子表格，就是当数据库之后电子表格出现，他并没有比数据库更强大，但是他使得不会写SQL的人也能够去操作数据了，让电子表格出现在每一个办公人员的桌面上，是数据分析的各个细分场景，比如说会计啊，统计啊，日常运维管理啊，都变得更加的方便和普及了。所以当大模型和提示工程所带来的这种微量化软件建模的能力被普及到了数以亿计的白领工人的时候，那可能会带来了一个电子表格时代，就是相当于lotus123或者Excel时刻

观点讨论

@刘焕勇：面向软件开发人员以及普通用户的智能化软件应用开发各自会向什么方向发展，前者会朝着开发软件的效率、创意性、功能边界不断外延；后者会变成AIGC各种创意、提升生产力和自我中心的外延。

@彭鑫：@刘焕勇前者继续往专业化方面发展，开发并维护软件基础设施；后者往个性化方面发展，支持用户按需定制自己的应用

Question 5

主持人：大模型时代的智能化软件生态未来将向什么样的方向发展？存在哪些人工智能、软件工程、系统工程等方面的研究问题？对于相关学术研究和产业发展有哪些建议？

邢振昌：

我认为未来将不再是软工，HCI，AI大家各自玩儿的嗨，要办成大事需要多领域知识的融合。我觉得除了用AI提升现有程序员和开发效率之外，学界和业界看你都需要思考AI2.0和软件3.0时代“程序员”是谁，想干啥，能干啥，怎么能干成等问题吧。

王昊奋：

在大模型时代，智能化软件生态未来将向以下方向发展：

更加普适的应用场景：随着大规模深度学习模型的不断发展和应用，智能化软件将更加普及和普适，涵盖更多的应用场景，如智能座舱、智能家居、Javis型的个人助手，以及各种垂类应用等。
更加自动化的开发流程：自动化机器学习和增强学习等技术的发展，将使得智能化软件开发过程更加自动化，开发人员可以更加专注于业务需求和用户体验的设计。
更加强大的模型性能：大型科技公司和开源社区不断推出更加强大的大规模深度学习模型，未来的模型性能将更加强大，能够处理更复杂、更高维度的数据和任务。

王昊奋：

在人工智能、软件工程和系统工程等方面，大模型时代也存在一些研究问题，例如：

模型可解释性：大规模深度学习模型通常是黑盒模型，难以解释其决策过程和预测结果。如何提高模型的可解释性是一个重要的研究问题。
模型优化和压缩：大规模深度学习模型的优化和压缩是一个重要的研究问题。如何提高模型的精度和速度，并减少模型的大小和计算资源的消耗，是一个具有挑战性的问题。
数据隐私和安全：在智能化软件应用中，数据隐私和安全是一个重要的问题。如何保护用户数据的隐私和安全，同时确保模型的准确性和效率，是一个需要解决的问题。

其实最关键的还是最后一公里的问题

王昊奋：

建议学术研究和产业发展应该关注以下几点：

支持多样化的研究和应用场景：针对不同的应用场景和需求，需要开发更加多样化和灵活的大规模深度学习模型和相关工具。
强化模型可解释性和透明度：在开发大规模深度学习模型时，需要考虑模型的可解释性和透明度，以便用户和开发人员能够理解模型的决策过程和预测结果。
重视数据隐私和安全：在智能化软件应用中，数据隐私和安全是一个重要的问题，需要开发更加安全和可信的算法和应用，同时加强数据保护和隐私保护措施。
加强跨领域合作：大规模深度学习模型和智能化软件的开发需要跨越多个领域和学科，需要加强跨领域合作和交流，促进技术的跨界融合和创新。

避免重复低水平内卷，应该大家合作，将每一个环节的1-2款产品或工具做强

邱锡鹏：

未来的软件生态将更加依赖大模型。

1.跨模型协作：在一些复杂的任务中，可能需要多个模型协作才能完成。这就需要我们研究如何在不同模型之间建立有效的通信机制，以及如何通过协调和调度使得多个模型能够有效协作。

2.模型的安全性和隐私保护：如何在保持模型性能的同时，保护用户的安全和隐私，也是一个重要的研究方向。

3. 模型的自我学习和自我优化：如何让模型能够根据使用情况自我学习和自我优化，也很重要。

4. 软件工程 for AI：大模型是否可以提供自己的优化和维护。

观点讨论

@彭鑫：@邱锡鹏 “跨模型协作：在一些复杂的任务中，可能需要多个模型协作才能完成” 这里是指多个专用的小模型吗？

@邱锡鹏：除了one4all的模型，可能会分化从一些不同功能强化的模型，比如诊断、修复的。插件本身也可能是大模型

鲍捷：

大模型时代的智能化软件生态未来将向以下几个方向发展：

更加人性化：大模型的普及意味着AI将更好地模仿人的行为和思维方式，从而使得智能软件更加智能化和人性化，具有更好的用户体验。

更多场景应用：大模型能够适用于各种领域和场景，未来智能化软件将更多地应用于智能家居、智能医疗、智能教育等各个领域，提供更加全方位的服务。

更高效的开发：发展大模型会促进软件开发的自动化和工业化，提高软件开发效率和质量，从而降低软件开发成本，实现更快速、灵活的开发和部署。

而在实现以上发展方面，还存在以下人工智能、软件工程、系统工程等方面的研究问题：

精度与效率的平衡问题：提高精度会降低计算效率，而提高计算效率会降低精度。如何在这两者之间找到平衡，尽量实现高精度和高效率，是当前需要解决的问题。

个性化和隐私保护问题：针对用户个性化需求，需要从大数据中分析和抽象出用户行为和需求。但同时需要保护用户的隐私，如何解决个性化和隐私保护的平衡问题，是当前需要解决的问题。

模型的可解释性问题：大模型的黑箱特性导致其缺乏可解释性，难以解释其决策过程和推荐理由等，如何实现AI的可解释性也是一个需要解决的问题。

为了促进相关学术研究和产业发展，有以下几个建议：

加强学术研究，推进基础理论研究，加强技术创新，提高核心竞争力。

多角度合作，包括学界与产业、不同领域之间的合作，建立交流平台，加强合作研究。

关注智能化软件的发展趋势和需求，结合实际需要推进技术创新和产业化转化，注重解决实际问题。

加强对人才培养的支持和引导，培养具有学术和产业双重能力的人才，提高产业创新能力。

这个来自chatGPT，我自己写不会这么全面。我自己的看法，核心是大量的新工具体系将要被发展。特别是提示工程的开发环境，还有针对大模型胡说八道情况的软件测试工具。

观点讨论

@彭鑫：@鲍捷传统的测试和验证仍然十分重要，要来给大模型生成的结果把关、扫尾

陈碧欢：

大模型时代的智能化软件生态将向万物皆服务的方向发展，而基于大模型的无代码/低代码开发技术也将大力发展。其中一个迹象是HuggingFace已经在把Hub上的模型部署为可调用的在线推理服务。

人工智能方面，需要提高大模型的规模和能力（特别是多模态的能力），以提供更高水平的智能化能力和更广泛的应用场景。还需要提高大模型的可解释性和可信任性，以便更好地理解和解决模型的偏见、错误和安全等问题。

软件工程方面，需要与企业开发实践及流程结合，提供全生命周期的全方位智能化支持；需要发展企业私有数据的数字化沉淀，进而实现大模型的企业本地个性化定制，更好地适应企业的个性化需求，同时保护数据隐私；需要发展基于大模型的无代码/低代码开发技术。

系统工程方面，需要发展LLMOps，提供微调现有基础模型并将这些优化模型部署为产品的操作能力和基础设施。随着模型规模的增长，特别需要发展模型的效率和部署能力，通过减少模型的计算和存储需求，以便更好地在边缘设备和资源受限环境中部署大模型。

冯大为：

接前面各位老师的回答，关于学术研究方面简要补充几点：

1. 模型持续训练和优化算法，以提高大模型持续学习与优化的效率和性能。

2. 开发全面的数据集和评估指标，以评估和比较大规模模型的质量和效果。

3. 设计更好的模型结构，以提高模型的效率、可扩展性和灵活性。

4. 人在回路的智能软件演化方法；

5. 大模型输出质量保证方法，以确保模型输出符合用户预期。

李辰：

大模型时代智能化软件的主线会和foundation model的能力高度相关，其中一个关键问题是目前存在prompt设计和理解能力较弱的问题，导致调度、执行会任务失败，应该是软件开发里不能允许的。软件生态依旧会向开源开放发展，大模型、框架、应用的边界和能力逐渐清晰，容错能力也会越来越强。最重要的相关研究问题嘛，算力！能用上什么样的计算单元（GPU、NPU、ASIC）、现在的计算资源是否够用（N卡、国产化）？学术界能用到多少算力、什么样的模型、工业界能做多少实验和测试、构建什么样的智能化软件开发标准，是可以量化的。

观点讨论

@刘焕勇：前面几位老师说的很全面了，我就简单补充下发展方向就是：可信可控、更多集成、轻量化、低成本

@王昊奋：模型航母战队

@刘焕勇：把成本打下来，把功能提上去，把可控调起来。

@刘焕勇：补充第五点，就是细分垂直化，也就是：可信可控、更多集成、轻量化、低成本、细分垂直化

@李辰：推理一遍不行就多跑几遍，retry

@鲍捷：其实咱们参考一下历史，看一看这个软件工程每一个历史阶段的发展，都是跟界面的进步有关的

@刘焕勇：嗯，就是信息获取/交互的变化

@鲍捷：比如说如果没有鼠标的话，那大概率就不可能有普通人用的浏览器，那也就不可能有RESTful架构

@鲍捷：同样在纸代机时代的话，那大概率大多数的应用都会是科学计算，而不会有复杂的业务系统，那么IBM360这种系统和之后所有的软件工程的思想都不会发生

@鲍捷：所以当以提示工程作为软件工程的一种新型界面的实践被普及之后，极有可能出现我们完全无法想象的软件工程的方法论和哲学

@朱少民：多机器人、多智能体。所以前面说，规划、协作很关键