LLM 提示词调优指南 (LLM Prompt Tuning Playbook)

Varun Godbole, Ellie Pavlick

目录

• 这份文档适合谁？
• 为什么需要一份调优指南？
• 背景：预训练与后训练
  • 预训练
    • 预训练的“电影宇宙”直觉
  • 后训练
    • 后训练数据收集
• 关于提示词的考量
• 提示词的基础“风格指南”
• 迭代新系统指令的流程
• 关于何时使用 LLM 的一些思考
• 更多资源
• 致谢

这份文档适合谁？

本文档适用于任何希望提升对后训练大语言模型（Post-trained LLMs）进行提示（Prompting）能力的人。我们假设读者已经与某种大语言模型（LLM，Large Language Model）有过一些基本的交互（例如 Gemini），但我们不假设读者具备严谨的技术理解能力。

文档的前半部分提供了关于后训练和提示本质的心智模型（Mental Models）。文档的后半部分提供了更具体的建议和调优提示词的高级流程。鉴于 LLM 的创新速度，我们怀疑后半部分的内容可能会比前半部分更快地过时。

为什么需要一份调优指南？

本指南受 深度学习调优指南 (Deep Learning Tuning Playbook) 启发，该指南用于指导深度学习（Deep Learning）工作负载的超参数（Hyperparameters）调优。

提示（Prompting）的“艺术”，就像更广泛的深度学习领域一样，最好的情况是经验性的，最坏的情况则如同炼金术般玄妙。尽管 LLM 正在迅速改变众多应用，但有效的提示策略对该领域而言仍是一个开放性问题。本文档源于我们与 LLM 合作数年的经验，以及无数次寻求提示工程（Prompt Engineering）协助的请求。它代表了整合并分享有益直觉和实用提示技术的一次尝试。

我们是两位与 LLM 合作了数年的研究人员和工程师。话虽如此，本文档不应被视为绝对真理，也不应被视为 Gemini 后训练团队的集体立场。相反，它是我们要个人观察和最佳实践（Best Practices）的集合。我们希望这本指南能作为我们当前思维的一个快照，随着我们信念的改变和新知识的出现，未来可能会在尽力而为的基础上进行更新。

我们希望通过写下我们具体的一套心智模型和流程，社区可以共同努力找到更好、更系统的提示策略。

本指南专门针对 Gemini 的各种后训练版本。据经验表明，本文档中的一些建议可能泛化到其他模型。但我们对其他模型的实践经验较少。

背景：预训练与后训练

预训练（Pre-training）

“预训练（Pre-training）”是深度学习中的一个古老概念。本质上：

1. 你有一个真正关心的小数据集（即数据集 A），以及一个大型数据集 B，它实际上不是 A，但在至少某些重要方面相似。例如，A 可能涉及少量乳腺 X 光图像，而 B 可能是像 ImageNet 这样的大型自然图像学术数据集。
2. 你在大型数据集 B 上训练模型，希望它能学到一些通用的有用特征。然后你在数据集 A 上对其进行“微调（fine-tune）”，以便在 A 的验证集上获得比直接在 A 上从头训练模型更好的性能。也就是说，你只是使用之前在数据集 B 上使用过的相同训练过程，继续在数据集 A 上进行训练。通过这种方式，当你的模型遇到来自数据集 A 的示例时，它能够更好地利用它们，因为它已经从在数据集 B 上的广泛经验中知道了许多通用的有用知识。
3. 为了更具体，再次考虑乳腺 X 光的例子。通过在互联网上大量现成的图像上进行预训练，你的模型可以学习基础知识，例如如何在图像中分割对象，或者如何识别概念而不受其在图像中位置的影响。这些是重要的图像处理技能，对你的乳腺 X 光应用很有用，但可能需要大量数据才能学会，并且并非乳腺 X 光所特有。如果你试图仅使用你的（获取成本高、供应有限）乳腺 X 光数据来教模型这些技能，它可能永远学不会，因此永远无法达到最佳性能。但是，如果你在日常生活图像上进行预训练，你的模型就可以带着这些通用技能来到你的乳腺 X 光数据面前，准备好利用你的专用数据仅学习那些在其他地方无法学到的专业技能。

训练大语言模型（LLMs, Large Language Models）的关键思想之一是将“语言建模（language modeling）”——即预测句子中的下一个词——作为预训练任务。事实证明，如果你训练一个模型从互联网上获取任意文本片段，并很好地完成预测下一个词的任务，该模型就会隐式地学习到网络中反映出的非常丰富的世界结构。

这似乎很容易理解，直到我们试图回答这个问题：互联网反映了什么样的世界？为了尝试理解这个问题（及其答案），我们建议一个有用但略显虚构的隐喻：电影宇宙（Cinematic Universe）。

