从上下文学习比预期更难

基本信息

导语

语境学习（In-Context Learning）是大语言模型的一项核心能力，但最新研究表明，模型从上下文中提取信息的过程比我们预想的更为复杂且脆弱。这项研究深入剖析了模型在处理上下文依赖任务时的局限性，揭示了其内部机制的运作细节。通过阅读本文，读者可以更客观地评估当前模型的实际表现，并了解在复杂应用场景中如何更有效地利用这一能力。

评论

深度评论

1. 内容深度：对“涌现能力”神话的祛魅与机制解构 [事实陈述] 该文章在方法论上极具严谨性，作者并未止步于展示SOTA（State of the Art）性能指标，而是通过“最小化对抗性测试”和“反事实数据构造”剥离了模型的伪装。 [你的推断] 文章的深度在于它挑战了当前AI社区对“涌现能力”的过度神话。通过精细的消融实验，研究揭示了ICL可能并非真正的“元学习”，而更接近于一种基于贝叶斯推理的近似形式——即模型是在计算 $P(\text{label} | \text{context})$ 而非真正习得了 $\text{task}$。这种对“黑盒”内部机制的解构，证明了ICL本质是对训练数据显性记忆的检索，这种视角的转换比单纯刷榜更具学术价值。

2. 实用价值：从“Prompt工程”转向“数据工程”的警示 [事实陈述] 文章指出的ICL对“预训练数据分布”的强依赖特性，对工程落地具有极强的警示作用。 [你的推断] 这意味着，若指望仅通过Prompt让大模型处理公司内部特有的、从未见过的复杂业务逻辑（如特殊的SQL语法或独特的审批流），纯ICL方案大概率会失败。实际指导意义在于：它迫使工程师从“狂热的Prompt Engineering”回归“数据工程”。既然模型依赖预存记忆，那么构建高质量、高相关性的知识库（用于检索）比设计复杂的Prompt模板更为关键。

3. 创新性：确立“模式匹配”作为ICL的核心解释 [作者观点] 文章的核心创新在于提出了“上下文学习是模式匹配的副产物”这一强有力的竞争假设，有力地挑战了“元学习”是ICL唯一解释的主流观点。 [你的推断] 尽管此前业界有零散讨论，但本文通过系统性数据证明了“预训练数据分布”对ICL性能的决定性影响。这一发现为理解LLM的认知局限提供了新的理论框架，将讨论从“模型是否推理”引向了“模型如何复现记忆”的更深层次。

4. 可读性：逻辑闭环与直观的实证展示 [事实陈述] 文章结构清晰，遵循从现象观察到假设提出、再到实验验证的科学范式，逻辑链条完整。 [你的推断] 尽管涉及统计学和认知科学概念，作者通过对比实验图表，直观地展示了模型“懂概念”与“懂模式”的区别，成功降低了理解门槛，使非专业读者也能领会“检索依赖”的精髓。

5. 行业影响：重塑RAG与Agent的开发路径 [你的推断] 这篇文章可能会给“无模型微调”的狂热泼下一盆冷水，并对行业产生深远影响：

  1. RAG领域：将推动RAG从简单的“语义检索”向“结构化知识注入”进化，单纯的上下文填充将被证明是不够的。
  2. Agent开发：提示开发者不要赋予LLM超出其能力的规划任务。因为模型可能只是在模仿规划的语言形式，而非真正理解逻辑，这要求在设计Agent时必须引入更严格的外部验证机制。

代码示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

# 示例1：上下文感知的文本摘要
from transformers import pipeline

def summarize_with_context(text, max_length=100):
    """
    使用预训练模型生成文本摘要，展示模型如何处理长上下文
    :param text: 输入文本
    :param max_length: 摘要最大长度
    :return: 摘要结果
    """
    summarizer = pipeline("summarization", model="facebook/bart-large-cnn")
    summary = summarizer(text, max_length=max_length, min_length=30, do_sample=False)
    return summary[0]['summary_text']

