如果你在一个知识库问答系统上跑过几轮真实对话，大概会懂那种憋屈感：用户问了一个看似简单的问题，你的程序却把过去几轮里塞进来的旧文档、无关日志、重复列表一股脑全带上了。结果Prompt越长，模型回答越慢，Token账单越滚越大，有时候上下文窗口眼看就要顶到上限，模型反而开始把早先的垃圾信息当成依据，答得牛头不对马嘴。
Context Pruning 的思路，简单说就是把给模型看的上下文里那些不相关的“废话”挑出来扔到一边，只保留和当前问题强相关的片段，把每一分Token都花在刀刃上。它不是简单粗暴地“砍到最短”，而是用一个自动化的方式判断“哪段话和当前话题真正有关系”。今天我完整拆一下这个做法：为什么朴素截断不靠谱、用语义相似度筛信息的设计思路、具体怎么落地，以及我踩过的那些坑。
1. 为什么需要 Context Pruning：Token账本与无效占位问题
1.1 长上下文不是免费的，读一遍就要付一遍钱
很多人一开始觉得，上下文窗口那么大了，多塞点内容无所谓。模型API按Token计费，多出的每1000字，都是真金白银。更麻烦的是，成本还不是线性增长这么简单——同样一段内容，你把它放进上下文里，模型生成第一个字时就要把整段内容“读”一遍，回应过程中每个新Token都会再次扫描整段上下文。
我算过一笔账。假设你的历史对话加上检索出来的文档一共5000个Token，单轮回复输出800Token。按某些通用大模型接口的定价粗算，一次请求成本大概是输入加输出的组合价。一次两次确实不多，但如果是每天几百上千次调用的线上问答服务，这个数字会非常可观。如果能把输入从5000Token压到1500Token，成本直接砍掉七成，响应速度也会明显变快，因为排队和计算量一起降下来了。
而且你还要考虑上下文窗口本身的物理限制。哪怕窗口是128K，长期跑多轮对话、多轮检索之后，旧内容总会一点点把空间填满。不做裁剪，总有一天会撞上“上下文超限”。我以前总觉得“窗口够大就能硬撑”，直到某个真实项目里连续对话十几轮后，程序突然报错说输入过长，才意识到上下文空间迟早是要精打细算的。
1.2 真正的“废话”不是字数多，而是语义上和当前问题不相关
这里就得掰扯一下“废话”到底是什么。博客写手可能会觉得重复形容词是废话，但在上下文管理里，真正的负担是“当下用不到的内容”——它们可能本身是完整、合理的文本，只是和用户现在这个问题毫无关系。
举一个很典型的例子：用户一开始在问“A项目的API认证方式”，后来话题转到“B项目的数据导入脚本”。如果你把当初检索出来的A项目接口文档、鉴权代码样例、配置说明统统保留到第二轮，那模型面对的上下文里就混进了大量和“B项目数据导入”无关的内容。这些片段哪怕写得再好、再规范，对当前答案都没有帮助。
更麻烦的是无用信息会干扰模型注意力。语言模型处理超长上下文时，并不会像人一样自动忽略“背景噪声”，它会一视同仁地把所有内容都纳入注意力计算。一堆语义上与本轮无关的片段混在里面，模型很容易被带偏，可能从老文档里“捡”一个根本不适用的方案出来。这种隐性质量损耗，比Token费用本身更值得警惕。
1.3 朴素方案：为什么固定截断和按长度排序都不行
最简单的办法大家都知道：按token数从后往前截，超过上限就把旧的丢掉。这个方案实现起来五分钟就够，但问题非常致命——对话刚开头那几句“初始设定”或“用户核心目标”往往会在第一轮被挤掉，而它们在后面恰恰是理解上下文的关键。
另一个常见思路是“按长度排序，保留最长的片段”。你能看出这逻辑哪里不对：长度和重要性没有必然联系。有时候决定答案好坏的恰恰是一行很短的约束条件，而不是一大段冗长的背景介绍。按长度排序可能把真正有用的短句丢掉，留下一堆毫无营养的长篇模板。
这两种方案的共同问题，是它们都只看了“形式”，没看“内容”。它们不知道一段文本和当前问题到底有多少关联，只会机械地做取舍。Context Pruning 要做的是语义层面的判断——让程序理解“当前问题是什么”，然后拿这个“问题语义”和历史片段逐一比对，把相似度高的留下，相似度低的全扔掉。这也是我为什么认为语义相似度是这个场景下最可靠的技术手段。
2. 语义相似度方案的核心：向量化与匹配策略
2.1 把文本变成“坐标”，相关性就变成了距离远近
语义相似度的方法论基础是文本向量化。嵌入接口会把你输入的句子、段落转换成一串浮点数，比如一个256维或768维的向量，这些数字组合在一起，可以看作文本在高维空间里的“坐标”。在这个空间里，语义相近的文本会靠得很近，语义不相关的文本会离得很远——这是通过大规模语料训练出来的分布规律。
拿生活场景打比方。你把所有文件都摆在一个巨大的仓库里，每个文件都有自己专属的坐标点。“认证方式”相关的文件都在仓库右侧，“数据导入脚本”相关文件都在仓库左侧。现在用户问了一个关于数据导入的问题，你要做的事就是走进仓库，找到问题所在的坐标位置，然后只把周围最近的那些文件拿出去，仓库那头的文件看都不用看。
实际计算距离时，最常用的是余弦相似度，公式是计算两个向量夹角的余弦值，结果落在-1到1之间。夹角小、方向基本一致，说明两个文本语义接近；夹角接近90度，数值接近0，说明基本无关；负值说明方向相反，但文本场景里很少刻意看负数，一般只关注正向接近程度。代码实现层面，通过类似similarity = dot(a, b) / (norm(a) * norm(b))的方式就能得到，很多向量计算库内部都直接封装好了。
2.2 向量化粒度选择：句子级、段落级还是块级？
做语义比较之前，得先决定把文本切成多大的单元。这个粒度会直接影响Pruning的精度和召回率。
段落级向量适合那些有天然段落边界的内容，比如网页、Markdown文档的每个小节。它计算量小、速度快，但段落里如果混了两三个不同的主题，向量会被平均掉，导致一个问题：整个段落的向量可能既不像这个话题，也不像那个话题。
句子级向量粒度最细，能准确判断“当前问题是否和这一句话相关”。但它的缺陷在于会带来海量的小向量，匹配时开销较大，而且最终返回给模型的上下文会被切成很碎的片段，缺少背景信息。一句孤零零的“接口返回401”如果没有上下文，模型根本看不懂是哪个接口。
在真实项目中，我一般默认用“块级”方案：按固定字符数量把长文本切成若干个有重叠的chunk，每个chunk大概300到500字。这样既有足够语义密度，也不至于颗粒太粗。分块时我会让相邻块有50到100个字符的重叠，确保关键词恰好被切在边界时不会丢失。下表是我对这几种粒度的实际感受对比：
| 粒度 | 匹配精度 | 上下文完整性 | 计算开销 | 适用场景 |
|---|---|---|---|---|
| 句子级 | 高 | 差 | 中 | 短对话历史、问答列表 |
| 段落级 | 中 | 好 | 低 | 结构清晰的网页、章节文本 |
| 块级（300-500字） | 中高 | 较好 | 中 | 绝大多数长文本场景 |
2.3 相似度阈值怎么定：紧一点还是松一点？
有了向量和距离度量之后，核心问题就变成了“相似度多少才算相关”。这里通常有两条路：定阈值，或者取TopK。
定阈值的逻辑是：计算历史和当前问题的余弦相似度，如果分数高于某个值就保留，低于就丢弃。我把阈值调过几个不同档位。阈值定得高，召回的内容少，上下文精简，但容易误杀关键信息；阈值定得低，上下文保留得丰富，但“废话”也跟着混进来。
根据我的经验，具体数值高度依赖嵌入接口训练的数据分布，没有“万能阈值”。但多数情况下，0.45到0.55之间是一个不错的起始区间。如果你用的是主流的通用嵌入模型，低于0.4的片段大部分确实关系不大，高于0.6的片段基本是强相关。所以我会先设0.5跑一轮，再人工抽查被裁剪和保留的内容，按项目实际情况微调。
TopK的优点是控制力更强——我明确知道自己想让模型看到几个片段，不会出现“阈值设松了结果塞满Token”的情况。缺点也很明显：如果当前问题确实只和一小段内容相关，TopK可能会把一些关联很弱的片段也硬塞进来凑数。我目前的做法是双保险：先按相似度阈值粗筛，再从保留结果里取TopK，既能控制token上限，又不会为了凑数强行加入不相关内容。
3. 完整实操：从分块、向量化到自动剔除的工作流
3.1 整体流程先看一遍：五步搞定一次Context Pruning
一次完整的Context Pruning流程，通常包含五个阶段：输入预处理、分块、向量化、相似度筛选、组装上下文。前面两步是基础装修，中间一步是核心判断，最后一步是把结果交付给模型。
输入预处理指的是把当前问题、历史对话、检索到的文档都统一成纯文本格式。历史对话既然要参与裁剪，就要保留每条消息的角色标签和发言者信息，方便裁剪后在最终上下文里维持对话连贯性。
分块就是把长文本切成可比较的小单元。这一步在离线阶段就可以完成，文本进入系统时切好，并把每个块连同对应的向量一起存入缓存。向量化阶段调用一次嵌入接口，把当前问题的文本和每个历史块都转换成向量。
相似度筛选阶段是主角，遍历所有块向量，与当前问题的向量算一遍余弦相似度，把得分低于预设阈值的块从上下文候选中剔除。组装上下文阶段，则把保留下的块按原始顺序重新拼接，附加在System Prompt和当前问题之前，交给语言模型生成答案。
3.2 核心代码实现：一套可以直接跑的参考逻辑
我直接给一套简化但可运行的Python参考实现。
首先是分块逻辑。这一段我没有用某个特定三方库，而是用最普通的字符切分，配合重叠窗口，保证切出的每个块大概300到500字：
def chunk_text(text, chunk_size=450, overlap=80): if len(text) <= chunk_size: return [text] chunks = [] start = 0 while start < len(text): end = min(start + chunk_size, len(text)) chunks.append(text[start:end]) if end == len(text): break start += chunk_size - overlap return chunks下一步封装一个嵌入客户端。实际项目里不同服务商提供的调用方式不一样，所以我习惯自己做一层薄薄的包装，方便后续替换：
class EmbeddingClient: def embed(self, texts): # 这里用模拟数据代替真实的嵌入接口调用 # 真实场景下你会在这里请求远程嵌入服务 return [self._mock_embed(t) for t in texts] def _mock_embed(self, text): # 实际工程中不会这样写，这里为了保证例子直接可跑 return [float(ord(c)) for c in text[:64]]这里要说明一下，生产环境绝不能这么mock，我用它只是为了演示数据结构。真实落地时，把embed方法替换成对嵌入API的批量请求即可。重点在下面的 Pruner 逻辑，它把“和当前问题无关的块”丢出去：
import math def cosine_similarity(vec_a, vec_b): dot = sum(x * y for x, y in zip(vec_a, vec_b)) norm_a = math.sqrt(sum(x * x for x in vec_a)) norm_b = math.sqrt(sum(y * y for y in vec_b)) if norm_a == 0 or norm_b == 0: return 0.0 return dot / (norm_a * norm_b) def prune_context(history_chunks, query, embedder, threshold=0.5, top_k=20): query_vec = embedder.embed([query])[0] scored = [] for chunk in history_chunks: chunk_vec = embedder.embed([chunk["text"]])[0] score = cosine_similarity(query_vec, chunk_vec) scored.append({"text": chunk["text"], "score": score, "index": chunk["index"]}) filtered = [item for item in scored if item["score"] >= threshold] filtered.sort(key=lambda x: x["score"], reverse=True) selected = filtered[:top_k] selected.sort(key=lambda x: x["index"]) return selected这段代码的核心就是把“相似度计算”和“阈值/TopK筛选”拆成两个独立步骤，先筛再排。注意最后一步我专门按原始index重新排了一次序，这个细节很重要。模型读上下文时讲究顺序自然，如果把筛选出来的块按相似度从高到低拼接，文本会变成东一句西一句，阅读体验和事实逻辑都会被打乱。
3.3 组装语义精简后的上下文
筛选完成之后，下一步是把选中的块拼回对话里。我一般会按原始对话顺序排列，并保留发言者身份：
def assemble_prompt(system_prompt, history, current_query, pruned_chunks): lines = [system_prompt, ""] for cluster in pruned_chunks: if cluster["role"] == "user": lines.append(f"用户: {cluster['text']}") else: lines.append(f"助手: {cluster['text']}") lines.append(f"用户: {current_query}") return "\n".join(lines)这一步有一点要格外小心：不要只拼裁剪后的块，完全丢掉对话的结构。如果历史上下文里原本有“系统提醒”“工具返回结果”这类特殊片段，裁剪完仍然应该保留它们的角色标记，哪怕只是[系统]前缀。不然模型看到一堆张冠李戴的文本，推理能力会下降得很明显。
3.4 省量怎么算：一个具体case的实测数字
我在某项目X上做过一次真实记录。那个项目是一个针对内部文档的问答助手，用户会连续提问，程序每次会检索数据库里的相关文档，并保留历史对话。
之前不做任何Pruning时，一次典型请求的输入Token在9000到11000之间，其中历史对话占据约4000Token，新检索到的文档占3000Token，其他杂项占了剩下部分。启用基于语义相似度的Context Pruning后，我对检索文档做了一次裁剪，对历史对话做了一次裁剪。
阈值我设的0.5，TopK设20。最终效果很可观：输入Token从平均10000降到了3500左右。由于文档块中真正和当前问题相关的只有少数几块，裁剪掉了接近六成的文档内容；历史对话中旧的不相关讨论也基本被筛没了。与此同时，我人工检查了连续20轮问答，答案质量没有下降，其中还有几轮明显更聚焦了，因为模型不再被无关内容干扰。
那次体验之后，我对这套方案的信心基本建立起来了——指标不是单纯在省Token，而是同时改善了回答质量。你说巧不巧，去掉“废话”之后，模型反而更懂“人话”了。
3.5 工程落地时需要注意的性能细节
真正上线之前，有几个工程问题绕不开。
向量化本身是有成本的。如果每一轮对话都把历史所有块重新向量化一次，接口调用量和延迟都会飙升。合理的做法是离线预处理：文档入库时就完成分块和向量化，向量结果存在本地缓存，消息历史也只在新增消息时对新块做一次向量化。这样在线阶段需要调用嵌入接口的部分就只剩下“当前问题”一条文本。
另一个要点是缓存设计。我习惯用哈希索引做缓存，即“文本内容哈希 -> 向量”，程序在处理新增内容时先查缓存，命中就直接复用，不命中再调嵌入接口。文档更新后只重新向量化受影响的区块，不做全量重建。
如果你对响应速度要求很高，还能再进一步：把历史块向量直接存在内存里，用近似最近邻检索和索引结构做召回，把原本需要逐个遍历计算的全局相似度比较压缩到只和“最接近的几百个向量”比较。当然，一般中小型项目直接用列表遍历就够，不需要引入重量级索引组件。
4. 常见问题与排查技巧实录
4.1 误删了关键信息，答案质量反而下降
我第一次把Context Pruning放到线上时，很快遇到误删问题。用户连续问了多个相关问题，第一轮的内容和当前第三轮的问题在关键词上不完全重合，但实际上是解决第三轮问题必须的前提信息。相似度阈值设置得比较高，于是这些关键前提被当成“废话”剔除了。
排查定位的方法是记录每次被裁剪的块以及它们的相似度分数，抽查那些在0.45到0.55之间徘徊的边界样本。我最后没有简单把阈值调低，而是加了一个“前几轮全局摘要保底”的逻辑：不论相似度高低，每轮对话保留上一轮压缩出的摘要，以及包含用户初始指令的那一条。相当于是给系统加了一张安全网。
从此之后我再也没有完全信任过“阈值”，它只是第一道过滤器，规则层必须跟上。
4.2 相似度分数起伏不定，换一天结果就变
相似度分数不稳定的来源，往往是文本主题太窄，或者嵌入模型对某些特殊领域词汇的表达不够稳定。比如内部技术名词缩写，嵌入模型的训练数据里可能很少见，向量落在很偏的位置，导致相似度整体偏低。
这个问题有两类解法。一类是词汇扩展：在计算相似度之前，把当前问题和历史文本里的缩写词、别名统一展开成完整描述词，提升匹配机会。另一类是滚动调参：不是静态定一个阈值，而是维护一个由最近N次人工反馈组成的基准线。如果用户对答案点了“不喜欢”，就把当次裁剪掉但可能相关的块恢复并加入候选。
实际项目里我不建议做太复杂的在线学习，简单的人工反馈计数就够了。关键是保留一个可追溯的日志：每次调用存下裁剪比例、相似度分布、最终答案采纳情况。后续想优化阈值时，这些日志就是决策依据。
4.3 表格、代码和自然语言要分开处理
纯文本的语义相似度表现相对稳定，但表格和代码是两类特殊内容。表格被切成块后，表头和表体经常分离，一个块里只有表体没有表头，向量就抓不住“这一列是什么”的关键信息。代码块也一样：一长串函数体单独看可能像一堆关键词，但离不开函数签名上面的注释和上下文。
我的处理办法是启一个内容类型标记：分块时如果是表格或代码，就把它们和它们前面的标题或描述打包成一个不可分割的块，而不是按字符硬切。这样裁剪时要么整块保留，要么整块丢掉，杜绝“半个表格”被塞进上下文的情况。
4.4 模型上下文窗口很大，还有必要做裁剪吗
这个问题的答案，在我做了一些长上下文模型的对比测试后变得非常明确。即便窗口大到可以容纳全部历史，给模型看清一色“相关的压缩信息”而不是“全部信息”，输出质量和速度依然有差异。
原因在于注意力机制的超长距离弱点。窗口越大，模型越可能在大量无关内容中“迷失”，对早先关键细节的关注反而减少。也就是说，Token预算无限，也不意味着模型的表现无限接近满分。把上下文精简到只保留与当前问题相关的信息，本质上是帮模型集中注意力。
所以哪怕你有宽松的上下文窗口，我也建议将Pruning作为默认策略而不是兜底策略。纯粹的多塞内容不等于更聪明的答案，等于更贵的账单和更模糊的重点。
4.5 实操问题速查表
我把几个高频问题整理成了一份速查表，方便你在项目里快速定位：
| 症状 | 可能原因 | 排查手段 | 解决方向 |
|---|---|---|---|
| 答案明显缺少背景 | 关键前提被误删 | 查看被裁剪块的相似度分数 | 增加保底机制，保留初始指令和上一轮摘要 |
| Token依然居高不下 | 阈值过低或TopK过大 | 看裁剪占比统计 | 适当调高阈值，或收紧TopK |
| 裁剪后文本逻辑混乱 | 块切得太碎或排序错误 | 检查最终Prompt的结构 | 加大chunk_size，按原始顺序重排 |
| 处理速度慢 | 在线重复向量化 | 查看接口调用日志 | 引入缓存和离线索引 |
| 相似度普遍偏低 | 领域词汇过于生僻 | 抽样查看向量分布 | 扩展同义词、别名、全称描述 |
我个人建议，在系统里加一个“诊断模式”。它不实际裁剪上下文，只输出一份裁剪报告，列出每个历史块的相似度分数和预测的保留/丢弃状态。调优阶段用它跑一批历史真实问题，比靠肉眼猜阈值靠谱得多。
结尾
做Context Pruning做久了我有一个明显体会：它不是一个“调完就生效”的死功能，而是一套需要跟着场景一起演的活流程。阈值、分块大小、保底规则，每个环节都要有数据支撑，都要经过真实对话的检验。我现在每次调整完参数，都会顺手再看一遍最近几十轮对话里被裁剪掉和保留下的内容样本，确认它在真实场景里的判断方向和我自己的直觉一致。
另外再分享一个小技巧：如果你发现当前对话的相似度筛选效果不稳定，可以先只对检索文档跑Pruning，历史对话继续完整保留。等方案稳定了，再把历史对话也纳入裁剪范围。分批上线，出问题的时候定位范围会小很多。Context Pruning 这个方向的价值，我做下来觉得不仅在省Token，更在于让模型每次回答前看的内容都更精准、更聚焦，这正是这类项目里最值得打磨的细节。