预训练的“电影宇宙”直觉

大语言模型必须通过阅读关于世界的文本来了解世界是什么样的。然而，文本从未被限制为只描述传统意义上“真实”的事物。人们非常关注虚假信息或不正确的陈述，但也有许多非常无辜且合理的理由，使得文本不应该也不应反映对应于单一世界状态的单一事实现实。

例如，考虑这句话：“阿拉贡最终成为了刚铎的国王”。这句话是真的吗？这取决于情况。例如，它取决于某种时间性。此外，这句话是否有意义也取决于讨论它的更广泛的前提或背景。如果前提是《指环王》（LoTR），那么是的，你可以认为这是一个事实。但想象一下，你是在漫威电影宇宙（Marvel Cinematic Universe）的前提下谈论。那么这就不是明显的事实了。如果你处于与我们通常认为“真实”相符的非虚构电影宇宙中，那么我们关于阿拉贡的陈述就不是真的。这不是真的，因为阿拉贡和刚铎是你无法在地球上找到的虚构角色。如果你处于漫威电影宇宙中，出于类似的原因，这也是不真实的。但如果你处于 LoTR 电影宇宙中，那么它就变成了真的。

这个问题——即难以定义某物“真实”的含义以及相对于哪个世界的问题——对 LLM 来说并不新鲜。它与哲学和语言学理论及争论的悠久历史有关。这段历史和理论是一个值得深入挖掘的领域（参见，例如，这个概述）。但是，就提示 LLM 的实际用途而言，它可以被过度简化为：一个陈述是否真实取决于作为该陈述背景的“电影宇宙”。

为了本文档的目的，你可以将预训练语料库（corpus）视为人类文化产生的所有电影宇宙的集合并集的近似值。或者更准确地说，是那些积极参与预训练数据源（如网络）的文化。

[!IMPORTANT] 你可以将预训练语料库视为人类文化产生的所有电影宇宙的集合并集的近似值。或者更准确地说，是那些积极参与预训练数据源（如网络）的文化。

当你给模型一个固定的上下文窗口（context window）（即前缀（prefix））时，它会尝试从前缀中推断它处于哪个宇宙，然后它将按照该宇宙的规则、惯例和事实行事。如果你提供一个具有非常强上下文信号的提示（prompt），LLM 将更容易识别剧本。例如，考虑这样一个提示："梦想成真的水泥丛林不仅仅是一句朗朗上口的歌词——它是纽约市（New York City）的电光真理。从刺破云层的摩天大楼到其多样化社区充满活力的脉搏，NYC 提供了一种地球上独一无二的体验"，即我可能会写的关于 NYC 的博客文章的前两行。）在这种情况下，模型在风格和主题上有很强的约束，这将影响它如何进行生成。

但是，如果你的提示非常通用——比如“嗨，你好吗？”——LLM 可能没有足够的上下文来理解它应该处于哪个电影宇宙中。“嗨，你好吗？”可能出现在它接受训练的多样语料库的各种上下文中。也就是说，用于解码生成的概率密度函数中有许多“模式（modes）”。或者简单来说，它看到了许多它可以扮演的可能性。文本“嗨，你好吗？”，甚至更长的内容，都没有给它提供足够的上下文来消除这种歧义。

这就是后训练（post-training）发挥作用的地方。

后训练（Post-training）

Post-training（后训练）为 LLM（大语言模型）提供了关于其存在的“默认”宇宙的指引。与其要求 LLM 仅从 Prompt（提示词）中推断这个宇宙，Post-training 可以约束 LLM 以一致的方式做出某些假设或解决歧义。有许多原因使得这对于使模型有用是必要的。例如，可能需要告诉 LLM，默认情况下它们遵循指令。否则，给定一个像"Write a report about George Washington"这样的 Prompt，未经 Post-training 的 LLM 可能会愉快地生成指令的延续，例如类似"It's due by 4:59pm on Friday"的内容，而不是生成所要求的报告。但 Post-training 也可用于施加其他默认设置，例如影响模型的默认行为以更符合社会规范（无论如何定义），理想情况下使其成为特定假设用例更安全或更有生产力的工具。

我们非常喜欢 Murray Shanahan 的阐述，他认为概念化这些模型可能在做的事情的一种方式就是，它们正在参与一种 角色扮演，这是其整体训练方案（training recipe）的函数。我们的直觉是，Post-training 教会这些模型在各种部署环境中扮演连贯且默认的角色。

[!IMPORTANT] Post-training 教会这些模型在各种部署环境中扮演连贯且默认的角色。

以下是它们在 Post-training 期间可能学到的内容的非详尽列表，范围从平凡实用的到主观个人的。

