11 In-Context Learning 详解：为什么提示中给例子模型就会学？-开发者社区

在上一篇 GPT-3 论文精读中，我们重点讲了一个现象：当模型规模足够大之后，即使不对参数进行微调，只要在提示词中给出几个例子，模型也能完成新的任务。

比如我们在提示中写：

句子：这部电影太精彩了。 情感：正面 句子：这个产品质量很差。 情感：负面 句子：这家餐厅的服务让我很满意。 情感：

模型很可能会继续输出：

正面

这个现象就是In-Context Learning，简称 ICL，上下文学习。

它看起来很像“模型学会了一个新任务”，但这里最关键的一点是：

In-Context Learning 并不会更新模型参数。
模型只是根据当前 prompt 中提供的上下文例子，在一次前向推理过程中临时完成任务。

也就是说，模型不是通过反向传播学习，而是通过“读懂上下文”来完成任务。这也是大语言模型区别于传统 NLP 模型的一个重要能力。

1. 什么是 In-Context Learning？

In-Context Learning 指的是：

在不更新模型参数的情况下，通过在输入上下文中提供任务描述、输入输出示例或推理过程，使模型在当前上下文内完成新任务的能力。

这里有几个关键词：

关键词	含义
不更新参数	模型权重保持不变，不进行 fine-tuning
上下文	prompt 中提供的任务说明、例子、问题等内容
临时学习	只在当前输入中生效，换一个 prompt 可能表现不同
完成新任务	模型根据例子推断任务规则，并应用到新的输入上

例如，对于一个已经训练好的语言模型，我们不给它重新训练，只给它这样的 prompt：

把下面的英文翻译成中文： English: I love machine learning. Chinese: 我喜欢机器学习。 English: Transformers are powerful models. Chinese: Transformer 是强大的模型。 English: In-context learning is interesting. Chinese:

模型会根据前面的格式和语义关系，推断出当前任务是“英译中”，然后输出类似：

上下文学习很有趣。

这就是典型的 In-Context Learning。

2. ICL 和传统训练有什么区别？

为了理解 ICL，先看传统机器学习和深度学习中的任务学习方式。

传统方式通常是这样的：

准备训练数据；
定义模型；
定义损失函数；
通过反向传播更新参数；
得到一个适配特定任务的模型。

可以表示为：

其中：

表示模型参数；
x是输入；
y是标签；
是损失函数；
训练过程会不断修改。

但是 In-Context Learning 不一样。在 ICL 中，模型参数 (\theta) 是固定的。模型要做的是根据 prompt 中的上下文 C，预测当前输入 x 的输出 y。可以写成：

其中：

是已经训练好的模型参数，不再更新；
C是上下文示例，也就是 prompt 中给出的例子；
x)是当前要处理的新输入；
y 是模型要生成的答案。

所以传统训练和 ICL 的核心区别是：

对比项	Fine-tuning	In-Context Learning
是否更新参数	更新参数	不更新参数
学习发生在哪里	训练阶段	推理阶段
任务信息存在哪里	模型参数中	prompt 上下文中
适配成本	较高，需要训练	较低，只需要设计 prompt
稳定性	通常更稳定	受 prompt 影响较大
灵活性	每个任务可能需要单独训练	一个模型可以处理多种任务

这也是为什么 GPT-3 之后，prompt engineering 变得非常重要。因为模型能力不再只取决于参数本身，也取决于你如何把任务组织成上下文。

3. “模型学了”到底是什么意思？

很多人第一次看到 In-Context Learning 时，会产生一个误解：

既然模型能根据例子完成任务，那是不是模型在 prompt 里面真的训练了一遍？

严格来说，不是。模型没有像 fine-tuning 那样进行梯度下降，也没有把新知识写入参数。它做的是一种上下文条件下的模式推断。也就是说，模型看到前面的例子后，会推断：

这些输入和输出之间可能存在某种映射关系。 现在新的输入来了，我应该按照这个映射关系继续生成输出。

比如：

苹果 -> apple 香蕉 -> banana 猫 -> cat 狗 ->

模型会判断这是一组“中文词到英文词”的映射，于是输出：

dog

再比如：

2 -> 4 3 -> 9 4 -> 16 5 ->

模型会判断这里的规则可能是：

于是输出：

这里看起来像模型“学会了平方函数”，但本质上是模型根据上下文中的输入输出模式，推断出了当前任务的规则。所以更准确地说：

ICL 不是参数层面的学习，而是上下文层面的任务适配。

