PDF虚拟的计谋：将大型语言模型用作神经计算机
大型语言模型不仅可以作为数据库发挥作用，还可以作为动态的、最终用户可编程的神经计算机。
Erik Meijer
许多人将大型语言模型（LLM）视为压缩世界知识的数据库。就像数据库一样，它们为给定的用户查询提供答案。与关系数据库中的行和列不同，LLM的知识被编码到数十亿（甚至数万亿）的权重中，这些权重在预训练和随后的微调过程中学习得到（见图1）。此外，LLM不是使用像SQL这样的合成语言进行查询，而是直接由用户查询，用户可以通过自然语言对话与它们互动。
LLM内部查询引擎的概念等价物是下一个token预测函数 next ∈ token* → ℙ(token)，它计算下一个可能token的概率分布 next(q) ∈ ℙ (token)，给定一个初始的token序列 q ∈ token*。正是下一个函数的这种概率性质使得能够产生多样化和创造性的响应，从而将LLM与提供确定性答案的传统数据库区分开来。在本文的上下文中，token可以代表模型摄取或生成的项目序列中的任何原子单元。这些单元可以包括LLM处理的模型词汇表数组中的索引，以及任何更高级别的实体，如单词和句子，或者更一般地，从聊天对话中导出的任何 用户、助手 或 系统 消息。
虽然使用 next 预测单个token构成了LLM推理的基础，但完整的完成函数 LLM ∈ token ∗ → ℙ(token*) 将此过程扩展到多个token的概率生成，以允许对给定的提示进行全面的响应。LLM 算法的实现依赖于各种采样启发式方法，有时称为解码，例如贪婪搜索、束搜索或随机采样，以提供比仅选择最高概率选项更有趣的答案。可以使用超参数（如温度、频率和存在惩罚、logit 偏置、top-p 和 top-k）来控制此采样过程。也可以基于一组给定的停止 token 提前终止完成。3
如果我们从模型呈现概率的能力中抽象出来，我们可以将 next 和 LLM 简单地表示为非确定性函数 next ∈ token* → {token}, 分别是 LLM ∈ token* → {token∗}，或者等效地表示为二元关系 next ⊆ token∗ × token 和 LLM ⊆ token∗ × token∗。然后，我们可以使用大步语义表示法17描述它们的非确定性计算行为。在这种情况下，有两个求值关系
• q 
t
这表示 t ∈ next(q) 或 (q, t) ∈ next （即，t 是给定初始 token 序列 q 时由 next 生成的下一个 token）。
• q 
r
这表示 r ∈ LLM(q) 或 (q, r) LLM （即，r 是 LLM 为提示 q 生成的答案）。
使用大步语义，我们可以简洁地解释 LLM 如何使用 next 生成更长的 token 序列，如下所示
• 要么 LLM 函数停止生成新的 token——例如，因为下一个预测的 token 将是停止 token，因为已达到输出 token 限制，或者仅仅是因为生成已完成
• 或者，从上到下阅读，它自回归地从先前的序列 q 扩展了由 next(q): 预测的 token t 的序列中生成新的 token：
这两个公式在一个很小的空间中包含了很多操作信息，这就是我们喜欢大步语义的原因。
使用虚拟内存的动态数据访问
无论 LLM 有多少权重，总会有超出范围的知识，因为它没有或无法存储在权重中
• LLM 在静态数据集上进行训练，这些数据集仅包含在数据收集被切断的特定时间点之前收集的数据。例如，如果我们询问模型
用户：帕洛阿尔托现在的温度是多少？
它会回复类似以下内容
助手：很抱歉，但我无法访问实时信息或提供当前的最新天气情况，
从而明确承认模型权重中不存在当前天气的知识。LLM 并非总是如此表现良好，并且经常产生听起来合理但没有根据的幻觉答案，而不是简单地说它们不知道。这种捏造回应的倾向是在使用 LLM 时的一个显著挑战。
• 对于诸如聊天机器人之类的应用程序，我们需要跟踪用户和模型之间的对话历史 (用户; 助手)∗。如果不保留上下文，就不可能进行多轮对话，而这正是使基于 LLM 的聊天界面引人注目的原因。显然，这是另一种存在于模型训练数据的时间范围之外的数据。
• 隐私敏感信息和具有访问限制的数据都不应直接编码到模型的权重中，因为这会有效地使该数据成为模型公共知识库的一部分，从而以不受控制的方式泄漏此信息。此外，访问限制可能会随时间变化或需要更新，这与已训练模型权重的静态性质相矛盾。每次其训练数据被 chmod-ed 时都重新训练模型是不切实际的。
幸运的是，我们可以通过模型的输入上下文动态加载附加信息，并要求模型将其考虑在内，而不是在训练期间静态地将信息摄取到模型的权重中，如下所示：4
用户
根据以下信息回答问题
截至太平洋标准时间上午 7:30。沿海洪水警报。
今天。55°/39°。2%。周四 11 | 白天。55°。2%。
西北风 6 英里/小时。开始时阳光明媚，
然后下午有一些云。
问题：帕洛阿尔托现在的温度是多少？
基于提供的上下文，模型现在能够回答当前的天气状况
助手
根据提供的信息，截至太平洋标准时间上午 7:30，帕洛阿尔托的当前温度为 55°F（华氏度）。
虽然通过模型的上下文提供动态信息效果良好，2 但 LLM 的上下文容量从根本上是有限的。截至 2024 年初，广泛生产的最大模型的输入上下文为 200K 到 128K 个 token，输出上下文为 4K 个 token，或者它们在整个上下文中分配了 32K 个 token。即使有 200K 个 token，或大约 500 页印刷页，实际上也不可能仅在上下文中包含所有必要的动态信息。
将 LLM 的上下文与传统计算机的 RAM 进行比较（尽管它实际上不是随机访问，因为模型实际上似乎更关注其输入的开头和结尾10），我们可以从传统操作系统中借鉴虚拟内存的想法。
虚拟内存通过在二级内存和 RAM 之间“分页”相关信息来提供无限内存的错觉。操作系统分析内存访问模式，并预测近期可能需要的页面，以决定要换入和换出哪些页面。我们也可以完全做同样的事情，以找到要加载到 LLM 上下文并从中驱逐的“块”来回答下一个问题。这称为 RAG（检索增强生成）。6 图 2 显示了使用 RAG 作为虚拟内存。
实现 RAG 的常用技术是计算用户查询的嵌入1，并使用它在向量数据库21（用作二级存储）中查找最佳匹配信息，以包含在上下文中。嵌入的一个有用的心智模型是语义敏感哈希，它将高维数据（如文本和图像）映射到低维向量，使得语义相似的项目被映射到嵌入空间中几何上接近的向量。
作为指令分发的动态工具调用
当前天气不是从二级存储通过 RAG 获取数据的最佳示例，因为它变化太快。为了访问需要实际计算而不是检索的实时（或瞬时）信息，模型应该能够使用外部“工具”（见图 3）。这些工具可以查询数据库或充当外部服务或 API 的接口，从而允许模型根据调用这些工具所需的实际参数（由模型本身生成）来摄取动态和上下文特定的信息。
如果这些工具中的任何一个由另一个 LLM 支持，则通常称为多代理系统。这有点自命不凡，因为我们不会将使用多个对象的传统 OO（面向对象）程序称为多对象系统。
基于模型作为数据库的类比以及 LLM 是关系的事实，7 我们也将工具建模为关系，因为它们可以使用模型本身来实现，或者通常是非确定性的或不确定的。例如，我们可以将给定城市的当前天气视为二元关系，如表 1 所示。
当推理调用工具 f 时，我们使用大步表示法 e 来表示 
vv ∈ f(e)，将工具 f 视为（非确定性）函数，或者等效地 (e, v) ∈ f，将工具视为关系。在这两种情况下，我们都说工具调用 f(e) 返回了 v。例如，根据表 1，工具调用 WEATHER("Palo Alto") 可能会返回 "下雨，40°F"，这在大步表示法中看起来像这样
大多数支持使用工具的语言模型将它们作为函数公开，15 但我们认为关系比使用函数提供更强大、更灵活和更直观的框架。
将工具调用集成到 LLM 交互中的一种流行技术是 ReAct（Reason+Act）方法，23 它在给定一组可能的工具的情况下，引导模型循环执行一系列解释和工具调用，以得出最终答案。这是一个可能的基于关系的 ReAct 风格的交互序列，其中用户询问当前天气，模型幻觉（灰色部分）工具调用以计算答案
系统
... 定义 WEATHER 工具的提示
用户
帕洛阿尔托现在的天气如何？
助手
为了获取帕洛阿尔托的天气，我将使用天气工具 [WEATHER("Palo Alto", "下雨，40°F")]. 所以，帕洛阿尔托的天气是潮湿的，40°F。
然而，协调工具和 LLM 之间流动的推理引擎，在工具调用 [WEATHER("Palo Alto", "晴朗，75F")] 紧随其后的右括号处拦截 LLM 生成，从而有效地忽略了模型对其不实际知道的天气的思考。相反，我们调用 WEATHER 工具并找到 "晴朗，80°F" ∈ WEATHER("Palo Alto")。随后，我们要求模型从我们用正确的信息（粗体显示）中断它的地方继续
助手
我需要调用天气服务来获取帕洛阿尔托的当前天气。[WEATHER("Palo Alto", "晴朗，80°F")]
助手
帕洛阿尔托现在的天气晴朗，80°F。
在第二轮中，无需工具调用即可生成用户问题的最终答案，模型使用了来自外部工具的提供的信息来正确回答问题。
ReAct 的大步语义
ReAct 风格的推理可以被捕获，以通过一系列工具调用来生成用户问题的答案
使用大步语义如下
• 要么 LLM 完成查询而无需进行工具调用，在这种情况下，我们就完成了，可以将之前的工具调用与最终答案组合起来作为结果
• 或者，从上到下阅读，LLM 进行工具调用，如生成的 助手: [f(e, w) 所见证的那样。在这种情况下，我们忽略模型幻觉的建议 w，而是将正确的计算值 v ∈ f(e) 插入到迄今为止为 助手: (calls; [f(e, v)]), 执行的工具调用列表中，并递归以计算最终结果
对于这两个规则，我们假设工具调用的空序列意味着 助手 为空。
请注意，第二个推理规则如何很好地说明了 LLM 作为分支预测器的类比。给定查询 用户: 问题 和迄今为止由 助手: calls 执行的工具，LLM 预测下一个工具调用 [f(e, w)。然后我们实际调用该“指令” f(e) 来计算真实值 v，并使用 [f(e, v)] 继续执行。
传统分支预测器和神经分支预测器的主要区别在于，后者完全幻觉它一次执行一条指令的程序，而常规分支预测器预测已存在程序中要调用的下一条指令。
解决意外的模型干扰
将外部工具添加到 vanilla ReAct 方法的根本问题在于，它允许模型完全了解自身和工具调用之间浮动的值，从而导致对工具输出的潜在重新解释和更正。
如果模型基于存储在其权重中的知识“认为”从工具返回的值与其内部知识相矛盾，则它可以——并且将会——丢弃从外部工具获得的值。然后，模型将假设一个与其内部世界模型更一致的新值，并使用该值而不是工具调用返回的值。
例如，如果工具调用返回帕洛阿尔托天气的温度为 10000°F，则模型将假定该温度过高，并默默地将其替换为 100°F，它认为这更合理。
用户
帕洛阿尔托现在的天气如何？
助手 为了获取帕洛阿尔托的天气，我将使用天气工具 [WEATHER("Palo Alto", "晴朗，10000°F")]
助手
所以，帕洛阿尔托的天气晴朗，100°F。
我们添加工具调用的原因是修复模型无法执行某些计算或访问实时数据的问题。显然，当模型开始干预传递给工具和从工具传递的值时，就不可能在此类机制之上构建可靠的系统。
也许这个问题可以通过再次从传统计算机体系结构中汲取灵感来解决。传统的 CPU 通常使用寄存器到寄存器模型来指定指令，而不是处理立即值，其中操作数和结果都驻留在命名的寄存器中。我们可以使用相同的方法：为了防止模型解释它操作的值，我们只是不再给它值。相反
• 在外部推理引擎内部，我们维护一个环境，其中变量绑定到值（类似于寄存器集），并且模型在与外部工具交互时只允许处理变量的名称。
• 为了实现这一点，我们需要提示模型在调用工具时幻觉变量名：[WEATHER("Palo Alto", @weatherInCity)] 而不是像以前那样幻觉值 [WEATHER("Palo Alto", "下雨，20°F")]。
• 此外，由于模型计算出的答案现在可能包含模型不知道其值的变量，我们需要向模型的词汇表添加诸如 [@weatherInCity] 之类的表达式，以便它可以将原始问题的答案表述为这些不透明变量的表达式。推理引擎当然知道变量的值，因此只有当模型生成表达式时才能向用户显示它们。
• 在极少数情况下，模型实际上需要查看值才能生成其预测，我们可以以受控方式将这些值作为特殊的特权工具公开。
以下是客户端和模型之间使用我们新的变量传递方法来回答问题： 山景城和门洛帕克之间的天气如何？ 的 用户 和 助手 消息交换的记录
与之前一样，我们从描述可用工具集的 system 消息开始，但也指示模型提供一个变量来绑定每个工具调用的结果
系统
... 可用工具的描述 ...
为了响应用户关于当前天气的隐含问题，模型再次使用其内部知识来确定我们正在查找帕洛阿尔托的天气，但现在它使用幻觉变量 @weatherPaloAlto 调用该工具。
助手
山景城和门洛帕克之间的城市是帕洛阿尔托。
让我们找出那里的天气。
[WEATHER("Palo Alto", @weatherPaloAlto)
与之前一样，我们在右括号处停止生成。但是这次我们没有忽略模型的建议，而是使用变量 @weatherPaloAlto 并将其在推理引擎的环境中绑定到工具调用的结果 {@weatherPaloAlto = "晴朗，80°F"}。然后我们在不告诉模型调用结果的情况下通过仅关闭 ] 括号来恢复生成
助手
山景城和门洛帕克之间的城市是帕洛阿尔托。
让我们找出那里的天气。
[WEATHER("Palo Alto", @weatherPaloAlto)]
我们依赖于模型在其自身头脑中跟踪变量 @weatherPaloAlto 包含帕洛阿尔托的当前天气。
在下一轮中，我们在生成的表达式处停止生成，模型通过在先前步骤中绑定的变量 @weatherPaloAlto 向我们告知帕洛阿尔托的天气
助手
帕洛阿尔托现在的天气是
[@weatherPaloAlto
我们使用推理引擎来计算生成的表达式 @weatherPaloAlto 的值，将其显示给用户，用 ⇝ 晴朗，80°F 表示，但不显示给模型，然后通过关闭 ] 括号继续生成
助手
帕洛阿尔托现在的天气是
[@weatherPaloAlto]⇝ 晴朗，80°F
助手 .
最后，模型通过不生成任何进一步的工具调用来表示答案已完成。
操作语义
这是一个操作语义的示例，为简单起见，它仅返回最终修改的环境，并省略了跟踪的 用户 和 助手 标签。这些语义清楚地表明推理引擎如何在工具脚本解释器的调用中传递环境 σ，同时向模型隐藏任何值
• 当模型在没有工具调用或表达式的情况下响应时，我们就完成了，并立即返回当前环境不变。
• 当 LLM 建议评估表达式 e 时，我们在当前环境 σ 中执行它并将其显示给用户 (⇝ v)，然后继续执行以计算 σ′，而不向模型显示该值。
• 当模型想要使用工具 f(e,@x) 时，我们在推理引擎内部调用 f(e)，以便我们可以使用当前环境来查找值 v ∈ f(e)，并将其绑定到 @x 以创建更新后的环境，然后递归地使用该环境来生成计算的其余部分。
环境 σ 类似于传统 CPU 的寄存器集，它也将（寄存器）名称绑定到值。主要区别在于，在传统的 CPU 中，只有固定数量的寄存器，但诸如 ADD r3, r1, r2 之类的指令通常也对寄存器名称而不是立即值进行操作。
神经计算机
既然您已经了解了如何通过工具使用来扩展 LLM，让我们放大并重新定义模型拥有的工具集，将其视为一种“神经计算机”的指令集。
在这个类比中，ReAct 风格的工具调用拦截和分发（如先前所示的 ReAct 大步语义捕获的那样）反映了传统计算机的控制单元，该控制单元获取下一条指令，将其发送到 ALU（算术逻辑单元）以执行，传递操作数，并通过寄存器接收结果。然后，LLM 的作用实际上类似于传统 CPU 中的分支预测器，它预测最有可能执行的下一条指令，并由迄今为止执行的指令序列指导。
表 2 中总结的 LLM 和传统计算机之间这些惊人的相似之处强烈表明，与其将 LLM 视为美化的数据库，不如将其视为一种新型神经计算机的核心组件。
基于自然语言的推理语言
在“发明”了一种新型计算机之后，我们自然也需要一种新颖的编程语言，可以用来指示神经计算机。为此，我们选择了一种嵌入在自然语言注释中的（受限）形式的逻辑编程——从而闭合了现代生成式 AI 和老式符号 AI 之间的循环。9
让我们回顾一下之前的 ReAct 风格的交互序列，只是现在假设我们有一组抽象的工具 f, ... , g 可供我们使用。如果我们像在大步语义中所做的那样组合所有部分 助手: 响应，那么 ReAct 风格的交互对应于一个目标，该目标由谓词/工具调用序列与注释交织组成
用户
问题
助手
..., [f( ..., x, ...)], ..., [g( ..., y, ...)], ...
其中 x 和 y 是 @-变量上的项。
每个工具调用都是 LLM 的中断幻觉，提供了对模型在通过生成一系列工具调用和解释来回答给定问题时如何推理的“思想”的窥视。20
通过以外部化编程语言的形式（LLM 的心智语言5，可以这么说）来表达模型执行的这种内部推理，我们可以将 助手 跟踪视为模型从 用户 发出的自然语言问题中合成的源代码。
通过诉诸 Tennent 的抽象和参数化原则，19 然后我们可以给这些目标一个名称和参数 h( ..., x, ...)，从而得到 规则 的形式 ...[h( ..., x, ... )] ...:- ...[f( ..., y, ... )], ...[g( ..., z, ... )], ... 嵌入在自然语言解释中，其中 x, y, z 是 @-变量上的项。为了转义自然语言解释中的代码片段，我们使用 'hedges" [ 和 ]。 而且，瞧，我们（重新）发现了文学 Prolog，作为思维链的外部化推理语言。
这是一个具体的例子，说明如何在我们提出的推理语言中编写工具。假设我们想使用国家气象局预报 API13来实现 WEATHER(@city, @weather) 工具。完成此操作意味着要完成以下一系列步骤，这些步骤会调用更原始的工具
在 [@city] 中使用国家气象局 API :-
为了找到 [@city] 的当前天气，
我们首先需要通过 [GEO_CODE(@city, @lat, @lon)] 找到城市的坐标。
然后给定其 [@lat] 和 [@lon] 坐标，
我们可以调用 [WEATHER_GOV(@lat, @lon,
{... "forecast": @url ...})],
以获得预报 url [@url]
使用它可以最终获取
[HTTP_GET(@url, {... "detailedForecast"
@weather ...})] [@city] 的当前 [@weather]。
诸如 GEO_CODE(@city, @lat, @lon) 之类的原始工具是事实，它们是在传统的（命令式）编程语言中实现的。
有了这样的推理语言，用户不仅可以从头开始定义新工具，还可以采用模型之前生成的代码序列，并将其作为新工具应用于模型，从而创建一个自学习系统。此外，鉴于该语言是模型内部推理的语法，用户还可以使用它来提供少量示例，以指导模型如何使用工具。
使用 AI 赋能的形式化方法的安全性
确保超人 AI 系统造福人类，同时减轻意外风险是一项重要的优先事项。从编程语言中借鉴的一种有趣的确保 AI 安全性的方法是使用携带证明的代码。14,18 基本思想是用户定义（可能在模型的帮助下）AI 系统必须遵守的安全策略，然后，当模型生成代码时，它还必须提供生成的代码满足所需安全策略的证明。
由于我们的语言仅由 Horn 子句组成（就像一个简陋的依赖类型系统），因此用于编写程序的同一种语言也可以用于使用不变量、前置条件和后置条件来定义安全策略。通过保持语言的简单性，我们降低了模型证明代码属性的门槛，同时也使代码更易于进行形式验证。尽管证明非平凡规范的正确性具有挑战性，但预计模型能力将提高 10 到 100 倍，这表明未来的 AI 能力可以帮助用户创建规范并生成代码，以及其相应的形式正确性证明。这意味着 AI 最终可以使形式化方法和按构造正确的软件的梦想成为现实。
我们认为这提供了一种实用且可扩展的方法来实现 AI 安全性，即使是非技术用户也可以监控和执行 AI 模型创建的所有计算的逻辑正确性和道德合规性。强大的 AI 最终将使形式化方法和按构造正确的软件的梦想成为现实。
思维树
仍然需要解决的一个主题是如何处理模型生成的代码执行期间的错误。例如，如果 LLM 生成的表达式或语句无效、抛出异常或未能根据规范进行验证，会发生什么情况？发生这种情况的一种常见情况是模型为工具生成了错误的参数，或者没有将值转换为正确的类型，从而导致工具调用崩溃。
然而，大步操作语义仅指定终止和有效的运行。当错误在执行期间浮出水面时，根本没有导致最终结果的派生。例如，对于每个环境 σ，都没有相关的环境 σ′ 是由执行类型错误的数学表达式（例如
因为没有值 v 是由执行
没有派生信号表明计算由于错误或非终止而无法正常进行。
当实际将大步语义实现为在 LLM 和脚本解释器之间协调的推理引擎时，我们必须处理错误，因为我们不能依赖预言机来防止失误。搜索有效派生的显而易见的算法是对所有可能的派生使用回溯。特别是，每当模型建议的表达式或工具调用的执行失败时，最好总是回退并尝试生成替代方案。
回溯使我们的语言更接近 Prolog；唯一缺少的是真正的逻辑变量。然而，即使在纯 Prolog 中，逻辑变量也有些花哨。12 虽然在理论上反向运行谓词（例如，使用相同的代码拆分和追加列表）看起来很可爱，但由于对关系的操作约束（例如 @X is @Y+@Z，这需要 @Y 和 @Z 为值才能执行加法），规则中通常隐含着明确的方向。
由于我们依赖于丰富的外部定义工具集，即使规则是可逆的，这些约束也变得更加普遍。虽然我们可以想象将 STT(@speech, @text) 和 TTS(@text, @speech) 表示为单个可逆谓词，但通过反向运行 WEATHER(@city, @weather) 并使用 @city ∈ WEATHER(@weather) 来查找给定天气的城市是否实用则更值得怀疑。太多城市拥有相同的天气。
我们实现的 Prolog 子集传统上称为“固定模式”，具有清晰的输入和输出，并且所有输入都需要完全评估（不包含未实例化的变量），并且依赖关系严格地从左到右流动。这意味着我们不需要合一，而只需要单向模式匹配。虽然这些限制可以解除并且可以实现真正的逻辑变量，但我们尚未发现这种通用模型的任何实际用例。
相关工作
鉴于生成式 AI 的迅速普及，以类似于更传统的计算资源的方式使用 LLM 的概念已被不同程度地探索。Andrej Karpathy 关于 LLM OS 的推文8 引发了大量后续博客文章和论文，例如一篇关于 LLM 代理操作系统的文章。11 后者创建了一个抽象的多代理操作系统，其中操作系统的各种组件（例如调度程序和内存管理系统）使用 LLM 实现。Karpathy 最初的推文将 LLM 比作 CPU。MemGPT 系统16 为“处理器 LLM”添加了虚拟内存功能，但它使用函数调用来让模型自身决定如何在上下文和外部存储之间移动数据。我们更倾向于将 LLM 处理器与管理整体上下文的机制解耦。这实际上更类似于传统系统中虚拟内存的工作方式，在传统系统中，操作系统（而不是 CPU）管理虚拟内存。
我们方法的独特之处在于定义了一种在基于 LLM 的计算机或操作系统之上运行的推理语言。当然，这触及了更广泛的神经符号 AI 领域，该领域旨在将神经网络与符号推理相结合。
参考文献
1. Bengio, Y., Ducharme, R., Vincent, P., Janvin, C. 2003. 神经概率语言模型。《机器学习研究杂志》，3，1137–1155； https://dl.acm.org/doi/10.5555/944919.944966。
2. Brown, T. B., Mann, B., Ryder, N., Subbiah, M., Kaplan, J., Dhariwal, P., Neelakantan, A., Shyam, P., Sastry, G., Askell, A., Agarwal, S., Herbert-Voss, A., Krueger, G., Henighan, T., Child, R., Ramesh, A., Ziegler, D. M., Wu, J., Winter, C., Hesse, C., Chen, M., Sigler, E., Litwin, M., Gray, S., Chess, B., Clark, J., Berner, C., McCandlish, S., Radford, A., Sutskever, I., Amodei, D. 2020. 语言模型是少样本学习者。《第 34 届神经信息处理系统国际会议论文集》。第 159 条，1877-1901； https://dl.acm.org/doi/abs/10.5555/3495724.3495883。
3. Chip, H. 2024. 文本生成的采样； https://huyenchip.com/2024/01/16/sampling.html。
4. Dong, Q., Li, L., Dai, D., Zheng, C., Wu, Z., Chang, B., Sun, X., Xu, J., Li, L., Sui, Z. 2023. 上下文学习综述。arXiv:2301.00234； https://arxiv.org/abs/2301.00234。
5. Fodor, J. A. 1975. 《思维的语言》。纽约州纽约：Thomas Y. Crowell Co.
6. Gao, Y., Xiong, Y., Gao, X., Jia, K., Pan, J., Bi, Y., Dai, Y., Sun, J., Guo, Q., Wang, M., Wang, H. 2024. 大语言模型的检索增强生成：一项调查。arXiv 2312.10997； https://arxiv.org/abs/2312.10997。
7. Hernandez, E., Sharma, A. S., Haklay, T., Meng, K., Wattenberg, M., Andreas, J., Belinkov, Y., Bau, D. 2024. Transformer 语言模型中关系解码的线性性。arXiv:2308.09124； https://arxiv.org/abs/2308.09124。
8. Karpathy, A. 2023. LLM 操作系统。请耐心等待，我还在构思。X； https://x.com/karpathy/status/1723135784142979392。
9. Körner, P., Leuschel, M., Barbosa, J., Santos Costa, V., Dahl, V., Hermenegildo, M. V., Morales, J. F., Wielemaker, J., Diaz, D., Abreu, S., Ciatto, G. 2022. Prolog 五十年及其未来。arXiv:2201.10816； https://arxiv.org/abs/2201.10816。
10. Liu, N. F., Lin, K., Hewitt, J., Paranjape, A., Bevilacqua, M., Petroni, F., Liang, P. 2023. 迷失在中间：语言模型如何使用长上下文。arXi:2307.03172； https://arxiv.org/abs/2307.03172。
11. Mei, K., Li, Z., Xu, S., Ye, R., Ge, Y., Zhang, Y. 2024. AIOS：LLM 代理操作系统。arXiv 2403.16971； https://arxiv.org/abs/2403.16971。
12. Mellish, C. 1985. Prolog 编译器的一些全局优化。《逻辑编程杂志》2(1), 43–66； https://www.sciencedirect.com/science/article/pii/0743106685900044。
13. 国家气象局。API Web 服务文档； https://www.weather.gov/documentation/services-web-api。
14. Necula, G. C. 2000. 携带证明代码（摘要）：设计、实现和应用。在《第二届 SIGPLAN 声明式编程原理与实践国际会议论文集》中，175–177； https://dl.acm.org/doi/10.1145/351268.351289。
15. OpenAI。函数调用。OpenAI 平台文档； https://platform.openai.com/docs/guides/function-calling。
16. Packer, C., Fang, V., Patil, S. G., Lin, K., Wooders, S., Gonzalez, J. E. 2023. MemGPT：将 LLM 作为操作系统。《arXiv:2310.08560》； https://arxiv.org/abs/2310.08560。
17. Siek, J. 2012. 编程语言理论中的符号速成课程； https://siek.blogspot.com/2012/07/crash-course-on-notation-in-programming.html。
18. Tegmark, M., Omohundro, S. 2023. 可证明安全的系统：通往可控 AGI 的唯一途径。arXiv:2309.01933； https://arxiv.org/abs/2309.01933。
19. Tennent, R. D. 1977. 基于语义原则的语言设计方法。《Acta Informatica》8, 97–112； https://link.springer.com/article/10.1007/BF00289243。
20. Wei, J., Wang, X., Schuurmans, D., Bosma, M., Ichter, B., Xia, F., Chi, E., Le, Q., Zhou, D. 2023. 思维链提示引发大型语言模型的推理。arXiv:2201.11903； https://arxiv.org/abs/2201.11903。
21. Wikipedia。向量数据库； https://en.wikipedia.org/wiki/Vector_database。
22. Yao, S., Yu, D., Zhao, J., Shafran, I., Griffiths, T. L., Cao, Y., Narasimhan, K. 2023. 思维树：使用大型语言模型进行深思熟虑的问题解决。arXiv:2305.10601； https://arxiv.org/abs/2305.10601。
23. Yao, S., Zhao, J., Yu, D., Du, N., Shafran, I., Narasimhan, K., Cao, Y. 2023. ReAct：语言模型中推理和行动的协同作用。arXiv 2210.03629； https://arxiv.org/abs/2210.03629。
Erik Meijer 将罕见的技术专长和人员领导力融入了他最新的探索，即使用 AI 来普及终端用户编程。作为一位著名的计算机科学家、企业家和技术影响者，Meijer 在微软、Meta (Facebook)、乌得勒支大学和代尔夫特理工大学任职期间，为编程语言、编译器、云基础设施和 AI 做出了开创性的贡献。
版权所有 © 2024 归所有者/作者所有。出版权已授权给 。
最初发表于 Queue vol. 22, no. 3—
在 数字图书馆 中评论这篇文章
更多相关文章
Mark Russinovich, Ahmed Salem, Santiago Zanella-Béguelin, Yonatan Zunger - 智能的代价
LLM 容易产生幻觉、提示注入和越狱，这对它们的广泛采用和负责任的使用构成了重大但可克服的挑战。我们认为，这些问题是固有的，至少在当前这一代模型中是这样，并且很可能在 LLM 本身中也是如此，因此我们的方法永远不能基于消除这些问题；相反，我们应该应用“深度防御”策略来缓解这些问题，并且在构建和使用这些系统时，要假设它们有时会在这些方面失败。
Sonja Johnson-Yu, Sanket Shah - 你对 AI 一窍不通
长期以来，很难确定 AI 到底是什么。几年前，这样的讨论会演变成长达数小时的会议，绘制维恩图并尝试描绘出 AI 的不同子领域。快进到 2024 年，我们现在都知道 AI 到底是什么。AI = ChatGPT。或者不是。
Jim Waldo, Soline Boussard - GPT 和幻觉
这项实验的发现支持了这样一种假设，即基于 LLM 的 GPT 在更流行且已达成普遍共识的提示上表现良好，但在有争议的主题或数据有限的主题上则表现不佳。应用程序响应的可变性强调，模型依赖于其训练数据的数量和质量，这与依赖于多样化和可信贡献的众包系统类似。因此，虽然 GPT 可以作为许多日常任务的有用工具，但应谨慎解读它们对晦涩和两极分化主题的参与。
Mansi Khemka, Brian Houck - 面向开发人员的有效 AI 支持
将 AI 集成到软件工程师日常生活中的旅程并非没有挑战。然而，它预示着开发人员如何将他们的创造性愿景转化为有形解决方案的变革性转变。正如我们所见，GitHub Copilot 等 AI 工具已经在重塑代码编写体验，使开发人员能够更高效地工作，并将更多时间用于创造性和复杂的任务。从对工作安全的担忧到其在现实世界中的功效，围绕 AI 的怀疑态度突显了需要采取平衡的方法，优先考虑透明度、教育和伦理考量。
© 保留所有权利。