为什么你的RAG系统效果不佳？【珍藏必学】11个组合策略带你从入门到精通，准确率从60%跃升至94%-平芜编程栈

为什么你的RAG系统效果不佳？如何通过组合策略彻底解决

我第一次构建RAG系统时，以为一切都很简单：把文档切块、创建向量、检索相似内容，然后喂给大模型。

结果准确率只有60%左右。

我花了数周时间排查问题。

后来发现，我使用的正是研究人员所称的“朴素RAG”——这种最基础的实现方案，几乎从不在生产环境中奏效。

本文将带你了解11个先进的RAG策略，它们将我的系统准确率从60%提升到了94%，并详细展示如何组合这些策略以实现最大效果。

朴素RAG的根本问题

我们先看看为什么基础RAG经常失败。

传统RAG遵循这个简单流程：

# 朴素RAG方法def naive_rag(query: str) -> str: # 1. 对查询进行向量化 query_embedding = embed(query) # 2. 查找相似片段 chunks = vector_db.search(query_embedding, top_k=5) # 3. 生成答案 context = "\n".join(chunks) answer = llm.generate(f"Context: {context}\n\nQuestion: {query}") return answer

看起来合理，对吧？

但问题出在哪里：

固定大小的分块会在思路中间切断句子，丢失上下文
单一查询视角会错过表述不同的文档
没有相关性过滤——你得到的是“最接近”的匹配，而不是最相关的
有限的上下文——小片段缺乏完整画面

结果就是？你的RAG系统变成了一个高级猜谜游戏。

下面展示如何修复这些问题。

真正有效的11个策略

我将这些策略分为三类：摄取策略（如何准备文档）、查询策略（如何搜索）和混合方法（组合策略以放大效果）。

策略1：上下文感知分块

作用：不是在固定字符数处分割文档，而是分析语义边界和文档结构。

解决的问题：当你分割“CEO宣布……[分块断开]……收入增长40%”时，上下文就丢失了。上下文感知分块将相关内容保持在一起。

代码示例：

from docling.chunking import HybridChunkerfrom transformers import AutoTokenizerclass SmartChunker: def __init__(self, max_tokens=512): # 使用实际的分词器，而不是字符计数 self.tokenizer = AutoTokenizer.from_pretrained( "sentence-transformers/all-MiniLM-L6-v2" ) self.chunker = HybridChunker( tokenizer=self.tokenizer, max_tokens=max_tokens, merge_peers=True# 合并相邻的小分块 ) def chunk_document(self, document): # 分析文档结构（标题、段落、表格） chunks = list(self.chunker.chunk(dl_doc=document)) # 每个分块包含标题上下文 contextualized_chunks = [] for chunk in chunks: # 添加分层标题信息 contextualized_text = self.chunker.contextualize(chunk=chunk) contextualized_chunks.append(contextualized_text) return contextualized_chunks

优点：

免费且快速
自然地保持文档结构
适用于任何嵌入模型

缺点：

比朴素分割稍慢
需要正确的文档解析

使用时机：这应该是你的默认策略。始终优先选择语义分块而不是固定大小分割。

策略2：上下文检索

作用：在嵌入之前为每个分块添加文档级上下文。LLM生成1-2句话解释每个分块与整个文档的关系。

解决的问题：像“收入增长40%”这样的分块如果没有上下文（哪个公司、哪个季度、哪个文档）就没有意义。

代码示例：

async def enrich_chunk(chunk: str, document: str, title: str) -> str: """使用LLM添加上下文前缀""" prompt = f"""标题：{title}{document[:4000]}{chunk}提供简要上下文（1-2句话）解释此分块 与完整文档的关系。格式："此分块来自[标题]，讨论[解释]。" """ response = await client.chat.completions.create( model="gpt-4o-mini", messages=[{"role": "user", "content": prompt}], temperature=0, max_tokens=150 ) context = response.choices[0].message.content.strip() # 嵌入带上下文的版本 return f"{context}\n\n{chunk}"

