1. 项目概述当RAG遭遇“信息过载”在构建基于检索增强生成RAG的应用时我们常常陷入一个两难境地为了让大语言模型LLM获得足够的信息来生成准确答案我们倾向于向它“投喂”尽可能多的相关文档片段chunks。然而这就像让一个学生在开卷考试时面前堆满了上百页的参考资料——他确实能找到答案但需要花费大量时间在无关信息中翻找甚至可能被冗余或矛盾的信息干扰最终答非所问或效率低下。这就是“上下文过长”的典型问题。LLM的上下文窗口Context Window虽然越来越大但并非无限。更重要的是即使窗口足够大过多的无关或低质量信息会严重稀释核心证据的权重导致模型注意力分散生成质量下降同时还会显著增加API调用成本按Token计费和响应延迟。我最近在一个企业知识库问答项目中就深刻体会到了这一点当检索返回8个相关chunk总计约6000个Token塞进提示词时回答的准确率反而比只使用前3个最相关chunk时低了约15%。因此“上下文剪枝”应运而生。它不是一个独立的模块而是RAG流程中位于“检索”与“生成”之间的一个关键优化层。其核心目标非常明确在尽可能不损失关键信息的前提下对检索到的候选文档集合进行压缩、筛选和重排剔除冗余、无关或低价值的内容只将最精炼、最相关的上下文传递给LLM。我通过引入一套组合策略成功将平均传入上下文的Token数量减少了68%而回答的准确率通过人工评估提升了22%。这不仅仅是节省成本更是对回答质量的一次显著提纯。2. 核心思路从“全盘接收”到“智能筛选”传统的RAG流程可以简化为用户提问 - 检索相关文档块 - 将所有检索结果拼接成上下文 - 连同问题一起交给LLM生成答案。这里的瓶颈在于第二步到第三步的简单粗暴的拼接。上下文剪枝的思路是将这个“黑盒”打开加入一个智能处理阶段。其核心思想是对检索结果进行“再评估”和“再加工”而不仅仅是按相似度分数简单排序后切片。这背后有几个关键认知转变相似度 ≠ 必要性向量检索返回的高分chunk可能与问题在语义上高度相关但可能只包含了问题背景信息或者重复表达了同一个事实。它们对生成最终答案并非都是必要的。信息存在冗余不同的chunk可能描述的是同一件事尤其是在拆分文档时相邻的chunk之间。同时传递它们是一种浪费。LLM的注意力是有限的即使上下文窗口很长模型对输入的所有部分也并非同等关注。位于中间位置、或被大量无关文本包围的关键信息其影响力会被削弱。基于此我的剪枝策略围绕三个核心原则展开去重Deduplication合并语义重复的内容避免信息冗余。重排Re-ranking使用比检索阶段更精细的模型根据与问题的真实相关性对chunk进行重新排序确保最重要的信息靠前。筛选Filtering设定阈值果断剔除相关性低于一定标准的chunk无论其检索分数如何。实现68%的剪枝率不是靠某一种“银弹”技术而是通过一个多阶段的、可配置的管道Pipeline来实现的。下面我将拆解这个管道中的每一个环节。2.1 阶段一检索结果预处理与粗筛在进入复杂的剪枝算法之前一些基础的预处理就能带来立竿见影的效果。首先设定一个合理的初始检索数量k值。很多开发者会设置一个很大的k比如20或30想着“宁可多不可少”。但这会给后续剪枝带来巨大压力。我的经验是对于多数问答场景初始检索k10到k15已经足够。你可以根据你的文档库平均chunk大小和问题复杂度进行调整。一个实用的方法是在测试集上观察当k超过多少后答案质量不再显著提升甚至下降那个拐点就是你的k值上限。其次进行基于嵌入Embedding的初步去重。即使使用不同的文本切片方法检索到的chunk之间仍可能有很高的语义重叠。一个简单有效的方法是计算chunk两两之间的余弦相似度。如果两个chunk的相似度超过一个阈值例如0.9则可以认为它们高度重复。此时你可以选择只保留其中检索分数更高的那个。# 伪代码示例基于嵌入的简单去重 def deduplicate_chunks(retrieved_chunks, similarity_threshold0.9): unique_chunks [] for i, chunk_i in enumerate(retrieved_chunks): is_duplicate False for unique_chunk in unique_chunks: # 计算chunk_i的嵌入向量与unique_chunk的嵌入向量的余弦相似度 sim cosine_similarity(embed(chunk_i.text), embed(unique_chunk.text)) if sim similarity_threshold: is_duplicate True # 如果重复保留分数更高的假设chunk对象有score属性 if chunk_i.score unique_chunk.score: unique_chunks.remove(unique_chunk) unique_chunks.append(chunk_i) break if not is_duplicate: unique_chunks.append(chunk_i) return unique_chunks注意这里的嵌入模型最好与检索时使用的模型一致以保证一致性。这个操作计算量较大O(n²)对于k值较小的情况可以接受如果k很大可以考虑更高效的算法或放在后续阶段处理。2.2 阶段二基于交叉编码器的重排这是提升剪枝质量最关键的一步。向量检索如使用BM25或稠密向量使用的是“双编码器”架构即问题和文档分别被编码为向量然后计算相似度。这种方式速度快适合海量检索但精度有上限。交叉编码器Cross-Encoder则不同。它将问题和文档文本同时输入到一个模型中进行深度的注意力交互直接输出一个相关度分数。这种方式精度远高于双编码器但因为需要两两组合计算速度慢只适合对少量候选进行重排。实操要点模型选择可以选择专门用于文本匹配的预训练模型如BAAI/bge-reranker-large、cross-encoder/ms-marco-MiniLM-L-6-v2等。中文场景下BAAI/bge-reranker系列表现非常出色。操作位置在完成初步检索和粗筛后将问题与剩下的每个chunk例如8-12个组成“(问题, chunk)”对送入交叉编码器打分。结果应用根据新的重排分数对chunk进行降序排列。这个顺序更能反映chunk对于回答当前问题的真实价值。from transformers import AutoModelForSequenceClassification, AutoTokenizer import torch class CrossEncoderReranker: def __init__(self, model_nameBAAI/bge-reranker-large): self.tokenizer AutoTokenizer.from_pretrained(model_name) self.model AutoModelForSequenceClassification.from_pretrained(model_name) self.model.eval() def rerank(self, query, chunks): scores [] with torch.no_grad(): for chunk in chunks: # 将问题和文档拼接输入 inputs self.tokenizer(query, chunk, paddingTrue, truncationTrue, return_tensorspt, max_length512) outputs self.model(**inputs) # 通常输出logits取最后一个维度如sigmoid后的分数或softmax后的相关类分数 score torch.sigmoid(outputs.logits).item() # 根据模型实际输出调整 scores.append(score) # 将分数与chunk关联并排序 ranked_chunks sorted(zip(chunks, scores), keylambda x: x[1], reverseTrue) return [chunk for chunk, _ in ranked_chunks], scores心得重排模型是计算密集型操作是延迟的主要来源。在实际部署中可以考虑将其异步化或者使用更轻量级的模型。我的经验是即使只对Top 10的chunk进行重排其对最终答案质量的提升也远大于将检索数量k从10增加到20。2.3 阶段三动态压缩与选择性摘要经过重排我们得到了一个按相关性排序的列表。接下来我们需要决定“剪”多少以及怎么“剪”。1. 动态阈值筛选不要使用固定的chunk数量如只取前3个。因为问题的复杂度不同有时需要1个chunk就能回答有时可能需要5个。我们可以基于重排分数设定一个动态阈值。绝对值阈值只保留分数高于某个固定值如0.7的chunk。这需要你对模型分数分布有了解。相对值阈值例如只保留分数不低于最高分60%的chunk。或者使用“分数断层”识别将分数从高到低排序找到分数下降最剧烈的那个点肘部法则只保留该点之前的chunk。2. 基于LLM的压缩与摘要对于保留下来的chunk如果其本身文本较长还可以进行一步压缩。这里可以巧妙地使用LLM自身的能力。指令压缩给LLM一个指令让它从给定的chunk中提取出与特定问题直接相关的信息忽略其他无关内容。提示词示例“请从以下文本中提取所有能用于回答问题‘[用户问题]’的信息。只输出提取出的关键事实和陈述不要添加任何解释。”摘要压缩如果chunk包含多个要点可以要求LLM对其进行极简摘要。提示词示例“请用一句话总结以下文本的核心内容专注于与‘[关键词]’相关的部分。”重要提醒这一步本身也需要调用LLM会增加成本和延迟。因此它通常只应用于那些通过了重排筛选、但文本长度依然很长的关键chunk而不是对所有chunk使用。这是一个权衡用一次小的LLM调用可能将一个500 Token的chunk压缩成100 Token从而为更重要的上下文腾出空间。2.4 阶段四上下文组织与提示词工程剪枝后的chunk如何组织成最终的上下文也影响着LLM的利用效率。顺序很重要将重排后分数最高的chunk放在最靠近用户问题或系统指令的位置。LLM尤其是某些模型对输入开头和结尾的信息更为敏感。添加清晰的分隔符与元数据在每个chunk前后使用如---文档块 [序号]---这样的标记。在chunk开头可以简要注明其来源如文件名、章节和相关性分数可选。这相当于给LLM提供了阅读指引。在系统指令中明确说明在系统提示System Prompt中告诉模型“你将收到多个与问题相关的文档片段。这些片段已按相关性排序最相关的在最前面。请基于这些片段提供答案如果信息不足请明确说明。” 这能引导模型更好地利用你精心准备的上下文。3. 实战架构与代码示例让我们将这些环节组合成一个完整的、可复用的剪枝管道。我将使用Python和一些常见库来演示。假设我们已有一个检索器retriever能返回包含text和metadata含score的文档列表。# 所需库sentence-transformers, transformers, torch import numpy as np from sentence_transformers import CrossEncoder from typing import List, Dict, Any class ContextPruner: def __init__(self, cross_encoder_modelBAAI/bge-reranker-large): self.reranker CrossEncoder(cross_encoder_model) self.similarity_threshold 0.88 # 去重阈值 self.relevance_threshold 0.6 # 相关性绝对阈值需根据模型校准 def prune(self, query: str, retrieved_chunks: List[Dict], max_context_tokens: int 3000) - str: 核心剪枝流程 :param query: 用户问题 :param retrieved_chunks: 检索返回的列表每个元素包含‘text‘, ‘score‘等 :param max_context_tokens: 最终上下文的最大Token数限制 :return: 拼接好的精炼上下文字符串 # 步骤1: 初步去重 chunks self._deduplicate_by_embedding(retrieved_chunks) print(f去重后剩余 {len(chunks)} 个片段) # 步骤2: 交叉编码器重排 chunk_texts [c[text] for c in chunks] # 交叉编码器需要(查询, 文档)对列表 pairs [[query, text] for text in chunk_texts] rerank_scores self.reranker.predict(pairs) # 将新分数与chunk关联 for chunk, score in zip(chunks, rerank_scores): chunk[rerank_score] float(score) # 按重排分数降序排序 chunks.sort(keylambda x: x[rerank_score], reverseTrue) print(f重排后Top3分数: {[c[rerank_score] for c in chunks[:3]]}) # 步骤3: 动态阈值筛选 filtered_chunks self._filter_by_threshold(chunks) print(f阈值筛选后剩余 {len(filtered_chunks)} 个片段) # 步骤4: 组织最终上下文考虑Token限制 final_context self._compose_context(query, filtered_chunks, max_context_tokens) return final_context def _deduplicate_by_embedding(self, chunks: List[Dict]) - List[Dict]: 基于嵌入向量的简单去重 # 这里简化处理假设我们有一个嵌入函数实际中可能需要缓存嵌入向量 # 更实用的方法如果使用相同模型检索可以直接用检索时的向量计算相似度 unique_chunks [] for new_chunk in chunks: duplicate False for unique in unique_chunks: # 此处应计算嵌入向量相似度为简化用文本长度模拟逻辑 # 真实场景替换为 embedding_similarity(new_chunk, unique) threshold sim self._approx_similarity(new_chunk[text], unique[text]) if sim self.similarity_threshold: duplicate True # 保留分数更高的 if new_chunk.get(score, 0) unique.get(score, 0): unique_chunks.remove(unique) unique_chunks.append(new_chunk) break if not duplicate: unique_chunks.append(new_chunk) return unique_chunks def _approx_similarity(self, text1: str, text2: str) - float: 简化的相似度计算仅用于示例。实际应使用嵌入模型。 # 这是一个占位函数。真实实现应调用sentence-transformers等库。 words1 set(text1.lower().split()[:20]) # 取前20词粗略比较 words2 set(text2.lower().split()[:20]) if not words1 or not words2: return 0.0 return len(words1 words2) / len(words1 | words2) def _filter_by_threshold(self, chunks: List[Dict]) - List[Dict]: 基于重排分数进行筛选 if not chunks: return [] # 方法1绝对阈值 # return [c for c in chunks if c[rerank_score] self.relevance_threshold] # 方法2相对阈值保留不低于最高分60%的 max_score chunks[0][rerank_score] threshold max_score * 0.6 return [c for c in chunks if c[rerank_score] threshold] def _compose_context(self, query: str, chunks: List[Dict], max_tokens: int) - str: 组织最终上下文并确保不超过Token限制 context_parts [] current_token_count 0 # 简单的Token估算函数实际应用应使用tiktoken或transformers的tokenizer def estimate_tokens(text): return len(text) // 4 for i, chunk in enumerate(chunks): chunk_text chunk[text] chunk_token_est estimate_tokens(chunk_text) # 检查加入后是否超限 if current_token_count chunk_token_est max_tokens: # 如果这是第一个chunk就超了可能需要压缩或报错 if i 0: print(f警告第一个片段就超出Token限制将进行截断) # 简单截断实际中应使用更智能的压缩 allowed_tokens max_tokens # 粗略按字符截断 allowed_chars allowed_tokens * 4 chunk_text chunk_text[:allowed_chars] ...[截断] else: print(f达到Token限制{max_tokens}已包含 {i} 个片段) break # 格式化片段添加序号和分数可选 formatted_chunk f[片段 {i1}, 相关性分数: {chunk[rerank_score]:.3f}]\n{chunk_text}\n---\n context_parts.append(formatted_chunk) current_token_count chunk_token_est final_context \n.join(context_parts) print(f最终上下文约 {current_token_count} Tokens由 {len(context_parts)} 个片段组成) return final_context # 使用示例 if __name__ __main__: pruner ContextPruner() # 模拟检索结果 mock_chunks [ {text: 大型语言模型LLM如GPT-4在自然语言处理任务中表现出色。, score: 0.95}, {text: 检索增强生成RAG通过结合检索和生成来解决LLM的知识截止问题。, score: 0.87}, {text: GPT-4是OpenAI开发的一个大型多模态模型。, score: 0.92}, # 与第一个可能重复 {text: 上下文剪枝可以有效减少RAG中传入模型的Token数量。, score: 0.78}, {text: 向量数据库如Milvus常用于高效存储和检索嵌入向量。, score: 0.65}, ] user_query 什么是RAG它如何帮助LLM refined_context pruner.prune(user_query, mock_chunks, max_context_tokens1000) print(\n 精炼后的上下文 \n) print(refined_context)这个ContextPruner类提供了一个基础框架。在实际项目中你需要替换_approx_similarity为真实的嵌入相似度计算。根据你选择的交叉编码器模型调整reranker.predict的输出处理有些模型输出的是softmax后的分数对。集成一个准确的Token计数器如tiktoken用于OpenAI模型。根据你的性能要求可能需要对去重算法进行优化如使用局部敏感哈希LSH。4. 效果评估与调优心得引入剪枝管道后如何评估其效果不能只看剪枝比例必须综合评估。评估指标上下文压缩率(1 - 剪枝后Token数 / 剪枝前Token数) * 100%。这是我提到的68%的由来。答案质量这是核心。可以通过人工评估准确性、相关性、完整性或使用LLM作为裁判如GPT-4进行偏好评分来对比剪枝前后答案的质量。检索精度Precisionk剪枝可以看作是在检索返回的Top k个结果中选取更小的、更精确的子集。可以计算最终送入上下文的chunk中真正相关的比例。成本与延迟记录剪枝前后单次查询的API Token消耗和总体响应时间包括剪枝本身的计算时间。调优心得与避坑指南阈值不是魔法数字相似度去重阈值如0.88和相关性阈值如0.6需要在你自己的数据集上进行校准。建议的做法是抽取一批样本问题人工标注chunk之间的重复关系以及每个chunk对回答问题的重要性如“关键”、“相关但冗余”、“无关”。然后根据标注结果调整阈值观察查全率和查准率的平衡。重排模型并非越大越好更大的重排模型通常精度更高但延迟也呈指数增长。对于延迟敏感的应用如在线对话BAAI/bge-reranker-base或cross-encoder/ms-marco-MiniLM-L-6-v2这类轻量模型往往是更优选择在精度和速度间取得良好平衡。警惕“过度剪枝”过于激进的剪枝策略可能会把一些看似冗余、实则包含关键细微差别的信息过滤掉。例如一个描述“操作步骤A”另一个描述“操作步骤A的常见错误”后者对于生成安全的答案至关重要。解决方法是在去重时不要只依赖语义相似度也可以结合元数据如是否来自“警告”章节或使用更复杂的、能识别“补充”而非“重复”关系的模型。缓存是性能之友交叉编码器重排是计算瓶颈。对于常见或高频问题可以缓存“问题-重排后chunk列表”的结果在一定时间内如TTL1小时直接使用能极大降低平均延迟。剪枝应与分块策略协同设计如果你的文档分块Chunking策略本身就很糟糕例如把完整的表格或代码块从中间切断那么再好的剪枝也无力回天。理想的分块应保证语义完整性。剪枝是后续的优化不能弥补分层的缺陷。5. 高级策略与未来展望在基础管道之上还有一些更高级的策略可以进一步优化剪枝效果1. 查询扩展Query Expansion后再剪枝有时用户问题很短或表述模糊导致检索不准。可以先使用LLM对原问题进行扩展或改写生成2-3个相关问题然后分别检索最后合并去重、重排。这样能召回更全面的相关文档为后续剪枝提供更好的“原料”。2. 基于LLM的智能摘要与融合与其简单拼接筛选后的chunk不如让一个轻量级LLM如小型微调模型先阅读这些chunk生成一个针对当前问题的、连贯的、无冗余的背景摘要。然后将这个摘要而非原始chunk作为上下文传递给主LLM。这实现了信息的深度融合但引入了额外的复杂性和延迟。3. 细粒度句子/实体级剪枝我们一直在chunk级别操作。但一个chunk内可能只有一两句话是真正相关的。可以先将chunk拆分成句子在句子级别进行相关性重排和筛选然后再将选中的句子组合。这能实现更极致的压缩但对处理流程的复杂度要求更高。4. 个性化剪枝策略根据问题类型动态调整剪枝策略。例如对于事实性问答采用严格的重排和筛选对于创意写作或头脑风暴则可以放宽去重阈值保留更多样化的信息。未来上下文剪枝将不再是RAG中一个可选的优化步骤而是构建高效、高质、低成本RAG系统的标准配置。随着LLM上下文窗口的继续扩大如何高效、精准地利用这个窗口而不是被其“淹没”会变得越来越重要。剪枝技术的核心思想——在信息过载的时代做信息的减法为价值做乘法——将会在更多AI应用场景中体现其价值。在我自己的项目中实施这套剪枝方案后最直接的感受是“清爽”了。LLM给出的答案更聚焦、引用更准确幻觉现象也减少了。更重要的是月度API成本下降了约40%。这不仅仅是技术的胜利更是工程思维对资源效率的极致追求。如果你也在为RAG的上下文膨胀而烦恼不妨从设置一个简单的重排器开始迈出智能剪枝的第一步。