少样本提示
概述
提高模型性能最有效的方法之一是向模型提供您希望它执行的操作示例。将示例输入和预期输出添加到模型提示的技术被称为“少样本提示”。该技术基于 语言模型是少样本学习器 论文。在进行少样本提示时，有几件事需要考虑
- 示例是如何生成的？
- 每个提示中有多少个示例？
- 如何在运行时选择示例？
- 示例在提示中如何格式化？
以下是每项的考虑因素。
1. 生成示例
少样本提示的第一步也是最重要的一步是提出一个良好的示例数据集。好的示例应该在运行时相关、清晰、信息丰富，并提供模型尚不知道的信息。
在高层次上，生成示例的基本方法有
- 手动：一个人/多人生成他们认为有用的示例。
- 更好的模型：更好的（可能更昂贵/更慢的）模型的响应被用作较差的（可能更便宜/更快的）模型的示例。
- 用户反馈：用户（或标注者）对与应用程序的交互留下反馈，并根据该反馈生成示例（例如，所有具有正面反馈的交互都可以转化为示例）。
- LLM 反馈：与用户反馈相同，但该过程是通过让模型自我评估来自动化的。
哪种方法最好取决于您的任务。对于需要真正理解少量核心原则的任务，手工制作一些真正好的示例可能很有价值。对于正确行为空间更广泛和更细致的任务，以更自动化的方式生成许多示例可能很有用，这样更有可能为任何运行时输入提供一些高度相关的示例。
单轮与多轮示例
在生成示例时要考虑的另一个维度是示例实际显示的内容。
最简单的示例类型只有用户输入和预期的模型输出。这些是单轮示例。
更复杂的示例类型是示例是整个对话，通常模型最初响应不正确，然后用户告诉模型如何纠正其答案。这称为多轮示例。多轮示例对于更细致的任务可能很有用，在这些任务中，显示常见错误并明确说明它们为什么是错误的以及应该做什么是有用的。
2. 示例数量
一旦我们有了示例数据集，我们需要考虑每个提示中应该有多少个示例。关键的权衡是，更多的示例通常会提高性能，但更大的提示会增加成本和延迟。并且超过某个阈值，过多的示例可能会开始混淆模型。找到合适的示例数量高度依赖于模型、任务、示例质量以及您的成本和延迟约束。 轶事表明，模型越好，它表现良好所需的示例就越少，并且您越快地达到添加更多示例的收益递减的程度。但是，可靠地回答这个问题的最好/唯一方法是运行一些使用不同示例数量的实验。
3. 选择示例
假设我们没有将整个示例数据集添加到每个提示中，我们需要有一种方法可以根据给定的输入从我们的数据集中选择示例。我们可以这样做
- 随机
- 通过输入的（语义或基于关键字的）相似性
- 基于一些其他约束，例如令牌大小
LangChain 有许多 ExampleSelectors，可以轻松使用任何这些技术。
通常，按语义相似性选择会导致最佳模型性能。但这有多重要再次取决于模型和任务，并且值得尝试。
4. 格式化示例
现在最先进的模型大多是聊天模型，因此我们将重点关注格式化这些模型的示例。我们的基本选择是将示例插入
- 在系统提示中作为字符串
- 作为它们自己的消息
如果我们将示例作为字符串插入到系统提示中，我们需要确保模型清楚每个示例的开始位置以及哪些部分是输入与输出。不同的模型对不同的语法反应更好，例如 ChatML、XML、TypeScript 等。
如果我们将示例作为消息插入，其中每个示例都表示为 Human、AI 消息的序列，我们可能还想为我们的消息分配名称，例如 "example_user" 和 "example_assistant"，以明确这些消息对应于与最新输入消息不同的参与者。
格式化工具调用示例
当我们的示例输出有工具调用时，将示例格式化为消息可能很棘手的一个领域。这是因为不同的模型对生成任何工具调用时允许的消息序列类型有不同的约束。
- 有些模型要求任何带有工具调用的
AIMessage之后立即跟随每个工具调用的ToolMessage， - 有些模型还要求任何
ToolMessage之后立即跟随AIMessage，然后再是下一个HumanMessage， - 有些模型要求，如果聊天记录中有任何工具调用/
ToolMessage，则必须将工具传递到模型中。
这些要求是模型特定的，应针对您正在使用的模型进行检查。如果您的模型在工具调用后需要 ToolMessage，和/或在 ToolMessage 后需要 AIMessage，并且您的示例仅包括预期的工具调用而不包括实际的工具输出，您可以尝试在每个示例的末尾添加虚拟 ToolMessage/AIMessage 以及通用内容，以满足 API 约束。在这些情况下，尤其值得尝试将您的示例作为字符串与消息插入进行实验，因为虚拟消息可能会对某些模型产生不利影响。
您可以在 此处 看到 Anthropic 和 OpenAI 如何在两个不同的工具调用基准测试中响应不同的少样本提示技术的案例研究。