🤖 AI

Empirical Computation: Prompting versus Programming

这篇愿景论文提出了“经验计算”（empirical computation）这一新范式，即大型语言模型通过提示词而非传统编程来解决计算问题，并指出其独特的能力与局限性要求软件工程界开发新的基础理论与技术，以分析其正确性及根本边界。

原作者： Eric Tang, Jing Liu, Marcel Böhme

发布于 2026-07-08

📖 1 分钟阅读☕ 轻松阅读

原作者： Eric Tang, Jing Liu, Marcel Böhme

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你有两种完成工作的方式：编程 (Programming) 与 提示 (Prompting)。

旧的方式：编程（严谨的建筑师）

把传统的编程想象成雇佣了一位严格、按部就班的建筑师。你给他们一份蓝图，上面有精确的尺寸、特定的材料和一步步的计划。

运作方式： 你告诉计算机如何精确地解决一个问题，比如对一组数字进行排序。你会说：“使用这个特定的算法（归并排序），取这些输入，并遵循这些规则。”
结果： 如果建筑师犯了错，你可以找到蓝图中出错的那块砖，修复它，并确信下次建筑一定会稳固。
局限性： 建造所需的时间取决于数学的复杂度。对一个巨大的列表进行排序所需的时间是可预测的，其时间复杂度为 $O(n \log n)$ 。

新的方式：提示（直觉敏锐的艺术家）

现在，想象你雇佣了一位才华横溢、直觉敏锐的艺术家。你不需要给他们一份蓝图。你只需说：“嘿，这里有一堆乱七八糟的数字，你能帮我排序吗？”

运作方式： 你使用自然语言（即“提示词”）来描述问题。这个“计算机”（大型语言模型或 LLM）并不遵循一套严格的规则。相反，它根据在互联网上读过的所有内容，来猜测最可能的答案。这就像一位厨师通过品尝汤的味道来猜测食材，而不是遵循食谱。
结果： 答案很快就会返回，但它是一个猜测，而不是一个保证。它是“最可能的”答案，而不是“被证明正确的”答案。

论文的发现：令人惊讶的“经验主义”发现

论文作者进行了实验，观察这种“直觉敏锐的艺术家”在处理经典数学问题（如数字排序或在列表中查找项目）时的表现。以下是他们的发现：

1. 时间并不以同样的方式运作

编程： 如果你将需要排序的项目数量增加一倍，所需的时间会以特定的数学方式增长。
提示： LLM 排序数字所需的时间随着列表变大呈线性增长（即一条直线）。这不是因为数学变得更难了，而是因为 LLM 需要阅读和写入更多的单词（Token）来处理更长的列表。这就像读一本更长的书，所需时间增加是因为要读完更多的文字，而不是因为故事本身变得更复杂了。

2. 准确率随规模扩大而下降

编程： 一个正确的程序永远是 100% 正确的。
提示： LLM 在处理小任务时表现出色，但随着列表变长，它会感到困惑。
- 对于一个包含 50 个数字的列表，LLM 的正确率约为 90%。
- 对于一个包含 150 个数字的列表，它的正确率仅为 58%。
- 如果你要求它在一个短字符串中寻找特定模式，一旦字符串稍长，它可能几乎会立即失败。
- “思考”模式： 当允许 LLM 在回答前进行“思考”（即逐步推理）时，它的准确率保持得很高，但所需的时间也大大增加了。

3. 语言游戏

编程： 无论你用英语还是德语编写代码，计算机读取符号的方式都是一样的。
提示： LLM 会受到它在互联网上阅读内容的偏见影响。
- 如果你要求 LLM 排序以英文单词形式呈现的数字（“one, two, three”），它做得很好。
- 如果你要求它排序以德文形式呈现的数字（“eins, zwei, drei”），它几乎完全失败了。
- 为什么？ LLM 在互联网上见过数百万个英文示例，但看到的德文示例却少得多。这就像请一位厨师去做一道他从未见过的菜；他可能会猜错。

4. “坏掉的砖块”问题

编程： 如果一个程序失败了，你可以找到 Bug，修复代码，然后问题就永久解决了。
提示： 如果 LLM 给出了错误答案，你无法轻易找到其中的“Bug”。你不能指向某一行代码去修复它。你可能会尝试改变提示词，或者要求它“再思考一下”，但这并不能保证下次一定会奏效。这就像试图通过改变做梦者的心情来修复一场梦境一样。

核心启示

论文指出，我们正在进入一个被称为**“经验计算” (Empirical Computation)** 的新时代。

在旧世界里，我们信任计算机是因为它们遵循严格的规则（理性主义框架）。在这个新世界里，我们信任计算机是因为它们基于数据做出“受过教育的猜测”（经验主义框架）。

作者呼吁软件工程师不要再试图用分析传统程序的旧方法来分析这些 AI 系统。我们需要新的工具来衡量、测试和理解这些“猜测机器”是如何工作的，因为旧的数学和逻辑规则已不再完全适用。我们需要弄清楚，如何去信任一个“大概正确”而非“绝对正确”的结果。

技术摘要：经验计算：提示词工程与编程

问题陈述

本文指出，在解决计算问题时正在发生一种范式转移：从编程（指定精确的算法和数据结构）转向提示词工程（向大语言模型或智能体提供非正式的自然语言描述）。传统的计算依赖于确定性的过程，具有可验证的正确性和明确的复杂度界限（例如，排序的 $O(n \log n)$ ），而“经验计算”（Empirical Computation）则依赖于从概率分布中采样输出。