• 模型应遵循特定格式。 例如，Gemma’s formatter 教导它处于一个电影宇宙（cinematic universe）中，其中总是存在它与某个任意人类用户之间的对话。在那个宇宙中，被要求扮演的角色在 System instructions（系统指令）中描述。根据 Formatter（格式化器），在每次对话中，人类的回合总是第一。
• 模型应“遵循”用户的指令。 也就是说，如果用户给它一个字符串 Prompt 让它“写一篇关于狗的文章”，它应该实际上这样做，而不是用越来越专横的指令延续来响应用户。
• 模型应与“现实世界”匹配（而不是其他电影宇宙）。 Post-training 通常用于通过将模型的隐式或默认电影宇宙与大多数用户可能关心的宇宙对齐来提高模型的事实性（factuality）。例如，如果你问它"$CELEBRITY 出生在哪里？”，它应该默认假设我们在谈论“现实世界”，而不是它可能在网络上遇到的、拥有同名名人的粉丝小说世界。
• 它应该是“安全”的。 互联网是一个复杂的规范性标准网络。不用说，相当多的互联网内容在全球商业部署的背景下不会被认为适宜。Post-training 有助于将模型对齐到选定的分布（distribution），该分布可以体现一系列安全策略，从而对模型应该或不应该生成什么施加规范性标准。最终，模型不可能在不就规范做出一些假设的情况下生成足够复杂的内容。

Post-training Data Collection（后训练数据收集）

Broad Takeaway（主要收获） - 这些模型最终是由 Human raters（人类评分员）训练和评估的。当指导 Post-trained LLM 时，你是在隐式地请求一个数字角色扮演者（即 LLM）扮演人类评分员（即生成 Post-training 数据的人）的角色，而这个人是为了扮演 AI 助手而被付费的。

本节是一个巨大的简化。关于任务人类标注员进行 LLM Post-training 的复杂性和微妙之处，可以写出长得多得多的文档。本节的目标是提供此背景下人类标注的整体直觉，因为它直接影响人们如何思考 Prompting（提示工程）。

从 AI 开发者的角度来看，Post-training 的人类数据收集过程大致如下：

1. 创建一个多样化的输入示例数据集–即，描述 LLM 可能被要求执行的任务的 Prompts。这可以是任何内容，从“将此数据重新格式化为 json"到“帮我计划我的婚礼”。（这可能来自你自己的直觉，或者来自人类评分员本身！）
2. 创建一个人类“评分员”池，他们的工作是告诉模型对于这些任务该做什么。评分员的工作可能是为这些输入示例编写黄金标准答案，例如，实际自己提供婚礼策划技巧。或者可能是查看模型生成的不同响应并从最好到最差进行排名。在 Post-training 的不同阶段，模型可以使用不同类型的人类生成数据。
3. 编写一些指南，说明这些评分员应该如何完成这项工作。通常，开发者会包含示例或关于任务和上下文的具体细节，以帮助评分员更好地理解任务。
4. 收集这些数据并在其上"Post-train"Pre-trained（预训练）模型。
5. 发布它。

LLM 能够“表现得像人”的一个很大原因是因为这些统计模型拟合了大量精心收集的人类行为演示数据集。Pre-training 阶段、模型架构、学习算法等提供了模型的核心基础设施和底层能力。但 Post-training 提供了模型的整体方向（通过人类演示），这决定了它在实际部署时的实际行为。

[!IMPORTANT] LLM 能够“表现得像人”的一个很大原因是因为这些统计模型拟合了大量精心收集的人类行为演示数据集。

Post-training 团队花费大量时间在其数据上进行质量控制。很多精力投入到将评分员与他们最适合的 Prompts 相匹配。例如，为了提供一个如何响应包含困难 Python 调试问题的 Prompt 的良好演示，有必要找到一个本身就是优秀 Python 程序员的评分员。

从人类评分者（human raters）那里收集“高质量”数据极具挑战性。原因包括：

