Prompt Engineering is for Transactional Prompting

Mitchell Hashimoto

提示工程面向事务性提示

原文由 Mitchell Hashimoto 发布,订阅该博客

每当谈起提示工程,我总会发现一个反复出现的困惑点,我认为这种困惑源于使用语言模型的两种截然不同的方式:交互式提示事务性提示。提示工程主要针对的是事务性提示,而当人们试图把它套用到交互式提示上时,就会产生大量的困惑甚至负面评价。

交互式提示就是像 ChatGPT 那样的用法,你与语言模型进行更像是一场对话的交流。如果模型返回的回答不够清晰,你可以利用已有的上下文进行澄清,引导模型给出正确的回应。而且,交互式提示主要由人来驱动。

事务性提示则更像是把语言模型当作编程语言中的一个函数:你给它输入,期望得到输出。这并不限于单次提示,你也可以串联多个提示,或是执行类似“智能体”的行为。关键在于,你是以事务性的方式,为某个非常具体的问题而使用语言模型,通常是大批量的、由软件驱动的。

这里假设你已经熟悉“提示”、“提示词”、“语言模型”等术语。如果你想了解这些术语以及提示工程的更多背景,请参阅我之前的文章Prompt Engineering vs. Blind Prompting

提示工程对两者都有帮助,因为从理论上讲,掌握提示工程的知识无论在哪种模式下都能让人更有效地从模型中获得想要的结果。不过,我认为提示工程的主要价值在于事务性场景。

提示工程的核心,是以最高的准确率和最低的成本从语言模型中获得期望的结果。这些目标本身就更契合事务性场景。


客观性与主观性

仅仅用交互式还是事务性来区分过程的性质,还不足以清晰地划分提示工程的价值。另一个可以切分的维度是客观性主观性

如果一个输入能够产生客观正确(甚至可以说“大体正确”)的输出,那么提示工程就能成功应用。具有客观正确答案的问题例如:信息抽取、分类、有限形式的代码生成等。

但如果一个输入产生的是主观上正确的结果,那么提示工程的作用就小得多。主观结果最典型的例子是艺术生成、写作、语义搜索等创造性任务。

就像你无法“设计”出一件客观上好或坏的艺术品一样,你也无法通过“提示工程”让 LLM 在主观任务上的表现达到客观意义上的好或坏。你可以通过提示工程来提高主观任务的输出被主观接受的概率,但无法像客观任务那样获得同等的确定性和准确率。

当然,你可能会指出,针对主观任务也存在许多广为人知的“提示模板”,它们确实有助于达成期望的结果。例如,就有能稳定生成特定风格艺术作品的模板。然而,得出这些提示模板的过程,与其说是工程或科学实践,不如说是创意写作的过程。

我认为“代码生成”就是一个兼具客观与主观的例子。理论上,代码生成可以是客观正确的:如果软件对其行为有足够精确的规约,那么软件能否通过规约是可以客观判定的。但现实中,几乎没有软件能达到这种精确程度。因此,代码生成的任务越大,就越主观;反之,任务越小,测试用例或输入语言就越有可能被精确定义,也就越客观1


客观的事务性提示

总体而言,无论手头是什么任务,掌握提示工程都能让人更有效地从语言模型中提取所需信息。不过,为交互式提示做提示工程,更像是成为一个高效的“搜索高手”(擅长使用 Google 搜索的人),而为事务性提示做提示工程,则更接近于成为一名数据科学家。

提示工程试图将 LLM 变成一个客观、可预测、事务性的 API,就像程序会调用的其他各类 API 一样,例如支付接口、进程内函数调用、SaaS 调用等。当然,语言模型并非确定性的、百分之百可靠的机器,因此其用途和使用场景必然有所不同。

总而言之,提示工程并不适用于所有与语言模型的提示交互。有些交互更具创造性,不那么依赖数据或方法论。但同样,也存在一些语言模型的使用场景,运用工程化的方法能够取得最佳效果。两者并存,互不否定。

还有一个需要特别澄清的点,是写作本文时正兴起的“智能体”。有人可能会说,智能体是与语言模型进行自动化、交互式处理的过程。严格来说,确实如此。但在我看来,智能体的使用在本质上仍是事务性的:你交给智能体一个任务,然后等待结果(这个结果可能是客观正确的,也可能不是)。由于智能体的使用具有大批量、由软件驱动的事务性特征,因此可以对其应用提示工程。

脚注

  1. 代码生成本身就是一个足够写一篇独立博文的大话题,但我认为,未来使用语言模型为更大、更复杂的软件生成代码时,缺乏精确规约将是主要挑战。如今我们已经看到智能体通过迭代代码来通过人工编写的单元测试,从而生成可运行的简单程序。也许未来会重新激发测试驱动开发(TDD)运动。当然,程序合成、程序规约和程序证明本身就是一个非常丰富的学术研究领域,或许未来也会出现思想上的融合。也可能已经出现了,只是这并非我持续关注的研究方向。无论如何,未来值得期待!

本文章由 muse-spark-1.2-contributor 进行翻译

评论