# 测试示例
long_text = """
人工智能（AI）是计算机科学的一个分支，致力于创建能够执行通常需要人类智能的任务的系统。
这些任务包括学习、推理、问题解决、感知和语言理解。AI技术已经应用于各个领域，
包括医疗诊断、自动驾驶、语音识别和自然语言处理等。尽管AI取得了巨大进展，
但在处理长文本和复杂上下文时仍然面临挑战。
"""

print(summarize_with_context(long_text))

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

# 示例2：上下文相关的问答系统
from transformers import AutoTokenizer, AutoModelForQuestionAnswering
import torch

def answer_question(context, question):
    """
    基于给定上下文回答问题，展示模型如何利用上下文信息
    :param context: 背景文本
    :param question: 问题
    :return: 答案
    """
    tokenizer = AutoTokenizer.from_pretrained("deepset/roberta-base-squad2")
    model = AutoModelForQuestionAnswering.from_pretrained("deepset/roberta-base-squad2")
    
    inputs = tokenizer(question, context, return_tensors="pt", max_length=512, truncation=True)
    with torch.no_grad():
        outputs = model(**inputs)
    
    answer_start = torch.argmax(outputs.start_logits)
    answer_end = torch.argmax(outputs.end_logits) + 1
    answer = tokenizer.convert_tokens_to_string(tokenizer.convert_ids_to_tokens(inputs["input_ids"][0][answer_start:answer_end]))
    
    return answer

# 测试示例
context = """
Python是一种高级编程语言，由Guido van Rossum于1991年首次发布。
它以简洁明了的语法著称，支持多种编程范式，包括面向对象、命令式、函数式和过程式编程。
Python广泛应用于Web开发、数据分析、人工智能等领域。
"""
question = "Python是什么时候发布的？"

print(answer_question(context, question))

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

# 示例3：上下文感知的情感分析
from transformers import pipeline

def analyze_sentiment_with_context(text):
    """
    分析文本情感，考虑上下文信息
    :param text: 输入文本
    :return: 情感分析结果
    """
    classifier = pipeline("sentiment-analysis", model="cardiffnlp/twitter-roberta-base-sentiment")
    result = classifier(text)[0]
    return result

# 测试示例
positive_text = "虽然这部电影节奏有点慢，但演员的表演非常出色，整体来说我很喜欢！"
negative_text = "尽管这家餐厅的装修很豪华，但食物味道很差，服务也不周到。"

print("正面文本分析:", analyze_sentiment_with_context(positive_text))
print("负面文本分析:", analyze_sentiment_with_context(negative_text))

案例研究

1：医疗诊断系统中的上下文理解偏差

1：医疗诊断系统中的上下文理解偏差

背景：某三甲医院引入了基于Transformer架构的AI辅助诊断系统，用于分析电子病历（EHR）。该系统在训练集上表现良好，但在实际临床应用中遇到了准确率问题。

问题：医生书写病历时常使用复杂的否定句式或跨页引用的历史数据（例如“患者否认有青霉素过敏史，但2018年入院记录显示曾出现皮疹”）。AI模型倾向于通过局部关键词匹配（如仅识别“皮疹”），忽略了否定逻辑和时间跨度上的上下文关联，导致误报率较高，医生需要花费额外时间复核。

解决方案：团队引入了医学实体关系抽取模型，并采用了长文本注意力机制。他们构建了包含否定、时序和家族史关联的专项数据集，以强化模型学习“非局部依赖”特征。同时，在推理阶段引入了“解释性模块”，要求模型在给出诊断结论时高亮依据的具体上下文片段。

效果：系统对复杂否定句和历史上下文的理解准确率有所提升，误报率显著下降。医生对AI建议的采纳率随之提高，减少了疑难病例的复核时间。

2：电商智能客服的意图识别难点

