对Google whitepaper的最佳实践部分内容进行了简单的整理，感谢Google.
最重要的最佳实践是在提示中提供（单样本 / 少样本）示例。这非常有效，因为它是一种强大的教学工具。这些示例展示了所需的输出或相似的响应，允许模型从中学习并相应地调整其生成内容。这就像给模型一个参考点或目标，以提高其响应的准确性、风格和语气，使其更好地符合输出期望。
提示应该简洁、清晰，并且易于您和模型理解。通常的经验法则是，如果您已经感到困惑，那么模型也很可能会感到困惑。尽量不要使用复杂的语言，也不要提供不必要的信息。
示例：
- 修改前：我正在纽约游玩，想了解更多好玩的地方。我带着两个3岁的孩子。我们假期应该去哪里 ？
- 修改后：扮演一名旅行指南。描述纽约曼哈顿适合带3岁孩子游玩的好地方。
尝试使用描述动作的动词。以下是一些示例： 行动 (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，或者可能过于通用。在提示中提供具体细节（通过系统或上下文提示）可以帮助模型专注于相关内容，从而提高整体准确性。
示例：
- 应该这样做：生成一篇关于五大视频游戏机的3段博客文章。博客文章应该信息丰富、引人入胜，并且以对话式风格编写。
- 不应该这样做：生成一篇关于视频游戏机的博客文章。
指令和限制在提示中用于引导LLM的输出。
- 指令提供关于响应所需格式、风格或内容的明确指示。它指导模型应该做什么或产生什么。
- 限制是一组对响应的局限或边界。它限制了模型不应该做什么或避免什么。
指令直接传达所需的成果，而限制可能让模型猜测允许什么。指令在定义的边界内提供灵活性并鼓励创造力，而限制可能会限制模型的潜力。此外，一系列限制可能会相互冲突。
但是限制在某些情况下仍然有价值。例如，当需要防止模型生成有害或有偏见的内容或当需要严格的输出格式或风格时。
示例：
- 应该这样做：生成一篇关于五大视频游戏机的1段博客文章。只讨论主机、制造公司、年份和总销量。
- 不应该这样做：生成一篇关于五大视频游戏机的1段博客文章。不要列出视频游戏名称。
首先优先使用指令，清楚地说明您希望模型做什么，并且只有在安全、清晰或特定要求必要时才使用限制。实验并迭代以测试指令和限制的不同组合，以找到最适合您特定任务的方法，并记录这些。
为了控制生成的LLM响应的长度，您可以在配置中设置最大token限制，或者在提示中明确请求特定长度。 示例：“用一条推文的长度解释量子物理学。”
为了重复使用提示并使其更具动态性，请在提示中使用变量，这些变量可以根据不同的输入进行更改。例如，如表20所示，一个给出城市事实的提示。与其在提示中硬编码城市名称，不如使用变量。变量可以通过让您避免重复自己来节省时间和精力。如果您需要在多个提示中使用相同的信息，可以将其存储在变量中，然后在每个提示中引用该变量。当将提示集成到您自己的应用程序中时，这非常有意义。
示例：
- 提示：
VARIABLES
{city} = "Amsterdam"
PROMPT
You are a travel guide. Tell me a fact about the city: {city}
- 输出：阿姆斯特丹是一个美丽的城市，布满了运河、桥梁和狭窄的街道。它是一个拥有丰富历史、文化和夜生活的好地方。
不同的模型、模型配置、提示格式、措辞和提交方式可能会产生不同的结果。因此，尝试提示属性（如风格、措辞和提示类型（零样本、少样本、系统提示））非常重要。
例如，一个旨在生成关于革命性视频游戏机 Sega Dreamcast 的文本的提示，可以被表述为一个问题、一个陈述或一个指令，从而产生不同的输出：
- 问题：Sega Dreamcast 是什么？为什么它是一款如此具有革命性的游戏机 ？
- 陈述：Sega Dreamcast 是 Sega 于 1999 年发布的第六代视频游戏机。它...
- 指令：写一段话描述 Sega Dreamcast 游戏机并解释其革命性的原因。
一般来说，少样本示例的顺序应该没有太大影响。但是，在进行分类任务时，确保少样本示例的顺序是打乱的，或者至少与给出的分类顺序是不一致的。否则LLM可能会过度拟合示例的特定顺序，换句话说，LLM可能学习到的是分类的顺序，而不是分类的规则。
举个例子，让模型执行分类任务（例如，将电影评论分为“正面”、“负面”、“中立”等）时，在提供示例时，应该打乱这些示例中不同类别的顺序，而不是把所有正面评论放在前面，然后把所有负面评论放在后面。
了解模型架构变化、新增数据和功能非常重要。尝试更新的模型版本，并调整提示策略以更好地利用新的模型功能。
除了提示输入格式，考虑规定输出格式。对于非创造性任务，如数据提取、选择、解析、排序、排名或分类，尝试输出以结构化格式（如 JSON 或 XML）返回。从提示中返回 JSON 对象的好处除了不需要手动创建这种 JSON 格式之外，最重要的是它会强制模型创建结构并限制幻觉。
- 对于 CoT 提示，需要在推理之后给出答案，因为推理的生成会改变模型在预测最终答案时获得的 tokens。
- 使用 CoT 和自洽性时，您需要能够从提示中提取最终答案，并将其与推理分开。
- 对于 CoT 提示，将温度设置为0。
- 思维链提示基于贪婪解码，它根据语言模型分配的最高概率预测序列中的下一个词。一般来说，在使用推理得出最终答案时，很可能只有一个正确答案。因此，温度应始终设置为0。
这是用户自我的迭代学习，详细记录所有提示尝试，这样您就可以随着时间的推移了解哪些地方做得好，哪些地方做得不好。
建议使用表1作为模板创建 Google Sheet。
除了此表中的字段，记录提示的版本（迭代）、捕获结果是否正常/不正常/有时正常的字段以及捕获反馈的字段也很有帮助。
在开发检索增强生成（RAG）系统时，您还应该捕获影响插入提示内容的 RAG 系统的特定方面，包括查询、块设置、块输出和其他信息。
一旦您觉得提示接近完美，就将其添加到您的项目代码库中。在代码库中，将提示保存在与代码分开的文件中，以便于维护。最后，理想情况下，您的提示是操作化系统的一部分，作为提示工程师，您应该依赖自动化测试和评估程序来了解您的提示在任务上的泛化程度。
提示工程是一个迭代的过程。创建和测试不同的提示，分析和记录结果。根据模型的性能改进您的提示。不断试验直到您达到所需的输出。当您更改模型或模型配置时，请返回并继续使用以前使用的提示进行实验。
表1. 记录提示的模板。
| 条目 | 内容 |
|---|---|
| 名称 | [提示的名称和版本] |
| 目标 | [对此尝试目标的单句解释] |
| 模型 | [所用模型的名称和版本] |
| 温度 | [0-1之间的值] |
| Token 限制 | [数字] |
| Top-K | [数字] |
| Top-P | [数字] |
| 提示 | [写出所有完整提示] |
| 输出 | [写出输出或多个输出] |