前后对比：

之前："收入增长40%至3.14亿美元，利润率提高。"之后："此分块来自ACME公司2024年第二季度SEC文件，讨论季度 财务表现与2024年第一季度的比较。收入增长40%至3.14亿美元，利润率提高。"

优点：

减少35-49%的检索失败（根据Anthropic研究）
分块变得自包含
适用于向量和关键词搜索

缺点：

昂贵（摄取时每个分块需要1次LLM调用）
摄取时间更慢
索引大小更大

使用时机：用于准确性比成本更重要的关键文档（法律、医疗、财务文档）。

策略3：重排序

作用：两阶段检索，快速向量搜索找到20-50个候选，然后交叉编码器模型重新评分以提高精度。

解决的问题：向量相似度并不总是匹配语义相关性。文档可能在嵌入空间中“接近”，但实际上并不回答问题。

代码示例：

from sentence_transformers import CrossEncoder# 初始化一次reranker = CrossEncoder('cross-encoder/ms-marco-MiniLM-L-6-v2')async def search_with_reranking(query: str, limit: int = 5) -> list: # 阶段1：快速向量检索（获取4倍候选） candidate_limit = min(limit * 4, 20) query_embedding = await embedder.embed_query(query) candidates = await db.query( "SELECT content, metadata FROM chunks ORDER BY embedding $1 LIMIT $2", query_embedding, candidate_limit ) # 阶段2：使用交叉编码器重新排序 pairs = [[query, row['content']] for row in candidates] scores = reranker.predict(pairs) # 按重排序分数排序并返回前N个 reranked = sorted( zip(candidates, scores), key=lambda x: x[1], reverse=True )[:limit] return [doc for doc, score in reranked]

性能比较：

查询："第二季度收入增长因素是什么？"纯向量（相似度分数）：1. "第二季度收入为3.14亿美元" (0.82)2. "增长因素包括..." (0.78)3. "第一季度，收入为..." (0.76)重排序后（相关性分数）：1. "增长因素包括..." (0.94)2. "第二季度收入为3.14亿美元" (0.89)3. "第二季度表现的关键驱动因素..." (0.85)

优点：

显著提高精度
考虑更多候选而不压倒LLM
可以修复向量搜索错误

缺点：

比纯向量搜索慢
需要更多计算资源
成本稍高

使用时机：当精度比速度更重要时。非常适合错误答案成本高的问题回答系统。

策略4：查询扩展

作用：使用LLM将简短查询扩展为更详细、全面的版本。

解决的问题：用户查询通常很模糊。“什么是RAG？”并不能捕捉他们想要的是架构细节、使用案例还是实施指南。

代码示例：

async def expand_query(query: str) -> str: """将简短查询扩展为详细版本""" system_prompt = """你是查询扩展助手。 接受简短的用户查询并将其扩展为更详细的版本：1. 添加相关上下文和澄清2. 包含相关术语和概念3. 指定应涵盖的方面4. 保持原始意图5. 保持为单个连贯问题将查询扩展为详细2-3倍，同时保持专注。""" response = await client.chat.completions.create( model="gpt-4o-mini", messages=[ {"role": "system", "content": system_prompt}, {"role": "user", "content": f"扩展此查询：{query}"} ], temperature=0.3 ) return response.choices[0].message.content.strip()

转换示例：

输入："什么是RAG？"输出："什么是检索增强生成（RAG），它如何将 信息检索与语言生成相结合，其关键组件和架构是什么， 以及它为问答系统提供了哪些优势？"

优点：

提高检索精度
更好地处理模糊查询
单一增强查询（快速）

缺点：

额外的LLM调用增加延迟
可能过度指定简单查询
成本稍高

使用时机：当用户通常询问简短、模糊问题时。非常适合聊天机器人和搜索界面。

策略5：多查询RAG

作用：生成相同问题的3-4种不同表述，并行搜索所有表述，并去重结果。

解决的问题：一种表述可能错过与不同表述匹配的相关文档。

代码示例：