核心问题在于，这种新形式计算的能力和极限无法在计算机科学经典的理性主义框架内得到理解。具体而言：

缺乏确定性： 输出不是通过程序化生成的，而是“经验上最可能的”结果，这使得它们容易受到幻觉和错误的影响，且这些错误无法通过传统的调试手段进行定位或修复。
输入存在歧义： 与需要正式契约（类型、格式）的编程不同，提示词接受非正式输入，其解释取决于上下文以及模型的训练分布。
复杂度不明： 运行时的行为似乎与经典的计算复杂度脱节，转而与分词（tokenization）和模型推理行为相关。
验证鸿沟： 现有的软件工程（SE）技术（静态分析、形式化验证）难以分析那些不存在显式程序的系统。

研究方法

作者进行了初步实验，以表征经验计算在五个经典计算问题上的效率和正确性：

排序： 随机数字的升序排列。
搜索： 在已排序和未排序的列表中查找索引。
最长回文子串： 在字符串中寻找最长的回文序列。
子集和问题 (SSP)： 寻找一组数字，使其总和等于目标值。

实验设置：

模型： 实验使用了在 MacBook Pro (M5 Pro, 48GB RAM) 上本地运行的开源权重模型 gemma-4-26b-a4b，以消除网络延迟。
配置： 测试了三种模式：
- 默认模式 (Default)： Temperature = 1.0。
- 确定性模式 (Deterministic)： Temperature = 0.0。
- 思考模式 (Thinking)： 启用推理模式。
指标：
- 效率： 求解时间及获得第一个正确解的时间。
- 正确性： 返回数学正确答案的试验比例。
变量： 输入规模 ( $n$ )、数值精度以及语言表示（各种语言中的数字 vs. 文字：英语、德语、韩语、日语等）。
基准真相 (Ground Truth)： 对于非平凡问题（子串、SSP），使用简单的 Python 程序生成正确答案用于验证。

关键结果

1. 效率与经典复杂度的关系

与经典理论相反，经验计算的运行时并不严格遵循问题的算法复杂度（例如， $O(n)$ 与 $O(n \log n)$ 的区别）。

线性缩放： 对于排序、搜索和 SSP，求解时间在所有模式下都随输入规模呈线性增长 ( $O(n)$ )。作者将其归因于输入/输出 token 数量的线性增加，而非计算逻辑本身的复杂度。
Token 依赖性： 增加一个数字所需的时间与预测 SHA-512 哈希值的明文相当，这表明运行时是由分词和推理机制驱动的，而非问题难度本身。
思考模式的成本： 启用“思考”（推理）显著增加了运行时间（例如，对 150 个元素进行排序可能耗时高达 275 秒），但保持了较高的正确性。

2. 正确性与输入规模

规模敏感性： 在默认和确定性模式下，随着输入规模的增加，正确性迅速下降。
- 对于排序 50 个整数，正确性降至约 50%（相当于抛硬币的概率）。
- 对于排序 150 个整数，尽管时间呈线性增加，但正确性降至约 58%。
- 对于子集和问题，长度为 10 的列表正确性趋于零。
- 对于子串问题，字符串长度为 5 时，正确性几乎降为零。
思考模式的韧性： 当启用推理能力时，即使对于较大的输入，正确性仍能保持在高水平（>90%），但受限于 token 和时间限制。

3. 自然语言表示的影响

研究调查了用于表示数字的语言如何影响正确性。

数据表示偏差： 正确性高度依赖于该语言在模型训练数据中的表示情况。
高 vs. 低表示率： 使用英语（高表示率）书写的数字进行排序，在规模为 20 时正确率超过 95%。相比之下，使用德语（低表示率）书写的数字进行排序，在相同规模下正确率不足 1%。
结论： 经验计算并非语言无关的；它偏向于在训练语料库中普遍存在的语言和格式。

4. 错误特征

与故障可以定位到特定代码行的传统程序不同，经验计算中的错误是非确定性的。LLM 可能会：

添加输入中不存在的数字。
移除输入中存在的数字。
产生重复数字。
未能完成整个列表的排序。
截断大型输入。

核心贡献

定义了经验计算： 本文正式引入了“经验计算”这一概念，将其定义为一个通过提示词和采样而非程序化执行来生成解决方案的独立领域。
经验特征刻画： 提供了首次对 LLM 解决经典算法问题的效率和正确性进行的系统性测量，揭示了运行时与算法复杂度无关，而是与分词相关。
识别了局限性： 研究表明，在没有推理模式的情况下，经验计算无法可靠地随输入规模扩展，并且对输入的语言表示高度敏感。
对新软件工程基础的呼吁： 作者认为，软件工程界必须开发新的工具进行“经验程序分析”（统计、反事实或因果推理），以分析、估计并预测这些系统的正确性。

意义与愿景

本文认为，软件工程界无法依靠经典的理性主义框架或现有的程序分析工具来确保 AI 驱动计算的可信度。随着 LLM 和智能体成为解决计算问题的核心，该领域必须演进以应对以下问题：

如何在缺乏正式程序的情况下分析正确性。
如何定义并测试经验计算的极限。
如何在不引入回归（regressions）的情况下提高特定问题实例的正确性。

作者将此视为一个及时且丰富的研究领域，敦促开发“经验程序分析”技术，以弥合 LLM 的概率本质与软件工程严苛需求之间的鸿沟。本文并非声称解决了这些问题，而是旨在建立该领域并强调建立新理论与实践基础的紧迫性。