Prompt 设计
提示词设计就像网页设计。让我们称之为 prompt 设计,并为其构建更好的工具。
发布者Arvid
5分钟阅读
我通常不喜欢将旧世界的类比应用于新世界现象的常见习惯。所以请容忍我犯下这个确切的“罪行”:请允许我阐述为什么应该将提示称为prompt 设计,并将其比作网页设计。
我将提示视为与时间受限的人类进行沟通。虽然特定于 LLM 的技术当然很有帮助(最值得注意的是思维链),但我发现提高性能的最佳方法之一就是拥有极其清晰和高质量的指令,就像清晰和简洁也有助于真人更好地理解一样。
提示即清晰沟通让提示听起来像写作。然而,我所做的大部分提示都是参数化的:我有很多输入变量,并且需要动态地调整我的提示以适应这些变量。
因此,提示即清晰沟通且带有动态输入感觉是最准确的描述。
还有哪个领域是关于与动态输入进行清晰沟通的?网页设计。
让我们列出所有相似之处。Prompt 设计和网页设计都
- 需要清晰度,并将沟通作为主要目标;
- 需要响应动态内容,这与写作或杂志排版不同;以及
- 需要使其内容适应不同尺寸——网页设计的屏幕尺寸,提示的上下文窗口。
根据我进行 prompt 设计和网页设计的经验,我还发现我在这两个领域有相似的开发者偏好
-
查看实际的 prompt 非常重要,就像查看渲染后的网站非常重要一样。如果我必须在脑海中模拟 HTML 和 CSS 渲染过程,我就无法设计网站。同样,如果不查看填充了所有输入变量的 prompt 的渲染输出,就很难编写良好且清晰的 prompt。
- 例如,prompt
"Hi ${username} ${message}"
看起来可能合理,但当您渲染它并意识到用户名与消息混在一起时,就会发现问题。
- 例如,prompt
-
可组合的组件在 prompt 设计和网页设计中都很有用。
-
对于两者而言,声明式都比命令式更好。要更改一个所有 HTML 元素都使用
document.createElement
调用创建的网站,真的很难。同样,读取和更改一个由一长串str += "..."
组成的 prompt 也很容易变得难以管理。 -
在这两者中,我有时都想实现“像素完美”。当提示能力较弱的模型(GPT-3.5 及更低版本)时,我想确保我没有多余的换行符或其他类型的不完美格式,而在设计网站时,有时每个像素都很重要。
对于 LLM 代理,可以将类比进一步延伸:代理 prompt 可以看作是为代理构建一个交互式网站,他们可以通过调用函数来“点击按钮”,并且 prompt 会响应函数调用而重新渲染,就像网站响应按钮点击而重新渲染一样。
当然,prompt 设计和网页设计之间也存在差异
- Prompt 设计目前只处理文本!(目前是这样!)
- 缓存是不同的:特别是对于代理,您需要确保您的重新渲染是廉价的,方法是仅更改 prompt 的后面部分。这里有一个人为的与网络的平行之处(您希望缓存优化您的网站),但我认为这从根本上来说是一个非常不同的挑战。
尽管如此,这些相似之处使我相信 prompt 应该被称为 prompt 设计,而不是 prompt 工程。编写 prompt 感觉就像设计网站,因此也应该以相同的方式命名。
prompt 设计的视角启发我创建了 Priompt,一个类似 React 的、基于 JSX 的 prompt 设计库。
Priompt v0.1:提示词设计库的首次尝试
Priompt 是首次尝试创建一个受现代网页设计原则启发的 prompt 设计库。我们在 Anysphere 内部使用它,我们非常喜欢它。
我认为它可能在其所有抽象中并非完全正确,但我至少相信 JSX 是一种比字符串模板更符合人体工程学的编写 prompt 的方式。即使是能够轻松注释掉 prompt 部分这样的简单事情,也使迭代循环快得多。
Priompt 还附带一个(非常仓促拼凑的)预览网站,您可以在其中使用真实数据预览您的 prompt。在开发应用程序时,您可以记录每次请求时进入组件的序列化 props
。然后,当您看到意外行为时,您可以转到 Priompt 预览,查看确切的 prompt,并更改源代码,并让 prompt 使用与真实请求相同的 props
进行更新。我们发现这使得迭代 prompt 变得更容易
如果您尝试使用它,请告诉我您的想法!我很想看到更多类似的想法,或者只是被告知我完全错了,prompt 设计很愚蠢 :)。
注意事项
模型变化很快,提示技术也必须如此。考虑到这一点,我认为对 prompt 设计 的描述有一些注意事项
- 像素完美的设计对于 GPT-4 并不重要,并且对于 GPT-4.5 或更好的模型可能会过时。
- 如果人们推断最近的长上下文模型的趋势,上下文窗口的限制可能会消失。但我对此并不确信。
- OpenAI 似乎正在朝着减少开发者对 prompt 的控制的方向发展;可能在一年后,将不再有 prompt 这种东西,API 调用只是要求我们提供原始输入加上指令。这种减少控制的趋势始于聊天格式,并随着最近宣布的函数调用而继续。
- 缓存可能是 prompt 最重要的方面之一,在这种情况下,它开始听起来更像是工程而不是设计。
- 也许 prompt 设计太底层了,应该留给更高级别的框架或编译器(例如 langchain)。我认为这可能是真的,但考虑到 LLM 的快速变化性质,我个人更喜欢尽可能接近原始模型。
必须的最后说明
...因为我希望与您合作:在 Anysphere,我们正在构建 Cursor,一款 AI 优先的代码编辑器。如果您对 prompt 设计、用于编码的 LLM 或构建精美产品感到兴奋,请发送电子邮件至 arvid@anysphere.co 联系我。我们在旧金山有 5 个人,我的所有同事都很出色,我们希望更多优秀的人——程序员和设计师——加入我们,共同构建编码的未来。