async def search_with_multi_query(query: str, limit: int = 5) -> list: # 生成查询变体 variations_prompt = f"""生成此查询的3种不同表述： "{query}" 仅返回3个查询，每行一个。""" response = await client.chat.completions.create( model="gpt-4o-mini", messages=[{"role": "user", "content": variations_prompt}], temperature=0.7 ) queries = [query] + response.choices[0].message.content.strip().split('\n') # 并行执行所有搜索 search_tasks = [] for q in queries: query_embedding = await embedder.embed_query(q) task = db.fetch( "SELECT * FROM match_chunks($1::vector, $2)", query_embedding, limit ) search_tasks.append(task) results_lists = await asyncio.gather(*search_tasks) # 按分块ID去重，保留最高相似度 seen = {} for results in results_lists: for row in results: chunk_id = row['chunk_id'] if chunk_id notin seen or row['similarity'] > seen[chunk_id]['similarity']: seen[chunk_id] = row # 返回前N个唯一结果 return sorted( seen.values(), key=lambda x: x['similarity'], reverse=True )[:limit]

变体示例：

原始："如何部署ML模型？"变体1："将机器学习模型部署到生产环境的步骤是什么？"变体2："ML模型部署基础设施的最佳实践"变体3："训练模型的生产部署选项"

优点：

对模糊查询有更好的召回率
捕捉不同视角
并行执行保持快速

缺点：

4倍数据库查询（尽管并行化）
更高的API成本
可能检索冗余内容

使用时机：当查询可能有多种有效解释时。非常适合广泛的探索性问题。

策略6：智能体RAG

作用：为AI智能体提供多个检索工具，让它根据查询自主选择使用哪个。

解决的问题：并非所有问题都需要相同的检索策略。有时需要语义搜索，有时需要完整文档，有时需要结构化数据。

代码示例：

from pydantic_ai import Agentagent = Agent( 'openai:gpt-4o', system_prompt='你是具有多个检索工具的RAG助手。为每个查询选择合适的工具。')@agent.toolasync def search_knowledge_base(query: str, limit: int = 5) -> str: """文档分块的语义搜索""" query_embedding = await embedder.embed_query(query) results = await db.match_chunks(query_embedding, limit) return format_results(results)@agent.toolasync def retrieve_full_document(document_title: str) -> str: """当分块缺乏上下文时检索完整文档""" result = await db.query( "SELECT title, content FROM documents WHERE title ILIKE %s", f"%{document_title}%" ) return f"**{result['title']}**\n\n{result['content']}"@agent.toolasync def sql_query(question: str) -> str: """查询结构化数据库获取特定数据""" # 智能体可以为结构化数据编写SQL查询 # （在生产环境中，使用具有安全检查的适当SQL生成） return execute_safe_sql(question)

示例流程：

用户："完整的退款政策是什么？"智能体推理：1. 调用search_knowledge_base("退款政策") → 找到提及"refund_policy.pdf"的分块 2. 意识到分块没有完整政策 3. 调用retrieve_full_document("退款政策") → 返回完整文档4. 从完整文档生成全面答案

优点：

高度灵活和自适应
处理多样化的数据源
可以组合多种检索策略

缺点：

实现更复杂
行为不太可预测
由于多步推理，延迟更高

使用时机：当你有异构数据源（文档、数据库、API）且查询复杂度差异很大时。

策略7：自反思RAG

解决的问题：初始搜索通常返回差的结果，但传统RAG只是使用它得到的任何结果。

代码示例：