2：电商智能客服的意图识别难点

背景：某电商平台拥有日均千万级的咨询量，其智能客服机器人基于BERT模型训练，主要处理退换货、物流查询等常见问题。

问题：在大促期间，用户常在一个对话轮次中混合多个意图，并带有情绪色彩（例如：“衣服质量差，且物流慢，怎么处理？”）。原有模型倾向于仅识别最后一个分句或根据关键词机械回复，忽略了用户情绪对优先级的排序影响，导致用户满意度低，转人工率居高不下。

解决方案：技术团队重构了对话状态追踪（DST）系统，引入了多轮对话历史编码。团队采用了层级注意力网络，分别对“语义内容”和“情感倾向”进行建模，以识别用户的核心诉求。此外，针对上下文切换问题，加入了指代消解模块，处理模糊指代。

效果：机器人对混合意图的识别准确率得到提升，能够更准确地识别用户最关心的问题。在大促期间，智能客服的自动解决率有所提高，缓解了人工客服的压力。

3：代码生成工具在长项目中的逻辑一致性问题

3：代码生成工具在长项目中的逻辑一致性问题

背景：某软件开发公司在内部部署了基于大模型的代码补全助手，旨在辅助工程师编写Java后端服务。

问题：在实际使用中，当需要修改的函数跨越多个文件或依赖之前的定义时，模型生成的代码常出现逻辑不一致。例如，模型建议调用在当前文件中不存在的变量，或忽略了项目头部定义的特定协议，导致生成的代码无法通过编译或存在逻辑漏洞。

解决方案：工程团队实施了RAG（检索增强生成）架构。在生成代码时，系统检索当前项目仓库中相关的类定义、接口文档和提交记录，并将其作为上下文信息。同时，调整了模型的关注窗口，优先参考检索到的项目内部上下文，而非通用训练数据。

效果：代码建议的可采纳率有所上升。生成的代码与项目现有逻辑风格的一致性提高，减少了工程师修复上下文不匹配错误的时间，缩短了功能开发周期。

最佳实践

最佳实践指南

实践 1：避免过度依赖隐式上下文推断

说明: 研究表明，人类和AI在处理信息时，从上下文中推断缺失信息（如隐含意图、省略参数或模糊指代）的认知成本远高于直接获取显式信息。过度依赖上下文推断会导致理解偏差和效率下降。

实施步骤:

  1. 在设计沟通内容或提示词时，明确陈述核心需求和参数，避免假设接收者能够“猜对”。
  2. 检查文档或代码，识别出所有依赖“默认值”或“惯例”的地方，并将其显式化。
  3. 在团队沟通中，推行“不假设”原则，对于模糊的指令立即要求澄清，而不是自行脑补。

注意事项: 显式声明可能会增加初始编写的时间，但这能显著减少后续的来回确认和误解修复的时间。

实践 2：优化上下文窗口的信息密度

说明: 上下文学习并非随着输入信息量的增加而线性增强。当上下文包含过多无关或冗余信息时，模型或读者会难以捕捉关键信号（即“迷失在中间”现象）。高质量、高密度的上下文比单纯的长度更重要。

实施步骤:

  1. 在向LLM提供上下文或编写文档时，删除与当前任务无关的背景信息和噪音。
  2. 使用结构化格式（如JSON、Markdown表格）来组织数据，而非松散的自然语言段落。
  3. 对长文本进行摘要预处理，仅将摘要和关键细节放入上下文窗口，而不是全文。

注意事项: 不要为了填满Token限制而填充内容，上下文的精准度优于广度。

实践 3：建立显式的参照系与定义

说明: 上下文理解困难往往源于对术语和概念定义的不一致。当读者或模型缺乏与作者相同的“知识背景”时，上下文学习就会失效。必须建立显式的参照系。

