Azure中提示工程API说明
虽然提示工程的原则可以在许多不同的模型类型间归纳，但某些模型需要专用的提示结构。 对于 Azure OpenAI GPT 模型，核心推荐CHAT API，提示工程可以在其中发挥作用：
CHAT API 支持 GPT-35-Turbo 和 GPT-4 模型。 这些模型旨在接收存储在字典数组中的[类似聊天的特定脚本]格式的输入。
系统消息
系统消息包含在提示的开头，用于为模型提供上下文、说明或与用例相关的其他信息。 可以使用系统消息来描述助手的个性，定义模型应回答和不应回答的内容，以及定义模型响应的格式。
下面的示例显示了示例系统消息和生成的模型响应：
系统消息的其他一些示例包括：
- “助手是由 OpenAI 训练的大型语言模型。”
- “助手是一种智能聊天机器人，旨在帮助用户回答有关 Azure OpenAI 服务的技术问题。 仅使用以下上下文回答问题，如果不确定答案，可以说“我不知道”。
- “助手是一种智能聊天机器人，旨在帮助用户回答其税务相关问题。”
- “你是一名助手，旨在从文本中提取实体。 用户将粘贴文本字符串，你将使用从文本中提取的实体作为 JSON 对象进行响应。 下面是输出格式的示例：
{
"name": "",
"company": "",
"phone_number": ""
}
需要了解的一个重要细节是，即使你在系统消息中指示模型在不确定答案时回答“我不知道”，这并不能保证此请求得到履行。 设计良好的系统消息可以增加产生特定结果的可能性，但仍可能会生成不正确的响应，可能会与系统消息中的指令的意图相矛盾。
少样本学习
使语言模型适应新任务的一个常见方法是使用少样本学习。 在少样本学习中，需要在提示中提供一组训练示例，以便为模型提供额外的上下文。
使用聊天补全 API 时，用户和助手之间的一系列消息（以[新的提示格式]编写）可以作为进行少样本学习的示例。 这些例子可以用来引导模型以某种方式相应，模仿特定的行为，并为常见的问题提供种子答案。
非聊天场景
虽然聊天补全 API 已优化为处理多回合对话，但它也可用于非聊天场景。 例如，对于情绪分析场景，可以使用以下提示：
从明确的说明开始
提示中显示信息的顺序很重要。 这是因为 GPT 风格的模型是以某种方式构建的，这定义了它们处理输入的方式。 我们的研究表明，在共享其他上下文信息或示例之前，在提示开始时告诉模型你希望它执行的任务有助于生成更高质量的输出。
在末尾重复指令
模型可能容易受到近因偏差的影响，在此上下文中，这意味着提示结束时的信息对输出的影响可能比提示开头的信息更大。 因此，值得尝试的是，在提示结束时重复指令，并评估对生成的响应的影响。
引导输出
这是指在提示的末尾包含几个字词或短语，以获取遵循所需形式的模型响应。 例如，使用 “Here’s a bulleted list of key points:\n- ” 等提示有助于确保输出的格式为项目符号列表。
在上述提示中，文本“一个可能的搜索查询是：”引导模型生成单个输出。 如果没有此提示，模型将生成多个搜索查询作为输出。
添加明确的语法
对提示使用明确的语法（包括标点符号、标题和节标记）有助于传达意向，并且通常使输出更易于分析。
在下面的示例中，分隔符（本例中为 ---）已添加到不同的信息源或步骤之间。 这允许使用 --- 作为生成的停止条件。 此外，节标题或特殊变量以大写形式显示，用于区分。
分解任务
如果任务分解为较小的步骤，大型语言模型(LLM)的性能通常会更好。 例如，在前面引用的搜索查询提示中，可以调整提示的结构，以便首先指示模型提取相关事实，然后指示生成可用于验证这些事实的搜索查询。
请注意，应使用清晰的语法来区分不同部分并引导输出。 在此简单示例中，将任务从一步分解为两步并不十分引人注目，但当为一篇有许多事实主张的大文本做这件事时，将任务分解就会产生很大的不同。
使用可供性
有时候，我们可以让模型使用可供性，而不是仅依赖其自身的参数来获取信息和答案。 例如，搜索可以作为一种可供性来帮助减轻虚构答案的风险，并获取最新的信息。
使用可供性的一种简单方法是在模型生成可供性调用时停止生成，然后将结果粘贴回提示中。 下面是执行上述 SEARCH 调用后进行跟进调用的示例。 请注意看我们如何将搜索结果粘贴到提示中并替换之前的 SEARCH 调用。
思维链提示
这是分解任务技术的变体。 在这种方法中，不是将一项任务分割成较小的步骤，而是指示模型响应逐步进行，并提出所有涉及的步骤。 这样做可以减少结果不准确的可能性，并使评估模型响应更容易。
指定输出结构
使用提示指定输出结构时，可能会对结果的性质和质量产生重大影响。 有时，系统消息输入“仅写出真实事实”或“不捏造信息”可能不足以缓解问题。 相反，要求模型响应同时包含引文有助于减少错误响应的概率。
如果你指示模型在编写语句时引用源材料，则这些语句更有可能有根据。 请求引文会使模型在每次生成响应时都犯两个错误：第一个错误是捏造的响应，第二个错误是错误的引文。 请注意，引文越接近它支持的文本，模型预测引文所需的距离就越短，这表明内联引文比内容末尾的引文更适合缓解虚假内容的生成。
同样，如果要求模型从段落中提取事实陈述，它可能会提取复合语句，例如“X 正在执行 Y 和 Z”（这可能更难验证）。 可以通过指定输出结构来避免这种情况，如（实体 1、关系、实体 2）。
以下示例演示了引文的使用，并指导模型响应适应定义的结构。
温度和 Top_p 参数
改变温度参数会改变模型的输出。 温度参数可以设置为 0 到 2。 较高的值（例如 0.7）将使输出更随机，并产生更多发散的响应，而较小的值（例如 0.2）将使输出更加集中和具体。 虚构的故事可以使用更高的温度生成。 而要生成法律文件的话，建议使用低得多的温度。 Top_probability 是另一个参数，与温度类似，它也控制模型响应的随机性，但它的控制方式有所不同。 一般建议一次只更改这两个参数其中之一，而不是同时更改它们。
提供基础上下文
提供可靠答案的最有效方法之一是为模型提供数据，让它从基础数据得出响应。 如果你的用例依赖于最新、可靠的信息，且不是纯粹的创意场景，我们强烈建议提供基础数据。 通常，源材料越接近所需答案的最终形式，模型需要完成的工作就越少，这意味着出错的可能性就越小。 下面的示例向系统提供了“描述 GPT-4 在 Azure OpenAI 服务中推出的最新博客”，并要求其命名一些早期客户。