AI地基篇:(五)few-shot 多样本

AI地基篇第五篇：few-shot 多样本，模型其实是「照着例题做」！！！

第四篇讲 CoT（思维链）时留了一个分叉：嘴上要求「逐步思考」是指令式；在 message 数组里先塞几组「问题 + 带步骤的标准答案」，让模型照着格式学，是示范式。

这种「先给例题、再出考题」的写法，就是 few-shot（少样本提示，用少量范例引导输出）。样本可以是 1 组（one-shot），也可以是 2～5 组甚至更多（few-shot）；一组都不给，只靠 system 或 user 里一句话交代，叫 zero-shot（零样本）。

很多人把 few-shot 当成「多贴几段文档让模型变聪明」。工程上它更接近在数组里插入人工示范对话：教的是格式、语气、步骤结构，不是把知识库整本复印进 prompt。prefill 怎么「替模型写好开头」、停止序列怎么截断，留到后面专篇。

AI 地基篇第五篇，只啃 few-shot 这一格。

01 承接前四篇：few-shot 就是数组中间的「范例对话」

第一篇钉死了 message 数组：有序列表，system / user / assistant / tool 各就各位。

few-shot 不发明新角色。它做的是在真正那条 user 问题出现之前，先 append 若干组「范例 user + 范例 assistant」：

system: （可选，场记板）
user: 范例问题 A
assistant: 范例回答 A
user: 范例问题 B
assistant: 范例回答 B
user: 这次真正要问的问题
assistant: （留空，等模型生成）

模型读的是整段序列。范例和真题在数组里一视同仁，都占 token、都进窗口。第四篇的 few-shot CoT，不过是 assistant 范例里带了推理步骤而已。

02 零样本、单样本、多样本：差的是「有没有例题」

先把三个词对齐，后面就不混。

zero-shot（零样本）

数组里只有 system（若有）+ 当前 user，没有示范对。靠模型预训练里已有的能力 + 你的文字指令。第四篇「请逐步思考」就属于这一类触发。

one-shot（单样本）

插 1 组范例对，再跟真题。适合格式非常固定、范例能代表全貌的场景。

few-shot（少样本，通常 2～5 组）

插多组范例，模型更容易稳定复制结构。组数再往上加，收益往往递减，窗口先顶不住——第二篇的尺子在这里再次登场。

零样本 → 只说规则，不给例题单样本 → 一题例题 + 一题真题多样本 → 多题例题 + 一题真题

这里最容易和「做模型训练」时的数据集划分搅在一起——如果你按 Transformers 那套自己训过模型，一定见过 train / val / test（训练集、验证集、测试集）：

训练集 → 用来更新权重，让模型「学进去」

验证集 → 用来调超参、看有没有过拟合

测试集 → 用来评最终泛化，尽量只评一次

那是训练阶段的事，样本量往往是成千上万条，动的是模型参数。

prompt 里的 few-shot 发生在推理阶段：不改权重，只是在这一次请求的 message 数组里，临时多塞几组「范例 user + 范例 assistant」。模型并没有把这几组例题写进权重里；请求结束，范例随上下文一起退场（除非你下一轮又手动带上）。

所以本篇说的 shot，指的是「示范回合」，不是训练集里的那一万条样本。它和 fine-tuning（微调，拿标注数据改权重）也不是一回事——微调要划分数据集、跑 epoch；few-shot 只是在窗口里摆卷面。

训练阶段的 few-shot / one-shot 学习 → 有时指「每个类别只给极少标注样本去训模型」（那是算法论文里的设定）

推理阶段的 few-shot 提示 → 本文讲的：prompt 里放几组例题，不改权重

两个「few-shot」撞名，初学者特别容易混。你一旦用 train/val/test 那套直觉去理解 prompt 里的范例，就会问「要不要也划验证集」——推理时没有这套流程，只有「这一轮窗口里放几组、放什么、占多少 token」。

03 范例怎么摆：顺序、数量、和真题像不像

few-shot 不是堆越多越好，排列本身就在发信号。

顺序：

范例按数组时间线排在真题前面，这是默认约定。把真题插在范例中间，模型会搞不清该模仿哪一段。第一篇说过「数组就是时间线」，范例是「过去的卷面」，真题是「现在要做的题」。

