Prompt Engineering

Design with simplicity

简洁设计：提示应该简洁清晰，易于理解(对个人和模型来说都是如此)。根据我的经验来讲，如果他对您来说已经令人非常的困惑，那么他很有可能对模型来说也是同样令人困惑的。尽量不要使用复杂的语言，也不要提供不必要的信息，有的时候少即是多，虽然上下文是好的，但不必要的行话或过于复杂的句子结构可能会混淆模型，所以提供直接、清晰的语言是首选。

示例：

Before: 我现在正在北京，我想了解更多地点的信息，我和我两个孩子在一起，我们应该去哪里玩？ After: 扮演游客的旅行指南。描述在北京适合带孩子参观的好地方。

尝试使用描述动作的动词，下面是一些示例：

扮演 (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).

Be specific about the output

具体说明输出：对于你期望的回答，要对他的输出格式做出具体的要求。简洁的指令可能不足以指导 LLM 或者可能过于笼统，在提示中提供具体细节，可以帮助模型专注于相关内容，提高整体准确性，不要猜测模型知道您想要什么，要明确的说明条件。

示例：

DO: 生成一篇关于销量排名前5的游戏机的博客文章。并应以对话式风格编写

DO NOT: 生成一篇关于游戏机的博客文章

Use Instructions over Constraints

使用指令而非约束: 指令和约束在Prompt中用于指导LLM的输出。

• Instructions 指令：提供关于响应的期望格式、风格或内容的明确指示。他指导模型应该做什么或产生什么。
• Constraint 约束：是对响应的一组限制或边界。他限制模型不应该做什么或避免什么。

越来越多的研究表明，在提示中专注于积极指令可能比严重依赖约束更有效。这种方法与人类更喜欢积极指令而非一堆“不要做”列表的偏好相一致。以积极的方式提出请求（包含什么）通常比消极约束（排除什么）更清晰，更不容易被误解或产生冲突。

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

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

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

示例：

DO：生成一篇关于排名前5的游戏机的1段博客文章，仅讨论游戏机本身、制造商公司、年份和总销量。

DO NOT：生成一篇关于排名前5的游戏机的1段博客文章，不要列出游戏名称

作为最佳实践，首先优先考虑指令，清楚地说明您希望模型做什么，仅在出于安全、清晰或特定要求需要时才使用约束。进行实验和迭代，测试指令和约束的不同组合，以找到最适合您特定任务的方法，并记录这些尝试。

Control the max token length

控制最大令牌长度：要控制生成的 LLM 响应的长度，您可以在配置中设置最大令牌限制，或者在提示中明确请求特定长度。

例如："用一条推文长度的消息解释量子物理学。"

长度可以通过技术（配置）和语义（提示）两种方式进行管理。基于提示的控制允许更细致的长度规范（例如，“用 3 句话”，“推文长度”）。

Experiment with input formats and writing styles

尝试不同的输入格式和写作风格：不同的模型、模型配置、提示格式、措辞选择甚至提交都可能产生不同的结果。因此，尝试提示属性（如风格、措辞选择和提示类型（零样本、少样本、系统提示））非常重要 。LLM 对输入的精确措辞和格式可能出奇地敏感。微小的变化可能导致不同的输出，这再次强调了实验的必要性。

例如，一个目标是生成关于革命性视频游戏机世嘉 Dreamcast 文本的提示，可以表述为问题、陈述或指令，从而产生不同的输出：

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

For few-shot prompting with classification tasks, mix up the classes

对于带分类任务的少样本提示，混合类别：一般来说，少样本示例的顺序不应有太大影响。但是，在进行分类任务时，请确保在少样本示例中混合可能的响应类别。这样做是因为您可能否则会过度拟合示例的特定顺序。通过混合可能的响应类别，您可以确保模型正在学习识别每个类别的关键特征，而不仅仅是记忆示例的顺序。这将导致在未见过的数据上表现更鲁棒和更具泛化性。在少样本分类中，示例的顺序可能无意中成为一个信号。混合类别迫使模型依赖示例的实际内容来区分类别，而不是仅仅依赖它们在序列中的位置 。

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

Adapt to model updates

适应模型更新：了解模型架构变化、新增数据和能力非常重要。尝试更新的模型版本，并调整您的提示以更好地利用新模型特性。像 Vertex AI Studio 这样的工具非常适合存储、测试和记录您提示的各种版本 。提示工程不是一次性任务。今天效果好的提示可能随着底层模型的演变而需要调整。持续测试和适应是必要的。

Experiment with output formats

尝试不同的输出格式：除了提示输入格式，考虑尝试输出格式。对于非创造性任务，如提取、选择、解析、排序、排名或分类数据，尝试让您的输出以结构化格式（如 JSON 或 XML）返回。明确要求结构化输出（如 JSON）可以作为一种强约束，提高可靠性并减少无意义或非结构化的响应，尤其对于面向数据的任务。

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

CoT Best practices

CoT 最佳实践：对于 CoT 提示，将答案放在推理之后是必需的，因为推理的生成会改变模型预测最终答案时获得的令牌。

对于 CoT 和自我一致性，您需要能够从提示中提取最终答案，并将其与推理分开。

对于 CoT 提示，将温度设置为 0。思维链提示基于贪婪解码，根据语言模型分配的最高概率预测序列中的下一个词。一般来说，当使用推理来得出最终答案时，很可能只有一个正确的答案。因此，温度应始终设置为 0。有效使用 CoT 需要注意具体的实现细节，如答案放置、可提取性和适当的配置（低/零温度）。