完整题目
在设计大模型提示（prompt）时，什么情况下应使用few-shot示例？请结合其作用机制、优势及典型应用场景，说明few-shot提示工程如何提升模型的推理与任务执行能力。
本文目录
何时使用Few-shot
核心判断标准：任务需要格式规范、推理模式示范或领域特殊约定，但又不值得专门微调模型时。
| 场景 | 典型case |
|---|---|
| 输出格式严格 | JSON提取、特定模板生成、代码注释风格 |
| 推理步骤隐含 | 数学解题、逻辑推理、多跳问答 |
| 任务边界模糊 | 情感细粒度分类、实体关系判断标准 |
| 领域术语特殊 | 医疗/法律/金融等专业领域的表述习惯 |
作用机制：上下文学习（ICL）
模型通过注意力机制动态地从示例中提取模式，而非记忆参数更新：
- 位置敏感：示例排列顺序影响注意力权重分布
- 模式匹配：识别输入→输出的映射规律，泛化到新样本
- 隐式推理：示例中的中间步骤可激活模型的CoT能力
关键：模型不是"学习"示例，而是**"定位"到预训练中的相关知识**并激活。
设计要点
- 示例选择：选代表性+多样性的边界案例，而非随机采样
- 数量控制：通常2-5个，过多会稀释注意力或触发幻觉
- 格式一致：输入/输出结构严格对齐，减少解析负担
- 位置策略：复杂示例放后面（近因效应），简单示例前置建立信心
优势与局限
| 优势 | 局限 |
|---|---|
| 零成本适配新任务 | 示例占用token，增加推理成本 |
| 无需训练数据积累 | 超长上下文模型才能承载复杂示例 |
| 可解释、可快速迭代 | 对示例质量敏感，"垃圾进垃圾出" |
工程实践：生产环境常将Few-shot作为兜底策略——先尝试Zero-shot，效果不达标再引入精选示例，而非一上来就堆示例。
学习建议
建议从具体任务入手，如分类、生成，动手设计单样本和多样本提示，对比输出差异，理解few-shot如何引导模型。
换一种问法，检查是否真正理解
场景切入
假设你在做一个电商客服助手，需要自动提取用户退货原因并格式化输出，比如“商品破损-退款”这种。你试了直接指令但格式总乱，这时候你会考虑用few-shot示例吗？具体怎么用？
层层追问
你平时写prompt，什么情况下会想着给模型几个例子？……如果任务是让模型做数学题，例子能起到什么作用？……那例子太多会不会有反效果？
直球架构
说说few-shot提示工程吧。你判断什么场景该用它？它的作用机制是什么？你一般怎么选例子、放几个、怎么排序来提升推理效果？
练习口述回答 · 约4分钟
- 本质定位：few-shot 是快速示范，不是学新知识
- 什么场景该用：格式、推理、边界模糊
- 业务案例：客服退款多轮分类
- 设计要点与风险：示例质量、数量、位置
- 落地取舍：先 zero-shot，再 few-shot，不滥用
这道题问的是什么时候该用 few-shot，我觉得本质是在问：我们怎么让大模型在不动参数的情况下，快速理解一个它没见过或者不好描述的任务。说白了，few-shot 不是让模型学新知识，而是给它打个样，帮它定位到预训练里已经会的相关能力。
那具体什么场景我会考虑用 few-shot 呢？我的判断标准是：任务对 输出格式 有严格要求，或者 推理步骤 需要示范，或者 任务边界 比较模糊，但又不值得专门微调。举个例子，输出格式严格，比如从非结构化文本里抽 JSON 字段，你告诉它“姓名：xxx，金额：xxx”，它就容易对齐。推理步骤隐含的，比如数学应用题，你给一个带中间步骤的例子，它就能激活 [[Chain-of-Thought]] 能力。任务边界模糊的，比如情感细粒度分类，你说“正面”和“负面”，但客户评论里“一般”算中性还是偏负面？给两个边界例子，它就懂了。
我拿一个真实的业务场景来说，客服退款分类。用户退款申请五花八门，有说“质量不好”，有说“发错了”，还有说“不想要了”。如果直接 zero-shot，模型经常把“不想要了”归到“无理由退货”，但公司政策里这种要归到“主观原因”，处理流程不一样。这时候我会给两个 few-shot 示例：一个“颜色不对”归到“商品瑕疵”，一个“买多了”归到“主观原因”。模型一看，就明白分类标准不是字面意思，而是背后的业务规则。而且我还会注意，把示例的输入输出格式写得非常一致，比如都用“用户说：xxx，分类：xxx”这种模板，减少模型的理解负担。
但 few-shot 不是万能药，它有前提和风险。首先，示例质量是命门，如果示例本身有歧义或者错误，那就是“垃圾进垃圾出”。我见过有人随便从数据集里抽几个样本，结果模型学偏了，召回率反而下降。其次，数量不是越多越好，我一般控制在 3 到 5 个，再多的话注意力会被稀释，而且会占用大量 token，推理成本上升。另外，示例的位置也有讲究，我会把 复杂或者有代表性的示例放在最后，利用近因效应让模型更关注它。
落地的时候，我更倾向把 few-shot 当成一个 兜底策略。我的习惯是：先 zero-shot 试试，如果效果达标，就不加示例，因为少一个依赖就少一个风险点。如果 zero-shot 不稳定，比如某些边界 case 总出错，我再精选两三个示例加进去。而且我会特别关注 上下文长度的消耗，如果 prompt 太长，模型可能在中段丢失注意力，所以我会优先选短而精的示例，而不是长篇大论的。
说到这里，其实有个挺有意思的点：few-shot 的示例顺序和选择方式，是不是可以动态调整？比如根据输入 query 的语义，从示例池里实时检索最相关的几条来拼 prompt，而不是固定写死。这有点像 [[In-Context Learning]] 里的动态示例选择，但落地时要注意检索的时效性和示例的多样性，避免模型被单一模式带偏。