• 与需要相同技能的其他工作相比，评分示例可能很枯燥： 如果你是一位优秀的 Python 程序员，从事自己的编码项目可能比每天花 8 小时调试用于训练 AI 系统的程序更有趣。如果你是一位才华横溢的诗人，你可能想写自己的诗，而不是将 AI 写的诗从最好到最差进行排名。当然，如果你每天花约 8 小时进行评分，你会因此获得报酬。但评分示例可能极其重复，而且评分者的激励通常基于产出量（throughput）。此外，自主权（agency）或所有权（ownership）的感觉也可能存在挑战——你并不总是知道这些数据如何改变了模型的整体质量，这些数据是否会被丢弃，它被用于哪个模型等。你与数据效用的唯一关系可能是你的主管告诉你做得好不好。如果你没有一个清晰的叙事（narrative）来说明为什么在那份工作中能起到对更广泛世界的积极改变作用，你可能不会觉得这是对我们时间的有意义的使用。这可能会影响你做一份“好”工作的无意识热情，即使你在抽象层面上想做一份好工作。
• 定义特定任务的“良好”响应是什么样子的非常具有挑战性。 当定义必然与关于事实性（factuality）、说明性写作（expository writing）或其他某些能力的现有规范相交时，这一点尤其正确。对于大多数有趣的人工制品而言，“好/坏”之间的“界限”实际上相当模糊，并且取决于许多规范性因素。（例如，想象指示 AI 系统充当一家公司的公关代理人（PR agent）。社会现实的全部复杂性真的很难钉入一套清晰的命题中。这项工作最终需要“良好的判断力”，其执行方式在不同人和情境下会有很大差异。）这使得开发者很难为该任务编写良好的指令，也让人类评分者在确定如何解释这些指令时非常主观。（这与普通法体系（common law system）的工作方式有相似之处。写下能够预见大量边缘情况（edge-cases）的立法（legislation）极其困难。因此，社会使用司法体系（judicial system）来仲裁边缘情况并创建先例（precedents）。）
• 评分者可能不理解任务。 任何工作的招聘都很困难，评分工作也不例外。即使在招聘上花费了大量精力，也不能保证评分者具备完成任务的技能。这可能出于多种原因。例如，因为设计者没有预料到评分者将获得的任务的复杂性（即，雇佣了一位具有入门级软件工程技能（software engineering skills）的人，而任务实际上需要一位经验丰富的软件工程师），或者因为评分者自己没有意识到自己知识的局限性（例如，根据他们在大学生物课上学到的内容回答问题，而这实际上与最新的研究不一致）。
• 人会犯错。 教授发布的考试中有错误答案。医生在饥饿或疲劳时更容易误诊。当人们在家庭生活中受到干扰时，在工作中会失去专注力。出于各种原因，人类在任务上的表现可能低于“黄金标准（gold standard）”。这意味着即使尽了最大努力，AI 系统有时也会在错误或误导性的数据上进行训练。

提示词（Prompting）编写注意事项

主要结论 - 当你编写系统指令（system instructions）和提示词（prompts）时，你实际上是在为后训练团队（post-training team）评分池（rater pool）的聚合精神而写，其种子来源于预训练语料库（pre-training corpus）的聚合精神。如果我们编写的指令是特定领域内的平均评分者能够理解、领会并忠实遵循的，那么模型更有可能遵循我们的指令。

[!IMPORTANT] 当你编写系统指令和提示词时，你实际上是在为后训练团队评分池的聚合精神而写，其种子来源于预训练语料库的聚合精神。

当我们编写系统指令时，想象屏幕另一端有一位友好、善意且胜任的评分者准备扮演 AI 角色，这很有帮助。我们提供的文本是他们拥有的全部。也就是说，当我们向 Gemini 模型发起 API 调用（API call）时，想象另一端有一位人类评分者会仔细阅读我们的提示词并提供回复。在构建提示词时，站在他们的角度考虑我们的指令非常有帮助。例如，假设指令是关于生成 Python 代码的。如果我们随机找一位胜任的 Python 工程师，让他们回应这些指令，他们会明白我们要什么吗？

这个比喻有助于帮助你编写良好的指令。但它不一定能很好地比喻 AI 系统是如何遵循这些指令的。例如，当我们考虑到这位所谓的评分者可能拥有所有人类知识时，这个比喻就开始失效了。他们只是缺乏智慧和上下文来超越我们提供的提示词进行洞察。此外，AI 系统可能不会像人类评分者那样“理解”提示词。相反，AI 系统将利用其非常强大的统计模型（statistical models）为你的输入提供输出。但是，这些统计模型是为针对善意且胜任的人类评分者编写的指令而优化的，因此，提供任何非为此类评分者编写的提示词可能会让 AI 系统感到困惑。没有什么比“分布外（out of distribution）”的情况更让 AI 讨厌的了！

鉴于此，以下是一些帮助你改进提示词中指令的注意事项。随着模型的改进，以下注意事项可能会很快过时。我们建议尝试与这份列表的整体精神保持一致，而不是拘泥于字面意思。

• 指令是否清晰、易读、简洁且明确？ 例如，假设我们的指令是关于某个 Python 编码任务的。如果我们随机找一位 Python 专家，让他们假装成 Gemini，我们的指令是否足够好，让他们在不问任何明显的澄清问题的情况下立即明白我们的意思？

  • 差： 编写一个计算质数的 Python 函数。
  • 好： 编写一个计算 1 到 100 之间质数的 Python 函数。为生成的函数包含 pytype 类型注解（pytype annotations），并使用 2 空格缩进。