4. 为什么给几个例子模型就会做？

这个问题是 In-Context Learning 的核心。我们可以从三个层次理解。

4.1 语言模型本来就在学习“续写模式”

GPT 类模型的训练目标非常简单：

给定前面的 token，预测下一个 token。

也就是：

整个语言模型训练过程可以理解为：

模型在海量文本中不断学习：

前面出现了这样的内容，后面大概率应该接什么？

而互联网文本、书籍、代码、题目解析、问答数据中，本身就大量存在类似这样的结构：

问题：... 答案：... 输入：... 输出：... 例子1：... 例子2：... 现在请完成：...

所以模型在预训练阶段，不只是学习了语言知识，也学习了很多“任务格式”。当我们在 prompt 中给出几个例子时，本质上是在构造一种模型熟悉的文本结构：

输入 A -> 输出 B 输入 C -> 输出 D 输入 E -> ?

模型根据预训练中学到的续写能力，会倾向于生成和前面格式一致、语义一致的答案。因此，ICL 的第一层原因是：

语言模型通过 next-token prediction 学会了在上下文中延续模式。

4.2 Transformer 可以让当前问题关注前面的例子

ICL 能发生，还和 Transformer 的 Self-Attention 结构密切相关。在 Transformer 中，当前 token 的表示不是孤立计算的，而是可以通过注意力机制关注前面所有 token。Self-Attention 的基本形式是：

其中：

Q表示当前 token 的查询向量；
K表示上下文中 token 的键向量；
V表示上下文中 token 的值向量；
注意力权重决定当前 token 应该关注上下文中的哪些内容。

在 ICL 中，prompt 里的示例都会被编码进上下文。例如：

句子：电影很好看 情感：正面 句子：电影很无聊 情感：负面 句子：演员表演很精彩 情感：

当模型生成最后的“情感”时，它可以通过注意力机制关注前面的：

电影很好看 -> 正面 电影很无聊 -> 负面

然后判断当前句子“演员表演很精彩”更接近前面的正面样例，于是输出“正面”。所以 ICL 的第二层原因是：

Transformer 的注意力机制允许模型在生成答案时读取并利用 prompt 中的示例。

如果没有这种上下文建模能力，模型就很难根据前面的例子动态调整当前输出。

4.3 模型会推断“当前到底是什么任务”

ICL 不只是简单模仿格式，更重要的是模型会根据例子推断任务类型。例如下面两个 prompt 的输入形式很像，但任务完全不同。第一个是翻译任务：

red -> 红色 blue -> 蓝色 black -> 黑色 white ->

第二个是分类任务：

red -> color blue -> color black -> color dog ->

虽然格式都是：

A -> B

但模型需要根据上下文判断：

第一个任务是英文到中文；
第二个任务是词语类别判断。

也就是说，模型并不是机械地看到箭头就续写，而是要根据多个示例共同推断当前任务。可以把这个过程理解为一种隐变量推断。

假设当前任务是一个隐藏变量 z，上下文示例 C提供了关于任务的信息，那么模型要做的是：

其中：

z 表示模型推断出来的任务；
C是 prompt 中的例子；
表示模型根据上下文判断当前是什么任务；
表示在该任务下，对新输入生成答案。

从这个角度看，ICL 的过程可以理解为：

先根据例子判断任务是什么， 再根据任务规则处理新的输入。

这也是为什么 few-shot prompt 通常比 zero-shot prompt 更稳定。因为例子越明确，模型越容易判断当前任务。

5. 一个完整的 ICL 推理过程

我们用一个简单的文本分类任务来看模型大概经历了什么。Prompt 如下：

请判断下面评论的情感，只输出“正面”或“负面”。 评论：这个手机续航很好，拍照也清晰。 情感：正面 评论：物流太慢了，包装也破损了。 情感：负面 评论：屏幕显示效果不错，系统也很流畅。 情感：

模型在处理这个 prompt 时，大致可以分为四步。

第一步，识别任务说明：

请判断下面评论的情感，只输出“正面”或“负面”。

模型知道这是一个情感分类任务，而且输出空间只有两个标签：

正面 / 负面

第二步，读取示例格式：

评论：... 情感：...

模型知道每个样本由“评论”和“情感”组成。

第三步，理解输入输出对应关系：

续航很好，拍照清晰 -> 正面 物流太慢，包装破损 -> 负面

模型根据语义判断正负情绪和标签之间的关系。

第四步，应用到新输入：

