A Prompt Pattern Catalog to Enhance Prompt Engineering with ChatGPT
-
ArXiv URL: https://arxiv.org/abs/2302.11382v1
-
作者: Henry Gilbert; Carlos Olea; Jules White; Quchen Fu; Sam Hays; Michael Sandborn; Jesse Spencer-Smith; Ashraf Elnashar; Douglas C. Schmidt
-
发布机构: Vanderbilt University
软件模式与提示模式的比较
本文提出，大型语言模型（LLM）输出的质量直接取决于用户提供提示（Prompt）的质量。提示是一种对LLM进行编程的形式，通过设定上下文、规则和期望的输出形式，可以定制化LLM的行为和输出。因此，本文引入了提示模式（Prompt Patterns）的概念，旨在系统化地记录与LLM交互时，为解决常见问题而设计的成功方法。
提示模式在知识传递上类似于软件模式（Software Patterns）。软件模式为特定上下文中反复出现的问题提供可复用的解决方案，而提示模式则专注于在与LLM交互和生成输出的上下文中解决常见问题。通过将这些知识以模式形式编纂，可以增强其在不同领域和上下文中的复用性和可移植性。
本文提出的提示模式遵循一种类似于经典软件模式的结构，但为适应LLM的上下文进行了调整，具体包含以下几个部分：
- 名称和分类 (Name and Classification)：唯一标识模式，并将其归入特定类别。
- 意图与背景 (Intent and Context)：描述模式要解决的问题和实现的目标。
- 动机 (Motivation)：阐述解决该问题的重要性，以及它如何改进用户与LLM的交互。
- 结构与核心思想 (Structure and Key Ideas)：描述模式提供给LLM的核心上下文信息。本文提出使用 基本上下文陈述 (Fundamental Contextual Statements) 来描述这些核心思想，这是一种用自然语言写成的、描述关键沟通要点的简洁陈述，旨在让不同背景的用户都能理解和应用。这种方法取代了可能过于僵化和复杂的UML图或形式化语法。
- 示例实现 (Example Implementation)：展示模式在实际中的具体措辞。
- 后果 (Consequences)：总结应用该模式的优缺点，并提供适应性建议。
本文所有示例均在 ChatGPT+ 服务上进行了测试。
面向对话式LLM的提示模式目录
本章节介绍了本文整理的提示模式目录，这些模式已被成功应用于解决与对话式LLM交互及为软件开发任务生成输出时的常见问题。
提示模式目录总结
本文对已识别的提示模式进行了初步分类，该分类体系是理解和组织这些模式的关键。
| 表 I |
|---|
| 提示模式分类 |
| 模式类别 | 提示模式 |
|---|---|
| 输入语义 (Input Semantics) | 元语言创建 (Meta Language Creation) |
| 输出定制 (Output Customization) | 输出自动化 (Output Automater) |
| 人设 (Persona) | |
| 可视化生成器 (Visualization Generator) | |
| 配方 (Recipe) | |
| 模板 (Template) | |
| 错误识别 (Error Identification) | 事实核查清单 (Fact Check List) |
| 反思 (Reflection) | |
| 提示改进 (Prompt Improvement) | 问题优化 (Question Refinement) |
| 替代方法 (Alternative Approaches) | |
| 认知验证器 (Cognitive Verifier) | |
| 拒绝破解器 (Refusal Breaker) | |
| 交互 (Interaction) | 翻转交互 (Flipped Interaction) |
| 游戏 (Game Play) | |
| 无限生成 (Infinite Generation) | |
| 上下文控制 (Context Control) | 上下文管理器 (Context Manager) |
分类体系解释：
- 输入语义 (Input Semantics)：关注LLM如何理解输入，并将其转化为可用的内部表示。
- 输出定制 (Output Customization)：专注于约束或定制LLM生成输出的类型、格式、结构或其他属性。
- 错误识别 (Error Identification)：旨在识别和解决LLM输出中的错误。
- 提示改进 (Prompt Improvement)：致力于提高输入（用户问题）和输出的质量。
- 交互 (Interaction)：侧重于改变用户与LLM之间的交互模式。
- 上下文控制 (Context Control)：用于管理LLM运行时所依赖的上下文信息。
元语言创建模式 (The Meta Language Creation Pattern)
- 意图与背景: 用户希望使用一种替代语言（如用于图的文本简写、状态机的状态转换描述等）来与LLM交流。该模式的意图是向LLM解释这种替代语言的语义，以便用户在后续的提示中可以使用这门新语言。
- 动机: 许多问题、结构或思想用英语等自然语言表达可能不够简洁、清晰或明确。为了让LLM能理解并基于一种替代语言生成输出，首先需要让它明白该语言的语义。
- 结构与核心思想:
| 基本上下文陈述 |
|---|
| 当我说 X 时，我的意思是 Y （或者我希望你做 Y）。 |
该模式的核心是向LLM解释一个或多个符号、单词或语句的含义，使其在接下来的对话中采用用户提供的语义。
- 示例:
从现在开始，每当我用“→”分隔两个标识符时，我都在描述一个图。例如，“a → b”描述了一个包含节点“a”和“b”以及它们之间一条边的图。如果我用“-[w:2, z:3]→”分隔标识符，我正在为边添加属性，比如权重或标签。 - 后果: 这个模式非常强大，但也可能导致LLM产生混淆。定义的语言必须无歧义，否则会降低LLM的性能和准确性。例如，重新定义逗号的含义可能会引发意想不到的语义冲突。当一个符号在不同领域有不同含义时（如“→”在图论和逻辑学中），此模式可以帮助限定上下文，提高输出的准确性。最好在一个全新的会话中使用此模式，避免语义冲突。
输出自动化模式 (The Output Automater Pattern)
- 意图与背景: 让LLM生成一个脚本或其他自动化工件，以自动执行其在输出中建议的步骤。目标是减少用户手动执行LLM建议所需的工作。
- 动机: LLM的输出常常是一系列需要用户手动执行的步骤，例如修改多个配置文件。这个过程繁琐且容易出错。
- 结构与核心思想:
| 基本上下文陈述 |
|---|
| 每当你生成一个包含至少一个步骤且满足某些属性的输出时（或者，总是这样做） |
| 请生成一个类型为 X 的可执行工件来自动化这些步骤。 |
模式的第一部分定义了触发自动化的条件（例如，当输出包含超过一定数量的步骤时），第二部分则明确了自动化工件的类型（例如，“生成一个Python脚本”）。
- 示例:
从现在开始，每当你生成跨越多个文件的代码时，请生成一个Python脚本，运行该脚本可以自动创建指定的文件或修改现有文件以插入生成的代码。 - 后果: 用户必须明确定义自动化工件的类型，因为LLM通常不接受模糊的“自动化”请求，但可以接受“生成代码”的指令。此模式在提供完整上下文时效果最好，例如从头生成一个项目。用户必须有能力审查和理解生成的自动化脚本，因为LLM可能会产生错误，盲目执行脚本存在巨大风险。用户需要为执行脚本的后果负责。
翻转交互模式 (The Flipped Interaction Pattern)
- 意图与背景: 让LLM主导对话，通过向用户提问来获取完成特定任务所需的信息。例如，让LLM进行一次快速测验，或者不断提问直到能生成一个完整的应用部署脚本。
- 动机: LLM通常拥有比用户更多的领域知识，由它来主导提问过程，可以更准确、更高效地收集信息，从而更好地实现目标。这种“控制反转”能够使交互更加聚焦和高效。
- 结构与核心思想:
| 基本上下文陈述 |
|---|
| 我希望你向我提问，以实现目标 X。 |
| 你应该持续提问，直到满足某个条件或实现某个目标（或者，永远提问）。 |
| （可选）每次问一个问题，或两个问题，等等。 |
提示应明确交互的最终目标、终止条件，并可选地规定提问的节奏（如每次提问的数量）。
- 示例:
从现在开始，我希望你向我提问，以便将一个Python应用部署到AWS。当你拥有足够的信息来部署该应用时，创建一个Python脚本来自动化部署过程。 - 后果: 提示的开放性（如上例）使其具有通用性，但也可能导致LLM提出一些本可以避免的额外问题。如果预先知道某些具体要求（例如，部署到AWS EC2），最好在初始提示中明确说明。在设计此类提示时，需要考虑用户的知识水平，并明确是希望最少化用户交互还是最大化用户参与。
人设模式 (The Persona Pattern)
- 意图与背景: 希望LLM的输出始终带有一种特定的视角或观点。例如，让LLM扮演一个安全专家来进行代码审查。该模式赋予LLM一个“人设 (Persona)”，帮助其决定生成何种类型的输出以及关注哪些细节。
- 动机: 用户可能不清楚实现某个任务需要关注哪些具体细节，但他们通常知道应该向哪种角色的专家求助。该模式让用户通过指定角色来表达需求，而无需了解所有输出细节。
- 结构与核心思想:
| 基本上下文陈述 |
|---|
| 扮演人设 X。 |
| 提供人设 X 会创建的那种输出。 |
人设可以是一个职位、头衔、虚构人物或历史人物。该角色应能唤起一系列众所周知的属性。
- 示例:
- 安全审查员：
从现在开始，扮演一名安全审查员。密切关注我们所查看的任何代码的安全细节。提供安全审查员会给出的那种关于代码的输出。 - 被攻击的Linux终端：
你将要假装是一个被攻击者入侵的计算机的Linux终端。当我输入一个命令时，你将输出Linux终端会产生的相应文本。
- 安全审查员：
- 后果: 人设模式非常有效，LLM能够将其“情境意识”带入角色中，生成符合该角色的、富有想象力的输出（例如，模拟被黑客攻击后的文件系统）。人设也可以是非人类实体（如数据库、动物）。但需注意，涉及在世人物或有害人物的人设可能会因LLM的内置规则而被忽略。
问题优化模式 (The Question Refinement Pattern)
- 意图与背景: 让LLM参与到提示工程的过程中，帮助用户提出更好、更精确的问题。LLM会根据用户的原始问题，建议一个经过优化的新版本，从而帮助用户更快地找到准确答案。
- 动机: 提问者可能不是其所在领域的专家，不知道如何最好地表述问题。LLM在回答时经常会指出其局限性或做出的假设，这些信息可以用来构造一个更好的提示。该模式让LLM直接利用这些信息来优化用户的问题，而不是让用户自己消化和改写。
- 结构与核心思想:
| 基本上下文陈述 |
|---|
| 在范围 X 内，建议一个更好的问题版本来替代我的问题。 |
| （可选）询问我是否愿意使用这个更好的版本。 |
该模式要求LLM在特定范围内（例如，仅限于关于软件安全的问题）对用户的问题进行优化，并可选地征求用户同意以使用优化后的问题。
- 示例:
从现在开始，每当我询问关于软件工件安全性的问题时，请建议一个更好的问题版本来替代我的问题，该版本应包含与我正在使用的语言或框架相关的特定安全风险信息，并询问我是否愿意使用你的问题。例如，如果用户问：“如何在我的Web应用中处理用户身份验证？”，LLM可以将其优化为：“在FastAPI Web应用中安全处理用户身份验证以减轻XSS、CSRF和会话劫持等常见安全风险的最佳实践是什么？”
- 后果: 此模式可以弥合用户知识与LLM理解之间的差距。但风险在于，它可能过快地将问题收窄到特定领域，导致用户错失更宏观的信息。一个解决方案是在提示中加入约束，如“不要将我的问题局限于特定的编程语言或框架”。此外，优化后的问题本身也可能引入事实性错误，这可以通过结合 事实核查清单 (Fact Check List) 等模式来缓解。
替代方法模式 (The Alternative Approaches Pattern)
- 意图与背景: 确保LLM总是提供完成任务的多种替代方案，以避免用户仅仅依赖他们熟悉的方法。这迫使用户思考他们当前的做法是否是实现目标的最佳途径。