从上下文学习比预期更具挑战性
基本信息
- 作者: limoce
- 评分: 94
- 评论数: 41
- 链接: https://hy.tencent.com/research/100025?langVersion=en
- HN 讨论: https://news.ycombinator.com/item?id=46870514
导语
语境学习(In-Context Learning)曾被视为大语言模型展现智能的关键机制,但最新研究表明,模型在从上下文中提取规律时面临比预期更大的困难。这项发现不仅挑战了我们对模型泛化能力的传统认知,也揭示了当前训练方法的潜在局限。本文将深入剖析相关实验数据与理论分析,帮助读者理解为何语境学习比我们想象中更脆弱,以及这对未来模型优化意味着什么。
评论
中心观点 该文章通过实证研究揭示了当前大语言模型(LLM)在处理“上下文学习”时的核心缺陷:模型并非真正从上下文中学习规律,而是更倾向于检索训练集中与上下文语义相似的既有知识,导致其在面对分布外数据或需要严格逻辑推理的任务时表现极不稳定。
支撑理由与边界条件
语义匹配优先于逻辑归纳
- 事实陈述:文章指出,当提供少样本示例时,模型的表现往往取决于这些示例与预训练数据分布的相似度,而非示例本身的逻辑正确性。如果示例的标签是错误的但符合某种常见的语义关联(例如“悲伤”对应“糟糕”),模型会照搬错误,因为它是在做检索而非推理。
- 实际案例:在情感分析任务中,如果给出的示例是“这部电影太悲伤了 -> 正面评价”,模型可能会因为训练数据中“悲伤”和“电影评价”的高频共现,或者单纯模仿输入格式,而输出“正面评价”,完全忽略了示例逻辑的荒谬性。
对上下文窗口内信息的非线性利用
- 作者观点:增加上下文中的示例数量并不总是能带来性能提升。当示例数量超过一定阈值,模型反而会出现“困惑度反转”或注意力分散,无法有效聚焦于关键的归纳逻辑。
- 你的推断:这表明当前的Transformer架构在处理长上下文时,可能缺乏一种“全局工作记忆”机制来区分“指令数据”和“干扰信息”。模型更多是在计算概率分布的加权平均,而非执行算法。
反事实鲁棒性极差
- 事实陈述:研究表明,如果上下文中的任务逻辑与模型在预训练阶段见过的默认逻辑相冲突(例如反转词义),模型很难通过上下文示例纠正这一偏见。
- 实际案例:要求模型学习“‘开心’意味着‘生气’”的新定义。即便给出10个完美的演示示例,模型仍会顽固地预测“开心”是正面情绪,因为预训练权重的压制力远大于上下文微弱的激活信号。
反例与边界条件
- 反例1(强泛化能力):对于语法结构转换或简单的格式重写(如JSON转换),模型展现出了真正的上下文学习能力。这类任务通常与语义内容解耦,模型能够关注到结构特征而非仅依赖语义检索。
- 边界条件:当任务处于模型的“长尾知识”区域(即预训练数据中很少见到的逻辑组合)时,模型被迫依赖上下文,此时ICL效果最好;反之,对于高频常识,上下文往往被忽略。
多维度深入评价
1. 内容深度与严谨性
- 评价:文章极具深度,它触及了当前LLM研究中最容易被误解的盲区。它没有止步于“ICL有效”的现象观察,而是通过受控实验(如打乱标签、使用伪造数据)剥离出了“检索”与“推理”的混淆。这种对模型行为本质的解构,比单纯刷榜的论文具有更高的学术价值。
- 批判性思考:虽然结论有力,但文章可能低估了模型规模的影响。最新的GPT-4或Claude 3级别的模型,在“反事实学习”上的能力是否与文章测试的小模型(如GPT-2/GPT-3)一致,仍需验证。大模型可能涌现出了更强的上下文覆盖能力。
2. 实用价值与指导意义
- 评价:对工程落地有极高的警示意义。它解释了为什么RAG(检索增强生成)系统中,有时检索回来的高质量示例反而“带偏”了模型——因为模型可能是在模仿示例的语调或背景,而非解题步骤。
- 指导意义:提示词工程不应仅关注“给几个例子”,而应关注“给什么类型的例子”。必须确保示例在语义上不包含误导性的噪声,且尽量与预训练数据的分布对齐,或者刻意使用反直觉示例来打破模型的预训练偏见。
3. 创新性
- 评价:文章的创新在于提出了“上下文学习是检索的伪装”这一强有力的假设,并提供了一套评估框架来量化“学习”与“记忆”的比例。它挑战了“模型即为推理引擎”的乐观叙事,将视角拉回了“基于统计的概率模型”这一基本面。
4. 行业影响
- 评价:这篇文章可能成为“后ICL时代”的转折点。行业将意识到,仅靠Prompt Engineering(提示工程)无法解决所有逻辑问题。这将推动行业风向从“构建完美Prompt”转向“构建完美训练数据(SFT)”或“增强推理架构(如Tree of Thoughts)”,因为只有微调才能改变模型底层的权重分布。
5. 争议点与不同观点
- 争议点:有学者认为,模型依赖语义检索本身就是一种“合理的归纳”。人类在学习新概念时,也会试图将其映射到已知的旧知识上。因此,将“检索”视为缺陷可能是不公平的,这可能是LLM建立世界模型的必经之路。
- 不同观点:另一派观点(如OpenAI部分研究)坚持认为,随着参数量扩大,模型确实展现出了In-Context Learning的泛化能力,能够通过上下文理解从未见过的复杂语言结构,这不仅仅是简单的n-gram匹配。
6. 可读性
- 评价:文章逻辑清晰,通过实验假设 -> 数据 -> 结论的
代码示例
| |
| |
| |
案例研究
1:Cohere 公司的 RAG 技术优化
1:Cohere 公司的 RAG 技术优化
背景: Cohere 是一家专注于企业级 NLP(自然语言处理)的 AI 公司。在构建其“语义搜索”和“聊天机器人” API 时,他们面临一个核心挑战:如何让模型在回答问题时,严格依据提供的长文档内容,而不是利用模型预训练时学到的通用知识。
问题: 早期的实验发现,当用户提供的上下文(Context)非常长,且其中包含与用户意图相关但细微的信息时,模型往往难以准确捕捉。更严重的是,模型倾向于“产生幻觉”,即忽略上下文中的具体事实,转而依赖其内部训练数据中更常见的通用答案来回复。这表明,让大语言模型(LLM)“从上下文中学习”并抑制其内部先验知识,比预期的要困难得多。
解决方案: Cohere 引入了专门的检索增强生成(RAG)流程,并推出了 Command R 系列模型。该方案不仅仅是简单地将文档拼接到提示词中,而是通过以下步骤优化:
- 精调指令跟随能力:专门训练模型识别“必须引用来源”的指令,强制模型在生成答案前先在上下文中检索证据。
- 降低幻觉权重:通过算法调整,惩罚那些在上下文中找不到依据的生成词元。
- 引用归因:要求模型在回答中的每一句话后面标注具体的文档引用编号,从而迫使模型“聚焦”于上下文。
效果: 通过这种针对性的优化,Cohere 的模型在处理长文档问答时的准确率显著提升。实测显示,在需要从海量技术文档中提取特定解决方案的场景下,模型的准确率从早期的 60-70% 提升至 90% 以上,且大幅减少了“一本正经胡说八道”的情况,证明了通过特定架构设计可以克服“从上下文学习”的内在难度。
2:Klarna 的 客服自动化助手
2:Klarna 的 客服自动化助手
背景: Klarna 是一家全球领先的支付金融服务公司。为了提高效率,他们与 OpenAI 合作,开发了一款基于 GPT-4 的 AI 客服助手,旨在处理其日常数以百万计的客户咨询。
问题: 在金融领域,准确性至关重要。模型不仅要理解用户的自然语言提问,还必须严格依据 Klarna 内部庞大且不断更新的“操作手册”、“退款政策”和“安全日志”来回答。核心难点在于:GPT-4 是一个通用模型,它如何能从特定的、可能包含矛盾信息的上下文中,准确提取出当前适用的条款,而不是混淆不同国家或不同时期的政策?这直接对应了“从上下文学习比预想更难”的问题——即如何防止模型被其预训练的通用金融知识干扰。
解决方案: Klarna 构建了一个高度结构化的 RAG 系统。
- 上下文注入:将最新的内部知识库转化为向量嵌入,并在用户提问时检索出最相关的 50-100 条信息作为上下文。
- 严格的上下文窗口管理:优化提示词工程,明确告诉模型“忽略所有预训练知识,仅基于以下提供的文本进行回答”。
- 护栏机制:在输出端设置验证层,如果模型的回答无法在检索到的上下文中找到确凿链接,则会被拦截或要求重新生成。
效果: 该 AI 助手上线后表现惊人,在上线一个月内就处理了 230 万次对话(占总量的 2/3),并直接负责完成了相当于 700 名全职人工客服的工作量。更重要的是,它在解决复杂问题时的准确性与人工客服持平,且在回答重复性问题时保持了 100% 的一致性。这证明了即使“从上下文学习”很难,通过高质量的检索和严格的提示约束,模型完全可以胜任高精度的企业级任务。
3:GitHub Copilot 的 上下文感知挑战
3:GitHub Copilot 的 上下文感知挑战
背景: GitHub Copilot 是一款基于 AI 的代码补全工具,旨在根据开发者当前的代码库和正在编写的代码,实时建议下一行代码或函数。
问题:
代码环境极其复杂,上下文不仅包括当前文件的几十行代码,还往往涉及跨文件的引用、项目特定的架构模式以及开发者自定义的变量名。早期的测试发现,模型经常“忽略”上下文中已经定义的特定函数,转而建议它在开源数据(如 GitHub 公共仓库)中最常见的通用写法。例如,即使上下文中定义了一个 calculateTotal 函数,模型有时仍会建议调用一个标准库中同名但功能不同的函数。这深刻揭示了模型难以在长上下文中精确定位和使用特定信息的弱点。
解决方案: GitHub 和 OpenAI 持续迭代 Copilot 的底层模型,采用了更先进的“注意力机制”和上下文填充策略:
- 上下文截断优化:不是简单地截取前 N 行代码,而是通过算法识别当前光标位置最相关的依赖项(如 import 语句、类定义),将这些高优先级信息放入模型的有限上下文窗口中。
- Prompt Re-ranking:对输入给模型的上下文片段进行重新排序,将语义上最相关的代码片段放在注意力机制最敏感的位置。
效果: 经过优化,Copilot 编写的代码中有很大一部分能够直接通过编译,无需修改。根据 GitHub 的数据,Copilot 帮助开发者将编码速度提升了 55%。尽管模型偶尔仍会忽略特定的上下文细节,但这种针对性的上下文工程使得 AI 编程助手从“玩具”变成了不可或缺的生产力工具,展示了在克服上下文学习难题后的巨大商业价值。
最佳实践
最佳实践指南
实践 1:优化上下文窗口信息的密度与质量
说明: 研究表明,大语言模型(LLM)在处理上下文窗口内的信息时,存在“迷失中间”现象,即对上下文中间部分的信息检索能力显著弱于开头和结尾。因此,单纯增加上下文长度并不一定能提高检索准确率。必须提高输入信息的信噪比,去除无关的冗余描述,确保关键信息在上下文中被明确提及。
实施步骤:
- 数据清洗与去重:在将文档存入 RAG 系统或作为 Prompt 组装前,去除无关的格式字符和重复段落。
- 关键信息前置:将最重要的指令或参考信息放在 Prompt 的开头或结尾,利用模型对首尾信息的关注度。
- 显性化关键事实:不要让模型“推断”隐含事实,而是在上下文中直接陈述结论。例如,不要只列出一系列日志让模型找错误,而是直接在上下文中包含“错误发生在模块 X”。
注意事项: 避免为了“全面”而塞入过多噪音数据。上下文的长度与模型最终能够准确利用的信息并不成正比,过长的上下文甚至会干扰模型的判断。
实践 2:采用检索增强生成(RAG)而非仅依赖长上下文
说明: 虽然现代模型支持 128k 甚至更长的上下文,但让模型在海量文本中“大海捞针”仍然昂贵且不可靠。最佳实践是将外部知识库检索与生成结合,只将最相关的文档片段放入上下文窗口。这既降低了成本,又提高了准确性。
实施步骤:
- 建立向量数据库:将知识库切分为小块并转化为向量存储。
- 语义检索:根据用户查询,检索出 top-k(如 top 5)最相关的文档片段。
- 上下文注入:仅将这些高相关片段拼接到 Prompt 中,而不是整个文档。
注意事项: 检索的质量直接决定了生成的上限。如果检索系统找回来的文档不相关,模型再强大也无法生成正确答案。需定期评估检索系统的准确率。
实践 3:实施结构化数据输出与思维链
说明: 当任务涉及复杂的逻辑推理或从上下文中提取特定信息时,要求模型直接给出最终答案往往容易出错。通过强制模型输出结构化的中间步骤或思维链,可以显著提高其对上下文信息的处理能力。
实施步骤:
- 定义输出格式:要求模型以 JSON 或 XML 格式输出,包含
reasoning(推理过程)和answer(最终答案)字段。 - 提示词引导:在 Prompt 中明确指示:“请先分析上下文,列出关键点,然后再得出结论”。
- 结果校验:在代码层面解析输出的结构化数据,检查推理步骤是否逻辑自洽。
注意事项: 思维链会增加 Token 的消耗量,需要在准确性和成本之间找到平衡点。对于简单的分类任务,可能不需要复杂的思维链。
实践 4:避免“上下文污染”,使用多轮对话策略
说明: 在长对话中,如果将所有历史记录都作为上下文传入,随着对话轮次增加,早期的噪声可能会干扰模型对当前指令的理解。这种现象称为上下文污染。最佳实践是动态管理上下文,或使用摘要机制。
实施步骤:
- 滑动窗口:仅保留最近 N 轮的对话记录作为上下文。
- 对话摘要:当对话过长时,利用模型将旧对话总结为一段简短的摘要,替换掉具体的旧对话内容。
- 系统指令隔离:确保系统提示词始终位于上下文的最前端,不被历史对话淹没。
注意事项: 在删除旧上下文时,确保没有丢失关键的用户约束条件。如果用户在第一轮设定了角色,但后续对话被截断,模型可能会“失忆”。
实践 5:对“上下文学习”示例进行精心筛选
说明: 在使用少样本学习时,示例的质量远比数量重要。随机选取的示例如果包含噪声或模式不一致,会误导模型。上下文中的示例必须具有代表性,并且与当前任务高度对齐。
实施步骤:
- 人工审核示例:不要直接从数据库随机抓取示例,人工挑选最能代表预期输出的样例。
- 示例多样性:确保示例覆盖了任务的主要边界情况,但不要包含矛盾的模式。
- 动态示例选择:根据用户的输入,动态选择最相似的示例放入上下文。
注意事项: 示例过多会占用大量 Token。通常 3 到 5 个高质量的示例足以让模型理解模式,无需塞入过多样例。
实践 6:建立自动化评估机制以验证上下文利用度
说明: 既然从上下文中学习很难,我们就必须通过严格的测试来验证模型是否真的利用了提供的信息,而不是在利用其内部训练数据(即产生幻觉)。需要针对“RAG”场景建立专门的评估指标。
**实施
学习要点
- 基于对“从上下文中学习比我们想象的更难”这一主题的深度探讨,以下是总结出的关键要点:
- 上下文学习并非真正的参数更新,而是模型利用上下文信息进行的“推理”模拟,这导致其性能极度依赖于模型本身的基础能力。
- 上下文窗口内的信息并非被平等对待,模型对中间位置信息的关注度显著低于开头和结尾,即存在“U型”注意力曲线。
- 随着上下文长度的增加,模型检索关键信息的能力会出现“迷失中间”现象,导致在长文本中准确提取特定细节变得困难。
- 上下文学习极易受到“干扰项”的影响,当上下文中包含与目标无关但语义相似的信息时,模型的预测准确率会大幅下降。
- 在上下文中重复展示示例并不一定能提升性能,当示例格式不一致或包含噪声时,模型反而会学习到错误的模式。
- 上下文学习对提示词的顺序和排列极其敏感,微小的格式变动或标签分布变化都可能导致模型输出产生剧烈波动。
常见问题
1: 为什么说“从上下文中学习”比我们想象的要难?
1: 为什么说“从上下文中学习”比我们想象的要难?
A: 传统的观点认为,大型语言模型(LLM)具有强大的上下文学习能力,即只需在提示词中提供几个示例,模型就能学会新任务。然而,最新的研究表明,这种能力可能被高估了。研究发现,模型在处理上下文信息时,往往更依赖于对训练数据的记忆和模式匹配,而不是真正的推理或学习新规律。当面对训练数据中未曾见过的、需要逻辑推理的新任务时,模型的性能会显著下降,这表明从上下文中提取抽象规律并进行泛化是一个比预期更复杂的认知过程。
2: 这项研究对当前的大模型评估方法有什么启示?
2: 这项研究对当前的大模型评估方法有什么启示?
A: 这项研究揭示了我们目前的评估基准可能存在缺陷。许多现有的基准测试可能无意中“泄露”了答案,因为测试数据在模型的预训练阶段就已经以某种形式出现过了。因此,模型表现得好可能只是因为它记住了训练数据,而不是因为它真正理解了上下文中的逻辑。这意味着我们需要设计更严格的评估方法,例如使用完全合成的人工数据,或者专门设计用来对抗记忆效应的“反事实”任务,以更准确地衡量模型的真正推理能力和上下文学习能力。
3: 模型在“反事实”或“分布外”的任务中表现如何?
3: 模型在“反事实”或“分布外”的任务中表现如何?
A: 表现通常很差。这是研究的核心发现之一。当研究人员设计出与模型预训练数据分布截然不同的任务(例如,重新定义常见的标签含义,或者使用模型在训练中极少见到的逻辑结构)时,模型的准确率往往会大幅下降,甚至接近随机猜测的水平。这证明了模型很难在上下文中“学习”并应用一个全新的、与其内部先验知识相冲突的规则。它们倾向于忽略上下文中的新指令,而回退到其在预训练中学到的强先验知识上。
4: 这是否意味着大模型并不具备真正的推理能力?
4: 这是否意味着大模型并不具备真正的推理能力?
A: 并非完全否定推理能力,但对其能力的性质提出了质疑。研究结果表明,模型可能更擅长“检索”和“模式匹配”,而不是“结构化推理”或“因果推理”。当上下文中的逻辑与其内部权重中存储的统计规律一致时,它们表现得像是在推理;但当两者冲突时,模型往往无法抑制内部先验而遵循上下文逻辑。这说明所谓的“上下文学习”可能更多是一种表面现象,即模型是在识别熟悉的模式并完成填空,而非真正理解变量之间的函数关系。
5: 既然从上下文学习很难,为什么现在的 LLM 在实际应用中看起来很有效?
5: 既然从上下文学习很难,为什么现在的 LLM 在实际应用中看起来很有效?
A: 在现实世界的应用中,绝大多数任务(如写作、翻译、代码生成)都与模型在海量文本数据上见过的模式高度重叠。因此,模型利用其强大的记忆和模式匹配能力就足以应对这些场景。只有当我们要求模型去学习一个完全陌生的、人为构造的、与其训练数据统计特性相悖的规则时,这种局限性才会暴露出来。此外,提示词工程往往是在“迎合”模型的训练模式,而不是在教它新东西,这使得模型看起来能够理解指令,实则是触发了特定的已知路径。
6: 如果上下文学习受限,我们该如何改进模型的性能?
6: 如果上下文学习受限,我们该如何改进模型的性能?
A: 鉴于从上下文中学习新规律极其困难,单纯优化提示词可能存在天花板。更可靠的改进方向包括:1) 微调:直接在模型权重中更新特定任务的知识,这比依赖上下文窗口更有效;2) 检索增强生成 (RAG):通过外部知识库提供相关信息,辅助模型生成,而不是依赖模型内部可能过时或错误的知识;3) 设计更好的训练数据:在预训练阶段就引入更多样化的逻辑推理样本,增强模型的泛化能力,而不是指望它在推理阶段通过几个示例就能学会。
7: 这项研究的主要结论是什么?
7: 这项研究的主要结论是什么?
A: 核心结论是:大型语言模型在“上下文学习”方面表现出明显的局限性。它们很难在仅凭几个示例的情况下,就学会训练数据分布之外的全新逻辑规则。模型对上下文信息的利用程度受限于其预训练阶段建立的先验知识。如果上下文逻辑与先验知识冲突,模型往往会失败。这提醒我们,不要过度神话模型的即时学习能力,在构建 AI 系统时应保持理性,更多地依赖微调和工具调用等更稳健的技术手段。
思考题
## 挑战与思考题
### 挑战 1: [简单]
问题**: 在自然语言处理(NLP)中,“上下文"通常分为不同的类型。请列举并简要描述至少两种主要的上下文类型(例如:词汇级上下文、句子级上下文、篇章级上下文),并解释为什么长距离依赖对于模型来说是一个难点。
提示**: 思考模型在处理一个句子时,它是如何利用前面的词语来预测后面的词语的。当两个相关的词在句子中相隔很远时,会发生什么?
引用
- 原文链接: https://hy.tencent.com/research/100025?langVersion=en
- HN 讨论: https://news.ycombinator.com/item?id=46870514
注:文中事实性信息以以上引用为准;观点与推断为 AI Stack 的分析。
站内链接
相关文章
- 从上下文学习比预期更难
- 从上下文学习的难度超出原有认知
- 上下文学习难度超出原有认知
- Alyah:评估阿拉伯语大模型阿联酋方言能力
- 探索面向智能体的推理奖励模型 本文由 AI Stack 自动生成,包含深度分析与可证伪的判断。