async def search_with_self_reflection(query: str, limit: int = 5, max_iterations: int = 2) -> dict: """自校正搜索循环""" for iteration in range(max_iterations): # 执行搜索 results = await vector_search(query, limit) # 评分相关性 grade_prompt = f"""查询：{query} 检索到的文档：{format_docs_for_grading(results)}按1-5分评估这些文档与查询的相关性。仅用数字回答。""" grade_response = await client.chat.completions.create( model="gpt-4o-mini", messages=[{"role": "user", "content": grade_prompt}], temperature=0 ) grade = int(grade_response.choices[0].message.content.strip().split()[0]) # 如果结果好，返回它们 if grade >= 3: return { "results": results, "iterations": iteration + 1, "final_query": query } # 如果结果差且不是最后一次迭代，优化查询 if iteration < max_iterations - 1: refine_prompt = f"""查询"{query}"返回了低相关性结果。 建议一个可能找到更好文档的改进查询。仅用改进后的查询回答。""" refined_response = await client.chat.completions.create( model="gpt-4o-mini", messages=[{"role": "user", "content": refine_prompt}], temperature=0.5 ) query = refined_response.choices[0].message.content.strip() # 返回最佳尝试 return { "results": results, "iterations": max_iterations, "final_query": query }

迭代示例：

迭代1：查询："部署"评分：2/5（太模糊）迭代2：优化查询："机器学习模型部署到生产环境"评分：4/5（良好结果）

优点：

自校正
在迭代中改进
可以从差的初始结果中恢复

缺点：

最高延迟（2-3次LLM调用）
最昂贵的策略
对于真正困难的查询可能仍然失败

使用时机：当答案准确性至关重要且延迟可接受时。非常适合研究应用和复杂查询。

策略8：知识图谱

作用：将向量搜索与图数据库结合以捕捉实体间的关系。

解决的问题：向量搜索找到相似的文本但错过了明确的关系，如“CEO of”、“located in”、“reported revenue”。

使用Graphiti的概念示例：

from graphiti_core import Graphitifrom graphiti_core.nodes import EpisodeType# 初始化Graphiti（连接到Neo4j）graphiti = Graphiti("neo4j://localhost:7687", "neo4j", "password")async def ingest_document(text: str, source: str): """摄取到知识图谱""" # Graphiti自动提取实体和关系 await graphiti.add_episode( name=source, episode_body=text, source=EpisodeType.text, source_description=f"文档：{source}" )async def search_knowledge_graph(query: str) -> str: """混合搜索：语义 + 关键词 + 图""" # Graphiti结合： # - 语义相似性（嵌入） # - BM25关键词搜索 # - 图结构遍历 # - 时间上下文 results = await graphiti.search(query=query, num_results=5) # 格式化图结果 formatted = [] for result in results: formatted.append( f"实体：{result.node.name}\n" f"类型：{result.node.type}\n" f"关系：{result.relationships}" ) return "\n---\n".join(formatted)

查询流程示例：

查询："谁运营ACME公司，第二季度发生了什么变化？"纯向量搜索：- "ACME公司CEO信息..."- "第二季度变化包括..."知识图谱搜索：ACME公司（公司） ├─ HAS_CEO → Jane Smith（人物） ├─ REPORTED_REVENUE → $314M（财务） │ └─ PERIOD → Q2 2024 └─ LOCATED_IN → California（地点）结果：可以回答 "Jane Smith运营ACME公司，收入在第二季度增加到3.14亿美元"

优点：

捕捉向量错过的关系
减少幻觉
非常适合互连数据

缺点：

需要Neo4j基础设施
设置和维护复杂
更慢且更昂贵
需要实体提取

使用时机：当实体间关系至关重要时（医疗网络、财务系统、研究数据库）。

策略9：分层RAG

作用：创建父-子分块关系。搜索小子分块以提高精度，返回大父分块以获取上下文。

解决的问题：小子分块精确匹配查询但缺乏上下文。大分块有上下文但匹配不佳。

代码示例：