屏幕显示效果不错，系统也很流畅 -> 正面

最终输出：

正面

整个过程中，没有参数更新，也没有训练过程。所有信息都来自当前 prompt。这就是 In-Context Learning 最直观的工作方式。

6. ICL 为什么在大模型中更明显？

并不是所有语言模型都有很强的 ICL 能力。通常模型越大、训练数据越丰富、上下文窗口越长，ICL 能力越明显。原因主要有三个。

6.1 大模型有更强的模式识别能力

小模型可能只能学习一些局部语言模式，比如词语搭配、简单句法关系。而大模型可以学习更复杂的结构，比如：

题目 -> 解法 -> 答案 输入 -> 中间推理 -> 输出 指令 -> 示例 -> 新问题

这种复杂模式正是 ICL 所需要的。当 prompt 中给出几个例子时，大模型更容易从例子中抽象出任务规则。

6.2 大模型拥有更多任务知识

ICL 的效果并不是凭空产生的。如果模型在预训练中从未接触过某类知识，那么单靠几个例子也很难表现很好。例如，让模型根据几个例子学习一个完全随机的加密规则，它可能就很困难：

A -> 73 B -> 19 C -> 88 D ->

如果这个映射没有任何语义规律，也不是模型训练中见过的结构，那么模型很难推断。但是对于翻译、分类、摘要、信息抽取、代码补全、数学推理等任务，大模型在预训练阶段已经见过大量类似文本。因此，当 prompt 给出几个例子时，模型更像是在激活已有能力，而不是从零学习。

6.3 上下文窗口提供了临时“工作区”

ICL 依赖上下文。prompt 越长，模型能看到的示例、规则、约束就越多。对于大语言模型来说，上下文窗口就像一个临时工作区。在这个工作区里，可以放入：

任务说明；
示例样本；
格式要求；
背景知识；
中间推理；
输出模板。

模型根据这个临时工作区生成答案。所以，ICL 可以理解为：

把任务数据和任务规则临时写进 prompt，让模型在当前上下文中完成适配。

这也是为什么上下文长度变长之后，大模型可以处理更复杂的文档问答、多轮对话、代码项目分析等任务。

7. ICL、Zero-shot、One-shot、Few-shot 的关系

在 GPT-3 之后，常见的提示方式一般分为三类。

7.1 Zero-shot

Zero-shot 不给示例，只给任务说明。

请判断下面句子的情感，只输出“正面”或“负面”。 句子：这部电影非常感人。 情感：

模型需要仅根据任务描述完成任务。优点是 prompt 简洁，成本低。缺点是模型可能误解任务要求，尤其是在任务格式复杂、标签定义模糊时。

7.2 One-shot

One-shot 给一个示例。

请判断下面句子的情感，只输出“正面”或“负面”。 句子：这个产品很好用。 情感：正面 句子：这次体验很糟糕。 情感：

一个示例可以告诉模型：

输入格式是什么；
输出格式是什么；
标签应该怎么写。

但是一个示例通常不足以覆盖任务的多样性。

7.3 Few-shot

Few-shot 给多个示例。

请判断下面句子的情感，只输出“正面”或“负面”。 句子：这个产品很好用。 情感：正面 句子：物流太慢了。 情感：负面 句子：客服回复很及时。 情感：正面 句子：包装破损，体验很差。 情感：负面 句子：屏幕清晰，运行流畅。 情感：

多个示例可以让模型更清楚地理解任务边界。因此，Few-shot 通常比 One-shot 和 Zero-shot 更稳定。

三者之间的关系可以总结为：

方式	是否给示例	适用场景
Zero-shot	不给示例	简单任务、常见任务
One-shot	给一个示例	需要指定输出格式
Few-shot	给多个示例	标签复杂、格式严格、任务容易歧义

In-Context Learning 通常主要指 One-shot 和 Few-shot 这种通过上下文示例让模型完成任务的方式。

8. ICL 和 Prompt Engineering 的关系

ICL 的效果高度依赖 prompt。同一个模型，不同 prompt 可能得到完全不同的结果。例如，对于情感分类任务，如果 prompt 写得很模糊：

分析下面这句话： 这家店服务不错。

模型可能输出一大段解释。但如果 prompt 写成：

请判断情感，只输出“正面”或“负面”。 句子：这家店服务不错。 情感：

模型更可能输出：

正面

如果再加上示例：

句子：体验很好。 情感：正面 句子：质量很差。 情感：负面 句子：这家店服务不错。 情感：