• 指令是否自相矛盾或难以遵循？ 一个无聊、饥饿、疲惫等的评估员（rater）真的会阅读我们过于冗长的指令并忠实遵循吗？请注意，为了确保给定 Prompt（提示词）中的所有指令都被遵循，通常涉及大量的质量控制。但人毕竟是人。我们的指令实际上是否“容易”遵循？还是它们包含了不必要的迂回、冗长等？当本指南（Playbook）的作者写下指令时，我们经常问自己，如果将这些指令在没有额外上下文的情况下呈现给我们公司的另一位员工，他们能否忠实遵循。

  • Bad: Don't write a story about a mean dog, unless it's friendly, and also sad, but not really that sad, and make it long even but not too long. Also the dog should be named Bob, or maybe Susan, doesn't matter. Write it about a cat too. But that’s not actually as important, but make the dog fluffy.
  • Good: Write a short story (200-300 words) about a loyal golden retriever named Buddy who gets lost in the woods during a family camping trip. The story should focus on Buddy's journey and his determination to find his way back to his family.

• 给定的系统指令（System Instruction）中是否包含了指令过多？ 我们注意到，Prompt（提示词）中的指令数量与模型忠实遵循所有指令的能力之间存在反比关系。尽管我们确实见过许多模型能够相当好地遵循长链条指令的案例。这只是一个经验法则，也适用于为人类编写指令的情况。基本上，如果可以的话，最好将任务分解为子任务。很难为此考虑提供好坏示例，因为它很大程度上取决于所考虑的模型，但这里是我们所指的精神实质。

  • Bad: Read each article and, for each key idea, rate it on a scale of 1-10 for how important it is to understanding the general point. Then for anything rated higher than 7, summarize it in the form of a Chinese social media post.
  • Good: Call the AI model for each subtask separately (what follows is not an example of a literal prompt for the model). 1) Break the article into a list of main ideas. 2) Rate each idea on a scale of 1-10. 3) Take the top ones and translate them into Chinese. 4) Take the Chinese text and convert it into a social media post.

• 使用正向指令而非负向指令。 下面的“坏”例子说明了模型不应该做什么。但它没有说明模型应该做什么。“好”的例子非常明确地列出了模型应该做什么。这里实际上与人们在教师培训或伴侣治疗等情境中学到的有效人际沟通有相似之处。我们应该试着想象我们正在试图与一个想给我们想要东西的人沟通。但我们需要给他们关于什么是“成功”的非常明确的指导，而不是告诉他们要“避免失败”。

  • Bad: “Don’t ever end your response with a full stop.”
  • Good: “Your response should always end with an exclamation mark or a question mark”.

• 良好的系统指令可以充当模型的“提醒”。 在迭代新 Prompt（提示词）时，考虑非常多样化的输入示例非常重要。很常见的是，人们编写的 Prompt（提示词）可能对约 60-70% 的可能模型输入有效，但对剩余的约 30-40% 未指定或模糊不清。通常值得给模型一套明确的正向指令，说明在这些情况下它应该做什么。我们通常在系统指令中创建一个名为“额外考虑”或“额外假设”的独立部分，其中包含针对这些边缘情况的规格要点列表。

• Prompt（提示词）是新的超参数（Hyperparameters），你可能永远找不到“最好”的一个。 例如，正确调整学习率可以对特定计算预算下模型在验证集上的最终性能产生巨大影响。同样，“好”Prompt（提示词）和“坏”Prompt（提示词）之间的差异会对系统的最终性能产生重大影响。同理，通过更多的 Prompt（提示词）调优，可能总存在一个“稍好”的 Prompt（提示词）。而且我们永远不会知道是否找到了“最好的一个”。如下文所述，我们可以利用与 深度学习调优指南 中使用的类似直觉，系统地找到比我们当前基线“更好”的 Prompt（提示词）。该指南在超参数搜索的背景下提到了“试验预算”。对于提示工程（Prompting），为我们的实验创建一个时间盒（Timebox）可能会很有用。

• 尝试给予模型明确的“我不知道”的指令。 例如，假设我们正在处理某种多类文本分类任务。我们有一些标准，规定输入示例应如何映射到每个类别。创建一个额外的“未知”或“边缘情况”类别可能非常有帮助。并提供明确的正向指令，如果模型认为指令对于正确分类此示例不清楚，则将输入分类到此类别。然后我们可以查看日志，了解何时/如何发生这种情况，并相应地改进 Prompt（提示词）。

