现如今,LLM的上下文窗口长度正在经历爆发式增长。
翻开LLM Leaderboard,可以发现顶级模型的上下文长度已经陆续突破了1M tokens,并且这个数字还在不断刷新。

但问题也随之而来:模型能够支持长上下文,那我们就能随心所欲往里面塞内容,输入越多,模型输出效果越好吗?
答案当然是否定的。
毕竟,往模型里塞进一百万个tokens,可能不仅大部分信息都没有用,导致浪费计算资源,还可能干扰模型的判断,导致生成质量下降。
如何精细化地管理和优化这些海量上下文,已经成为Context Engineering(上下文工程) 要解决的核心问题。
那么长上下文在什么情况下会出问题?针对长上下文导致的模型输出崩溃,我们有什么解决方案?本文将对此进行探讨。
01
长上下文的四种失败模式

业界已经总结出了四种常见的长上下文失效的模式:
1. Context Clash(上下文冲突)
多轮对话中累积的信息相互矛盾。就像早上说"我喜欢苹果",中午说"我不喜欢水果",模型会confused:你到底喜不喜欢苹果?
2. Context Confusion(上下文混淆)
上下文中无关信息过多,导致模型在工具调用时选错。类似工具箱里塞满了各种工具,找个螺丝刀反而眼花缭乱。
3. Context Distraction(上下文分心)
海量上下文信息压制了模型的训练知识。就像桌上的教科书被一米高的漫画堆淹没,学生注意力全被吸引走了。
4. Context Poisoning(上下文中毒)
错误信息在多轮对话中不断被引用和强化。第一次说错一个事实,后续对话又基于这个错误继续编造,越走越偏。
02
Context Pruning:精准管理上下文的关键
针对这些长上下文问题,主要有六种管理策略:RAG(检索增强生成)、Tool Loadout(工具装载)、Context Quarantine(上下文隔离)、ContextPruning(上下文剪枝)、Context Summarization(上下文摘要)、Context Offloading(上下文卸载)。
在这些策略中,ContextPruning尤其关键,因为它直接作用于信息输入环节。
在RAG系统里,我们从向量数据库检索回来大量文档,其中大部分是无效或者低相关度信息。而Context Pruning就是要在检索之后、生成之前,精准地过滤掉无关内容。从而带来生成质量提升、计算成本降低、上下文窗口利用率更高。
也是因此,Context Pruning质量,往往会成为RAG优化的核心环节。

03
Provence: 一个实用的ContextPruning模型
研究Context Pruning的时候,我发现了两个有意思的宝藏开源模型:Provence和XProvence,来自Naver AI Lab的工作。

Provence的核心功能很简单:给它一个问题和一段检索回来的文档,它会帮你筛选出真正相关的句子,把无关的内容过滤掉。
这样既加快了LLM生成速度,又减少了噪声干扰。而且它是即插即用的,可以配合任何LLM或检索系统使用。
Provence有几个让我印象深刻的特点。
第一是它会整体理解文档。不像有些方法单独看每个句子,Provence会把所有句子放在一起看。
这很重要,因为文档里经常有"它""这个"这样的指代词,单独看一句话可能不知道在说什么,但放在上下文里就清楚了。这样可以显著提高剪枝的准确性。
第二是它会自己判断该留几句话。不需要你告诉它"给我留5句话"或"留10句话",它会根据具体情况决定。有些问题可能一句话就够了,有些可能需要好几句,Provence都能自动处理。
第三是效率很高。一方面它是个轻量级模型,比调用大型LLM快多了;另一方面它把剪枝和重排序(Reranking)合在一起做了,基本不增加额外成本。
第四是它有跨语言版本。XProvence是Provence的跨语言版本,它是另外单独训练的一个模型,支持多种语言,包括中文、英文、韩文等。训练模式大致和Provence一样,只是数据集不同。
实现上,Provence采用了比较巧妙的设计。它的输入很简单:把问题和文档拼起来,一起送进模型。这种 Cross-Encoder 架构,让模型能同时看到问题和文档的全貌,理解它们之间的关联。