输出会更加稳定。因此，Prompt Engineering 的本质之一就是：

用更清晰的上下文帮助模型更准确地进行 In-Context Learning。

一个好的 few-shot prompt 通常需要注意以下几点。

8.1 示例格式要一致

不建议这样写：

输入：这个产品很好 输出：正面 评论：质量很差 标签是负面 帮我判断：物流很快

格式混乱会增加模型理解难度。更推荐：

评论：这个产品很好。 情感：正面 评论：质量很差。 情感：负面 评论：物流很快。 情感：

格式越统一，模型越容易学习。

8.2 示例要覆盖不同情况

如果所有示例都是正面：

评论：很好用。 情感：正面 评论：非常满意。 情感：正面 评论：体验不错。 情感：正面 评论：太糟糕了。 情感：

模型可能受到前面标签分布影响，更倾向于继续输出“正面”。所以 few-shot 示例要尽量覆盖不同类别：

正面、负面、中性 简单样本、复杂样本 典型样本、边界样本

这样模型才能更准确地理解任务边界。

8.3 标签名称要稳定

如果前面一会儿写“正面”，一会儿写“积极”，一会儿写“好评”，模型可能不知道应该输出哪种格式。

不推荐：

情感：正面 情感：积极 情感：好评

8.4 明确限制输出格式

如果希望模型只输出标签，就要明确写：

只输出“正面”或“负面”，不要解释。

如果希望模型输出 JSON，就写：

请按照如下 JSON 格式输出： { "sentiment": "...", "reason": "..." }

ICL 不只是让模型知道“做什么”，还要让模型知道“怎么输出”。

9. ICL 看起来像学习，但它也有局限

In-Context Learning 很强，但不能把它理解成万能学习能力。

它有明显局限。

9.1 容易受示例顺序影响

在 few-shot prompt 中，示例顺序可能影响结果。

例如：

正面 正面 正面 负面 待判断样本

和：

负面 正面 负面 正面 待判断样本

模型输出可能不同。因为语言模型生成时会受到最近上下文、标签分布、文本结构等因素影响。

9.2 容易学习到错误规律

如果 prompt 中的示例有偏差，模型可能会学到错误规则。

比如：

猫 -> 动物 狗 -> 动物 汽车 -> 动物 飞机 ->

模型可能因为前三个示例都输出“动物”，而错误地输出：

动物

这说明模型不一定总能识别示例中的错误，它有时会优先模仿上下文模式。

9.3 无法真正记住新知识

ICL 中的“学习”只在当前上下文内有效。如果你告诉模型：

在本次对话中，X123 表示某个特殊设备。

模型可以在当前上下文里使用这个信息。但是一旦上下文消失，模型不会像 fine-tuning 那样把它写入参数。因此，ICL 不适合需要长期记忆的场景。

9.4 对复杂推理仍然不稳定

对于简单分类、翻译、抽取任务，ICL 通常效果不错。但对于复杂数学推理、长链路逻辑推理、多步规划任务，单纯 few-shot 可能仍然不稳定。这时候通常需要结合：

Chain-of-Thought；
Self-Consistency；
RAG；
工具调用；
程序执行；
检索增强；
专门微调。

也就是说，ICL 是大模型能力的重要基础，但不是解决所有问题的唯一方法。

10. ICL、Fine-tuning 和 RAG 的区别

在实际应用中，ICL 经常和 Fine-tuning、RAG 一起比较。

10.1 ICL：把任务规则放进 prompt

ICL 的核心是：

通过 prompt 示例告诉模型当前任务怎么做。

适合：

快速验证任务；
小规模定制；
输出格式控制；
少量样本场景；
不方便训练模型的场景。

缺点是：

prompt 长度有限；
成本随上下文增加；
稳定性不如微调；
难以沉淀长期能力。

10.2 Fine-tuning：把任务能力写进参数

Fine-tuning 的核心是：

通过训练数据更新模型参数。

适合：

任务长期稳定；
有较多标注数据；
对输出风格要求统一；
需要降低推理时 prompt 复杂度；
需要更高稳定性的垂直任务。

缺点是：

训练成本更高；
数据质量要求更高；
更新任务需要重新训练或继续训练；
可能带来灾难性遗忘或过拟合问题。

10.3 RAG：把外部知识放进上下文

RAG 的核心是：

先从知识库检索相关内容，再放进 prompt 让模型回答。

适合：

