新来的帮厨小张第一天进后厨,胖大厨没有让他背三个月菜谱,也没有只说一句“好好认菜”就撒手不管。他端出四道菜——宫保鸡丁、口水鸡、酸辣汤、红糖糍粑,每盘旁边压张纸条:招牌菜、凉菜、例汤、甜品。小张盯着这四对“菜—标签”看了几分钟,忽然就悟了:红油重的是招牌,清爽的是凉菜,带汤水的归例汤,甜口的算甜品。下一道新菜端上来,他竟也猜了个八九不离十。 这四道菜加字条,就是本文的主角:Few-Shot 提示范式(少样本提示)。大模型就像小张——你不必重头训练它(那是微调),也不用只丢一句模糊任务(那是零样本提示),只要在提问时附上几条“输入→输出”示范,它就能现场归纳规律,把新问题答得又准又稳。示例怎么选、放几条、如何评估,就是这门手艺的全部学问。
Few-Shot 提示是 Prompt 工程中成本最低、见效最快的模型适配手段之一。掌握它,意味着你在没有标注大数据集、没有训练预算时,依然能让大模型快速上手新任务——这是 AI 工程师日常落地中最实用的技能之一。
目录
可视化演示
动态演示Few-Shot提示范式的核心机制,通过基础/核心/应用/扩展四种模式展示关键概念与交互流程。
本节配有交互动效(进入视口后自动加载,约 3KB)。
Few-Shot提示范式:FewS Few-Shot模式归纳原理与 示例选择策略与样本质量影响 核心机制可视化 Few-Shot提示范式整体架构与关键组件
概念定位:三种教法的梯度
小张进后厨第一天,胖大厨其实有三种带法:第一种,甩给他一句“自己去认菜”,什么都不给——这是零样本提示;第二种,端出四道配好标签的拼盘——这是少样本提示;第三种,让他整本菜谱背完再考核——这是微调。小张的成长路径,也正是大模型适配新任务的三种路线的缩影。
Few-Shot 提示范式(少样本提示)就是第二种带法:在发给大模型的提示里嵌入少量“输入→输出”的标注示例,让模型在回答之前先“看几道菜”。它不更新模型的任何参数,只改文字本身。相比零样本,它多了可参照的“锚点”;相比微调,它不需要训练环境、不产生新权重,是三者中成本最低的适配方式。
具体来说,给定一个查询输入 $x$ 和一个包含 $k$ 条标注样本的示例集 $E$,模型在生成时会看到“指令 + 全部示例 + 查询”,并输出使条件概率最大的答案。这个 $k$ 通常是个位数到二十以内,因此叫“少样本”(Few-Shot)——少的是示例,动的是提示,不变的是权重。
小张第一天没背菜谱,只端详了四道拼盘就上了工。Few-Shot 也一样:不需要训练集群,不需要海量标注,只需在提示里“摆几道菜、贴几张标签”,大模型就能快速进入工作状态——这正是它被称为 Prompt 工程“第一性价比工具”的原因。
- 候选答案上取最大模型在全部可能的输出里挑一个概率最高的当作答案,也就是它“最有把握”的结果。
- 条件概率的含义输出不仅取决于当前输入 $x$,还取决于示例集合 $E$——示例相当于给模型铺了一条“这类输入对应这类输出”的轨道。
- 示例集合的构成$E$ 是 $k$ 条配对样本的集合,每条由输入 $x_i$ 与标注输出 $y_i$ 组成——就像“宫保鸡丁 → 招牌菜”这样一张字条。
- k 的取值范围$k$ 落在 1 到 20 的小区间内,这个区间定义了“少样本”的“少”字——比零样本多,比训练集少得多。
工作原理:顺着上文接着写
小张盯着四道菜和四张字条,没有人告诉他“红油多的就是招牌”,但他自己看出来了。这种“没人教、看看就会”的本事,对应到大模型身上,就是上下文学习(In-Context Learning,ICL)。
大模型的本质是一个超大的“接龙机器”:给它一段上文,它就会续写概率最高的下文。预训练阶段,它见过天文数字般的文本片段,早就练就了“顺着前文找规律”的本能。Few-Shot 提示做的事情,就是把你要它完成的活,伪装成一段它很熟悉的“前文”——示例不是被“记住”的,而是被“读”进去的。
一份典型提示可以拆成三层:任务指令(可选但推荐)、$k$ 条示例、查询与一个“未完成的结尾”。模型要做的,就是接着这个结尾往下写。它归纳的并不是什么神秘规则,而是示例序列中“输入模式 → 输出标签”的统计对应关系。示例格式越规整(比如统一用“反馈:…\n类别:…”),这种对应关系越容易被模型捕捉。
小张后来明白,他能“看看就会”,是因为见过的世面够多——大模型也一样。上下文学习不是玄学,而是预训练积累出的“接龙本能”被示例巧妙地引向了特定任务。这也是 Few-Shot 高效的根本原因:不改变模型,只改变它“眼前的世界”。
- 整体生成概率给定查询 $x_q$ 和示例集 $E$,模型生成整个答案 $y_q$ 的概率。
- 自回归分解答案是一个词一个词蹦出来的,整体概率等于每个词概率的连乘。
- 每一步的视野生成第 $t$ 个词时,模型能看到指令、全部示例、查询,以及已经生成的前文。
- 示例的位置示例只是当前上下文的一部分,它出现在“前文”里,而不是“权重”里。
示例设计:挑好教学样板
胖大厨摆拼盘极有讲究:四道菜绝不重样,招牌、凉菜、例汤、甜品各占一类;字条都贴在盘沿同一位置,字迹工整;最要紧的是菜和字条绝不能对错。因为小张学到的全部“知识”,就藏在这四道菜里——样板选错了,徒弟就学歪了。
示例选择(Example Selection)正是 Few-Shot 效果的第一杠杆。工程上常用三条黄金准则:多样性——示例覆盖任务的不同子类,避免“四盘全是辣的”;相关性——示例尽量与待查询输入语义相近;准确性——标签必须经过校验,一条错签可能抵消三条对签。此外,示例的排列顺序也有影响,同类示例相邻摆放通常更稳。
落地时最常用的手段是“检索式选例”:先用文本编码器把候选样本转成向量,再计算查询向量与每个候选向量的余弦相似度,取前 $k$ 条拼进提示;如果担心选出的示例太过同质化,还可以加入多样性惩罚项,让示例彼此之间保持一定差异。
小张后来发现,拼盘选得越典型,他认新菜越准;要是哪天大厨图省事端出四盘全辣的,他准会把手撕包菜也猜成招牌菜。示例不只是“样例”,它是模型唯一的“教科书”——挑好书,比多印书更重要。
- 语义编码把一段文本映射成高维向量,语义越近,向量方向越接近。
- 余弦相似度两个向量夹角的余弦值,取值在 -1 到 1 之间,越接近 1 表示语义越相似。
- 取最大者对候选池 $\mathcal{D}$ 里的每条样本计算相似度后,挑得分最高的那一条作为示例。
数量权衡:边际递减的收益
拼盘越摆越多,小张反而开始犯迷糊:四十道菜铺满桌,他顾此失彼,把相似的菜认混。而且备菜要时间、端盘要人力——示例多了,成本也跟着涨。胖大厨很快发现:四道菜和八道菜差别不大,八道和二十道更是没什么两样。
示例数量 $k$ 与模型表现之间,大致呈“边际递减”曲线:从 0 到 4 个示例,效果提升最猛,通常能带来十几个百分点的增益;4 到 8 个仍有明显提升;超过 8 个后收益趋缓,甚至在部分任务上出现波动——因为上下文越长,模型注意力越容易被冗余信息稀释。
合适的 $k$ 取决于任务复杂度:简单分类 2 到 4 条足矣;抽取、改写类任务 4 到 8 条;复杂的多步推理可能需要 8 到 16 条。同时必须盯住 token 成本——每加一条示例,都意味着一笔固定的输入开销,在高吞吐的生产环境里,这笔账要精打细算。
胖大厨最后把小张的拼盘定为四道:既能看清门道,又不至于眼花。工程上同理——先用 4 条左右高质量示例跑通效果,再按收益曲线决定是否加量;永远别把“示例多”当成目标,模型要的是“刚刚好”。
- 性能上限示例无限多时的理论精度,由模型本身的能力决定,不会无限上涨。
- 缺口项当前精度与上限之间的差距,随 $k$ 增大按 $\frac{1}{k}$ 的速度缩小。
- α 的现实含义任务越难,$\alpha$ 越大,意味着需要更多示例才能把差距填平。
工程实践:模板化与示例库
上手几天后,胖大厨把“摆拼盘”写成了后厨规矩:盘子位置固定、字条统一贴右上角、辣菜永远放左边。谁来摆都一个样,小张认错率立刻降了一半。工程化,就是把“灵光一现”变成“标准动作”。
Few-Shot 的工程化第一步是模板化:用一段固定指令 + 一组格式完全一致的示例槽位 + 一个查询占位符,拼出每次请求的完整提示。模板要保证任何样本放进去都整齐划一——模型最怕的就是格式忽长忽短、分隔符千奇百怪。一个可用的模板长这样:
第二步是建立示例库:把已标注样本按标签分层存储,每次请求时根据查询动态采样 $k$ 条,让示例选择与提示拼装彻底解耦。第三步是成本预估:提示的 token 消耗约等于每条示例的输入加输出长度之和乘以 $k$,再加上查询本身的长度——上线前先算清账,输出侧还要加正则校验或 logit 约束,防止模型输出乱七八糟的格式。
小张发现,后厨规矩越清晰,他上手越快。Few-Shot 工程化的意义同样在此:模板、示例库、成本预估三件套就位后,任何同事看一眼就能复现方案——这才是把“提示技巧”升级为“工程能力”的关键。
- 逐示例累加对示例集中的每条样本分别计算 token 数再加总。
- 输入与输出都算钱每条示例的输入文本与标准答案都占用 token,一个都不能省。
- 加上查询成本最后加上查询本身的长度;总体成本随 $k$ 线性增长。
请判断用户反馈的情感类别,只能输出「投诉」「咨询」「表扬」之一。 反馈:系统升级后页面打不开类别:投诉 反馈:请问如何重置密码类别:咨询 反馈:{查询文本}类别:
局限应对:警惕边界
有一天,客人点了一道分子料理,小张对着四道家常菜拼盘束手无策——他没见过这个门类,看再多川菜示例也没用。拼盘教学是有边界的:样板覆盖不到的地方,就是盲区。
Few-Shot 的局限主要有三个:一是覆盖度不足——示例没覆盖的子类,模型很难凭空猜中;二是对噪声敏感——只要有一条示例标签贴错,模型就可能被整体带偏;三是上下文窗口约束——示例总量和查询长度不能无限膨胀,超出窗口就只能截断或报错。
应对策略也对应三条:针对覆盖度,要么扩大示例多样性,把“分子料理”也摆上桌,要么干脆转向微调,给模型真正“补课”;针对噪声,给示例标签加人工校验和交叉审核,杜绝“贴错字条”;针对长度限制,用检索选例只挑最有代表性的少数示例,长文本任务则拆成多个子问题,每个子问题各配一份少样本提示。
胖大厨后来也学聪明了:遇到小张拿不准的新菜系,就再补一样菜;实在补不齐,就送他去培训学校深造。Few-Shot 是“通用快充”,到了专业深水区,该微调时还得微调——知道边界在哪,才叫真会用它。
- 示例总长所有示例的 token 长度之和,是提示的主体开销。
- 查询与硬边界示例总长加上查询本身长度,不能超过模型的上下文窗口上限。
- 窗口的意义$L_{\max}$ 由模型结构和部署硬件共同决定,是推理时不可逾越的硬约束。
效果评估:用指标说话
三天后,胖大厨验收:他把十道菜的标签全撕了,让小张盲猜。小张猜对八道,这才获准单独掌勺。没有“撕标签盲测”,一切“我觉得挺好”都是幻觉——评估 Few-Shot 效果,同样要有一场严格考试。
评估不能靠“看起来能答”就拍板。要准备一个固定测试集(绝不能混进示例选择环节),分别跑零样本、$k=1$、$k=3$ 等配置,算出准确率或 F1,量化“加示例”到底带来多少增益。这就是消融实验:把变量逐个拔掉,看每个组件贡献了多少。
实操上有四个要点:一是测试集与示例池严格隔离,避免“开卷考试”式泄题;二是每组 $k$ 都随机抽样多轮取均值,防止单次幸运;三是必须设基线,至少对比零样本和一次微调;四是记录方差,多轮结果波动大说明示例组合不稳定,要回头调选例策略。
小张通过盲测正式出师。Few-Shot 上线前也请记得“撕标签”:跑通基线、量化增益、盯住方差。别让“看起来还行”的提示,带着隐患走进生产环境——评估,是给提示发“上岗证”的那道关。
- 精确率模型判定为正类的样本里,真正为正类的占比——“猜中的里面,对的比例”。
- 召回率真实正类中被模型找出来的占比——“该抓的里面,抓到了多少”。
- 调和平均F1 对两者取调和平均,任何一项偏低都会显著拉低得分,专治“偏科”。
AI 应用场景
场景 1:客服工单实时分类
阶段:推理部署 / 应用上线
解决的问题:传统做法需要攒上万条标注工单并训练分类模型,上线周期以周计;Few-Shot 只需在提示中放 3 至 5 条不同类型工单样例,产品当天就能试运行,把“攒数据—训练—上线”压缩成“写例句—上线”。
具体案例:某电商平台新开“售后维修”工单子类,工程师从历史工单里挑出 4 条(投诉、咨询、表扬、建议)拼进统一模板,接上客服机器人,当天把该子类的人工分类准确率从 60% 提升到 88%,一周后确认收益,才开始启动正式标注与微调。
场景 2:新业务快速打样
阶段:方案验证 / 快速迭代
解决的问题:新业务(如新品类评论分析、新语言内容审核)没有历史标注数据,微调无从谈起;Few-Shot 让算法同学用几行示例完成打样,先验证“模型能不能干这活”,再决定是否投入数据建设——用最少成本排除最坏方案。
具体案例:内容社区要做“评论区风险识别”,算法先用 4 条例句(广告、辱骂、涉政、正常)搭出 Few-Shot 版本,跑通日报管道;跑了一周发现误报率偏高,再针对性补充示例子类,最终把误报率压到可接受范围后才启动微调。
Python 演示
# -*- coding: utf-8 -*-"""Few-Shot 提示范式演示:用少量标注样本构造提示,模拟大模型完成情感分类。"""import random DATA = [ ("系统升级后页面打不开", "投诉"), ("请问如何重置密码", "咨询"), ("新版本界面很清爽,好评", "表扬"), ("订单三天未发货,差评", "投诉"), ("客服耐心细致,点赞", "表扬"),] TEST = [ "登录一直报错,非常生气", "优惠券在哪里领取", "售后响应快,体验极佳",] def build_prompt(examples, query): """把 examples 与 query 拼成 Few-Shot 提示文本。""" lines = ["请判断用户反馈的情感类别,只能输出:投诉 / 咨询 / 表扬。", ""] for text, label in examples: lines.append("反馈:" + text) lines.append("类别:" + label) lines.append("") lines.append("反馈:" + query) lines.append("类别:") return "\n".join(lines) def predict_fake(model_prompt, examples): """用字符重合度模拟模型从示例归纳规律的过程。""" query_line = model_prompt.split("反馈:")[-1].split("\n")[0] best_label, best_score = "咨询", -1 for text, label in examples: common = len(set(query_line) & set(text)) score = common / max(len(set(query_line)), 1) if score > best_score: best_label, best_score = label, score return best_label def main(): random.seed(42) examples = random.sample(DATA, 3) for query in TEST: prompt = build_prompt(examples, query) print("---- 输入提示 ----") print(prompt) print("预测类别 =>", predict_fake(prompt, examples), "\n") if __name__ == "__main__": main()
random.seed(42)固定随机种子,保证每次运行时选出的 3 条示例一致,结果可复现。examples = random.sample(DATA, 3)从标注数据里随机抽 3 条,模拟“示例选择”环节。lines.append("反馈:" + text)按“反馈:文本”的固定格式写入示例输入。lines.append("类别:" + label)紧随其后写入示例标签,构成完整的“输入 → 输出”示范。lines.append("反馈:" + query)追加待预测的新查询,开始“接龙”。lines.append("类别:")在末尾留下“未完成的结尾”,让模型接着续写答案。for text, label in examples模拟模型“看着全部示例”逐一比对规律的过程。common = len(set(query_line) & set(text))用字符重合度充当“相似度”的简化版本。if score > best_score找出与查询最相似的示例,取其标签作为预测结果。
常见误区
误区“我给模型塞了 20 个示例,怎么效果反而没有 5 个示例好?Few-Shot 不是应该越多越好吗?”
正解示例数带来的收益是边际递减的,而且会迅速耗尽上下文窗口。示例太多时,重复信息占主导,模型注意力被稀释,还容易被个别错误示例带偏。正确做法是把 $k$ 控制在个位数,优先保证每条示例的质量与相关度,而不是盲目堆量。
为何常见:直觉上“练习越多学得越好”,但模型的“上下文”是一个有限的注意力窗口——盘子塞满桌,反而端不稳。
误区“Few-Shot 也要用标注数据,所以它跟微调差不多,只是训练数据少一点。”
正解两者本质不同:Few-Shot 不更新任何参数,示例只作为文本出现在上下文里,模型权重原封不动;微调则需要反向传播去更新权重。因此 Few-Shot 不需要训练环境和算力,改提示即可上线——它是“给老师傅看一眼样例”,而不是“重塑老师傅”。
为何常见:两者都会用到“少量标注数据”,人们容易把“数据的使用方式”误当成“模型的训练方式”。
误区“反正模型很强,随便从网上找几条例句放进去,效果应该差不多。”
正解示例的选择直接决定归纳质量:标签错误会误导模型,子类单一会让模型只学会一种模式,格式混乱会让模型“接话”失败。工程上要选与查询语义相似、覆盖多子类、标签经过校验的示例,并保持格式完全一致——拼盘里的每一道菜都在教徒弟。
为何常见:把 Few-Shot 看成“玄学加例子”,忽略了示例本质上是模型在这项任务上唯一的学习材料。
误区“既然几条示例就能让模型干活,那以后再也不需要微调了。”
正解Few-Shot 适合任务模式清晰、示例能表达规则的场景;对于领域知识深、输出格式复杂、需要稳定低延迟的任务,微调依然不可替代。实践中常按“零样本打底 → 少样本调优 → 必要时微调固化”的顺序推进,三者是配合关系,不是替代关系。
为何常见:在示例恰好有效的简单任务上产生了“万能”错觉,忽略了边缘案例和领域深度——小张看得懂川菜,不代表他能做分子料理。
面试题
Q1. 关于 Few-Shot 提示,下列说法正确的是?
- A.需要在训练集上更新模型参数
- B.在提示中嵌入少量标注示例← 正确答案
- C.完全不提供任何任务示例
- D.必须使用数千条标注数据
答案:B。Few-Shot 的核心就是在提示中嵌入少量“输入→输出”示例,模型不更新参数。B 正确;A 描述的是微调,C 是零样本,D 是传统训练集规模,均不符合 Few-Shot 的定义。
Q2. 相比 Zero-Shot,Few-Shot 最主要的价值是?
- A.增加模型的参数量
- B.扩大训练语料规模
- C.提供任务规律锚点← 正确答案
- D.加快单次推理速度
答案:C。Few-Shot 通过示例让模型看到输入与输出之间的对应关系,相当于给了“锚点”,从而降低任务理解难度。它不改变参数量、不扩充训练语料,反而因拼接示例会略微增加推理耗时,故选 C。
Q3. Few-Shot 提示与微调的本质区别是?
- A.前者不更新模型权重参数← 正确答案
- B.微调不使用标注数据
- C.前者必须离线训练模型
- D.微调只改变提示文本
答案:A。Few-Shot 把示例塞进上下文,权重原封不动;微调用梯度更新权重。A 正确。B 说反了,微调恰恰依赖标注数据;C 说反了,Few-Shot 是在线推理;D 说反了,微调改的是权重而非提示。
Q4. 挑选 Few-Shot 示例时最合理的做法是?
- A.随机抽几条文本即可
- B.优先选与查询相似← 正确答案
- C.永远只用第一条样例
- D.用越长的示例越好
答案:B。选与查询语义相似的示例能提供最贴切的任务线索,同时兼顾子类多样性与标签正确性。随机抽取、固定用第一条都可能带偏模型;“越长越好”没有依据,长度不是质量的代名词。
Q5. 一般随示例数量 k 增大,Few-Shot 性能的变化趋势是?
- A.先升后平,增益递减← 正确答案
- B.线性上升,无止境
- C.持续下降,直至归零
- D.随机波动,无规律
答案:A。性能随示例数先快速上升,之后趋于饱和,符合边际递减规律;不会线性无限上升,也不会持续下降或完全随机。这也是工程上优选 4 至 8 条示例的原因——收益与成本的最佳平衡点。
Q6. 下列哪些属于 Few-Shot 示例设计的要点?
- A.示例标签必须准确← 正确答案
- B.各示例要覆盖多种子类← 正确答案
- C.示例数量越多越稳
- D.示例格式务必保持一致← 正确答案
答案:ABD。标签准确、子类多样、格式统一都能显著提升归纳效果,分别对应“教学质量、覆盖广度、可读性”三个维度。C 错:示例过多会超上下文窗口并引入噪声,不是越多越稳。
Q7. 上下文窗口受限时,Few-Shot 的正确做法是?
- A.删除任务指令只留示例
- B.优先选代表性强的少量示例← 正确答案
- C.压缩示例输出保留完整输入
- D.拆分模型并多次调用取平均
答案:B。窗口有限时应精选少量高代表性、高相关性的示例,把预算花在刀刃上。删除指令可能丢失任务约束,压缩输出会破坏示例的完整性;拆分模型并多次调用既增加成本又不改变单次窗口上限,故选 B。
Q8. Few-Shot 提示属于哪类学习方式?
- A.深度学习训练微调
- B.少样本上下文学习← 正确答案
- C.无监督聚类分析
- D.强化学习智能决策
答案:B。Few-Shot 属于少样本学习(Few-Shot Learning),具体机制是上下文学习:模型从上下文中的少量示例归纳规律并推理,不更新参数。A 是微调,C、D 与提示工程无关。
Q9. Few-Shot 提示的常见局限有哪些?
- A.对示例标签噪声较敏感← 正确答案
- B.较难覆盖未知新子类← 正确答案
- C.效果被上下文窗口约束← 正确答案
- D.完全替代大规模微调
答案:ABC。标签错误会误导归纳;示例没覆盖的子类模型难以凭空推断;上下文长度限制示例数量与文本长度。D 错:复杂领域任务中微调仍不可替代,Few-Shot 不能包打天下。
Q10. 生产环境中 Few-Shot 最大的工程价值是?
- A.无需训练即可快速适配← 正确答案
- B.推理速度大幅提升
- C.替代全部算法系统
- D.自动修复模型幻觉
答案:A。新任务上线时,Few-Shot 只需写几条例句即可试运行,省去数据标注与训练环节,是成本最低的快速适配手段。它不是加速推理的工具,也不是万能方案,更不能自动修复幻觉,故选 A。