此外,Provence是基于DeBERTa训练微调的,作为一个轻量级的Encoder模型,训练时它同可以时做两件事:
-
给整个文档打分(Rerank score)- 判断这段文档和问题的相关程度,比如0.8分表示相关度很高
-
给每个词打标签(Binary mask)- 用0和1标记每个词是否相关,1表示相关要保留,0表示无关可以删掉
这样训练出来的模型,既能判断文档相关性,又能精准地做句子剪枝:推理时,Provence会给每个词打分,然后按句子聚合:如果一个句子里标记为1(相关)的词比标记为0(无关)的词多,就保留这个句子,否则就删掉。通过调整阈值,就能控制剪枝的激进程度。
最重要的是,Provence复用了重排序的能力,所以在RAG流程中几乎是零成本加入的。
04
定量评估实验
前面我们介绍了Provence的设计原理和技术特点,那么它在实际应用中的表现如何?与其他模型相比有何优劣?为了回答这些问题,我们设计了一套完整的定量评估实验,对比其他模型在真实场景下的剪枝质量。
实验有两个核心目标:
-
定量评估ContextPruning的效果:通过标准指标(Precision、Recall、F1)量化模型的剪枝质量
-
测试域外泛化能力(Out-of-Domain):评估模型在与训练数据分布不同的场景下的鲁棒性
为此,我们选择了三个代表性的模型进行对比:
- Provence (
naver/provence-reranker-debertav3-v1) - XProvence (
naver/XProvence) - OpenSearch Semantic Highlight (
opensearch-project/opensearch-semantic-highlighter-v1),同样基于BERT架构训练的剪枝模型
05
实验设计
数据集选择:我们选择WikiText-2作为测试集。这是一个基于维基百科文章的数据集,文章结构多样,答案往往分散在多个句子中,语义关联也比较复杂。
更重要的是,它与模型通常的训练数据存在较大的分布差异,同时又很接近日常业务场景——这正是我们想要的out-of-domain测试环境。
问题生成与标注:为了确保out-of-domain的效果,我们使用GPT-4o-mini从WikiText-2原始语料中自动生成问答对。每个样本包含三个部分:
- 问题(Query):从文档内容生成的自然语言问题
- 文档(Context):完整的原始文档
- 答案标注(Ground Truth):标注出哪些句子包含答案(应保留),哪些句子不相关(应剪枝)
这种构造方式天然形成了一个Context Pruning任务:模型需要根据问题,从完整文档中识别出真正相关的句子。答案句子作为"正样本"(应保留),其他句子作为"负样本"(应剪枝),这样我们就可以通过Precision、Recall、F1等指标量化评估模型的剪枝准确性。
更重要的是,这样生成的问题不会出现在任何模型的训练数据中,能够真实反映模型的泛化能力。我们一共生成了300个样本,涵盖简单事实类、多跳推理类、复杂分析类等不同类型的问题,尽可能贴近实际应用场景。
实验流程:

参数优化:使用Grid Search对每个模型进行超参数优化。测试不同的超参数组合,最终选择F1最优的配置。
06
实验结果

从实验结果来看,三个模型的表现存在明显差异。
Provence表现最好,F1达到66.76%。Precision(69.53%)和Recall(64.19%)相对平衡,显示出良好的域外泛化能力。最优参数为threshold=0.6,alpha=0.051,说明模型输出的分数分布较为合理,阈值设置也相对直观。
XProvence的F1为58.97%,略微有些高召回(75.52%)、低精确度(48.37%)的特征。这种"宁可错选不可漏选"的策略在某些场景下具有优势,比如医疗、法律等对信息完整性要求高的领域。但同时也会引入更多的误判,降低精确度。好在XProvence支持多语言,它可以弥补Provence在除了英文以外场景的不足。
OpenSearch的F1为46.37%(Precision 62.35%,Recall 36.98%),在三个模型中相对较弱,显著低于Provence和XProvence,说明在out-of-domain场景下,模型输出的分数校准和泛化能力还有提升空间。
07
ContextPruning与Semantic Highlight
顺带提一下,Context Pruning与一个新兴的搜索系统功能——Semantic Highlight(语义高亮),他们在技术本质上是同一件事。
可能说到Highlight,大家可能更熟悉Elasticsearch里的传统Highlight功能——它基于关键词匹配,用<em>标签高亮查询词出现的位置。但这种方式很机械,只能匹配字面相同的词。
而Semantic Highlight则完全不同,它基于语义理解,通过深度学习模型判断文本片段与查询的语义相关性,即使没有相同关键词也能准确识别相关内容。
仔细想想,Context Pruning与Semantic Highlight的本质都是:
基于query和context的语义匹配,找出最相关的部分,排除掉不相关的部分。

