Geoffrey Litt 本刊之前推荐过好几次他的作品和文章，他是日裔美国人在 MIT 读书，在 Muse.app 实习。我了解的不多的西方青年中，他关注的领域和我很重合，也是非常乐于学习的对象。如果你对未来的编程、工具、软件等感兴趣，他的实验和论文值得你花时间研究开阔一下视野也行。AIGC （AI-generated content）最近很多人关注的领域，我了解不多。不过最近 Geoffrey Litt 介绍了很多 IA /AIA 的文章和项目，让人好奇心上升。本周跟着 Geoffrey Litt 的视角，看一下 AI 的另一面 IA / AIA 。注意黄色的部分可以带你进入的兔子洞。
2022 年是大型語言模型(LLM)之年。这项技术已经足够好，可以做很多有用的事情，而且进步的速度是惊人的。我正在努力跟上所有的变化，并思考 AI 如何适应最终用户编程（end-user programming）。
我对 AI 辅助我编程的观点改变了
在我的日常编程工作中，我每天都使用 GitHub Copilot。我还经常问 GPT-3更多关于编程和其他主题的开放式问题，并发现它在许多情况下比 Google/Stack Overflow 更有用。三年前，我确信语言模型需要很长时间才能变得对编程有用，我期望传统的程序综合方法能够在一段时间内保持它们的优势。我现在得到了痛苦的教训。如果你还没有跟上进度，还和我 3 年前一样。
- 我建议你通过浏览 Riley Woodside 的 Twitter 消息
- 然后在免费的 GPT-3上复制他的一些例子，调试一下他们的 API 来获得一些直觉，淘宝搜搜OpenAI。
最新的 GPT-3 模型相当不错，你知道如何正确地与它对话，那么它确实类似于人的软推理，尽管有明显的缺陷。
最大的学习障碍和人类的梦想
显然，AI 在帮助非程序员开发和定制软件方面有着巨大的机会。
让计算机运行的最大障碍之一是学习用传统的编程语言编写代码，这些语言有着严格的推理和精细的语法。
人们已经思考了很长时间的方法来解决这个问题。
几十年来，人们一直在追求这样一个梦想: 让用户演示一些示例，然后自动创建程序。
通过演示进行编程背后的动机是简单而引人注目的。
如果用户知道如何在计算机上执行任务，这应该足以创建一个程序来执行任务。
学习 C 或 BASIC 这样的编程语言是没有必要的。
相反，用户应该能够指示计算机“观察我做什么”，计算机应该创建与用户行为相对应的程序。
来自 Allen Cypher in Watch What I Do: Programming by Demonstration
不过，这方面的进展相当缓慢，从实例中很好地归纳出结论是一个非常困难的问题。
Microsoft Excel 中的 Flash Fill 是这个领域的一个重大突破，可以关注一下
Tools vs machines
我认为“工具”和“机器”之间有一个模糊但有用的区别。
当谈到 AI 时，我更感兴趣的是使用 AI 来增强人类的能力，而不是人类已经能够做的廉价的自动化任务。在这方面可以阅读一个论文《Using Artificial Intelligence to Augment Human Intelligence》，作者们把这个想法称为“人工智能增强”，简称 AIA。我认为这是一个很好的词。也可以读另一本书《How To Become A Centaur》。AIA 的总体是: 人类坐在驾驶座上，精确地使用工具，但是由人工智能能力支持。
本刊前几期推荐的人物 Linus 最近发布了一些演示，通过拖动一个滑块来改变文本摘要的长度或情感基调，我认为这与“工具”而不是“机器”的含义类似。
人工智能可以帮助从凌乱的原始文本数据中提取结构化数据，但仍然让用户自己决定在结构化数据上运行什么类型的计算。这种原则也可以在 Nardi, Miller 以及 Wright 在 invented data detectors at Apple 中所说的。
我们试图找到一个中间立场，使用用户相关信息的明确表示作为识别用户可能希望采取的操作的手段，但将这些操作的选择留给用户。
最近我一直在使用一个很棒的视频编辑应用程序，叫做 Descript，它可以让你通过编辑文本文本来编辑视频。这显然是一个增强我能力的工具，当我使用这个软件的时候，我在编辑演讲数量级上会更快，而且它可以实现全新的工作流。但是它也建立在一个看起来非常机械化的功能之上: 自动将视频转录成文本，这个任务过去需要大量的人力。也许 Descript 的例子表明“自动化去除乏味的部分”是制作支持人类能力的工具的可靠方法，但是对我来说什么才是乏味的部分并不明显。如果我写一个句子总结，自动扩展成一个完整的博客文章，这是一个工具还是一台机器？我对这些事情有本能的看法，但是我担心过于相信这些本能。 我不想成为一个在数学课上反对计算器的老家伙。
解释器和编译器
似乎有 2 种使用 LLM （大型語言模型）的方式
- AI as fuzzy interpreter：给出指令，就让人工智能直接为你做事。
- AI as compiler：让人工智能用 Python、 JavaScript 或任何你可以运行的语言编写代码。
这里存在着严重的权衡。人工智能可以进行软推理，这在传统代码中基本上是不可能做到的。不需要处理烦人的编程，只需要写指令，然后让它运行。
另一方面，依赖人工智能更加困难ー当你给它新的输入时，或者当模型发生变化时，会发生什么？与运行传统代码相比，运行人工智能推理的速度更慢，成本也更高(Andrej Karpathy Software 2.0 文章更深入地讨论了这些权衡)。这里有一个“只要使用 AI”方法的很好的例子: 将 GPT 提示作为“公式”直接输入到 Google Sheets 中。效果很好。
写代码的未来和思考
我很好奇我们将在哪里看到这两种技术的使用。我预计，随着模型和提示技术变得越来越成熟，未来几年的可靠性将大幅提高，但最后5% 至10% 的可靠性将非常困难。任何90% 准确率足够好的地方都可以直接运行人工智能，但是99% 以上的准确率可能会在一段时间内受益于代码生成。我怀疑这意味着，在任何已经使用代码的领域，代码将在一段时间内保持主导地位，即使它越来越多地由人工智能生成。
撇开可靠性不谈，将代码作为一个结构清晰的基建，让人类和 AI 可以一起迭代，似乎也有很多好处。如果人们不那么多地手工编写代码，那就意味着编程语言可以朝着比从头开始编写更容易阅读和编辑的方向发展。在这个领域中，我最喜欢的交互思想之一来自于一篇论文，User Interaction Models for Disambiguation in Programming by Example。其思想是 AI 生成一个基于用户规范的程序，然后向用户展示用自然语言语法编写的程序的描述。它还显示了可以在程序的不同部分编写的替代代码，并允许用户直接在选项中进行选择。
我喜欢这种方式，它能让人们清晰而直接地推理所期望的行为，同时还能从模糊推理中得到很多帮助。看看编程语言是如何演变以支持更容易的阅读、编辑和验证，而不是总是从头开始编写，这将是一件有趣的事情。
推荐