大规模语言模型将如何影响软件的构建？|出品
发表时间：2023-09-19 14:00:54
文章来源：炫佑科技
浏览次数：187
菏泽炫佑科技
大规模语言模型将如何影响软件的构建？|出品
出品| CSDN（ID：）
*近，大语言模型掀起了一股热潮。 发布的GPT-4模型在包括编程在内的各种功能上都取得了令人瞩目的进步。 微软研究院发布的一篇论文显示，GPT-4 可以在没有太多提示的情况下生成非常复杂的代码，例如 3D 视频游戏。 与此同时，插件也发布了。
大型语言模型将如何影响软件的构建？
大型语言模型可以提高专业开发人员的工作效率，并且已经证明了这个方向的可行性。 这意味着开发人员不必担心未来的就业前景，软件的生产和分发方式也不会发生巨大变化。
然而，大型语言模型的影响并不止于此。 大型语言模型将成为专业程序员的工具，但过于关注狭隘的用途可能会导致我们错过未来推动更大变革的潜力。
因为我认为有可能在短时间内所有计算机用户都能够开发小型软件工具并描述他们想要如何修改他们正在使用的软件。 换句话说，大型语言模型将演变成支持用户编程的工具，让普通人可以充分利用计算机，而无需掌握复杂的编程。 就目前情况而言，这一愿景在将模糊的非正式意图转化为正式的可执行代码方面遇到了障碍。 接下来，借助大规模语言模型，瓶颈正在迅速打开。
如果这个假设成真，我们将看到人们使用软件的方式发生一些惊人的变化：
大规模语言模型+可扩展软件
接下来，我们将深入研究大型语言模型可能给软件创建和分发带来的广泛变化，同时也会影响人们与软件交互的方式。 讨论的问题包括：
什么时候应该使用聊天机器人？
在大规模语言模型时代，用户交互模型将如何演变？ 特别是，聊天机器人可以接管哪些类型的任务？ 当我们考虑武装*终用户的不同方法时，这个问题的答案尤其重要。
我认为虽然聊天 UI 比 Siri 更强大，但它并不能很好地完成很多任务，我们仍然需要图形用户界面。 稍后，我们将讨论使用大规模语言模型来帮助我们构建 UI 的混合交互模型。
*终，我们将得到一个有趣的设计：一种开放的计算介质，用户可以直接学习和构建模型，并且大规模语言模型可以作为介质内的合作伙伴。
在进一步讨论之前，我首先声明，本文讨论的许多观点均基于个人猜测，具有很强的不确定性。 我什至无法预测这些变化何时会发生。 重点是想象人工智能的当前状态如何推断用户和计算机之间的新型交互，以及我们如何利用这项新技术来*大限度地提高*终用户的能力。
打破编程瓶颈
为什么大规模语言模型对普通用户使用计算机的能力很重要？
几十年来，计算先驱们一直在努力实现*终用户编程的愿景：普通人可以充分利用他们的计算机，而不仅仅是使用程序员提供给他们的预制应用程序。 Alan Kay 在 1984 年写道：“我们希望像编辑文档一样编辑我们的工具。”
这个想法有多种形式。 现代*终用户也接触过一些编程系统，包括电子表格、Glide 或 iOS 快捷方式，以及早期的脚本、 和 Yahoo Pipes。
虽然其中一些产品已经取得了成功，但它们现在受到一个根本性挑战的限制：帮助人们将粗略的想法转化为正式的可执行代码是一个非常困难的步骤。 系统设计人员尝试了超高级语言、具有更好语法的友好可视化编辑器、复杂性分层以及基于示例的简单代码自动生成。 但事实证明，使用这些技术很难突破一定的复杂度上限。
我自己在工作中也遇到过编程瓶颈。 几年前，我开发了一个名为 的*终用户编程系统，它允许用户通过电子表格界面自定义网站。 例如，在下面的简短演示中，您可以看到用户以不同的顺序对新闻文章进行排序，然后为页面上的文章添加阅读时间，这一切都是通过将网页与电子表格同步来实现的。
这个演示看起来很棒，对吧？
然而，如果仔细观察，你会发现这个系统有两个稍微尴尬的编程瓶颈。 首先，用户必须能够编写小型电子表格公式来表达计算。 虽然它比学习一门成熟的编程语言难度要小得多，但对于新手用户来说仍然是一个障碍。 其次，在幕后，需要特定于站点的抓取代码才能将电子表格连接到网站。 理论上，该代码可以由开发人员编写和维护，并在*终用户社区之间共享，但这需要付出巨大的努力。
现在有了大规模的语言模型，这些编程瓶颈不再是限制因素。 将自然语言规范转换为网络抓取代码或电子表格公式是现在可以通过大规模语言模型实现的代码生成过程。 我们可以想象，有大规模的语言模型来帮助爬取代码并生成公式，这样就不需要任何人手动编写代码来实现上述演示。 当我这样做的时候，这种程序生成还只是一个幻想，现在它很快就变成了现实。
然而，这个例子也提出了一个更深层次的问题。 如果我们让大规模语言模型为我们修改网站，为什么还要使用 UI？ 我们不能重新排序网站并增加阅读时间吗？
我认为这个问题的答案尚不明确。 将电子表格视为网站基础数据的另一种视图非常有价值，我们可以直接查看和操作这些数据。 单击列标题对表中的数据进行排序感觉很好，而且比键入“按 X 列排序”更快。 允许用户直接查看和编辑电子表格公式可以让他们拥有更多控制权。
所以，用户界面仍然很重要。 我们可以想象，大规模语言模型的具体、有针对性的作用应该是帮助用户定制和构建软件，而不是留下数十年的交互设计。
GPT 真的适合写代码吗？
如今 GPT-4 的编程能力如何？ 这很难用一句话来概括。 了解 GPT-4 当前功能的*佳方法是查看一些正面和反面的示例，然后亲自体验，*好是亲自尝试。
不难找到积极的例子。 就我个人而言，我已经成功地使用 GPT-4 编写了一次性代码来处理数据，我的妻子也编写了一些代码来从网站上抓取数据。 微软研究院*近发表的一篇论文发现，GPT-4（使用零样本提示技术）可以生成在浏览器中运行的复杂3D游戏，如下所示。
但反面例子也不难找到。 根据我的经验，GPT-4 在解决相对简单的算法问题时仍然会感到困惑。 前几天我尝试用它来制作一个 React 应用程序来执行一些简单的视频编辑任务，虽然它完成了 90%，但它未能正确实现一些拖动/调整大小交互。 所以，GPT-4并不完美。 GPT-4 感觉就像一个初级开发人员，打字速度很快，了解很多库，但很粗心，经常感到困惑。
我个人比较看好大规模语言模型的发展。 以下是一些不太明显的原因。
首先，迭代是大规模语言模型的必要组成部分。 当**个生成的代码不起作用时，您只需粘贴收到的错误消息，或描述意外行为，GPT 就会进行调整。 例如，网上有一位设计师（他不会编写游戏代码）通过多次迭代创建了一款视频游戏。
参考链接：
GPT-4 开发者的直播中还有一些使用错误消息进行迭代的示例。 如果你想一想，这也是人类编写代码的方式，你可能并不总是**次尝试就成功。
有些程序员对人工智能持怀疑态度，我经常看到这样的笑话：“太好了，现在我们不需要编写代码，只需编写计算机行为的准确规范......”（意思是，这不就是代码吗？ ！）我认为这种观点太短视了。 大规模语言模型可以反复与用户沟通并提出问题，帮助他们编写规范，也可以用常识来填补不清楚的细节。 这并不意味着它很容易实施，但我希望看到这些领域取得进展。 我已成功向 GPT-4 提出问题，从而澄清了我指定的规范。
还有很重要的一点是，根据MSR论文和我自己有限的实验来看，GPT-4的编程水平相比GPT-3似乎提升了不少，而且提升幅度巨大。 如果我们继续按照这个速度发展，下一代车型也将呈现出巨大的改进。
编程的难度因环境而异，我们可能会看到专业软件工程和*终用户编程之间的差异。 一方面，我们可能会看到*终用户编程的难度远低于专业编程，因为许多任务可以通过简单的编程来完成，主要工作是将多个库粘合在一起，而不需要新颖的算法创新。
另一方面，在新手*终用户主导的过程中，如果人工智能给出错误代码，与熟练的程序员相比，后果会更严重。 熟练的程序员可以嘲笑大规模语言模型的愚蠢建议并自己编写代码，或者利用他们的技能与大规模语言模型一起进行调试。 但*终用户会不知所措，甚至可能一开始都没有注意到这些问题。 虽然这些都是现实问题，但我认为它们并不是无法克服的。 *终用户一直在编写混乱且有缺陷的电子表格程序，但我们已经找到了解决它的方法软件开发，即使这对于关心正确性的专业软件开发人员来说是无法忍受的。
聊天本质上是一种有限的互动
接下来，我们来讨论一下本文的主题：在这个新的计算时代，交互模型将如何发展？ 首先我们来看看聊天交互模式。 计算的未来真的是计算机使用自然语言与我们交谈吗？
我认为关键是要注意聊天机器人让我们失败的两个主要原因。 首先，聊天机器人的功能有限（如 Siri），无法执行您希望它执行的操作。 但从根本上来说，无论机器人的质量如何，聊天本质上都是一种有限的交互模式。
例如，Greg *近在插件发布期间发布了以下推文，其中他与 进行了交互，并要求它剪掉视频的前 5 秒：
一方面，对于了解计算机工作原理的人来说，这个演示确实令人惊叹，我对其中的可能性感到兴奋。
然而，从另一种意义上来说，这个演示是愚蠢的，因为我们有现成的软件，提供直接编辑视频的界面，并具有丰富的交互反馈。 例如，它提供了用于编辑视频的用户界面，不仅提供了丰富的反馈，还允许对编辑进行精确控制。 我们不使用这样的软件，但不厌其烦地来回沟通：“请编辑前4.8秒”？
现在，我明白格雷格演讲的重点不仅仅是编辑视频，而是展示了广泛的可能性。 但这里仍然有一些重要的事情需要注意：聊天界面不仅非常慢且不准确，而且还需要有意识地努力理解用户的思维过程。
当我们使用一个好的工具（例如一把锤子、一把画笔、一双滑雪板或一个汽车方向盘）时，我们下意识地就与该工具成为了一体。 我们可以进入心流状态，应用肌肉记忆，实现精细控制，甚至可以发挥创造力或创造一些艺术作品。 不管机器人有多好大规模语言模型将如何影响软件的构建？|出品，聊天的感觉永远不如开车的感觉。 这一点在特里和1986年的著作《和》中有详细阐述：
驾驶汽车时，控制交互通常是透明的。 您不会想：“您需要将方向盘转动多少才能绕过前方的弯道？” 事实上，你甚至没有意识到你正在使用方向盘（除非有东西侵入）……汽车设计随着时间的推移而不断发展，才达到了目前的人车融合状态。 这不是通过让汽车像人类一样进行通信来实现的，而是通过相关领域（在道路上行驶）提供驾驶员和驾驶行为之间的正确耦合来实现的。
咨询与申请
从更高的层面思考聊天和直接操作的问题。 一种方法是思考人类顾问团队通过 Slack 进行交互，而不是直接使用应用程序来完成工作会是什么样子。 那么，我们就可以看到大规模语言模型在这方面的作用。
假设您想要获取一些与业务相关的指标，例如下一季度的销售预测。 你会怎么做？
一种方法是询问熟练的业务分析团队。 您可以向他们发送您的问题，但由于他们很忙，可能需要几个小时才能得到答复，而且这个过程很昂贵，因为您占用了他们的时间。 如果是一些简单的任务，可能得不偿失，但*大的好处就是灵活性。 顾问团队拥有丰富的经验和知识，他们可以执行许多不同的任务。
相反，另一种选择是使用自助分析平台，您可以在其中单击某些仪表板。 它更快、更便宜，而且不需要令人不安的分析师。 仪表板提供强大的交互操作，例如排序、过滤和缩放。
那么有哪些缺点呢？ 使用应用程序并不像与顾问合作那么灵活。 当您需要执行平台不支持的任务时，您必须寻求帮助或切换到其他工具。 您可以尝试向分析平台的开发人员发送电子邮件，但这通常不会产生任何结果。 如果您和开发人员之间没有建立有意义的反馈循环，您只能希望软件更加灵活。
现在我们已经建立了比较基线，让我们想象一下如何利用大规模语言模型。
假设我们可以利用人类分析师的替代团队来完成任务，同时保持相同水平的灵活性。 （今天的模型还没有完全实现，但已经越来越接近了。）事情会发生什么变化？ 首先，大规模语言模型的成本远低于人类； 其次，它的响应速度更快，因为它不忙，也不喝咖啡休息时间。 这些是主要优点。 然而，与它交谈需要等待几秒钟（甚至几分钟），这使得它比操作 GUI 或方向盘慢得多。
接下来，我们考虑将大规模语言模型应用到应用程序模型中。 我们从交互式分析应用程序开始，但如果我们有一个大规模的语言模型开发团队可供使用怎么办？ 首先，我们可以询问大规模语言模型应用程序是如何使用的，这比阅读文档更容易。
但更大的优势是大规模语言模型的帮助远不止于此，还可以更新应用程序。 当我们提供有关添加新功能的反馈时，我们的请求不会迷失在看不到尽头的等待队列中。 他们立即回复并与我们沟通如何实现该功能。 当然，有些新功能不需要所有人都可以使用，只要为我们服务即可。 这在经济上是可行的，因为我们不依赖人类开发团队来更新应用程序。
请注意，目前这些只是粗略的假设。 我们没有提及如何实现这个模型的细节。 目前软件构建方式的许多细节使得这种类型的即时定制非常具有挑战性。
但重要的是，我们在交互中建立了两个循环。 对于内部循环，我们有一个与该工具集成的快速且简单的用户界面。 对于外循环，我们可以有意识地向大规模语言模型提供反馈，并在达到现有应用程序的极限时构建新功能。 这既保持了UI的优点，又增加了灵活性。
从应用程序到计算媒体
这个双重交互循环让你想起了什么？
想想电子表格是如何工作的。 假设您在电子表格中构建了一个财务模型，然后您可以尝试修改单元格中的数字以应对特定情况。 这相当于直接操作的内循环。
但是，您也可以编辑公式。 电子表格不仅仅是专注于特定任务的“应用程序”，它们更接近于通用计算介质，可以让您灵活地表达各种任务。 “平台开发人员”（电子表格的创建者）为您提供了一组可用于制作许多工具的通用原语。
我们可以通过下图来描述与电子表格交互的双循环。 您可以编辑电子表格中的数字，但也可以使用编辑工具编辑公式：
从上图中我们可以看出电子表格具有一定的灵活性。 然而，个人用户在使用电子表格时很容易达到他们的知识极限。 在现实生活中，电子表格比上图更灵活。 原因是图表中缺少使用电子表格的一个关键组成部分：协作。
与当地开发商合作
大多数团队都有领域专家和技术专家，您可以与他们合作创建电子表格。 重要的是，您与创建电子表格的人员之间的关系完全不同于通常的“开发人员”与“*终用户”关系。 在 1990 年关于协作电子表格开发的论文中，Nardi 和 James 解释说，假设 Betty 是一位非常熟悉财务的 CFO，而 Buzz 是电子表格编程方面的专家：
Betty 和 Buzz 之间的关系似乎是*终用户和开发人员的关系，很容易想象两者一起开发电子表格的常见情况：Betty 根据她对该领域的了解指定电子表格应执行的操作， Buzz 实现了它。 。
然而，这种情况并非如此。 当他们协作处理电子表格时，有两个重要方面与上述常见场景完全不同：
(1) Betty 在没有 Buzz 帮助的情况下构建了一个基本的电子表格。 她将参数、数据值和公式编程到模型中。 此外，Betty 全权负责用户界面的设计和实现。 她使用颜色、阴影、字体、轮廓和空白单元格来组织和显示电子表格中的信息。
(2) 当 Buzz 帮助处理电子表格中*复杂的部分（例如绘图或复杂的公式）时，他需要在 Betty 的工作之上发言。 他向 Betty 的基本电子表格添加了一些更高级的代码，其中 Betty 担任首席开发人员，Buzz 担任咨询角色。
这是制度设计和实施职责的重要转变。 非程序员可以负责电子表格的大部分开发和大型应用程序的实现，而如果他们必须使用传统的编程技术，他们将无法承担这些工作。 非程序员可能永远不会学习递归函数和嵌套循环，但他们可以非常有效地使用电子表格。 由于缺乏经验的用户参与电子表格开发，因此当他们发现自己即将突破自己的知识极限或对更复杂的编程技术感兴趣时，他们更有动力与经验丰富的开发人员交谈。
因此，我们应该在描述使用电子表格的流程图中添加像Buzz这样的“本地开发人员”，他们会在迭代之外添加一层，用户在建模自己的工具时可以得到他们的帮助。 由于他们与用户属于同一团队，因此向他们寻求帮助比向第三方应用程序或平台的开发人员寻求帮助要容易得多。 *重要的是，随着时间的推移，用户会更多地了解如何使用电子表格，因为他们参与了开发过程。
总体而言，拥有本地开发人员可以使电子表格的使用更加灵活，尽管这种方法是有代价的，因为需要人类技术专家的参与。 如果您的团队中没有电子表格专家怎么办？ 您仍然需要在网络上搜索复杂的电子表格编程......
这种情况下，我们可以考虑让大规模语言模型扮演本地开发者的角色。 也就是说，用户主要主导电子表格的创建，但在需要时寻求某些公式的技术帮助。 大规模语言模型不仅可以创建完整的解决方案，还可以教会用户下次如何自己创建解决方案。
在我看来，上面展示的流程非常吸引人。 有一个内部交互循环，用户可以充分利用直接操作的全部功能，还有一个外部循环，用户可以在开放媒体中更深入地编辑他们的工具。 他们可以使用人工智能驱动的编辑工具并提高处理媒体的能力。 随着时间的推移，他们可以学习公式的基础知识及其工作原理。 这种结构知识可以帮助用户思考如何使用该工具，还可以帮助他们审查大规模语言模型的输出。
在一个用户完全依赖人工智能并且对其内部机制一无所知的世界中。 在以AI为助手的计算媒体中，随着时间的推移，随着用户逐渐适应媒体，用户对AI的依赖也会逐渐降低。
到目前为止，开放计算介质的设计一直受到编程瓶颈的限制。 大型语言模型提供了一种更灵活地将自然语言转换为代码的有前途的方法，这就提出了一个问题：什么强大的计算媒体适合这种新情况？
☞百度发打假声明：目前文心一言无官方 App；吴恩达LeCun直播回怼马斯克：汽车都没发明要什么安全带|极客头条 ☞ChatGPT 一统所有 AI 模型入口，四步实现文本分类、图像生成等 24 种复杂任务！ 炫佑科技专注互联网开发小程序开发-app开发-软件开发-网站制作等