因此,它们本质上是同一个技术在不同场景下的应用。
这意味着同一个模型可以服务多个场景,提高了技术的可复用性。
而伴随着Semantic Highlight逐渐成为一个新兴的功能需求,Milvus团队正在规划内置Semantic Highlight功能。
目前当Milvus提供向量检索时,用户反馈检索返回大量chunk后,难以快速识别哪些句子真正有用。而借助提供基于模型的Semantic Highlight功能,能够与向量检索pipeline无缝融合。
这样Milvus将演进为集成检索、重排序、上下文剪枝的智能检索归因平台,覆盖RAG优化、搜索高亮、文档摘要等多个场景。
如何高效转型Al大模型领域?
作为一名在一线互联网行业奋斗多年的老兵,我深知持续学习和进步的重要性,尤其是在复杂且深入的Al大模型开发领域。为什么精准学习如此关键?
- 系统的技术路线图:帮助你从入门到精通,明确所需掌握的知识点。
- 高效有序的学习路径:避免无效学习,节省时间,提升效率。
- 完整的知识体系:建立系统的知识框架,为职业发展打下坚实基础。
AI大模型从业者的核心竞争力
- 持续学习能力:Al技术日新月异,保持学习是关键。
- 跨领域思维:Al大模型需要结合业务场景,具备跨领域思考能力的从业者更受欢迎。
- 解决问题的能力:AI大模型的应用需要解决实际问题,你的编程经验将大放异彩。
以前总有人问我说:老师能不能帮我预测预测将来的风口在哪里?
现在没什么可说了,一定是Al;我们国家已经提出来:算力即国力!
未来已来,大模型在未来必然走向人类的生活中,无论你是前端,后端还是数据分析,都可以在这个领域上来,我还是那句话,在大语言AI模型时代,只要你有想法,你就有结果!只要你愿意去学习,你就能卷动的过别人!
现在,你需要的只是一份清晰的转型计划和一群志同道合的伙伴。作为一名热心肠的互联网老兵,我决定把宝贵的AI知识分享给大家。 至于能学习到多少就看你的学习毅力和能力了 。

第一阶段(10天):初阶应用
该阶段让大家对大模型 AI有一个最前沿的认识,对大模型 AI 的理解超过 95% 的人,可以在相关讨论时发表高级、不跟风、又接地气的见解,别人只会和 AI 聊天,而你能调教 AI,并能用代码将大模型和业务衔接。
- 大模型 AI 能干什么?
- 大模型是怎样获得「智能」的?
- 用好 AI 的核心心法
- 大模型应用业务架构
- 大模型应用技术架构
- 代码示例:向 GPT-3.5 灌入新知识
- 提示工程的意义和核心思想
- Prompt 典型构成
- 指令调优方法论
- 思维链和思维树
- Prompt 攻击和防范
- …
第二阶段(30天):高阶应用
该阶段我们正式进入大模型 AI 进阶实战学习,学会构造私有知识库,扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架,抓住最新的技术进展,适合 Python 和 JavaScript 程序员。
- 为什么要做 RAG
- 搭建一个简单的 ChatPDF
- 检索的基础概念
- 什么是向量表示(Embeddings)
- 向量数据库与向量检索
- 基于向量检索的 RAG
- 搭建 RAG 系统的扩展知识
- 混合检索与 RAG-Fusion 简介
- 向量模型本地部署
- …
第三阶段(30天):模型训练
恭喜你,如果学到这里,你基本可以找到一份大模型 AI相关的工作,自己也能训练 GPT 了!通过微调,训练自己的垂直大模型,能独立训练开源多模态大模型,掌握更多技术方案。
到此为止,大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗?
- 为什么要做 RAG
- 什么是模型
- 什么是模型训练
- 求解器 & 损失函数简介
- 小实验2:手写一个简单的神经网络并训练它
- 什么是训练/预训练/微调/轻量化微调
- Transformer结构简介
- 轻量化微调
- 实验数据集的构建
- …
第四阶段(20天):商业闭环
对全球大模型从性能、吞吐量、成本等方面有一定的认知,可以在云端和本地等多种环境下部署大模型,找到适合自己的项目/创业方向,做一名被 AI 武装的产品经理。
- 硬件选型
- 带你了解全球大模型
- 使用国产大模型服务
- 搭建 OpenAI 代理
- 热身:基于阿里云 PAI 部署 Stable Diffusion
- 在本地计算机运行大模型
- 大模型的私有化部署
- 基于 vLLM 部署大模型
- 案例:如何优雅地在阿里云私有部署开源大模型
- 部署一套开源 LLM 项目
- 内容安全
- 互联网信息服务算法备案
- …
学习是一个过程,只要学习就会有挑战。天道酬勤,你越努力,就会成为越优秀的自己。
如果你能在15天内完成所有的任务,那你堪称天才。然而,如果你能完成 60-70% 的内容,你就已经开始具备成为一名大模型 AI 的正确特征了。
这份完整版的大模型 AI 学习资料已经上传优快云,朋友们如果需要可以微信扫描下方优快云官方认证二维码免费领取【保证100%免费】

11万+

被折叠的 条评论
为什么被折叠?