def ingest_hierarchical(document: str, title: str): """创建父-子结构""" # 父级：大部分（2000字符） parent_chunks = [document[i:i+2000] for i in range(0, len(document), 2000)] for parent_id, parent in enumerate(parent_chunks): # 存储父级 metadata = {"heading": f"{title} - 部分 {parent_id}"} db.execute( "INSERT INTO parent_chunks (id, content, metadata) VALUES (%s, %s, %s)", (parent_id, parent, json.dumps(metadata)) ) # 子级：小子分块（500字符） child_chunks = [parent[j:j+500] for j in range(0, len(parent), 500)] for child in child_chunks: embedding = get_embedding(child) db.execute( "INSERT INTO child_chunks (content, embedding, parent_id) VALUES (%s, %s, %s)", (child, embedding, parent_id) )async def hierarchical_search(query: str) -> str: """搜索子级，返回父级""" query_emb = get_embedding(query) # 搜索小子级以提高精度 results = await db.query( """SELECT p.content, p.metadata FROM child_chunks c JOIN parent_chunks p ON c.parent_id = p.id ORDER BY c.embedding %s LIMIT 3""", query_emb ) # 返回大父级以获取上下文 formatted = [] for content, metadata in results: meta = json.loads(metadata) formatted.append(f"[{meta['heading']}]\n{content}") return "\n\n".join(formatted)

优点：

平衡精度与上下文
减少搜索中的噪音
对于结构化文档很自然

缺点：

需要父-子模式
更复杂的索引
需要仔细的层次设计

使用时机：当文档具有清晰的层次结构时（技术手册、法律文件、研究论文）。

策略10：延迟分块

作用：在分块标记嵌入之前通过转换器处理整个文档（而不是文本）。

解决的问题：传统分块丢失长距离上下文。延迟分块在每个分块的嵌入中保留完整的文档上下文。

概念示例：

def late_chunk(text: str, chunk_size=512) -> list: """分块前嵌入完整文档""" # 步骤1：嵌入整个文档（最多8192个标记） full_doc_token_embeddings = transformer_embed(text) # 标记级别 # 步骤2：定义分块边界 tokens = tokenize(text) chunk_boundaries = range(0, len(tokens), chunk_size) # 步骤3：为每个分块池化标记嵌入 chunks_with_embeddings = [] for start in chunk_boundaries: end = start + chunk_size chunk_text = detokenize(tokens[start:end]) # 平均池化标记嵌入（保留完整文档上下文！） chunk_embedding = mean_pool(full_doc_token_embeddings[start:end]) chunks_with_embeddings.append((chunk_text, chunk_embedding)) return chunks_with_embeddings

优点：

保持完整文档上下文
有效利用长上下文模型
更好的语义理解

缺点：

需要长上下文嵌入模型
实现更复杂
受模型最大标记数限制

使用时机：当文档上下文对于理解分块至关重要时（密集技术文档、法律合同）。

策略11：微调嵌入

作用：在特定领域的查询-文档对上训练嵌入模型。

解决的问题：通用嵌入不理解专业术语（医学术语、法律行话、技术缩写）。

代码示例：

from sentence_transformers import SentenceTransformer, lossesfrom torch.utils.data import DataLoaderdef prepare_training_data(): """领域特定的查询-文档对""" return [ ("什么是EBITDA？", "EBITDA（利息、税项、折旧及摊销前利润..."), ("解释资本支出", "资本支出（CapEx）指的是..."), # ... 数千对更多 ]def fine_tune_model(): """在领域数据上微调""" # 加载基础模型 model = SentenceTransformer('all-MiniLM-L6-v2') # 准备训练数据 train_examples = prepare_training_data() train_dataloader = DataLoader(train_examples, shuffle=True, batch_size=16) # 定义损失函数 train_loss = losses.MultipleNegativesRankingLoss(model) # 训练 model.fit( train_objectives=[(train_dataloader, train_loss)], epochs=3, warmup_steps=100 ) model.save('./fine_tuned_financial_model') return model# 使用微调模型embedding_model = SentenceTransformer('./fine_tuned_financial_model')

性能比较：

查询："什么是营运资金？"通用嵌入：1. "营运资金包括..." (0.72)2. "资本市场提供..." (0.68) ← 错误！3. "工作条件在..." (0.65) ← 错误！微调嵌入：1. "营运资金包括..." (0.89)2. "营运资金比率计算..." (0.84)3. "有效管理营运资金..." (0.81)

优点：