Google 「Prompt Engineering」提示词工程白皮书阅读总结

前言

注意，本文不是翻译，只是针对自己觉得有用的一些地方的记录和总结；对于我自己觉得已经比较清楚的概念，就完全没有记录。其中最后的「最佳实践 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

应用步骤：

1. top-k=5筛选后，只保留前5个词：“的”、“是”、“在”、“了”、“有”
2. 计算这5个词的累积概率：0.3+0.25+0.2+0.1+0.05=0.9，正好等于top-p的阈值0.9，所以这5个词都被保留
3. 应用temperature=0.7，这会使概率分布更加平滑，减小高概率词与低概率词的差距：
   • 较高的temperature（>1.0）会使分布更均匀，增加采样的随机性和创造性
   • 较低的temperature（&LT1.0）会使分布更集中，减少随机性，增加可预测性
   • 例如，调整后"的"的概率可能从0.3降到0.28，而"有"的概率可能从0.05升到0.07

几种极端情况的 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 时，所有非零概率令牌均满足标准，无令牌被筛选。

2 - Prompt 分类

系统提示（System Prompting）、上下文提示（Contextual Prompting）和角色提示（Role Prompting）都是用于指导大型语言模型（LLMs）生成文本的技术，但它们关注的重点不同。尽管这些提示类型之间存在相当大的重叠（例如，一个提示可能同时为系统分配角色并提供上下文），但每种提示的主要目的略有不同。

以下是三种提示类型的核心区别和作用：

3 - Step-back Prompting (回退 Prompt)

Step-back prompting 是一种通过提示 LLM 先考虑与具体任务相关的一般性问题，然后将该问题的答案输入到后续的具体任务提示中来提升性能的技术。这种“step back”方法使 LLM 在尝试解决具体问题之前激活相关的背景知识和推理过程。通过考虑更广泛和基本的原则，LLM 能够生成更准确和有洞察力的回应。

Step-back prompting 鼓励 LLM 批判性思考并以新的和创造性的方式应用知识，通过利用 LLM 参数中的更多知识来改变执行任务的最终提示，而这些知识在直接提示 LLM 时可能不会被激活。它还可以通过关注一般原则而非具体细节来帮助减轻 LLM 回应中的偏见。

传统 prompt:

step-back prompt:

1. 首先询问:

1. 之后基于 LLM 的回答，追加提问:

4 - APE: Automatic Prompt Engineering (自动生成提示词)

编写提示（prompt）可能是一项复杂的任务。为了解决这个问题，可以采用Automatic Prompt Engineering (APE)方法。这种方法不仅减少了人工输入的需求，还能提升模型在各种任务中的表现。你可以让模型生成更多提示，对它们进行评估，可能的话修改好的提示，然后重复这个过程。

case:

5 - Code Prompting

这节没什么特别出彩的，就是列举了几个 coding 的用法，不过可以参考一下 Gemini 在 coding 时是如何推荐配置 topk, topp 和 temperature 的

• Temperature：0.1
• Token Limit：1024
• Top-K：N/A
• Top-P：1
• writing code

• explain code

• translating code

• debug code

6 - 最佳实践 Best Practices

这个很有价值，一些很容易想到和验证的概念，但是 Google 帮你总结出来了

最重要的原则是在提示中提供示例（one shot/few shot）。这是高效的方法，因为它能作为强大的教学工具。这些示例展示了期望的输出或类似的响应，让模型从中学习并相应地调整其生成内容，提高准确性、风格和语调。

提示应该简洁、清晰，易于你和模型理解。如果对你来说已经令人困惑，对模型来说也可能令人困惑。尽量不要使用复杂的语言，不要提供不必要的信息。

示例改进：

尝试使用描述动作的动词，例如: 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.

要明确期望的输出内容。简洁的指令可能不足以引导LLM或过于笼统。在提示中提供具体细节（通过系统或上下文提示）可以帮助模型专注于相关内容，提高整体准确性。

推荐做法：

不推荐的做法:

• 指令提供了关于期望格式、风格或内容的明确指导，指导模型应该做什么或生成什么
• 约束是对响应的一系列限制或边界，限制模型不应该做什么或避免什么

研究表明，在提示中专注于积极指令比过度依赖约束更有效。这与人类偏好积极指令而非列出不应做的事项的方式一致。

指令直接传达期望的结果，而约束可能让模型猜测什么是允许的。指令在定义的边界内提供灵活性并鼓励创造力，而约束可能限制模型的潜力。此外，约束列表可能相互冲突。

约束在某些情况下仍然有价值，例如防止模型生成有害或有偏见的内容，或当需要严格的输出格式或风格时。

如果可能，使用积极指令：不要告诉模型不要做什么，而是告诉它应该做什么。这可以避免混淆并提高输出的准确性。