实施步骤:

  1. 在技术文档或长篇论述的开头，列出“关键术语表”或“核心假设”，确保后续引用有据可查。
  2. 在代码注释中，解释“为什么这样做”而不是仅仅描述“做了什么”，以补充逻辑上下文。
  3. 在跨部门协作中，使用具体的例子来抽象概念，确保双方对同一词汇的理解一致。

注意事项: 定义应当保持一致性，避免在同一上下文中对同一概念使用不同的表述。

实践 4：采用分层上下文呈现策略

说明: 一次性呈现大量上下文会增加处理难度。最佳实践是将信息分层，先呈现高层概览，再根据需要深入细节，这符合人类认知的“由粗到细”的处理机制。

实施步骤:

  1. 采用“金字塔原理”组织内容：结论先行，然后是核心论据，最后是支撑数据。
  2. 在提示词工程中，利用“指令-示例-查询”的结构，将指令与具体数据上下文物理分隔。
  3. 对于复杂的API或系统，提供“快速开始”指南作为第一层上下文，将详细规范作为深层链接。

注意事项: 确保层与层之间的逻辑链接清晰，避免底层细节与高层概览产生矛盾。

实践 5：引入验证机制以确认上下文理解

说明: 由于从上下文学习具有主观性和不确定性，必须建立反馈回路来验证接收者（无论是人还是AI）是否正确提取了上下文中的信息。

实施步骤:

  1. 在AI应用开发中，要求模型在生成最终答案前，先提取并列出关键信息点，由系统进行校验。
  2. 在团队协作中，采用“回传确认”机制，接收方用自己的话复述需求，发送方确认无误后再执行。
  3. 编写测试用例时，不仅测试结果，还要测试对边界条件和特定上下文场景的处理逻辑。

注意事项: 验证机制应当轻量化，避免因验证过程过于繁琐而降低整体效率。

实践 6：将静态上下文转化为动态交互

说明: 静态的上下文（如长文档）往往包含过时或不适用的信息。承认“从上下文学习”的局限性，转而通过动态交互（如检索、提问）来获取信息，往往更有效。

实施步骤:

  1. 实施RAG（检索增强生成）策略，根据当前问题动态检索最相关的上下文片段，而不是每次都提供全量上下文。
  2. 在产品设计中，将复杂的帮助文档转化为交互式向导，根据用户操作动态提供上下文帮助。
  3. 定期审查和维护上下文库，删除过时的示例，确保上下文随业务变化而更新。

注意事项: 动态交互依赖于良好的索引和检索质量，需确保信息源的结构化程度。

学习要点

  • 基于对标题“Learning from context is harder than we thought”（从上下文中学习比我们想象的要难）及相关讨论的常见分析，以下是总结出的关键要点：
  • 上下文学习（ICL）并非简单的模式匹配，而是严重依赖预训练过程中模型对特定模式的记忆程度，而非真正的推理能力。
  • 模型在处理上下文时极易受到“干扰项”的影响，当上下文信息过多或存在矛盾时，模型性能会急剧下降。
  • 仅仅增加上下文窗口的长度并不一定能提升性能，模型往往难以有效检索和利用长窗口末尾或中间的信息（即“迷失在中间”现象）。
  • 上下文学习对示例的顺序和排列非常敏感，微小的格式变化可能导致模型输出巨大的差异。
  • 模型倾向于过度依赖上下文中的表面统计特征，而非理解底层的语义逻辑，这使得它在面对分布外数据时表现不佳。
  • 目前的上下文学习方法缺乏真正的泛化能力，它更多是在模仿预训练数据中的相似案例，而非通过上下文学习到了新的规则。

常见问题

1: 为什么“从上下文中学习”被认为是人工智能领域的一个难题？

1: 为什么“从上下文中学习”被认为是人工智能领域的一个难题？

