微信扫码
添加专属顾问
我要投稿
检索阶段面临的一个挑战是,通常你无法预知你的文档存储系统在处理数据时会面临哪些具体的query。这意味着,对于一个query来说,最相关的信息可能被埋没在包含大量无关文本的文档中。如果你将整个文档传递给LLM,可能会导致更昂贵的调用开销,以及响应质量的下降。这其实与上一节介绍的一样,都是信息被稀释的问题。
上下文压缩(Contextual compression)技术尝试解决这一问题,想法非常简单:不是理解原样返回检索到的文档,而是使用给定的query对上下文进行压缩,这样只会返回有关的内容。此处的“压缩”不仅指压缩单个文档的内容,也指过滤整个文档集合。
在Langchain中使用上下文压缩需要两个步骤:
构建一个基础检索器,就是我们在使用RAG技术构建企业级文档问答系统之基础流程中介绍的那种retriever
将基础检索器和大语言模型,使用Document Compressor构建相应的对象
如上面所介绍的,上下文压缩的工作原理如下图所示:
从下表可以看出,三种上下文压缩的方式,最终的问答效果都不够理想,毕竟压缩多少还是会造成信息损失的,其实有一种折中的方式是,将压缩后的文档,和原始文档一起进行检索,就像卷积神经网络Inception中,将1×1、3×3、5×5卷积后的结果拼接起来一样,这样对原始文档不同视角(粒度)的信息都会保留,这种方式其实已经有论文进行了研究,后面会介绍。
这其中尤其明显的是EmbeddingsFilter,由于涉及到卡阈值,这个值设置过小会使得过滤失效,设置过大可能导致所有检索到的片段都被过滤掉。
3 核心代码
本文完整代码已开源,地址在:https://github.com/Steven-Luo/MasteringRAG/blob/main/retrieval/10_contextual_compression.ipynb
Langchain中的上下文压缩,相关的方法有4种,下面首先介绍基础检索器,然后分别介绍4种的构造方法。
添加一个方法,便于打印检索结果:
基础检索器:
使用基础检索器:
结果:
LLMChainExtractor
构造方法如下:
使用:
结果:
可以看出,结果短了很多,对原文内容进行了摘要压缩。
LLMChainFilter
这种方法,LLM会将不那么相关的文档片段过滤掉。
构造方法如下:
使用:
结果:
LLMListwiseRerank
LLMListwiseRerank
使用zero-shot的方式对文档进行reranking,它的作用与LLMChainFilter
类似,但是更加鲁邦也会耗费更多资源。官方建议使用强大一些的模型,此处为了控制变量,依然使用Ollama中的qwen2-7b。
构造方法:
使用:
结果:
EmbeddingFilter
这种方式会按照Embedding相似度进行过滤。
构造方法:
使用:
53AI,企业落地大模型首选服务商
产品:场景落地咨询+大模型应用平台+行业解决方案
承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业
2025-10-13
LightRAG × Yuxi-Know——「知识检索 + 知识图谱」实践案例
2025-10-13
PG用户福音|一次性搞定RAG完整数据库套装
2025-10-12
任何格式RAG数据实现秒级转换!彻底解决RAG系统中最令人头疼的数据准备环节
2025-10-12
总结了 13 个 顶级 RAG 技术
2025-10-11
企业级 RAG 系统实战(2万+文档):10 个项目踩过的坑(附代码工程示例)
2025-10-09
RAG-Anything × Milvus:读PDF要集成20个工具的RAG时代结束了!
2025-10-09
RAGFlow 实践:公司研报深度研究智能体
2025-10-04
Embedding与Rerank:90%的RAG系统都搞错了!为什么单靠向量检索会毁了你的AI应用?
2025-09-15
2025-08-05
2025-08-18
2025-09-02
2025-08-25
2025-08-25
2025-07-21
2025-08-25
2025-09-03
2025-08-20
2025-10-04
2025-09-30
2025-09-10
2025-09-10
2025-09-03
2025-08-28
2025-08-25
2025-08-20