优化生成效果与降低成本：几种高级RAG技术探索

RAG技术让大语言模型从外部数据源获取信息来支撑回答，说白了就是搜索加LLM提示：你把查询和检索到的上下文一起塞进提示里，让模型在给定信息范围内回答问题。这听起来很简单，但实际用起来，效果往往跟不上业务需求——核心卡在了怎么检索、怎么处理传给LLM的内容上。下面聊聊几种优化思路，以及LangChain里对应的实现。

一个典型的RAG向量化应用包含两个主要组件：

1. 索引
   ：从源头获取数据，做向量化并建索引。

2. 检索与生成
   ：运行时把用户查询转成向量，从索引中捞相关数据，再扔给LLM生成答案。

这两步看似直接，但实际操作中问题不少。下面逐个展开。

1. 分层索引

当文档量很大时，得先找对文档，再找对细节。一种有效做法是建两个索引：一个存摘要，一个存文档块。搜索时分两步走——先用摘要过滤出相关文档，再在这个文档集里精细搜索。这样既能缩小范围，又不丢失精度。

2. 假设性问题和HyDE

让LLM为每个文档块生成一个可能的问题，然后把这些问题向量化。实际查询时，去匹配这些问题向量，命中后再路由到原始文档块，作为上下文传给LLM。因为查询和假设问题之间的语义相似度通常比直接匹配原文更高，搜索质量自然就上去了。

还有个反向逻辑的方法叫HyDE：你给LLM一个查询，让它先生成一个假设的响应，把这个响应的向量和原始查询向量一起用，也能提升搜索质量。

3. 上下文丰富化

检索用小块的文本，精确度更高，但传给LLM时要把周围的上下文一起打包——这样模型看到的信息更丰满。关键是在建索引时就处理好分块关系：存小块用于检索，同时记住它的“父块”（更大的文档）。搜索时先拿到小块，再回溯父块返回。LangChain里的ParentDocumentRetriever干的就是这个活。

4. 融合检索/混合搜索

把不同检索方式得到的结果按相关性进行融合排序。常见的是用倒排融合算法（RRF）重排结果。LangChain的EnsembleRetriever类实现了这种思路——你可以定义一组检索器（比如Faiss向量索引加BM25关键词检索），让它们互补，再用RRF排序。混合搜索通常效果更好，因为语义相似性和关键词匹配都被考虑进来了。

5. 过滤与压缩

向量化索引时，你很难预设用户会问什么。因此，一个文档块里可能只有一两句话有用，其余都是噪声。一股脑全传给LLM，既费钱（肉疼）又影响效果。

LLMChainFilter的做法是用LLM链决定哪些文档该保留、哪些该剔除——但有意思的是，你本意是为了省钱才做过滤，结果又调了一次LLM，有点悖论。更经济的替换方案是EmbeddingsFilter：只用嵌入向量的相似度来过滤，又快又便宜。

另一种思路是上下文压缩（ContextualCompressionRetriever）：拿到检索结果后，对每个文档只提取与查询相关的那一小段内容，再传给LLM。这样既干净又省成本。

6. 元数据过滤

就像在SQL查询里加where条件一样，RAG也不是每次都需要语义检索。比如“找出所有评分大于8分的电影”，或者在某些业务场景中只检索特定品牌的数据。做法很简单：把元数据（如品牌ID）和向量一起存进数据库，然后用大模型的能力把自然语言查询转成元数据过滤条件。LangChain里用metadata_field_info（pydantic格式）来定义结构。

7. 时间加权

有些场景比如客服FAQ，检索越频繁的数据应该越靠前。LangChain用了一个组合公式：语义相似度加上时间衰减。其中的hours_passed是自上次访问（而非创建）对象以来经过的小时数——频繁被访问的对象会一直保持“新鲜”。还有另一种时间权重：针对新闻资讯，创建时间越近权重越高，甚至可以设置过期时间。

说到底，RAG应用最让人操心的就是三个因素：准确率、速度、成本。上面聊的方案基本都在提升准确率，但代价往往是速度下降，有的还会让成本上升。不过在实际业务中，准确率可能才是生死线——LLM本身可能只有60分，业务却要求90分。如果不用这些优化手段拉一把，应用连上线都做不到。