• Prompt（提示词）可能与其开发的检查点（Checkpoint）深度耦合。 也就是说，如果我们从 Gemini 1.5 Flash 获取一个 Prompt（提示词）并在 Gemini 1.0 Pro 上运行它，它可能不会以“相同的方式”工作，并且在评估（Eval）上可能表现出非常不同的聚合行为。这在某种程度上是有道理的。我们的心理模型是，我们用自然语言编写的 Prompt（提示词）类似于如果我们进行随机梯度下降（SGD）时会训练的参数。这在多大程度上是正确的，是一个开放研究的问题。模型有点像机器，后训练过程有点像编译器，而系统指令有点像计算机代码。只不过机器和编译器是完全流动的，给定的模型可以持有这些的许多不同组合。我们怀疑生态系统将有机地收敛到关于指令外观的某种共识结构，这种结构随时间快速变化，并以组合爆炸的方式保持合理的向后兼容性。这类似于 x86 指令集随时间保持相对稳定，相比之下，构建在其之上的编程语言的多样性呈爆炸式增长。

提示词（Prompts）的初步“风格指南”

目前，我们推测在前沿模型（frontier model）上执行的经过良好调整的提示词（Prompts），足以应对大量此前需要定制训练模型（bespoke trained model）的机器学习（ML）工作负载。

随着推理成本（inference costs）、延迟（latency）、上下文窗口大小（context window sizes）等持续改善，提示词技术（prompting）将变得越来越普遍。编程语言风格指南的出现源于这样一个观察：软件主要是为其他软件工程师编写的，以便于维护等。我们不确定提示词技术（prompting）中相当于编程语言风格指南的是什么。但存在许多有趣的可能性。包含提示词的 Markdown 文件最终可能会被视为版本控制系统（version control systems）中具有特定文件扩展名的独立“语言”。或者，编程语言最终可能会与模型推理（model inference）有更“透明”的集成。现在做出确切的预测还为时过早！

我们这里没有提供一份完整的风格指南。但我们想分享以下观察结果：

• 考虑使用 Markdown： 大多数版本控制系统都擅长渲染 Markdown 文件。因此，将每个提示词存储在单独的 Markdown 文件中可能是有用的。并且明智地使用 Markdown 标题等来组织我们每个提示词的内容。
• 为他人着想！ 我们鼓励将保存的提示词视为主要是为了其他提示词维护者，而不仅仅是为了大语言模型（LLM）。随着模型变得更好，我们希望我们需要花费更少的精力在独特的取巧方法上来引导模型达到我们期望的行为。如上所述，这也可能自然地促成更好的提示词。
• 简洁性： 我们的提示词产生的“技术债务”与其长度和整体复杂度成正比。提示词与特定的检查点（checkpoint）紧密相连。每当底层模型发生变化时，都值得定量和定性地检查我们的提示词是否仍然有效。真的值得让提示词尽可能简单、简练和直接。让模型所做的隐含假设免费地为我们所用。如果简单的提示词就能解决问题，就不要试图向提示词中添加更多细节。这明确假设执行提示词的底层模型不会与提示词被随意解耦。当然，我们不知道模型是否会对不同的输入示例做出相同的隐含假设集。随着我们提示词的部署变得更加“严肃”，实施更严格的定量评估变得不可避免地至关重要。
• 优先选择零样本（zero-shot）指令而非少样本（few-shot）指令： 这与简洁性的精神一致。零样本指令更容易理解、调试和推理。少样本示例，尤其是当它们包含完整对话时，在我们显式指令的“字面意思”不足以捕捉指令“精神”时最为适用。我们见过很多少样本效果不如零样本的情况。我们不应仅仅假设少样本会更好，而应该对此进行实证研究。我们建议将少样本示例作为最后手段，因为它们会严重影响提示词的可读性。
  • 与其使用完整的少样本示例，不如将示例编织进我们指令的正文中。考虑以下在指令末尾使用“例如”的系统指令（system instruction）：
    • 始终用某种被动攻击性的内容开始你对用户的回复。例如，以类似“哦，这就是你想要的？我不是说你错了。但是，好吧，如果你真的想要的话。”这样的话开头。但要保持新鲜感，根据用户消息中的内容，每次回复使用不同的开头。

迭代新系统指令的流程

提示工程（Prompting）本质上是迭代的。它在本质上非常类似于使用某些验证集（validation set）来训练模型。只不过，你不需要 JAX 等工具，而是可以通过编写清晰的文本来完成。

与撰写文本类似，我们发现最好将任务分解为独立的生成（generate）和编辑（edit）阶段。