企业知识库问答；
文档问答；
法规、制度、产品手册查询；
需要使用最新知识的任务；
希望答案可追溯来源的场景。

RAG 和 ICL 并不冲突。

事实上，RAG 检索出来的内容也是上下文的一部分，模型仍然要通过上下文理解和生成答案。

可以说：

RAG 负责把相关知识找出来，ICL 负责让模型在当前上下文中利用这些知识完成任务。

三者对比如下：

方法	信息放在哪里	是否更新参数	适合场景
ICL	Prompt 示例中	否	快速适配任务
Fine-tuning	模型参数中	是	长期稳定任务
RAG	外部知识库 + Prompt	否	知识密集型问答

11. 一个更深入的理解：ICL 是“临时构造任务空间”

我们可以把 prompt 看成一个临时的小数据集。

例如：

(x_1, y_1) (x_2, y_2) (x_3, y_3) x_q -> ?

模型要根据这些示例推断：

背后的映射关系是什么。

于是对于新输入，模型生成：

这里的f不是一个新训练出来的模型，而是大语言模型在上下文中表现出来的临时函数。从直觉上看，ICL 就像是：

把几个样本临时放到模型面前， 让模型根据这些样本猜测当前任务， 然后用猜到的任务规则处理新样本。

这也是为什么 ICL 能够支持非常灵活的任务形式。比如同一个模型，可以通过不同 prompt 完成：

翻译 分类 摘要 信息抽取 代码生成 SQL 生成 文本改写 数学推理 表格理解 问答系统

模型本身没有为每个任务单独训练一个分类头，而是通过上下文动态切换任务行为。这就是大语言模型“通用性”的重要来源。

12. 为什么 ICL 是 GPT-3 的关键突破？

在 GPT-1 和 BERT 时代，主流思路仍然是：

预训练模型 + 下游任务微调

也就是说，预训练只是提供一个好的初始化参数，下游任务仍然需要训练。GPT-3 的重要变化在于，它证明了：

当语言模型足够大时，仅通过 prompt 中的任务说明和少量示例，就可以在很多任务上获得不错的性能。

这意味着大模型开始从“需要微调的基础模型”，转向“可以直接通过提示使用的通用模型”。这种范式变化非常重要。以前我们使用模型的方式是：

为每个任务收集数据 为每个任务训练模型 为每个任务部署模型

而现在可以变成：

准备一个通用大模型 为不同任务设计 prompt 通过上下文临时适配任务

这极大降低了使用 NLP 模型的门槛。也正是从 GPT-3 开始，Prompt、Few-shot Learning、In-Context Learning 成为了大语言模型领域的核心概念。

13. ICL 的本质总结

最后，我们可以用一句话总结 In-Context Learning：

In-Context Learning 是大语言模型在不更新参数的情况下，根据 prompt 中的示例和任务描述，在当前上下文内临时推断任务规则并生成答案的能力。

它的本质不是传统意义上的训练，而是：

上下文理解 + 模式匹配 + 任务推断 + 条件生成

从模型角度看，它依赖：

语言模型的 next-token prediction 训练目标；
Transformer 的 Self-Attention 机制；
大规模预训练中积累的任务格式和语义知识；
足够大的模型容量；
prompt 中清晰、稳定、具有代表性的示例。

从应用角度看，它带来了一个非常重要的变化：

我们不再总是通过修改模型来适配任务，而是可以通过修改上下文来适配任务。

这也是大语言模型时代最重要的范式变化之一。

14. 本文小结

本文围绕 “为什么提示中给例子模型就会学” 解释了 In-Context Learning 的核心逻辑。

主要结论如下：

ICL 不会更新模型参数，它发生在推理阶段；
prompt 中的示例相当于一个临时小数据集；
模型通过上下文推断当前任务是什么；
Transformer 的注意力机制让模型可以读取并利用前面的示例；
大规模预训练让模型学会了大量任务格式和输入输出模式；
few-shot prompt 可以显著增强模型对任务格式和标签规则的理解；
ICL 很灵活，但也容易受到 prompt 顺序、示例质量和上下文长度影响；
ICL、Fine-tuning、RAG 不是互相替代关系，而是适用于不同场景的能力增强方式。

如果说 GPT-1 证明了“生成式预训练可以迁移到下游任务”，GPT-2 证明了“语言模型可以进行 zero-shot 泛化”，GPT-3 则进一步证明了：

大语言模型可以通过上下文示例，在不训练的情况下临时适配新任务。

而 In-Context Learning，正是这个能力背后的核心机制。