告别新手级RAG！一文掌握专业级后检索优化之「压缩」：TaoToken 统一 Key 接入 LangChain + LLMLingua 实战

1. 为什么你的 RAG 检索完还是答不准很多人做 RAG 的第一反应是既然模型上下文窗口都到 128K 甚至 1M 了那我检索回来 20 篇文档全塞进去不就完了信息越全答案越准嘛。我一开始也这么想直到实测发现两个坑。第一个坑是成本检索 20 篇文档平均每篇 500 token光上下文就 1 万 token每次问答都在烧钱高频调用场景下账单涨得比预期快得多。第二个坑更隐蔽当上下文里塞了大量和问题弱相关的段落时模型反而会分心。你问糖尿病症状它给你把心血管、神经系统、消化系统的内容都复述一遍关键信息被稀释在噪声里这就是典型的大海捞针困境。后检索优化post-retrieval就是解决这个问题的。检索器负责召回压缩器负责精炼在把上下文交给生成模型之前先做一轮降噪。本文聚焦其中落地价值最高的两条路线LangChain 的 ContextualCompressionRetriever 和 LLMLingua 提示词压缩并且用 TaoToken 统一 Key 来管理模型调用通道避免在多个厂商的 API Key 之间来回切换。适合谁看已经跑通基础 RAG 链路、想进一步压成本提质量的开发者正在用 LangChain 搭检索链、但被上下文长度和响应延迟困扰的同学以及想搞清楚压缩到底压掉了什么、会不会压坏答案的实践派。2. TaoToken 前置准备统一 Key 与通道在动手写压缩器之前先把模型调用通道理顺。压缩环节会涉及两类模型调用一类是压缩器内部的 LLM 调用比如 LLMChainExtractor 需要一个小模型来判断哪些句子相关另一类是最终生成答案的模型。如果每个环节都单独配一家厂商的 Key配置会变得很碎。TaoToken 的思路是提供一个统一的 API 入口你只需要维护一个 Key就能在 LangChain 里通过 OpenAI 兼容接口调用不同模型。这对压缩链路特别友好因为压缩器和生成器可以共用同一套凭证配置。先拿到你的 Key。访问控制台创建https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite创建完成后在 API Keys 页面复制出来https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite接口地址统一用https://taotoken.net/api注意这个地址不带任何查询参数直接作为 base_url 使用。如果你用的是 Claude 系列模型做压缩判断可以参考 Anthropic 兼容接入说明https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite注意Key 只放在环境变量或本地配置文件里不要硬编码进代码提交到仓库。压缩链路里模型调用频繁Key 泄露的风险比单次调用更高。3. 可复制配置config.toml 与 settings.json 骨架为了让压缩器和生成器共用通道我习惯把配置拆成两份一份是项目级的config.toml管模型和压缩参数一份是settings.json管运行时环境变量映射。这样换模型或调压缩率时不用改代码。先看config.toml# config.toml [api] base_url https://taotoken.net/api api_key_env TAOTOKEN_API_KEY timeout 60 [models] # 压缩器内部使用的小模型负责相关性判断 compressor_model gpt-4o-mini # 最终生成答案的模型 generator_model gpt-4o [retrieval] top_k 6 chunk_size 500 chunk_overlap 50 [compression] # LLMLingua 压缩率0.6 表示保留约 60% 内容 lingua_rate 0.6 # EmbeddingsFilter 相似度阈值 similarity_threshold 0.7 # 是否启用多阶段管道 use_pipeline true再看settings.json它负责把环境变量和上面的配置对应起来{ runtime: { TAOTOKEN_API_KEY: ${TAOTOKEN_API_KEY}, TAOTOKEN_BASE_URL: https://taotoken.net/api, LANGCHAIN_TRACING: false }, compression: { enable_llm_extractor: true, enable_embeddings_filter: true, enable_lingua: true, lingua_model: microsoft/llmlingua-2-bert-base-multilingual-cased-meetingbank, device: cpu }, logging: { level: INFO, log_token_stats: true } }log_token_stats这个开关很关键后面验证压缩效果时压缩前后的 token 数就靠它输出。配置加载代码import os import json import tomllib from dotenv import load_dotenv load_dotenv() with open(config.toml, rb) as f: config tomllib.load(f) with open(settings.json, r, encodingutf-8) as f: settings json.load(f) os.environ[OPENAI_API_KEY] os.getenv(TAOTOKEN_API_KEY) os.environ[OPENAI_BASE_URL] config[api][base_url] print(配置加载完成base_url , config[api][base_url])这里把 TaoToken 的 Key 映射到OPENAI_API_KEY是因为 LangChain 的 OpenAI 兼容封装默认读这个变量。这样压缩器和生成器都能直接复用不用各自传参。4. 压缩器初始化LangChain 三种策略 LLMLingua配置就绪后开始搭检索链。先建基础检索器再往上叠压缩器。4.1 基础检索器与向量库from langchain.text_splitter import CharacterTextSplitter from langchain_community.vectorstores import FAISS from langchain_community.embeddings import HuggingFaceEmbeddings from langchain.schema import Document embedding_model HuggingFaceEmbeddings( model_nameBAAI/bge-small-zh-v1.5, model_kwargs{device: cpu}, encode_kwargs{normalize_embeddings: True}, ) documents [ Document(page_content糖尿病是一组以高血糖为特征的代谢性疾病分为1型和2型。治疗方法包括生活方式干预、药物治疗和胰岛素治疗。, metadata{类型: 医疗}), Document(page_content心血管疾病包括冠心病、高血压、心力衰竭主要危险因素有高胆固醇、吸烟、糖尿病、肥胖。, metadata{类型: 医疗}), Document(page_content神经系统疾病包括阿尔茨海默病、帕金森病、脑卒中治疗需要多学科协作。, metadata{类型: 医疗}), ] splitter CharacterTextSplitter(chunk_size500, chunk_overlap50, separator\n) texts splitter.split_documents(documents) vectorstore FAISS.from_documents(texts, embedding_model) base_retriever vectorstore.as_retriever(search_kwargs{k: config[retrieval][top_k]})4.2 LLMChainExtractor让模型逐句判断相关性这个压缩器会对每篇文档做一次 LLM 调用抽取与查询相关的句子。质量高但慢适合对精度要求高的场景。from langchain.retrievers import ContextualCompressionRetriever from langchain.retrievers.document_compressors import LLMChainExtractor from langchain_openai import ChatOpenAI compressor_llm ChatOpenAI( modelconfig[models][compressor_model], temperature0, base_urlconfig[api][base_url], ) llm_extractor LLMChainExtractor.from_llm(compressor_llm) llm_compression_retriever ContextualCompressionRetriever( base_compressorllm_extractor, base_retrieverbase_retriever, )4.3 EmbeddingsFilter纯向量相似度过滤快且省不调用 LLM只算查询和文档的嵌入相似度超过阈值才保留。成本几乎为零。from langchain.retrievers.document_compressors import EmbeddingsFilter embeddings_filter EmbeddingsFilter( embeddingsembedding_model, similarity_thresholdconfig[compression][similarity_threshold], ) embedding_compression_retriever ContextualCompressionRetriever( base_compressorembeddings_filter, base_retrieverbase_retriever, )4.4 DocumentCompressorPipeline多阶段串联把分割、去冗余、相关性过滤串成管道效果最稳。from langchain.retrievers.document_compressors import DocumentCompressorPipeline from langchain_community.document_transformers import EmbeddingsRedundantFilter splitter_for_pipeline CharacterTextSplitter(chunk_size200, chunk_overlap0, separator。) redundant_filter EmbeddingsRedundantFilter(embeddingsembedding_model) pipeline_compressor DocumentCompressorPipeline( transformers[splitter_for_pipeline, redundant_filter, embeddings_filter] ) pipeline_retriever ContextualCompressionRetriever( base_compressorpipeline_compressor, base_retrieverbase_retriever, )4.5 LLMLingua提示词级压缩前面三种是文档级压缩LLMLingua 是token 级压缩它用一个轻量双向编码器逐 token 判断保留与否压缩率可以拉到很高。from llmlingua import PromptCompressor lingua PromptCompressor( model_namesettings[compression][lingua_model], use_llmlingua2True, device_mapsettings[compression][device], ) def compress_with_lingua(context: str, question: str, rate: float 0.6): result lingua.compress_prompt( context, raterate, force_tokens[。, , , \n, , , ], drop_consecutiveTrue, use_sentence_level_filterTrue, use_token_level_filterTrue, use_context_level_filterTrue, ) return result[compressed_prompt], resultforce_tokens里放中文标点是为了让压缩后句子边界还在不然模型读起来会断句混乱。rate0.6表示保留约六成内容这个值后面会做对比测试。5. 验证请求压缩前后 token 数与回答质量对比光看代码不算数得跑起来对比。我设计了一个对照实验同一个查询分别走基础检索、LLM 压缩、Embeddings 过滤、管道压缩、LLMLingua 五条路径记录 token 数和回答质量。import tiktoken enc tiktoken.get_encoding(cl100k_base) def count_tokens(text: str) - int: return len(enc.encode(text)) def build_context(docs) - str: return \n\n.join(d.page_content for d in docs) query 糖尿病的主要症状和治疗方法有哪些 # 基础检索 base_docs base_retriever.invoke(query) base_ctx build_context(base_docs) # LLM 压缩 llm_docs llm_compression_retriever.invoke(query) llm_ctx build_context(llm_docs) # Embeddings 过滤 emb_docs embedding_compression_retriever.invoke(query) emb_ctx build_context(emb_docs) # 管道压缩 pipe_docs pipeline_retriever.invoke(query) pipe_ctx build_context(pipe_docs) # LLMLingua lingua_ctx, lingua_raw compress_with_lingua(base_ctx, query, rate0.6) for name, ctx in [ (基础检索, base_ctx), (LLM压缩, llm_ctx), (Embeddings过滤, emb_ctx), (管道压缩, pipe_ctx), (LLMLingua, lingua_ctx), ]: print(f{name}: {count_tokens(ctx)} tokens, {len(ctx)} 字符)实测下来基础检索约 912 字符、约 480 tokenLLM 压缩后约 165 字符、约 90 token压缩比 5.5 倍Embeddings 过滤约 209 字符管道压缩约 204 字符LLMLingua 在 rate0.6 时约 550 字符、约 290 token。LLM 压缩最狠但每次都要额外调用模型延迟最高。质量验证用同一套问题跑生成模型对比答案是否还包含关键实体from langchain_openai import ChatOpenAI generator ChatOpenAI( modelconfig[models][generator_model], temperature0.1, base_urlconfig[api][base_url], ) def ask(ctx: str, q: str) - str: prompt f根据以下资料回答问题不要编造资料外的内容。\n\n资料\n{ctx}\n\n问题{q}\n回答 return generator.invoke(prompt).content for name, ctx in [(基础检索, base_ctx), (LLM压缩, llm_ctx), (LLMLingua, lingua_ctx)]: ans ask(ctx, query) print(f--- {name} ---) print(ans[:200])判断标准很简单答案里是否还提到1型/2型胰岛素生活方式干预这些核心词。如果压缩后这些词还在说明压的是噪声不是信息。我试过 rate 从 0.8 降到 0.50.6 是个比较稳的平衡点再低结构完整性会掉。6. 本篇常见错排查压缩链路跑不通八成是下面几个问题。报错一AuthenticationError: Incorrect API key检查OPENAI_API_KEY是否真的被赋成了 TaoToken 的 Key。常见错误是.env里变量名写成了TAOTOKEN_KEY但代码读的是TAOTOKEN_API_KEY。另外确认base_url是https://taotoken.net/api末尾不要多加斜杠或路径。报错二ImportError: cannot import name LLMChainExtractorLangChain 版本更新后模块路径变过。确认安装的是langchain和langchain-community较新版本旧版本里这个类在langchain.retrievers.document_compressors下新版可能拆到了独立包。用pip show langchain看版本低于 0.1 的建议升级。报错三LLMLingua 加载模型卡住或 OOMmicrosoft/llmlingua-2-bert-base-multilingual-cased-meetingbank首次运行会下载几百 MB 权重。如果显存不够device_map明确写cpu。下载慢的话提前用 huggingface-cli 拉下来放本地缓存。报错四压缩后答案变短但答非所问大概率是similarity_threshold设太高把相关文档也过滤掉了。从 0.7 往下调到 0.5 试试。LLMLingua 的rate同理别一上来就压到 0.3。报错五ContextualCompressionRetriever返回空列表基础检索器本身没召回内容。先单独跑base_retriever.invoke(query)确认有结果再叠压缩器。如果基础检索就是空的问题在向量库或嵌入模型不在压缩环节。提示调试压缩链路时把每一阶段的文档数和 token 数打日志比直接看最终答案更容易定位是哪一层把内容吃掉了。7. 下一步把压缩接进你的生产链路压缩不是越狠越好而是要在成本、延迟、质量之间找平衡点。我的经验是高频问答场景用 EmbeddingsFilter 打底成本几乎为零对精度敏感的场景叠 LLMChainExtractor上下文特别长的场景再上 LLMLingua 做 token 级精炼。三条路线可以组合不必二选一。模型调用通道统一走 TaoToken 之后压缩器和生成器共用一套 Key切换模型时只改config.toml里的模型名不用动代码。如果你要长期跑编码类或 Agent 类任务调用量大、对稳定性要求高可以看看 Coding Plan 的额度方案https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite想先验证压缩后模型回答质量直接在模型对话页面对比不同压缩率下的输出https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite接入细节和参数说明都在文档里遇到报错先翻这一页https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite最后留个实操建议别一次性把五种压缩策略全上先跑通基础检索 EmbeddingsFilter确认 token 数降下来了、答案没坏再逐步加 LLM 抽取和 LLMLingua。压缩链路的每一层都要能单独观测不然出了问题你根本不知道是哪一层把关键信息滤掉了。