我们发现，大多数尝试对模型进行提示的用户并没有一个干净的验证集来基准测试模型的响应。这对于快速构建最小可行性产品（MVP）来说是可以的。但最终，正式的定量评估对于跟踪模型性能是无价的。即使拥有最佳的提示词 + 模型组合，也不可能确定性地保证模型的行为。重要的是要设计能够优雅处理失败的产品界面，以防底层模型做出意外行为。

像 AI Studio 这样的工具对于迭代新的系统指令集可能非常有价值。

1. 从该问题的一组真正多样化的输入示例小样本开始，并尝试直观地了解期望的输出行为可能是什么。这可能是大约 ~10-50 个示例。

2. 从最简单的系统指令开始，该指令可能满足每个输入示例，并使用可用中最小且最便宜的模型。目前，这很可能是像 Gemini Flash 8B 这样的模型。

   • 当我们说“最简单”时，我们就是指最简单。在不损失任何清晰度的情况下，使其尽可能简洁简短。

3. 在第一个输入示例上运行系统指令。

4. 尝试对该特定示例进行“过拟合（overfit）”。

   • 也就是说，向原始系统指令添加“提醒”，直到模型可靠地产生“足够好”的响应。当我们说提醒时，我们字面意思就是指提醒。找出模型对原始系统指令响应的任何具体缺陷。现在向其添加指令，指出这些具体行为。一次做一个。例如，假设原始指令告诉模型从输入字符串中提取所有命名实体（named entities）。我们注意到它也在提取建筑物、地点等的名称，但在这个黄金示例中，我们的意图是只提取人名。我们可以编辑/修改原始指令以反映这一点。
   • 如果它无法对第一个输入提示产生足够好的响应，请尝试第二个输入提示。如果模型在我们的大多数输入示例上一贯失败，请回到步骤 (2) 并尝试更好的模型。例如，如果我们从 Flash 开始，请尝试 Pro。

5. 一旦我们能够成功对第一个示例进行过拟合，请尝试下一个输入示例。

   • 此时，我们可能会注意到其中一些指令对第一个示例过拟合得太严重了。也许它们需要更多的细微差别。例如，也许它们需要明确的指令来澄清某些规格不足（underspecification），或者一些 if/else/then 子句。
   • 重复此整个过程，直到我们找到适用于所有多样化输入示例的系统指令。

6. 在此过程中，我们可能随意编辑了系统指令的文本，使其适用于所有输入示例。现在是清理该文本的时候了。例如，添加章节标题、修正拼写错误等。完成此操作后，验证指令是否仍然适用于所有输入示例。如果不适用，请使用上述过程系统地调试它们。但不要以步骤 (2) 中的 MVP 系统指令为基础，而是使用当前清理后的文本状态。

   • 出现某种情况并不令人惊讶：在某些模型上，“混乱”的提示词比“干净”的效果更好。这引发了一系列问题：
     • 相对于其性能，维护此提示词有多重要？
     • 我们是否有针对生产环境中模型行为的监控？此次部署是否重要到值得这样做？

7. 也许有一天，从输入示例到系统指令的整个流程将由用于生成指令的元优化器（meta-optimizer）可靠地自动化。那将很棒，但我们不应被愚弄！这里没有免费的午餐。在使用机器学习（ML）系统时，总有一个旋钮需要调节。总有一些反复的定性工作需要进行，以确保我们的模型的相关性感知（即“电影宇宙”）与我们作为开发者在面对特定输入示例数据集时发现的相关内容保持一致。永远不可能凭空消除定性分析的艰苦工作，原因就像永远不可能凭空消除培训我们工程团队新成员的艰苦工作一样。提高工具的抽象程度仅仅将定性工作的焦点和“活化能”转移到了不同的抽象层级。但这并不意味着此类工具不能有用！

[!IMPORTANT] 永远不可能凭空消除定性分析的艰苦工作，原因就像永远不可能凭空消除培训我们工程团队新成员的艰苦工作一样。

关于大语言模型（LLMs）何时有用的几点思考

我们已经花了很多篇幅讨论如何思考提示工程。也值得花一分钟谈谈“为什么”LLM 可能会证明是有用的。尽管这个领域非常新兴且创新迅速。因此，本节内容可能在几个月内迅速过时。

LLM 最适合于答案难以生成但易于检查的场景。我们推荐 Chris Gorgolewski 的 这篇文章。根据我们的经验，如果我们将 LLM 用于不符合这一条件的场景，我们会遇到问题。

与其编写难以理解、调试等的单体提示词，不如将问题分解为子问题并将推理链式连接起来。如果我们使每个子问题足够小，它们通常定义得更好，也更易于检查/评估。

硬件、商业模式等方面可能会有重大创新，以继续解锁更多的推理能力。我们应该去球将要落到的地方，而不是它现在所在的地方。

