少样本提示（Few-shot prompting）
概述
提升模型性能最有效的方法之一，就是为模型提供你希望它完成任务的示例。这种在模型提示中添加输入示例和期望输出的技术，被称为“少样本提示”。该技术基于论文 Language Models are Few-Shot Learners。在使用少样本提示时，有几个关键点需要考虑：
- 示例是如何生成的？
- 每个提示中应包含多少示例？
- 运行时如何选择示例？
- 提示中如何格式化示例？
以下是对每个问题的详细说明。
1. 生成示例
少样本提示的第一步也是最重要的一步是创建一个高质量的示例数据集。好的示例应当在运行时具有相关性、清晰、有信息量，并能提供模型原本不具备的知识。
总体而言，生成示例的基本方式有以下几种：
- 手动：由人（或多人）生成他们认为有用的示例。
- 更优模型：使用一个性能更好（可能更昂贵/更慢）的模型的响应作为示例，用于训练一个较差（可能更便宜/更快）的模型。
- 用户反馈：用户（或标注人员）在与应用交互时提供反馈，并基于这些反馈生成示例（例如，所有获得积极反馈的交互都可以转化为示例）。
- LLM反馈：类似于用户反馈，但通过模型自我评估实现自动化。
哪种方法最好取决于你的任务。对于需要深入理解少量核心原则的任务，手工精心制作几个高质量的示例是非常有价值的。而对于正确行为范围更广、更复杂的情况，可以通过更自动化的方式生成大量示例，以提高运行时匹配到高度相关示例的可能性。
单轮 vs 多轮示例
生成示例时还需要考虑另一个维度：示例展示的内容类型。
最简单的示例只包含用户输入和期望的模型输出，这类示例称为单轮示例。
更复杂的示例则可能是一整段对话，通常情况下是模型先给出了错误回答，然后用户指出问题并指导模型如何修正。这种类型的示例称为多轮示例。多轮示例适用于更复杂的任务，可以展示常见错误，并明确解释错误原因及应采取的正确做法。
2. 示例数量
一旦有了示例数据集，就需要考虑每个提示中应包含多少示例。
关键权衡在于：示例越多通常性能越好，但提示越长会导致成本和延迟增加。超过一定阈值后，过多的示例反而会让模型混淆。
最佳的示例数量高度依赖于模型本身、任务类型、示例质量以及成本和延迟限制。
经验表明，模型越强大，所需的示例就越少，且添加更多示例带来的收益迅速递减。因此，最可靠的方法是尝试使用不同数量的示例进行实验。
3. 选择示例
假设我们不会将整个示例数据集都放入每个提示中，就需要一种根据当前输入选择示例的方法。可以采用以下策略：
- 随机选择
- 根据输入的语义或关键词相似性选择
- 根据其他约束（如 token 数量）选择
LangChain 提供了多种 ExampleSelectors，可以方便地使用上述任何一种选择技术。
通常，基于语义相似性选择示例可以获得最佳模型性能。但其重要性仍取决于所使用的模型和具体任务，建议进行实验验证。
4. 格式化示例
目前最先进的模型大多是聊天模型，因此我们将重点介绍如何格式化这些模型的示例。基本的格式化选项包括将示例插入：
- 系统提示中作为字符串
- 作为独立的消息
如果你将示例作为字符串插入到系统提示中，需要确保模型能清楚识别每个示例的起始位置以及输入和输出的区分。不同模型对语法格式的响应不同，例如 ChatML、XML、TypeScript 等格式可能更受某些模型欢迎。
如果你将示例作为消息插入，其中每个示例由 Human 和 AI 消息组成，建议为这些消息指定 名称，如 "example_user" 和 "example_assistant"，以明确这些消息代表不同的参与者，与当前输入消息区分开。
格式化工具调用示例
当示例输出包含工具调用时，将示例格式化为消息可能会比较复杂。这是因为不同模型对包含工具调用的消息序列有不同的限制：
- 一些模型要求任何包含工具调用的
AIMessage后必须立即跟上每个工具调用对应的ToolMessage； - 一些模型还要求任何
ToolMessage后必须立即跟上一个AIMessage，然后才能出现下一个HumanMessage； - 一些模型要求如果聊天历史中包含工具调用或
ToolMessage，则必须将工具传递给模型。
这些要求是模型特定的，使用前应查阅所用模型的文档。如果你的模型要求在工具调用后包含 ToolMessage 和/或 AIMessage，但你的示例只包含预期的工具调用而没有实际工具输出，你可以尝试在每个示例末尾添加带有通用内容的虚拟 ToolMessage / AIMessage 来满足 API 约束。在这种情况下，值得尝试将示例作为字符串或消息插入，因为虚拟消息可能对某些模型产生负面影响。