1. 项目概述重新审视大模型的“学习”本质最近和几个做算法落地的朋友聊天大家不约而同地提到一个现象当业务方看到大模型比如GPT-4、Claude 3在几个例子指导下就能完成新任务时总会惊叹“它学得真快”。每次听到这种评价我内心都会默默摇头。这其实是一个广泛存在的认知偏差。大模型在收到几个“示例”Demonstration后表现出的能力跃升并非传统意义上的“学习”或“训练”而是一种被称为上下文学习的神奇机制。它没有更新自身的任何参数没有经历反向传播和梯度下降仅仅是“看”了你给的几个例子就仿佛“学会”了新技能。这种能力颠覆了我们对机器学习范式的传统理解。过去要让一个模型处理新任务我们需要收集数据、标注、重新训练或微调Fine-tuning整个过程耗时耗力。而上下文学习让这一切变得像“对话”一样简单你只需要在输入中即“上下文”或“Prompt”里提供几个任务描述和输入-输出的例子模型就能照猫画虎生成符合要求的输出。它更像一个拥有极强模式识别与泛化能力的“超级模仿者”而非一个从零开始的“学习者”。这篇文章我们就来彻底拆解In-context Learning。我会结合大量一线实践中的观察和测试讲清楚它到底是怎么工作的为什么说它不是“学会”以及我们如何利用好这把“双刃剑”。无论你是开发者、产品经理还是对AI技术好奇的爱好者理解ICL都能帮你更清醒地评估大模型的能力边界避免被表象迷惑从而设计出更可靠、更高效的AI应用。2. ICL核心机制为什么是“看例子”而不是“学会”要理解ICL我们首先得抛开“学习”这个词带来的固有印象。在机器学习领域“学习”通常指模型通过训练数据调整其内部参数即权重从而将知识“固化”到模型中的过程。一旦训练完成模型的能力就基本确定了。而ICL发生时模型的参数是完全冻结、纹丝不动的。那么奇迹是如何发生的关键在于大模型的预训练阶段。在吞食了互联网级别的海量文本数据后大模型内部形成了一个极其复杂的“世界模型”。它不仅仅记住了语法和事实更深刻地掌握了语言中蕴含的任务格式、推理逻辑和解决模式。当你在上下文Prompt中给出几个例子时模型实际上是在进行一场高速的“模式匹配”与“信息检索”。2.1 预训练奠定的“元能力”基础你可以把大模型的预训练过程想象成让一个超级天才阅读整个人类文明的数字档案。在这个过程中它看到的不是孤立的句子而是无数完整的文档、对话、代码库、问答对、教程等。因此它潜移默化地学会了任务指令与格式的对应关系它见过太多“翻译”后面跟着双语文本“总结”后面跟着长文和摘要“写代码”后面跟着需求描述和函数。它建立了“指令词 - 任务格式 - 输出风格”的强关联。输入到输出的映射规律在无数的小说、剧本、技术文档中它看到了事件A如何导致结果B问题C通常有答案D。它学会了预测“接下来最可能发生什么”或“最合理的回答是什么”。类比与泛化的能力当它看到“苹果水果 - 胡萝卜”这类类比时它并不是“知道”胡萝卜是蔬菜而是从海量文本中统计出“A是一种B”这种模式后能将其泛化到新的实体对上。所以ICL并不是赋予模型新知识而是激活并引导模型在预训练中已经获得的这些“元能力”。你给的例子就像一个精准的“导航指令”告诉模型“请调用你在预训练中学到的、与当前例子最相似的那种问题解决模式。”2.2 ICL的工作流程一场精密的内部“注意力”调度从模型内部机制看ICL过程可以粗略分解为以下几步模式识别模型读取你提供的示例对例如“输入今天天气真好。 - 输出情绪积极”。它的注意力机制会迅速聚焦于示例中输入和输出之间的关键关联词如“天气真好”与“积极”。任务推断模型根据示例的格式和内容推断出你希望它执行的任务类型如“情感分类”。它会在其庞大的内部知识网络中定位到与“情感分类”相关的概念和模式区域。格式对齐模型识别出你期望的输出格式如“情绪[标签]”。它会调整其生成策略使输出严格遵循示例中展示的格式而不仅仅是内容正确。泛化应用当遇到新的查询输入如“输入我考试没考好。”时模型会将刚才识别到的“任务模式”和“格式要求”应用到新输入上从预训练知识中检索出最匹配的答案“情绪消极”。整个过程模型的权重没有任何改变。改变的是模型处理当前输入序列时的“注意力分布”和“生成路径”。例子通过改变模型的“临时工作焦点”引导它走向了正确的答案方向。注意这里存在一个关键限制。ICL只能引导模型调用其已有知识。如果任务完全超出了预训练数据的范围例如让一个中文预训练模型理解一个它从未见过的少数民族语言的语法或者要求进行需要更新世界模型的复杂逻辑推理如全新的数学定理证明仅靠几个例子通常是无效的。ICL是“锦上添花”而非“无中生有”。3. ICL的实操要点如何设计有效的“例子”理解了ICL不是“学习”后我们的重点就应该从“如何训练它”转向“如何更好地引导它”。设计上下文中的示例Demonstration是一门艺术直接决定了任务执行的成败。根据我的经验有效的示例设计遵循以下几个核心原则。3.1 示例选择质量远大于数量很多人认为例子越多越好其实不然。对于当今的千亿参数大模型3-5个高质量示例往往比10个普通示例效果更好。相关性优先示例必须与你的目标查询在任务类型、领域和难度上高度相关。如果你想做医疗报告的情感分析就应该用医疗文本的示例而不是电影评论。覆盖关键变体有限的几个示例应尽量覆盖任务中可能出现的核心情形或边界情况。例如在分类任务中示例应覆盖所有类别在翻译任务中示例应包含不同时态、语态的句子。避免噪声示例本身必须正确、清晰、无歧义。一个有错误的示例会严重误导模型。实操心得我常用的策略是“种子示例困难示例”组合。先提供1-2个最典型、最简单的示例种子让模型快速抓住任务本质。然后补充1-2个稍微复杂或容易出错的示例困难帮助模型明确边界。例如在信息抽取任务中种子示例展示标准实体抽取困难示例则展示嵌套实体或别名情况。3.2 示例格式清晰、一致、可模仿模型是严格的格式模仿者。你给出的示例格式就是它输出的“模板”。输入-输出分隔清晰使用明确的符号或换行来分隔示例中的输入和输出如“输入...\n输出...”或“Q: ...\nA: ...”。在整个Prompt中保持绝对一致。标注指令如果任务需要在示例中明确标注出关键部分。例如在命名实体识别中可以用XML标签或特殊符号标出实体文本马云创立了阿里巴巴。 - 实体人物马云/人物 公司阿里巴巴/公司。输出标准化确保所有示例的输出格式完全统一。即使是细微的差别如一个用“是/否”另一个用“Yes/No”也可能导致模型混淆。3.3 示例排序逻辑与效果之谜示例的排列顺序对结果有微妙但有时显著的影响。相关性与难度递进一种常见的有效策略是将与当前查询最相关的示例放在最后。因为模型的自注意力机制对序列末尾的内容权重更高。同时可以采用从易到难的排列。避免负面干扰不要把可能产生冲突或矛盾的示例紧挨着放。例如两个同样合理但答案不同的示例在某些开放性问题中连续出现会让模型无所适从。实践出真知排序的影响因模型和任务而异没有金科玉律。最好的方法是进行A/B测试。对于关键任务可以准备2-3种不同的示例排序在测试集上跑一下选择效果最佳的一种。常见问题实录我们曾在一个文本分类项目中发现将某个特定类别的示例放在Prompt末尾时模型对该类别的识别准确率会系统性偏高。这证实了“近因效应”在ICL中的存在。因此在设计需要公平分类的系统时必须考虑示例顺序带来的潜在偏差。4. ICL的典型应用场景与方案实现ICL的强大之处在于其灵活性。它几乎可以应用于任何基于语言的任务。下面我结合几个最常见的场景拆解具体的实现方案和核心环节。4.1 场景一少样本分类与标注这是ICL最直接的应用。你有一些未标注的数据希望模型帮你分类或打标签。方案实现任务定义明确分类体系和标签。例如客户评论的情感积极/消极/中性工单的类型技术问题/账单问题/投诉。构建示例为每个标签手工编写或从已有数据中挑选1-2个清晰、无歧义的示例。确保示例文本能代表该类别的典型特征。组装Prompt请将以下客户评论分类为 [积极, 消极, 中性] 之一。 示例 评论物流速度超快包装也很精美下次还会再来 情感积极 评论等了半个月才发货客服也找不到人体验极差。 情感消极 评论商品已经收到了和图片描述一致。 情感中性 现在请对新的评论进行分类 评论[你的新评论文本] 情感调用与解析将组装好的Prompt发送给大模型API解析其返回的答案。通常需要设置合适的temperature低值如0.1-0.3以保证输出确定性和max_tokens控制输出长度。核心环节关键在于示例的代表性和区分度。一个常见的坑是示例过于简单或模糊导致模型对边界情况判断不准。例如如果“中性”的示例都是“收到了货”这种纯事实陈述那么模型可能无法正确分类“质量一般说不上好也说不上坏”这种真正中性的评价。4.2 场景二复杂格式生成如JSON、SQL、代码大模型能生成严格结构化的输出这为自动化数据处理和代码生成打开了大门。方案实现定义Schema明确你期望的输出数据结构。对于JSON给出一个完整的、带注释的示例Schema。对于SQL明确数据库的表结构。提供完整示例示例必须是一个从自然语言描述到完整、正确、可运行的结构化输出的完美映射。对于代码生成示例应包括输入描述、思考过程可选和最终代码。强调格式在指令中明确要求“请输出一个JSON对象”或“请生成可执行的Python代码”。在示例中格式必须完美。组装Prompt以生成API请求参数JSON为例请根据用户需求生成调用天气查询API所需的JSON参数。 示例 用户需求“查询北京明天下午的天气。” 思考城市是“北京”时间是“明天下午”需要的是预报信息。 JSON参数 { city: Beijing, date: tomorrow, time_period: afternoon, query_type: forecast } 用户需求“[你的新需求例如获取上海当前温度]” JSON参数后处理与验证永远不要完全信任模型的第一次输出。对于生成代码必须进行语法检查和沙箱测试。对于生成SQL必须在测试数据库上验证其正确性和安全性防止SQL注入。对于JSON使用解析器验证其格式有效性。避坑技巧对于复杂格式采用“分步思考Chain-of-Thought” ICL的组合拳效果极佳。即在示例中不仅展示输入输出还展示模型“应该有的”推理步骤。这能极大提升生成结果的逻辑正确性。例如在数学或逻辑问题上示例中先写“让我们一步步思考...”再给出最终答案。4.3 场景三信息抽取与结构化从非结构化文本如新闻、报告、邮件中抽取特定信息如人名、公司、日期、事件并整理成表格或结构化数据。方案实现定义抽取框架明确要抽取哪些字段字段名、数据类型、说明。提供标注示例示例文本应包含各种需要抽取的信息类型并以清晰的方式展示抽取结果。推荐使用键值对或列表的形式呈现结果而不是纯文本描述。处理复杂情况在示例中涵盖信息缺失、信息重复、指代消解如“该公司”、“他”等情况并展示正确的处理方式。组装Prompt请从以下新闻摘要中抽取出“事件主体”、“事件类型”、“发生地点”、“发生时间”四个信息。如果某个信息不存在则填写“未提及”。请以JSON格式输出。 示例 文本“昨日苹果公司在加州总部发布了新一代iPhone手机。” 抽取结果{ “事件主体”: “苹果公司” “事件类型”: “产品发布” “发生地点”: “加州总部” “发生时间”: “昨日” } 文本“[你的新文本]” 抽取结果结果归一化模型抽出的可能是“昨天”、“2023年10月27日”等多种时间格式。需要在后处理环节进行归一化转换为标准格式。实操心得对于字段多、关系复杂的抽取任务不要让模型一次做完所有事情。可以拆分成多个子任务通过多个ICL Prompt串联即Prompt Chaining来完成。例如先让模型判断文本是否相关再抽取实体最后判断实体间关系。这样每一步的精度更高也更容易调试。5. ICL的局限性、陷阱与应对策略尽管ICL非常强大但盲目使用会带来很多问题。我们必须清醒地认识到它的边界。5.1 局限性什么情况下ICL会失效知识边界外模型无法生成它预训练数据中不存在或极少存在的知识。例如询问一家昨天刚成立的公司的详细信息或者一个非常小众的专业概念。需要精确数值计算或符号推理大模型本质上是语言模型不擅长精确计算。虽然通过ICL可以引导它进行简单算术但对于复杂数学、逻辑推导或需要严格符号处理的任务其可靠性远低于专用工具或代码。长上下文依赖与“中间迷失”当Prompt非常长需要综合前文很远的信息进行推理时模型可能会“遗忘”或混淆早期示例中的信息导致性能下降。输出不一致性即使输入和示例完全相同由于模型本身的随机性取决于temperature等参数多次运行也可能得到略有不同的输出。这对于需要确定性的生产系统是个挑战。5.2 常见陷阱与排查技巧陷阱一示例偏见放大模型会放大你示例中存在的任何偏见。如果你提供的示例中“CEO”总是与男性代词关联那么模型在生成关于CEO的描述时也倾向于使用“他”。排查检查示例集在性别、种族、文化等方面的代表性是否均衡。应对精心设计去偏见的示例或使用多个不同背景的示例集进行集成。陷阱二格式过度拟合模型可能过度关注示例的表面格式而忽略了任务本质。例如如果你在每个示例输出后都加一个句号模型可能会在不需要句号的任务输出中也加上句号。排查检查输出中是否出现了示例中存在的、但与任务无关的固定模式或词语。应对简化示例格式移除所有不必要的装饰性文本。让输入和输出的对应关系尽可能纯粹。陷阱三对示例顺序过度敏感如前所述不同的示例顺序可能导致不同的输出结果这在需要高稳定性的系统中是不可接受的。排查固定输入随机打乱示例顺序多次调用模型观察输出是否稳定。应对对于生产系统可以采用以下策略示例集成使用几组不同的、但都有效的示例分别得到结果后进行投票多数决。校准输出在Prompt后加入一句指令如“请只基于任务本身进行判断忽略示例的先后顺序”有时能起到一定效果但非绝对可靠。后处理规则建立一套后处理逻辑对模型的原始输出进行清洗和标准化。陷阱四上下文长度限制与成本大模型的上下文窗口有限如4K、8K、16K、128K tokens。示例会占用宝贵的上下文空间增加API调用成本和延迟。排查计算你的Prompt指令示例查询的总token数确保在模型上下文窗口内。应对压缩示例用最精炼的语言表达示例。有时可以删除示例中不相关的句子。动态示例选择不总是使用全部示例。可以根据当前查询实时从示例库中检索最相关的几个示例来构建Prompt。微调Fine-tuning替代如果任务非常固定且调用频繁将ICL示例中的知识通过微调“固化”到一个小模型中可能是更经济、更高效、延迟更低的选择。微调才是真正的“学会”。6. 超越基础ICL高级模式与未来展望掌握了基础的ICL后我们可以探索一些更高级的模式以解决复杂问题。6.1 思维链提示这是当前提升复杂推理任务性能最有效的方法之一。其核心是在示例中不仅展示答案还展示得出这个答案的逐步推理过程。基本格式问题一个篮子里有5个苹果你拿走了2个又放进去3个现在篮子里有几个苹果 思考最初有5个。拿走2个后剩下5-23个。再放进去3个现在有336个。 答案6个。 问题[你的新问题] 思考这种方法强迫模型“慢思考”模仿人类的推理步骤极大地提高了在数学、常识推理、逻辑谜题等任务上的准确性。在实际应用中设计好的、逻辑清晰的“思考”示例是成功的关键。6.2 自洽性解码与投票对于开放式或容易产生多样答案的问题单一生成结果可能不可靠。自洽性方法通过让模型多次生成答案每次可以略有不同通过调整temperature实现然后从这些生成结果中选择最一致的答案作为最终输出。操作流程使用同一个Prompt调用模型N次例如N5得到N个候选答案。对这些答案进行聚类或统计。出现频率最高的答案或者经过简单后处理如提取数字、选择最长/最短后最一致的答案被选为最终答案。这种方法能有效平滑掉模型的随机波动提高输出的鲁棒性。6.3 ICL与工具的结合让大模型“动手”大模型不擅长计算和实时信息获取那就让它学会调用工具。通过ICL我们可以教会模型在何时、如何使用外部工具如计算器、搜索引擎API、数据库查询器。示例Prompt设计你是一个助手可以调用工具来回答问题。 可用工具 1. 计算器用于数学计算。调用格式计算器表达式。 2. 搜索用于查询实时信息。调用格式搜索查询词。 示例 用户圆周率的前五位小数乘以2是多少 助手我需要先知道圆周率的前五位小数然后进行计算。 助手搜索圆周率 前五位小数 假设搜索返回3.14159 助手圆周率前五位小数是3.14159。计算3.14159 * 2。 助手计算器3.14159 * 2 假设计算器返回6.28318 助手结果是6.28318。 用户[你的新问题] 助手在这种模式下模型的任务变成了规划和使用工具而将不擅长的子任务外包出去。这是构建强大AI智能体的核心思路之一。回过头看“大模型不是学会了只是会看例子”这个说法虽然略带调侃却精准地指出了ICL的本质——一种基于庞大先验知识的、动态的、情境化的能力引导与激发。它降低了AI应用的门槛让我们能够以“对话”的方式快速开发原型。但与此同时我们必须警惕它的局限性它无法创造预训练知识之外的东西其表现严重依赖于示例的质量和设计且存在不稳定性和偏见放大等风险。因此在实际工作中我的态度是将ICL视为一把锋利无比的“瑞士军刀”而非万能钥匙。对于简单、明确、定义清晰的任务它可能是最快、最优雅的解决方案。但对于需要精确性、可靠性、处理未知知识或复杂逻辑的核心生产系统我们仍需依赖更传统的微调、知识图谱、规则引擎或者将ICL作为复杂流水线中的一个智能组件来谨慎使用。理解ICL就是理解当今大模型能力的核心运作机制之一。它让我们从“魔法崇拜”走向“理性运用”从而能更好地驾驭这项技术去解决真正有价值的问题。
