什么是 Few-shot Learning？Zero-shot、One-shot、Few-shot 有什么区别？

🏛 业务架构师

Few-shot Learning 指在提示词里给模型若干示例，让它照着做新任务——不更新参数的"现场学习"。Zero-shot（零样本）：只给指令不给示例；One-shot：给一个示例；Few-shot：给多个（通常 2~10 个）示例。

三者的区别与适用：

Zero-shot：最快最省 token，适合模型已有较强先验的常见任务（摘要、翻译、通用问答）；缺点是格式和口径靠运气，复杂或生僻任务容易跑偏；
One-shot：给一个"样板"，主要为了锁定输出格式——当任务简单但输出格式必须严格时最经济；
Few-shot：多个示例展示多样性（不同输入类型、边界情况），模型能归纳任务"范式"——适合企业特有口径的任务（按你们的分类标准打标、按你们的风格写周报）。

选择的经验法则：从 zero-shot 开始试，不满意加示例，示例加到 3~5 个仍不达标，问题多半不在示例数量而在任务定义或模型能力。示例质量大于数量：覆盖典型 case+边界 case，示例之间保持格式一致（格式不一致模型会随机模仿）。

成本视角：每个示例都是常驻 token 成本——高频调用场景要权衡"示例 token 开支"与"准确率收益"，可通过微调或结构化输出约束把"每次都带的示例"固化掉。2026 年的趋势：模型指令遵循能力变强，简单任务 zero-shot 已够用，few-shot 留给有业务私有范式的任务。

Few-shot = 带少量示例的提示学习；三兄弟按示例数：Zero-shot（0 个示例，纯指令）、One-shot（1 个）、Few-shot（几个到几十个）。

区别与机理：本质是上下文学习（ICL）——模型不更新参数，把示例当作"任务说明书"在推理时即时理解任务模式。示例越多，任务定义越明确（格式、风格、判断边界），输出越稳定，但消耗 token 也越多。

选型逻辑（架构师的成本-效果账）：

Zero-shot：指令清晰、任务常见（摘要、翻译、常识问答）——够用且最省；现代强模型指令跟随好，很多任务 zero-shot 已达标。缺点：输出格式与判断边界容易漂移；
One-shot：需要钉死输出格式（给一个输入输出示例）——格式对齐的最小成本方案；
Few-shot（2~8 shot 常用）：任务有隐式规则（分类标准、风格、边界 case）——示例比文字描述更高效（"什么叫正面情感"说不清，三个例子就清楚）；缺点：每请求多几百~几千 token（配合 Prompt Cache 摊薄）、示例选择不当会引入偏差；
微调（终极形态）：few-shot 需求固定且 QPS 高 → 把示例行为微调进权重，省掉每请求的示例 token——成本优化的标准路径。

示例设计三原则：代表性（覆盖典型 case + 边界 case）、多样性（避免模型学到错误共性）、格式严格一致（示例格式就是输出契约）。

一句话：zero-shot 到 few-shot 到 fine-tune 是**"任务定义成本"从指令到示例到权重**的三级火箭，按任务复杂度 × 调用频率选档。

Few-shot Learning：在提示里给模型若干「输入→输出」示例，让它照着模式处理新任务——不更新权重，靠上下文学习（ICL）。

三者区别就是示例数量：

	示例数	特点
Zero-shot	0	只给指令，依赖模型预训练与对齐能力；快、省 token，但格式和边界容易漂
One-shot	1	一个示例主要起「格式锚定」作用
Few-shot	2~n	示例多则模式更清晰，输出稳定；占上下文、成本高

实用经验（工程视角）：

选择原则：先 zero-shot 试，格式不稳加 1 个示例，仍不稳上 3~5 个 few-shot；再不行说明不是示例问题，是任务拆解或模型能力问题。