北京
在RAG（检索增强生成）管道中，文档会先被切分成数据块，转换成嵌入向量，然后存储在向量数据库里。当用户查询到来时，它同样被转换成嵌入向量，用来从向量数据库中检索出相关结果。这个过程看起来顺畅，但问题就出在这里——检索出来的结果虽然“相关”，却不一定和用户提问精准匹配。
举个例子，当用户搜索“FastAPI依赖注入”时，返回的数据块可能涵盖了FastAPI的方方面面：路由设计、中间件机制、请求处理流程等等。从语义上看，它们确实和FastAPI沾边，但未必是“依赖注入”这个话题下最准确的内容。这取决于文档当初是如何被嵌入和存储进向量数据库的。
面对这种情况，一种优化思路应运而生：把检索到的结果在送入“增强”阶段之前，先压缩成一两个更有针对性的数据块。这样做能直接减少增强环节消耗的token数量，相当于一种优化技术。从上面的例子来看，那些从向量数据库捞出来的数据块并不完全切合用户意图，所以需要在保留原始上下文的前提下进行压缩，生成一两个与查询高度相关的浓缩块。
但要明确一点：上下文压缩并非每条RAG管道都必须执行的步骤。它更多是基于试错和经验判断，取决于具体应用的需求。那么，什么情况下它才真正派得上用场呢？通常在检索结果过于宽泛、token预算有限、或对响应准确性要求极高时，这项技术才会被纳入考量。
目前实现上下文压缩的方法主要有几种。第一种是LLM驱动的方式：把从向量数据库中取出的若干相关数据块交给另一个语言模型进行压缩。比如说，拿到了四个数据块，先不直接塞给主模型，而是让一个专门负责压缩的LLM把它们合并成一块或两块有意义的内容。
表面上看，调用大模型做压缩似乎成本不低，但实际操作中，人们往往采用本地部署的模型或低成本模型来完成这个任务。这个用于压缩的LLM并不生成最终回答，它的唯一职责就是合并检索内容、精简信息并保持上下文完整。之后，压缩后的数据块才会被传递给功能更强、更符合应用场景的主模型生成最终回复。这样一来，就形成了一个两阶段管道，既节省了token，又保证了输出质量。
第二种是嵌入相似度筛选法：把检索到的顶级数据块的嵌入向量和用户查询的嵌入向量进行余弦相似度比对。那些和用户问题最相关的数据块会被挑出来，直接作为压缩后的上下文使用。
关键词匹配法是第三种思路。它借助TF-IDF或BM25算法这类传统信息检索技术，把用户查询中的关键词和检索到的数据块进行比对。关键词重合度最高的数据块会被选中，构成精简后的上下文。
实际上，单一应用完全不必只拘泥于一种压缩方式。根据自身需求，完全可以把两种甚至多种技术融合起来使用。上下文压缩的本质，就是在检索质量与生成效率之间找到一个平衡点——它不追求“全”，而是追求“准”，让最终进入主模型的信息更聚焦、更干净。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