示例：

要控制生成的LLM响应的长度，你可以在配置中设置最大token限制，或在提示中明确要求特定长度。例如：

在提示中使用变量，可以针对不同输入而改变。例如，提供关于城市的事实的提示。与其在提示中硬编码城市名称，不如使用变量。变量可以通过避免重复自己来节省时间和精力。如果需要在多个提示中使用相同的信息，可以将其存储在变量中，然后在每个提示中引用该变量。在将提示集成到自己的应用程序中时，这非常有意义。

示例：

不同的模型、模型配置、提示格式、词汇选择和提交方式可能产生不同的结果。因此，实验提示属性如风格、词汇选择和提示类型（零样本、少样本、系统提示）很重要。

例如，对于一个目标是 “生成关于革命性视频游戏机Sega Dreamcast的文本” 的 Prompt，其可以表述为问题、陈述或指令，产生不同的输出：

• 问题：Sega Dreamcast是什么，为什么它是如此革命性的游戏机？
• 陈述：Sega Dreamcast是世嘉于1999年发布的第六代视频游戏机。它…
• 指令：写一段描述Sega Dreamcast游戏机并解释为何它如此革命性的单段文字。

一般来说，few-shot （少样本）示例的顺序不太重要。然而，在进行分类任务时，确保在few-shot示例中混合可能的响应类别。这是因为否则你可能会过度拟合到示例的特定顺序。通过混合可能的响应类别，你可以确保模型正在学习识别每个类别的关键特征，而不是简单地记住示例的顺序。这将导致在未见数据上更强健和可泛化的性能。

一个好的经验法则是从6个few-shot 示例开始，并从那里开始测试准确性。

跟踪模型架构变化、添加的数据和功能很重要。尝试更新的模型版本，并调整提示以更好地利用新的模型特性。

例如，对于非创造性任务，如提取、选择、解析、排序、排名或分类数据，尝试让输出以结构化格式如JSON或XML返回。

从提取数据的提示中返回JSON对象有一些好处。在真实应用中，我不需要手动创建JSON格式，可以直接以排序顺序返回数据（处理日期时间对象时非常方便），但最重要的是，通过提示要求JSON格式，它迫使模型创建结构并限制产生幻觉。

使用JSON输出的好处总结：

• 始终以相同风格返回
• 专注于你想要接收的数据
• 幻觉机会减少
• 使其关系感知
• 获得数据类型
• 可以排序

对于CoT Prompt，将答案放在推理之后是必需的，因为推理的生成会改变模型在预测最终答案时获得的tokens。

使用CoT和自我一致性时，你需要能够从提示中提取最终答案，与推理分开。

对于CoT Prompt，将temperature设置为0。

思维链提示基于贪婪解码，根据语言模型分配的最高概率预测序列中的下一个词。一般来说，使用推理来得出最终答案时，可能只有一个正确答案。因此，temperature始终应设置为0。

前面已经提到过，但我们再次强调：详细记录你的提示尝试，这样你可以随时了解哪些方法行之有效，哪些不行。

提示输出可能在不同模型、不同采样设置，甚至同一模型的不同版本之间有所不同。此外，即使对同一模型的相同提示，输出句子格式和词汇选择也可能存在细微差异。（例如，如前所述，如果两个tokens具有相同的预测概率，则可能随机打破平局。这可能影响后续预测的tokens。）

建议创建一个Google表格，使用模板记录：

• 提示名称和版本
• 目标（一句话解释这次尝试的目标）
• 使用的模型名称和版本
• Temperature值（0-1之间）
• Token限制
• Top-K和Top-P值
• 完整提示
• 输出（或多个输出）

还建议跟踪提示的版本（迭代），记录结果是否OK/NOT OK/SOMETIMES OK，以及反馈。如果有幸使用Vertex AI Studio，保存提示（使用与文档中相同的名称和版本），并在表格中跟踪保存的提示超链接。这样，你只需一次点击就可以重新运行提示。

在使用检索增强生成系统时，还应捕获影响插入到提示中的内容的RAG系统的特定方面，包括查询、块设置、块输出和其他信息。

一旦你觉得提示接近完美，将其带入项目代码库。在代码库中，将提示保存在与代码分开的文件中，这样更容易维护。最后，理想情况下，你的提示是一个可操作系统的一部分，作为提示工程师，你应该依靠自动化测试和评估程序来了解你的提示如何针对任务泛化。

提示工程是一个迭代过程。制作并测试不同的提示，分析并记录结果。根据模型的表现改进你的提示。继续实验直到达到期望的输出。当更改模型或模型配置时，回去继续实验先前使用的提示。

Generated by RSStT. The copyright belongs to the original author.

Source