假设推理成本很快会变得“便宜到无法计量”、“足够好”或围绕“价值”而非“成本”导向，似乎更具未来保障。也就是说，如果我们在一个更有价值但需要更多推理调用才能可靠工作的功能，与一个价值低得多但成本更低的功能之间做权衡，那么以前者为导向似乎更具未来保障。并且或许通过限制发布范围等方式来解决当前的单位经济问题。如果我们开始看到类似于摩尔定律的现象，但是是针对 LLM 推理的价格下降，我们也不会感到惊讶。

更多资源

关于提示词（Prompting）的在线优质资源非常丰富，这里无法一一列举。我们并非唯一在思考提示词工程的人。本指南仅仅汇集了我们一些非正式的想法。但在互联网上确实有非常多的优秀成果。例如：

• AI 提示工程：深度解析 by Anthropic.
• 本指南 from OpenAI.
• 本指南 for Gemini.

思考“高语境”和“低语境”文化之间的差异也颇有趣味。我们经验性地发现，那些善于向模型提问的人，与那些擅长在低语境文化中进行有效沟通的人之间，存在着显著的交集。这很好理解，因为大语言模型（LLM）其实并不清楚它应该处于哪个“电影宇宙”中运作。它需要明确的指令来明确其角色扮演的身份、所处位置，以及环境中哪些信息是相关的。

从个人经验来看，练习 非暴力沟通（Nonviolent Communication） 会非常有帮助。它教会了人们区分可观察的行为和内心的独白。这种区分对于用可观察的行为来表述指令非常有帮助。虽然不言而喻，我们练习非暴力沟通最初并不是为了更擅长向模型提问。

致谢

• 感谢 Slav Petrov 和 Sian Gooding 在最终审查期间审阅了本文档。
• 感谢 Anna Bortsova 在文档最终版本的起草过程中提供了许多有益的评论/反馈。
• 感谢 Jennimaria Palomaki, James Wexler, Vera Axelrod 提出了许多有用的修改建议。

prompt-tuning-playbook 快速上手指南

本指南旨在帮助开发者快速理解并使用 prompt-tuning-playbook。该工具主要是一份关于后训练大语言模型（Post-trained LLMs，如 Gemini）提示词调优的最佳实践文档与方法论集合，而非传统的可执行代码库。

环境准备

由于本项目主要为文档资源，对环境要求极低：

• 系统要求：任何支持文本浏览的操作系统（Windows, macOS, Linux）。
• 前置依赖：
  • 互联网连接（用于访问在线文档或克隆仓库）。
  • （可选）Git 客户端（用于本地离线阅读）。
  • Markdown 阅读器（如 VS Code, Typora 或浏览器）。

安装步骤

本项目无需编译或安装依赖包，主要通过获取源代码或在线查看方式使用。

1. 在线查看 直接访问项目的 GitHub 页面或文档链接阅读 README 文件。

2. 本地克隆（推荐） 若需离线参考，可使用 Git 将仓库克隆到本地：

   git clone <repository-url>
   cd prompt-tuning-playbook
   

   请将 <repository-url> 替换为实际的项目地址。

基本使用

本“工具”的核心价值在于其提供的思维模型和操作流程。以下是基于文档内容的核心使用方法：

1. 理解核心概念

在阅读具体技巧前，先建立正确的心理模型：

• 预训练 (Pre-training)：理解模型通过互联网数据学习到了多种“电影宇宙”（Cinematic Universe），即不同的语境和事实体系。
• 后训练 (Post-training)：理解后训练赋予了模型默认的“角色”和行为准则（如遵循指令、符合社会规范）。

2. 应用提示词风格指南

参考文档中的 "A rudimentary 'style guide' for prompts" 部分优化你的 Prompt：

• 避免模糊：不要使用过于通用的开场白（如 "Hi, how are you?"），这会让模型难以确定所处的“宇宙”。
• 提供强信号：在 Prompt 中明确风格、主题和上下文约束。

示例：

# 较差的 Prompt
请写一篇关于纽约的文章。

# 推荐的 Prompt
The concrete jungle where dreams are made of isn't just a catchy lyric – it's the electric truth of New York City. From the soaring skyscrapers that pierce the clouds to the vibrant pulse of its diverse neighborhoods, NYC offers an experience unlike any other on Earth. 
(续写以下内容，保持这种充满活力的博客风格...)

3. 迭代系统指令

按照文档中的 "Procedure for iterating on new system instructions" 流程进行优化：

1. 定义具体的任务目标。
2. 编写初始系统指令。
3. 测试并观察模型行为是否符合预期的“默认宇宙”。
4. 根据反馈调整指令，直到模型行为一致且安全。

通过遵循上述步骤，你可以更系统地利用该 Playbook 提升与大语言模型的交互效果。