Google「提示词工程」白皮书阅读总结
本文最后更新于 2025年4月21日 晚上
前言
注意,本文不是翻译,只是针对自己觉得有用的一些地方的记录和总结;对于我自己觉得已经比较清楚的概念,就完全没有记录。其中最后的「最佳实践 Best Practice」部分个人感觉比较有用,强烈建议结合原版 PDF 的一些示例 demo 进行对比查看。
简单介绍:
「Prompt Engineering」是 Google 推出的提示词工程白皮书,一共 60 多页,原始版本可以在 https://www.kaggle.com/whitepaper-prompt-engineering 上获取到,或者直接 下载链接 (googledrive)。
1 - 采样控制
主要三个可配置项:
- Top-P
- Top-K
- Temperature (温度)
作用的先后顺序: Top-K -> Top-P -> Temperature
例子
假设我们有以下设置:
- top-k = 5
- top-p = 0.9
- temperature = 0.7
当模型预测下一个词时,可能给出了这样的概率分布:
- “的”: 0.3
- “是”: 0.25
- “在”: 0.2
- “了”: 0.1
- “有”: 0.05
- “和”: 0.03
- “人”: 0.02
- 其他词: 各小于0.01
应用步骤:
- top-k=5筛选后,只保留前5个词:“的”、“是”、“在”、“了”、“有”
- 计算这5个词的累积概率:0.3+0.25+0.2+0.1+0.05=0.9,正好等于top-p的阈值0.9,所以这5个词都被保留
- 应用temperature=0.7,通常来说,温度与模型的“创造力”有关。但事实并非如此。温度只是调整单词的概率分布。其最终的宏观效果是,在较低的温度下,我们的模型更具确定性,而在较高的温度下,则不那么确定。(ref: 知乎: 大模型文本生成——解码策略(Top-k & Top-p & Temperature))
极端情况
几种极端情况的 LLM 实现考虑:
- 温度设为 0 时,Top-K 和 Top-P 无关,概率最高的令牌被选为下一个预测令牌;温度极高(如 10 量级)时,温度无关,Top-K 和/或 Top-P 标准的令牌将被随机采样。
- Top-K 设为 1 时,温度和 Top-P 无关,仅概率最高的令牌被选;Top-K 设为词汇表大小时,所有非零概率令牌均满足标准,无令牌被筛选。
- Top-P 设为 0 或极小时,仅概率最高的令牌满足标准,温度和 Top-K 无关;Top-P 设为 1 时,所有非零概率令牌均满足标准,无令牌被筛选。
推荐配置
Use Case | Temperature | Top-P | Top-K | Description |
---|---|---|---|---|
通用场景 General Purpose | 0.2 | 0.95 | 30 | Relatively coherent results with some creativity |
高创造力场景 High Creativity | 0.9 | 0.99 | 40 | Especially creative results |
比较精确的场景 (比如coding) Low Creativity |
0.1 | 0.9 | 20 | Less creative results |
Single Correct Answer | 0 | - | - | For tasks with only one correct answer (e.g., math problems) |
2 - Guide Prompt 分类
系统提示(System Prompting)、上下文提示(Contextual Prompting)和角色提示(Role Prompting)都是用于指导大型语言模型(LLMs)生成文本的技术,但它们关注的重点不同。尽管这些提示类型之间存在相当大的重叠(例如,一个提示可能同时为系统分配角色并提供上下文),但每种提示的主要目的略有不同。
以下是三种提示类型的核心区别和作用:
提示类型 | 主要目的与功能 | 特点与作用 |
---|---|---|
System Prompt | 定义模型的基本能力和总体目的。 | 设定语言模型的“大局观”,例如翻译语言、分类评论等,指导模型的整体行为。 |
Contextual Prompt | 提供与当前对话或任务相关的具体细节或背景信息,指导模型生成针对性的回应。 | 高度特定于当前任务或输入,具有动态性,帮助模型理解细微差别并调整回应。 |
Role Prompt | 为模型分配特定的角色或身份,帮助模型生成与该角色一致的回应。 | 塑造模型的输出风格和语气,增加具体性和个性,使回应符合角色的知识和行为。 |
system prompt
1 |
|
contextual prompt
1 |
|
role prompt
1 |
|
3 - 示例个数: one-shot & few-shot
在为AI模型创建提示时,提供示例非常有帮助。示例可以帮助模型理解您的需求,尤其是在希望模型输出特定结构或模式时特别有用。
- One-shot 提示提供单个示例,因此得名one-shot,目的是让模型有一个可以模仿的示例来完成任务。
- Few-shot 提示则提供多个示例,向模型展示需要遵循的模式,增加模型遵循该模式的机会。Few-shot提示所需的示例数量取决于任务复杂性、示例质量以及所使用的generative AI (gen AI)模型的能力。一般建议至少使用三到五个示例,但对于复杂任务可能需要更多示例,或者由于模型输入长度限制可能需要更少。选择示例时,应确保示例与任务相关,具有多样性、高质量且编写良好,因为一个小错误就可能导致模型混淆并输出不符合预期的结果。此外,如果希望生成的输出能适应各种输入,包含edge cases(异常或意外输入)在示例中非常重要。
4 - Step-back Prompting (回退提示词)
Step-back prompting 是一种通过提示 LLM 先考虑与具体任务相关的一般性问题,然后将该问题的答案输入到后续的具体任务提示中来提升性能的技术。这种“step back”方法使 LLM 在尝试解决具体问题之前激活相关的背景知识和推理过程。通过考虑更广泛和基本的原则,LLM 能够生成更准确和有洞察力的回应。
Step-back prompting 鼓励 LLM 批判性思考并以新的和创造性的方式应用知识,通过利用 LLM 参数中的更多知识来改变执行任务的最终提示,而这些知识在直接提示 LLM 时可能不会被激活。它还可以通过关注一般原则而非具体细节来帮助减轻 LLM 回应中的偏见。
传统 prompt & step-back prompt 对比
传统 prompt:
1 |
|
step-back prompt:
- 首先询问:
1 |
|
- 之后基于 LLM 的回答,追加提问:
1 |
|
5 - APE: Automatic Prompt Engineering (自动生成提示词)
编写提示(prompt)可能是一项复杂的任务。为了解决这个问题,可以采用Automatic Prompt Engineering (APE)方法。这种方法不仅减少了人工输入的需求,还能提升模型在各种任务中的表现。你可以让模型生成更多提示,对它们进行评估,可能的话修改好的提示,然后重复这个过程。
case:
1 |
|
6 - Code Prompting
这节没什么特别出彩的,就是列举了几个 coding 的用法,不过可以参考一下 Gemini 在 coding 时是如何推荐配置 topk, topp 和 temperature 的
-
Temperature:0.1
-
Token Limit:1024
-
Top-K:N/A
-
Top-P:1
-
writing code
1 |
|
- explain code
1 |
|
- translating code
1 |
|
- debug code
1 |
|
7 - 最佳实践 Best Practices
这个很有价值,一些很容易想到和验证的概念,但是 Google 帮你总结出来了
7.1 - 提供示例 (Provide examples)
最重要的原则是在提示中提供示例(one shot/few shot)。这是高效的方法,因为它能作为强大的教学工具。这些示例展示了期望的输出或类似的响应,让模型从中学习并相应地调整其生成内容,提高准确性、风格和语调。
7.2 - 设计简洁明了的提示 (Design with Simplicity)
提示应该简洁、清晰,易于你和模型理解。如果对你来说已经令人困惑,对模型来说也可能令人困惑。尽量不要使用复杂的语言,不要提供不必要的信息。
示例改进:
1 |
|
尝试使用描述动作的动词,例如: Act, Analyze, Categorize, Classify, Contrast, Compare, Create, Describe, Define, Evaluate, Extract, Find, Generate, Identify, List, Measure, Organize, Parse, Pick, Predict, Provide, Rank, Recommend, Return, Retrieve, Rewrite, Select, Show, Sort, Summarize, Translate, Write.
7.3 - 明确指定输出要求 (Be Specific About Output)
要明确期望的输出内容。简洁的指令可能不足以引导LLM或过于笼统。在提示中提供具体细节(通过系统或上下文提示)可以帮助模型专注于相关内容,提高整体准确性。
推荐做法:
1 |
|
不推荐的做法:
1 |
|
7.4 - 使用指令而非约束 (Use Instructions over Constraints)
- 指令提供了关于期望格式、风格或内容的明确指导,指导模型应该做什么或生成什么
- 约束是对响应的一系列限制或边界,限制模型不应该做什么或避免什么
研究表明,在提示中专注于积极指令比过度依赖约束更有效。这与人类偏好积极指令而非列出不应做的事项的方式一致。
指令直接传达期望的结果,而约束可能让模型猜测什么是允许的。指令在定义的边界内提供灵活性并鼓励创造力,而约束可能限制模型的潜力。此外,约束列表可能相互冲突。
约束在某些情况下仍然有价值,例如防止模型生成有害或有偏见的内容,或当需要严格的输出格式或风格时。
如果可能,使用积极指令:不要告诉模型不要做什么,而是告诉它应该做什么。这可以避免混淆并提高输出的准确性。
示例:
1 |
|
7.5 - 控制最大token长度 (Control Max Token Length)
要控制生成的LLM响应的长度,你可以在配置中设置最大token限制,或在提示中明确要求特定长度。例如:
1 |
|
7.6 - 在 Prompt 中使用变量 (Use Variables in Prompts)
在提示中使用变量,可以针对不同输入而改变。例如,提供关于城市的事实的提示。与其在提示中硬编码城市名称,不如使用变量。变量可以通过避免重复自己来节省时间和精力。如果需要在多个提示中使用相同的信息,可以将其存储在变量中,然后在每个提示中引用该变量。在将提示集成到自己的应用程序中时,这非常有意义。
示例:
1 |
|
7.7 - 实验不同的输入格式和写作风格 (Experiment with Input Formats)
不同的模型、模型配置、提示格式、词汇选择和提交方式可能产生不同的结果。因此,实验提示属性如风格、词汇选择和提示类型(零样本、少样本、系统提示)很重要。
例如,对于一个目标是 “生成关于革命性视频游戏机Sega Dreamcast的文本” 的 Prompt,其可以表述为问题、陈述或指令,产生不同的输出:
- 问题:Sega Dreamcast是什么,为什么它是如此革命性的游戏机?
- 陈述:Sega Dreamcast是世嘉于1999年发布的第六代视频游戏机。它…
- 指令:写一段描述Sega Dreamcast游戏机并解释为何它如此革命性的单段文字。
7.8 - 分类任务中混合类别 (Mix Classes in Few-shot)
一般来说,few-shot (少样本)示例的顺序不太重要。然而,在进行分类任务时,确保在few-shot示例中混合可能的响应类别。这是因为否则你可能会过度拟合到示例的特定顺序。通过混合可能的响应类别,你可以确保模型正在学习识别每个类别的关键特征,而不是简单地记住示例的顺序。这将导致在未见数据上更强健和可泛化的性能。
一个好的经验法则是从6个few-shot 示例开始,并从那里开始测试准确性。
7.9 - 适应模型更新 (Adapt to Model Updates)
跟踪模型架构变化、添加的数据和功能很重要。尝试更新的模型版本,并调整提示以更好地利用新的模型特性。
7.10 - 尝试不同的输出格式 (Experiment with Output Formats)
例如,对于非创造性任务,如提取、选择、解析、排序、排名或分类数据,尝试让输出以结构化格式如JSON或XML返回。
从提取数据的提示中返回JSON对象有一些好处。在真实应用中,我不需要手动创建JSON格式,可以直接以排序顺序返回数据(处理日期时间对象时非常方便),但最重要的是,通过提示要求JSON格式,它迫使模型创建结构并限制产生幻觉。
使用JSON输出的好处总结:
- 始终以相同风格返回
- 专注于你想要接收的数据
- 幻觉机会减少
- 使其关系感知
- 获得数据类型
- 可以排序
7.11 - 关于思维链(CoT)的最佳实践 (Chain of Thought Best Practices)
对于CoT Prompt,将答案放在推理之后是必需的,因为推理的生成会改变模型在预测最终答案时获得的tokens。
使用CoT和自我一致性时,你需要能够从提示中提取最终答案,与推理分开。
对于CoT Prompt,将temperature设置为0。
思维链提示基于贪婪解码,根据语言模型分配的最高概率预测序列中的下一个词。一般来说,使用推理来得出最终答案时,可能只有一个正确答案。因此,temperature始终应设置为0。
7.12 - 尝试与记录 (Document Prompt Attempts)
前面已经提到过,但我们再次强调:详细记录你的提示尝试,这样你可以随时了解哪些方法行之有效,哪些不行。
提示输出可能在不同模型、不同采样设置,甚至同一模型的不同版本之间有所不同。此外,即使对同一模型的相同提示,输出句子格式和词汇选择也可能存在细微差异。(例如,如前所述,如果两个tokens具有相同的预测概率,则可能随机打破平局。这可能影响后续预测的tokens。)
建议创建一个Google表格,使用模板记录:
- 提示名称和版本
- 目标(一句话解释这次尝试的目标)
- 使用的模型名称和版本
- Temperature值(0-1之间)
- Token限制
- Top-K和Top-P值
- 完整提示
- 输出(或多个输出)
还建议跟踪提示的版本(迭代),记录结果是否OK/NOT OK/SOMETIMES OK,以及反馈。如果有幸使用Vertex AI Studio,保存提示(使用与文档中相同的名称和版本),并在表格中跟踪保存的提示超链接。这样,你只需一次点击就可以重新运行提示。
在使用检索增强生成系统时,还应捕获影响插入到提示中的内容的RAG系统的特定方面,包括查询、块设置、块输出和其他信息。
一旦你觉得提示接近完美,将其带入项目代码库。在代码库中,将提示保存在与代码分开的文件中,这样更容易维护。最后,理想情况下,你的提示是一个可操作系统的一部分,作为提示工程师,你应该依靠自动化测试和评估程序来了解你的提示如何针对任务泛化。
提示工程是一个迭代过程。制作并测试不同的提示,分析并记录结果。根据模型的表现改进你的提示。继续实验直到达到期望的输出。当更改模型或模型配置时,回去继续实验先前使用的提示。