数量：

常见 2～5 组。1 组有时够（输出格式极固定时），10 组以上要警惕：窗口、成本、范例之间互相矛盾（前面范例说用 JSON，后面范例说用 Markdown，模型会选最近或最像真的）。

相似度：

范例和真题越像，模型越会 copy 表面格式。分类任务里，每类给 1 个代表范例，往往比 3 个重复范例更有效。代码场景里，范例用的语言、框架、目录结构最好和真题同一套，否则模型可能「学会格式但套错栈」。

顺序 → 范例全部在真题之前数量 → 2～5 组为常见甜点区相似 → 范例像真题，才学得到有用模式

04 范例该教什么、不该教什么

few-shot 最适合教「怎么做」，不适合塞「全世界是什么」。

适合写进范例 assistant 的

固定的输出骨架（标题、字段、JSON 键名）
分步结构（和 CoT 叠用：范例里就带步骤）
语气与长度（短答 / 详述 / 只给 diff）
边界行为（信息不足时怎么拒答）

不适合塞进范例的

长篇领域百科（应走 RAG 或文档检索）
经常变的业务数字（今天的价格、今天的库存）
和 system 完全重复的规矩（双份 token）
只在真题里才成立的答案（范例应可泛化，不是抄答案）

第三篇讲 system 写场记板；few-shot 写「卷面示范」。system 说「必须输出 JSON」，范例就演示一条合规 JSON；别把整本 API 手册贴进范例 assistant。

05 和窗口、CoT、system 一起算账

每多一组范例，都是实打实的输入 token。

1 组范例对 → 可能几百到几千 token5 组范例对 → 可能吃掉小半个窗口

还要留空间 → 给真题材料、给模型输出 max_tokens

和 CoT 叠用时，范例 assistant 若带完整推理链，token 膨胀更快。可以只在范例里保留「一步式摘要 + 结论」，把啰嗦步骤缩短，真题仍要求详细 CoT。

和 system 的分工：

system → 稳定规则（语言、禁忌、默认格式）few-shot → 1～3 个具体卷面，让模型「看见」长什么样user → 本次真实输入

长对话里，few-shot 通常只在首轮请求里带；若每轮都重复同一批范例，是在烧钱。很多 Agent 把范例编译进 system 或缓存（命中输入缓存时，重复范例可能便宜一些——计费细节因平台而异，但窗口占用仍在）。

和系列后续接口：

prefill → 不写完整范例 assistant，只预填开头，和 few-shot 互补停止序列 → 范例若演示「答完就停」，真题也可配同样停止符tool use → 范例可演示一次 tool 调用 + tool 回填 + 最终 assistantRAG → 检索片段是材料；few-shot 教怎么读材料并输出

06 常见坑与自检

范例互相打架

一组范例输出列表，另一组输出表格，模型在真题上随机。解决：统一范例模板，或减到一组最权威的。

范例太像真题

几乎把答案写进范例，模型会「抄范例」而不是泛化。解决：换表述、换数字、换边界条件。

把 few-shot 当 fine-tuning

以为多加 50 组范例就能替代训练。推理 prompt 里的范例只影响这一次调用，不改权重。

忽略窗口截断

范例 + 长文档 + 长 history 一起把 system 或早期范例裁掉，行为突然漂移。解决：量 token，优先保 system 和最近一轮。

自检接在前几篇之后：

10. 数一组范例占多少 token，占输入百分之几

11. 删掉全部范例只留 system+user，对比输出格式是否崩

12. 换一道「表面像、条件不同」的真题，看是否瞎抄范例数字

写到最后

第一篇数组、第二篇窗口、第三篇 system、第四篇 CoT，few-shot 是第一次在数组里主动造假历史：用你写的范例对话，教模型下一句 assistant 该怎么长。

下一篇进入 prefill（预填充）：不写完整个范例答案，只替模型写好 assistant 开头几个 token，让它顺着格式往下接——和 few-shot 是近邻，但占窗口的方式不一样。

如果你认同这样的表达，欢迎把文章转发给身边正在学习 AI 的朋友。愿每一次阅读，都不是信息的堆积，而是真正理解的开始。