我一直觉得把零样本学习和少样本学习放在同一节课里讲真是又省事又容易让人误会的安排。省事是因为它俩都依赖同一个底层机制——上下文学习误会是因为很多人学完之后以为零样本就是“啥也不给直接问”少样本就是“多给几个例子而已”至于这个机制到底怎么提升推理能力、为什么提升、卡在哪儿了完全没有感觉更别说在实际项目里把它调成一套稳定可用的配置。先给个最直观的场景。你让大语言模型判断一堆客服工单的情感倾向直接一条条丢给它它的输出可能一会儿正一会儿负还时不时带一句解释。但你在提示里预先放上两三条带标准答案的对话样例再开始问新的工单——同一个模型、同样的权重、同样的温度输出立刻稳定得多。这个过程中模型参数一个都没动它仅仅是“读了”几个例子行为就变了。这就是上下文学习的魔力也是少样本学习区别于传统少样本训练方法的核心理由。这篇博文想讲清楚三件事上下文学习的机理到底可能是什么怎样把零样本/少样本提示做成一套可靠的生产配置以及在什么情况下该果断放弃上下文学习、转向微调。无论你是正在做提示工程、准备把大模型接进业务系统还是单纯想理解“为什么几个例子这么关键”这篇内容应该都能用上。1. 从“参数学习”到“语境学习”范式转变的核心理解1.1 零样本、少样本与上下文学习到底指什么先把术语掰开。零样本学习zero-shot可以泛指模型在没有见过该类任务标注样本的情况下完成推断在大语言模型语境里更常见的含义是“只给任务描述不提供任何示例直接把输入丢进去要答案”。少样本学习few-shot在传统机器学习里是“用极少标注样本做训练”但在大模型这里通常指“在提示里放几个输入输出示例模型读完就地输出”——全程没有梯度更新没有权重变化。两者共同的引擎叫上下文学习In-Context LearningICL模型通过前向传播时读取到的上下文指令、示例、输入来改变自己的输出分布而不是靠反向传播调整参数。这也是为什么这个章节标题里把零样本、少样本和上下文学习放在一起——它们不是并列的三种技术而是“两种场景”加上“同一个引擎”。术语容易打架是因为“少样本学习”这个词在旧时代很重在现在很轻。以前你拿几百条数据在小型模型上微调那叫少样本学习现在你在提示里写5条示例也常被叫少样本学习。两者差的不是数量级而是学习发生的载体彻底变了。我的习惯是遇到有人聊少样本学习先确认他说的是“上下文少样本”还是“梯度少样本”否则后面全是鸡同鸭讲。1.2 权重没动模型凭什么会了我最初接触大模型时的困惑就是这个如果不更新权重模型怎么算“学会”后来我把这个问题拆成了两半。第一半模型预训练时已经在海量文本里见过无数“模式配对”——输入句子、对它的回复、分类标签、推理步骤……这些知识作为隐式能力沉淀在权重里。比如它看过几千万条“这条评论是正面还是负面”的语料情感判断的神经通路早就有了。第二半模型读到你给的示例时并不需要重新练出这条通路它只需要在上下文里“激活”对应的通路。几个例子起的作用更像按开关而不是喂养分。按完开关之后模型在解码每一步token时都会把上下文里的示例当成“参照物”来决定下一个token该落在哪里。这种“联想型学习”有一句特别贴切的类比你给一个资深厨师一份菜谱和两个成品参考图他就能照着做出一模一样的菜不是因为他在你面前练了厨艺而是因为他本来就会做只是需要你告诉他“今天要做这道菜”。大模型的权重就是那个厨师的厨艺上下文就是今天的要求。所以范式转变的本质是传统机器学习把学习定义为“调整参数直到拟合”上下文学习把学习定义为“在推理时构造一个任务环境让预训练时的技能被精准触发”。参数学习给你的是“肌肉记忆”语境学习给你的是“临场发挥”。这个理解直接影响做法你要做的不是“教”模型完成任务而是“唤醒”它已经会的任务。提示设计的第一性原理是让上下文的格式、词汇、句式尽可能贴近它在预训练语料里见过的、该类任务的自然文本形态。2. 为什么几个例子就能改变行为ICL机理的几个硬核解释2.1 隐式任务识别示例是“任务指纹”学界对上下文学习的机制目前没有最终定论但这不妨碍我们了解几种主流解释每个都有实验支持。第一种解释叫任务识别。模型在阅读上下文时会下意识地根据示例的样式推断出“这像是什么任务”。比如示例是“电影台词……用户评价正面/负面”模型就会把后续输入套进这个任务模板。从这个角度看示例相当于一个“任务指纹”——它告诉模型现在处于哪个语言游戏里模型接着按那个游戏规则输出。这解释了为什么示例的格式这么重要如果任务指纹被噪声干扰得很模糊比如示例里夹杂无关内容模型就识别失败。我见过很多项目把少样本示例当成“附属品”随便填进提示结果效果波动极大就是这个机制在捣乱。反过来当示例的格式高度统一、标签词明确模型任务识别的成功率就会显著上升。2.2 隐式贝叶斯推断把示例当作证据更新先验第二种解释是模型其实在做隐式的贝叶斯推断。预训练导致它对“下一个token”有一个先验分布而上下文里的示例则相当于证据让它在输出类别上的后验分布朝着示例所暗示的方向收窄。通俗讲示例改变了模型对不同答案的“主观概率”你放两条负面例子它输出负面标签的概率就会高一些你放三条正面例子它又会偏正面。这个解释能帮我们理解标签分布问题——示例里某一类比另一类多模型输出也更偏向那一类。模型输出的不是一个“理性的任务解”而更像“围绕证据加权后的概率采样”。对做分类任务的人来说这意味着要像做统计一样小心地控制示例的标签比例消除偏见。一个常见操作是每个类别固定放同样数量的示例哪怕某些类别在真实业务里占比很低也要在示例里保持均衡否则模型会因为示例的“多数派效应”而高估低频类别的发生概率。2.3 归纳头与模式复制注意力层面的机械解释第三种解释来自机制层面的研究。有研究者观察到Transformer内部存在一种被称为“归纳头”的模式当上下文里出现“A B A”这样的结构注意力头会把两个A对齐然后预测下一个token时倾向于复制曾经跟在A后面的B。这种“找相似序列然后照搬”的机制会让模型在做少样本时特别容易跟着示例走示例里怎么写的它就更可能照着写。这个机制往好了说是让模型快速对齐示例风格和输出格式往坏了说就是“过拟合到示例表面形式”。比如你示例里用了JSON它就会尽量回JSON你示例里带了解释它就也带解释——哪怕任务并不需要解释。理解这一层你就能解释很多“玄学”现象为什么示例顺序一变结果就变、为什么模型会复制示例里的错误标签。2.4 机制不明的阶段我们能抓住什么老实说这三种解释之间并不互斥更像是在不同抽象层面解释同一个现象。任务识别偏向宏观意图贝叶斯推断偏向概率视角归纳头偏向微观机制。学界还没有完全统一的答案但这不影响我们得到实用的结论示例的格式、标签、顺序都会显著影响输出所以示例需要被当作工程变量来管理模型的预训练语料决定了它认哪种“任务指纹”所以示例的风格要贴近真实世界文本而不是生造的抽象格式上下文学习的本质可以被理解为“按需触发局部模仿概率偏置”三者的混合它不是模型真正的泛化能力增长。这些认知直接决定了我写提示的手感永远不轻视示例设计但我也不指望光靠堆示例就能让模型学会一个它从未接触过的新技能。3. 提示模板与上下文工程从零样本到少样本的实战编排3.1 零样本最省事但先检查“任务指纹”是否清晰零样本意味着提示里没有任何输入输出示例只有任务描述和输入。它的优点是快、省token、流程干净缺点是模型靠什么确认自己在做哪个任务只能靠任务描述本身。所以零样本提示的关键是“把任务描述写得像模板”。我的常用结构是三段式角色system任务内容user输出约束最后一句话。比如做客服工单情感分类时我会写你是一个客服工单分析助手。对每条消息只输出三个词之一正面 / 负面 / 中性不要输出其他文字。就这么清晰的三段。注意很多教程喜欢给角色加戏“你是一位资深情感分析专家”实测下来对任务识别帮助有限有时甚至因为引入无关风格使输出变得花哨。我一般只在需要特定语气或专业术语时才加角色。零样本做推理类任务时有的模型容易“抢答”——直接给结论不给过程有的则会稳定一些。如果你发现零样本输出很飘先不要急着怀疑模型笨先检查两点任务描述里是否包含足够的历史任务关键词是否给了明确的输出格式约束。大多数零样本翻车其实翻在这两点上。3.2 少样本示例的质量、顺序与标签比例一旦零样本不稳定最快修正手段就是加示例。示例有几个硬指标。代表性每个输出类别至少一条输入形态要有区分度多样性尽量覆盖不同表达长度、句式而不是挑几条最典型的标签比例每个类别的示例数尽量接近至少不能差出一倍顺序很多人忽略模型习惯偏向靠后的信息所以可以把最易混淆的示例放在序列后段。数量上我建议起点是4~8条。太少模型可能没抓到任务指纹太多会稀释注意力且成本升高。我之前在某个信息抽取任务里做过对比2条示例准确率约78%5条示例涨到89%加到12条反而只涨了0.4个百分点。这个边际收益递减非常明显示例数量不是线性优势。为了让你对成本有感觉我列一次典型对比测试的体感数据模型输出稳定度主观评估示例数量准确率观察token消耗延迟体感稳定度0条零样本约76%最少最低不稳偶尔格式漂移2条约78%低低略好5条约89%中中稳定8条约89%中高中高稳定12条以上约89.4%高明显上升偶发“迷失在中间”3.3 示例的“长相”决定成功半径格式工程示例用什么格式呈现我把它称为“长相工程”。同一个信息用自然语言段落、JSON结构、XML标签、Markdown列表表示模型的响应风格会完全不同。原因是模型预训练时在不同格式下的“模式强度”不同。我的经验排序对绝大多数结构化抽取任务JSON是目前兼容性最好的输出格式对分类任务用简短自然语言或固定标签词足够对生成总结类任务示例最好也是完整段落而不是干巴巴的模板。最怕的是混搭示例用JSON输出要求却是纯文本模型反而会被两股力量拉扯。举个例子判断新闻标题所属领域的少样本提示可以写成这样任务判断新闻标题所属领域。仅输出科技 / 财经 / 体育 / 文娱。 示例 输入某公司发布新一代电池能量密度提升30% 输出科技 输入美股高开低走科技股领跌 输出财经 输入球队官宣新主帅签约两年 输出体育 --- 输入{待判断标题} 输出这种“输入”“输出”的模式几乎就是模型在预训练语料里最常看到的人机对话模板任务指纹识别的成功率极高。分隔符用“---”或换行都可以关键是全提示保持一致。3.4 输出约束与后处理少样本提示里最被低估的一项工作是输出可解析性设计。你让模型输出“不要其他文字”它还是会偶尔给你带个句号、引号、斜杠你让它输出JSON它可能输出成markdown代码块。解决方式是双保险提示里给出一句“直接输出结果不要解释不要使用代码块”后处理时再用正则或JSON解析器加一层兜底。别指望模型百分百遵守指令工程上永远要给自己留护栏。这些编排经验核心都是在做同一件事让上下文的每一部分都为“任务指纹识别”服务——指令负责定位任务示例负责确定风格输出约束负责校准终态。4. 推理链的涌现以“逻辑一致性”为核心的提示策略与参数工程4.1 为什么零样本也能“推理”却总是不稳定第三章处理的场景还偏分类和抽取推理能力才是标题里真正的重头戏。什么叫推理能力我的定义是模型能在不做检索、不看外部资料的情况下通过多步操作得到新结论。数学应用题、多跳问答、代码逻辑解释、策略规划都算。零样本模型当然能做这些但它是“快思考”——直接根据统计偏好给出最可能的答案。对于小学应用题这种分布很稠密的还行一遇到稍微反直觉的题快思考就会给出自信的错误答案。核心问题在于模型跳过了从条件到结论的推导闭环中间步骤一旦缺失错误的概率就指数上升。4.2 把思维过程写出来提示重构与思维链的触发最简单的改进是让模型在给出最终答案前把推理步骤显式地写出来这正是思维链Chain-of-Thought提示做的事。它的本质是增加模型在前向传播中“思考”的token预算让每一步结论都能被后续步骤引用从而缩小从条件到结论的跳跃幅度。零样本触发词那一句“让我们一步一步思考”确实有效但不建议当成万能钥匙。有效的原因是这个句式在预训练数据里高频出现在“严谨解题”语境里相当于一个任务指纹开关但它在有些领域也会诱导模型生成冗长的、看似合理但完全跑偏的解释。我的做法是任务需要数学或逻辑时再上情感分类之类的就没必要。少样本版本更强在示例里直接展示推理过程。格式建议Q某个果园原来有苹果树120棵又种了30棵先后死了5棵现在有多少棵 A先算总数12030150再减去死树150-5145。答案是145。这种“QA带过程”的示例等于给模型示范了输出的“思维方式”而不只是最终答案。我做过对比实验同样一道多步推理题零样本直接答的正确率约55%零样本加“思考”触发词约74%加上两条带过程的少样本示例后约86%。这个差距非常大而且全部发生在权重冻结的状态下。4.3 解码参数与自洽性稳定性比单发准确率更值钱提示词写好了解码参数也不能瞎调。总结我这几年的经验分类/抽取类任务temperature 0~0.2top_p 0.9以内输出稳定优先开放生成/创意任务temperature 0.7~1.0有意义写的文本更有多样性推理任务temperature可以低接近0但如果你要的是“逻辑一致性”而不是“单个答案”更有效的手段是做自洽性采样同一道题用较高温度比如0.5~0.7跑5~8次再把答案多数投票。这个“sample and vote”思路能把不稳定模型变成相对可靠的推理器。推理任务上自洽性的效果原理和集成学习一个道理单次解码可能被局部较强的token路径带走多次采样相当于探索更多条件组合多数投票抑制随机噪声。缺点是成本乘了N倍。我在高价值推理场景比如小额金融审核、逻辑判断会用5次采样一般场景则只跑1次。4.4 让模型“自查”逻辑一致性检验的实战技巧还有一个容易被忽视的推理提升手段把推理过程作为一个可回溯的文本交给模型自己检查。比如先让它给答案和步骤再追问一句“你刚才的步骤里有没有哪一步用错了条件如果没有请确认最终答案。”这种简单的自查提示在小模型上往往能抓住代数符号抄错这类低级错误。注意自查也不是无限的——追问太多次模型会开始“自我纠结”甚至把对的改成错的。我的底线是最多自查两轮第三轮就开始信任第一轮。这些技巧加在一起效果就是标题里那句话上下文学习确实能提升推理能力但提升的前提是提示策略主动把“推理过程”变成显式上下文而不是指望模型默默消化。5. 上下文的限度示例选择、顺序敏感性与若干实战陷阱5.1 示例顺序的“近朱者赤”陷阱前面提过顺序敏感这里展开。我在一类情感分类任务上做过小实验同一批5条示例顺序完全打乱后同一批测试输入的预测仅在顺序变化下就有8~12个点的准确率波动。原因就是前面归纳头机制里的“邻近效应”模型倾向于受越靠近输入位置的示例影响越强。这意味着两件事第一调提示时如果要对比效果必须固定示例顺序否则你对比的是顺序带来的噪声第二生产环境里可以决定把最有代表性的、最容易出错的示例放在离输入最近的位置。我在实际测试里发现把“困难示例”放在序列末尾通常比放在开头效果更稳因为模型会把刚读到的模式迁移到后续输入上。5.2 标签分布与“多数派偏见”跟顺序类似的是标签比例。如果5条示例有4条都是“正面”模型输出的正面比例会显著提高这不是因为它觉得数据里正面多而是因为它把示例当成了概率证据。有个实验很直接把示例中所有标签故意翻转来写比如明明是正面标注成负面模型测试时也会跟着把正面判成负面。这个现象常被当作“模型在抄袭示例”的证据但它也揭示了上下文学习的上限示例是模型唯一能看见的任务分布示例若是坏的模型只会更高效地学坏。线上跑分类任务时我建议每上线一批示例前用一个小验证集跑一遍标签平衡检测防止某类样本在上下文里悄悄占多尤其当业务数据天然不均衡时。5.3 上下文长度与“迷失在中间”什么时候少样本该止步当示例本身很长、每条都要占几百token时示例数量可能多到让后续输入处于上下文的中部而注意力对这种长上下文的覆盖并不均匀——于是出现“迷失在中间”模型对上下文开头和结尾的内容记得更清楚对中间内容记忆模糊。所以我的铁律是把最重要的示例放开头最相关的示例放结尾中间只放支撑性示例如果上下文总长度超过模型窗口的一半宁可砍示例也不要无限堆。少样本是“让模型看到线索”不是“让模型读完一本书”。5.4 错误传染与格式漂移另一个高频坑是错误传染。示例中只要有一条标注错了模型不仅可能学错还会因为样例间的规律性把它当成“规律”。所以示例质量必须人工或用小模型两轮审核不敢用没跑过验证的样本直接上提示。格式漂移则更隐蔽。你要求输出JSON模型偶尔回一个markdown代码块你要求输出情感词它给你附带一句“我将这样判断”。这种漂移的解法有三层提示层加强约束、解码后加解析兜底、连续漂移时用规则强制改写。把后处理当作上下文学习的一部分而不是事后补丁。5.5 故障排查清单当你怀疑少样本提示出问题时按这个顺序查先查示例顺序变动是否影响结果再查标签比例然后查示例格式是否和输出要求一致再查上下文长度是否超窗最后再怀疑模型版本和参数设置。我几乎每次都能在这个清单上定位问题而不是盲目换模型或堆示例。6. 上下文学习与微调的选型判断什么场景该坚持ICL6.1 ICL最“舒适”的场景什么样的任务最适合用上下文学习我的判断标准有三条任务形态变化频繁标注样本稀缺对透明可控要求高。比如你是一个产品运营今天要抽客服工单里的退货原因明天要看评论里的价格敏感词后天要做竞品信息对比。每个任务的样本都不多、需求各异如果用微调就得为每个任务准备数据和训练流程而用上下文学习只需要每个任务写几条示例几分钟就能上线。这种“多任务、小样本、快迭代”的场景我是坚决用ICL的。另外上下文学习对“可解释性”有天然优势——你给用户展示“模型是参考这5条示例得出答案的”比解释一个微调黑盒容易得多。我在需要向非技术同事解释模型行为时ICL几乎是首选。6.2 该转微调的三个明确信号但ICL不是银弹。我的经验里出现以下信号就该考虑微调或至少做轻量微调任务固定且长期运行同一类任务每周跑几百万次每次带8条示例的成本在token上非常可观把任务逻辑写进权重比每次携带示例便宜得多。上下文长度塞不下所需知识需要引用长文档、知识库、大量规则时示例撑不起这个体量。模型输出怎么调都差一截且格式需求严苛比如必须输出特定schema但模型总是记不住这时候微调等于把提示的有效部分固化到权重里。轻量微调方案在底座上增加少量低秩适配层逐渐成为这个场景的标准答案只需要几百到几千条数据、成本不高、改动可控还能保留底座模型的通用能力。6.3 我建议的顺序先上下文后微调很多项目一上来就定义“我们要微调一个垂类模型”我总劝他们先别急。正确顺序应该是先写一个极其清晰的零样本提示跑通流程如果效果不够加4~8条高质量的少样本示例如果还不够加推理链示例或做自洽性采样只有前两步把天花板摸出来了发现确实卡在“上下文学习表达不了这个任务逻辑”上才考虑轻量微调。这套顺序的价值在于它用几小时的提示调优替代了可能几天的工作而且提示调优得到的“任务指纹”理解能为后续微调的数据设计提供直接指导——你知道模型哪里理解得不对才知道该给什么样的训练样本。6.4 一点收尾的体会做提示工程这几年我最大的体会是不要神化上下文学习也别低估它。它的本质是给一个已经被预训练知识填满的模型装配“临时说明书”说明书写得好不好直接决定模型能否调用出它早已具备的推理能力。对模型权重里的知识来说“上下文学习提升推理能力”这半句话我更愿意理解为“上下文学习唤醒了沉睡的推理能力”。所以下次你遇到模型表现不佳先别急着怪模型笨也别急着上训练先问自己一句我给它的语境足够让它知道自己现在是谁、在做什么、要做到什么程度了吗这比切换更大的模型或堆更多参数往往都更快见效。