A: “从上下文中学习”通常指的是大语言模型在不更新权重参数的情况下，仅通过提示词中提供的示例或信息来掌握新任务的能力。这之所以被认为比预期更难，是因为模型本质上是在进行“模式匹配”而非真正的“概念学习”。研究发现，模型往往依赖于训练数据中已见过的模式，或者是基于输入提示的表面特征进行推理，而不是像人类那样通过上下文真正理解潜在的逻辑或因果关系。当面对训练数据中罕见的全新逻辑时，模型的性能会显著下降。

2: 这项研究与提示词工程有什么关系？

2: 这项研究与提示词工程有什么关系？

A: 这项研究直接揭示了提示词工程的局限性。许多用户和开发者试图通过精心设计“少样本”提示，即给模型展示几个例子来让它学会新任务，期望模型能举一反三。然而，研究表明，如果模型只是在进行某种形式的检索或模仿，而不是真正从上下文中提取规律，那么仅仅增加例子数量或调整例子的顺序可能无法带来预期的性能提升。这意味着我们需要更谨慎地评估模型在特定任务上的表现，而不能盲目依赖“给几个例子就能学会”的假设。

3: 模型无法有效从上下文学习，是否意味着它们不具备推理能力？

3: 模型无法有效从上下文学习，是否意味着它们不具备推理能力？

A: 不完全是。模型确实具备一定程度的推理能力，特别是在处理数学、代码或逻辑推理等任务时表现出了惊人的潜力。但是，这项研究强调了这种推理能力的“脆弱性”和“依赖性”。模型可能更擅长利用上下文中的信息来辅助其已有的知识库进行检索和整合，而不是像人类一样能够通过极少量的上下文信息构建全新的、从未见过的认知结构。简单来说，模型更像是“利用上下文进行检索”，而不是“从零开始学习”。

4: 该结论对当前的大模型训练方式有何挑战？

4: 该结论对当前的大模型训练方式有何挑战？

A: 如果模型主要依赖预训练记忆而非上下文推理，那么单纯通过扩大模型规模或增加数据量可能无法解决“泛化能力差”的问题。这挑战了“Scaling Laws（缩放定律）”在所有维度上的有效性。研究暗示，为了提高模型从上下文中学习的能力，可能需要改进训练目标，例如设计专门的架构来鼓励模型关注上下文中的因果关系，或者开发新的训练范式，让模型在预训练阶段就学会如何从局部信息中提取抽象规律，而不仅仅是记忆全局统计规律。

5: 既然从上下文学习很难，未来的 AI 发展方向会是什么？

5: 既然从上下文学习很难，未来的 AI 发展方向会是什么？

A: 这一发现可能会推动研究重心从单纯追求模型参数量转向更高效的架构设计。未来的方向可能包括：1) 开发具有更强“上下文记忆”机制的模型，如结合检索增强生成（RAG）技术；2) 探索新的学习范式，让模型具备更强的元学习能力，即学会如何学习；3) 更关注模型的系统化泛化能力，确保模型能够理解并组合复杂的规则，而不仅仅是模仿输入输出的映射关系。

6: 对于普通用户而言，这一发现意味着什么？

6: 对于普通用户而言，这一发现意味着什么？

A: 对于普通用户而言，这意味着在使用 AI 工具时需要管理预期。虽然 AI 看起来能理解你给它的长文本或新规则，但它可能并没有真正“学会”或“理解”这些内容的深层逻辑。在使用 AI 处理高度专业、逻辑复杂或需要严格从新数据中推导结论的任务时，用户仍需要进行严格的验证，而不能完全信任模型仅凭几行提示就能准确掌握全新的业务逻辑。

思考题

## 挑战与思考题

### 挑战 1: [简单]

问题**:

在自然语言处理（NLP）中，“上下文"通常被分为两类。请列举这两类上下文的名称，并简要说明它们在信息获取方式上的主要区别。

提示**:

引用

注：文中事实性信息以以上引用为准；观点与推断为 AI Stack 的分析。

站内链接

相关文章