020 高级RAG多查询检索、重排序与HyDE技术从一次诡异的“答非所问”说起上周三凌晨两点我盯着终端里吐出的JSON发呆。用户问“苹果公司的总部在哪里”RAG系统返回了“苹果是一种富含维生素C的水果”。Embedding相似度0.89按理说匹配度很高但答案完全跑偏。排查了一小时发现问题出在检索阶段用户query被编码后在向量空间里和“水果苹果”的文档簇撞在了一起。单向量查询的局限性暴露无遗——一个query只能表达一种语义而现实中的用户问题往往是多义的、模糊的、甚至带有隐含意图的。这就是为什么我们需要高级RAG技术。今天这篇笔记我会从实战角度拆解三个核心技巧多查询检索、重排序、以及HyDE假设文档嵌入。每个技术我都会附上踩过的坑和优化后的代码片段。多查询检索别让一个query决定生死核心思路单查询检索就像用一根钓竿在池塘里钓鱼鱼群分布在不同水层你只能钓到钩子所在深度的那几条。多查询检索的思路是把用户的一个问题用LLM生成多个不同角度、不同表述的变体查询然后分别检索最后合并结果。实战代码带注释版fromlangchain.llmsimportOpenAIfromlangchain.embeddingsimportOpenAIEmbeddingsfromlangchain.vectorstoresimportChromafromlangchain.schemaimportDocument# 这里踩过坑不要用默认的temperature0否则生成的查询太相似llmOpenAI(temperature0.7,modelgpt-3.5-turbo-instruct)defgenerate_multi_queries(original_query:str,n:int5)-list: 生成多个查询变体 别这样写直接让LLM生成不同角度的查询太模糊 应该给具体示例比如从技术角度、从商业角度、从历史角度 promptf给定用户问题{original_query}请生成{n}个不同角度的查询变体每个查询用换行分隔。 要求 1. 每个查询必须是完整的问句 2. 覆盖不同语义维度如定义、原理、应用、对比、历史 3. 不要包含序号 示例 原始问题什么是Transformer 变体 Transformer模型的核心架构是什么 Transformer在NLP中如何应用 Transformer相比RNN有什么优势 responsellm(prompt)queries[q.strip()forqinresponse.split(\n)ifq.strip()]# 这里踩过坑LLM可能生成少于n个查询需要补全whilelen(queries)n:queries.append(original_query)returnqueries[:n]# 检索阶段defmulti_query_retrieve(queries:list,vectorstore,k:int3)-list: 多查询检索合并去重 别这样写直接append所有结果会导致重复文档权重过高 all_docs[]seen_idsset()forqueryinqueries:docsvectorstore.similarity_search(query,kk)fordocindocs:# 这里踩过坑Document对象没有唯一ID需要用内容hash去重doc_idhash(doc.page_content[:100])# 取前100字符做hashifdoc_idnotinseen_ids:seen_ids.add(doc_id)all_docs.append(doc)returnall_docs# 使用示例vectorstoreChroma(embedding_functionOpenAIEmbeddings())queriesgenerate_multi_queries(苹果公司的总部在哪里)resultsmulti_query_retrieve(queries,vectorstore,k3)踩坑记录查询数量不是越多越好我试过生成10个查询结果检索时间翻了3倍但召回率只提升了5%。经验值是3-5个。去重策略要谨慎直接用文档内容hash去重可能把同一份文档的不同段落误判为重复。更好的做法是用文档的元数据ID如果有的话。LLM生成质量不稳定有时候LLM会生成“请回答以下问题”这种废话需要在prompt里明确禁止。重排序把金子从沙子里筛出来为什么需要重排序多查询检索会召回大量文档但相关性参差不齐。Embedding相似度只能反映语义接近程度无法精确判断“这个文档是否直接回答了问题”。重排序就是用一个更精确的模型通常是交叉编码器对召回结果重新打分排序。实战代码fromsentence_transformersimportCrossEncoderimportnumpyasnp# 这里踩过坑不要用Bi-Encoder做重排序效果和Embedding检索差不多cross_encoderCrossEncoder(cross-encoder/ms-marco-MiniLM-L-6-v2)defrerank_documents(query:str,documents:list,top_k:int5)-list: 使用交叉编码器重排序 别这样写直接对全部文档排序如果文档数量很大100会很慢 # 构建(query, doc)对pairs[(query,doc.page_content)fordocindocuments]# 这里踩过坑batch_size设置太小会导致推理速度极慢scorescross_encoder.predict(pairs,batch_size32,show_progress_barFalse)# 按分数降序排列scored_docslist(zip(documents,scores))scored_docs.sort(keylambdax:x[1],reverseTrue)# 返回top_kreturn[docfordoc,scoreinscored_docs[:top_k]]# 使用示例retrieved_docsmulti_query_retrieve(queries,vectorstore,k5)reranked_docsrerank_documents(苹果公司的总部在哪里,retrieved_docs,top_k3)性能优化技巧两阶段策略先用Embedding检索出top-50再用交叉编码器重排序取top-5。这样既保证了速度又提升了精度。模型选择ms-marco系列模型在检索任务上表现不错但如果你做的是中文场景建议用BAAI/bge-reranker-v2-m3。批处理交叉编码器推理是计算密集型操作务必用batch处理单条推理会慢10倍以上。HyDE让query“变成”文档再检索核心思想HyDEHypothetical Document Embeddings的思路很巧妙既然query和文档之间存在语义鸿沟那不如先让LLM根据query生成一个“假设文档”即如果存在一篇完美回答这个问题的文档它应该长什么样然后用这个假设文档的embedding去检索。实战代码defgenerate_hypothetical_document(query:str)-str: 生成假设文档 这里踩过坑不要生成太长的假设文档否则embedding会丢失焦点 promptf给定问题{query}请生成一段假设的文档内容这段内容应该是对该问题的完美回答。 要求 1. 长度控制在100-200字 2. 包含具体事实和数据可以虚构但要合理 3. 使用陈述句不要用问句 4. 不要包含根据...研究表明...等引用标记 示例 问题Transformer模型的核心架构是什么 假设文档Transformer模型由Vaswani等人于2017年提出其核心架构包括编码器和解码器两部分。编码器由6个相同的层堆叠而成每层包含多头自注意力机制和前馈神经网络。解码器同样由6层组成但额外包含编码器-解码器注意力层。自注意力机制允许模型在处理每个位置时关注输入序列的所有位置从而捕获长距离依赖关系。 responsellm(prompt)returnresponse.strip()defhyde_retrieve(query:str,vectorstore,k:int5)-list: HyDE检索流程 别这样写直接用假设文档的embedding检索忽略原始query # 生成假设文档hypo_docgenerate_hypothetical_document(query)# 这里踩过坑假设文档的embedding可能偏离原始query太远# 更好的做法是用假设文档embedding和原始query embedding的加权平均embedding_modelOpenAIEmbeddings()hypo_embeddingembedding_model.embed_query(hypo_doc)query_embeddingembedding_model.embed_query(query)# 加权融合alpha控制假设文档的权重alpha0.7combined_embedding[alpha*h(1-alpha)*qforh,qinzip(hypo_embedding,query_embedding)]# 用融合后的embedding检索resultsvectorstore.similarity_search_by_vector(combined_embedding,kk)returnresults# 使用示例hyde_resultshyde_retrieve(苹果公司的总部在哪里,vectorstore,k5)HyDE的适用场景query过于简短比如用户只输入“苹果”HyDE能帮你补全上下文query和文档表述差异大比如用户问“库克在哪办公”文档里写的是“Apple Park”需要跨语言检索HyDE生成的假设文档可以用目标语言从而弥合语言鸿沟踩坑记录假设文档质量依赖LLM如果LLM生成的内容偏离事实检索结果会变差。建议用temperature0.3既保证多样性又不至于太离谱。权重alpha需要调参我试过0.5-0.9的范围0.7在大多数场景下表现最好。如果假设文档质量高可以调高alpha。不要完全替代原始queryHyDE是增强手段不是替代方案。我见过有人只用假设文档检索结果跑偏到火星去了。三合一实战构建高级RAG流水线把三个技术整合成一个完整的检索流水线defadvanced_rag_pipeline(query:str,vectorstore,top_k:int5)-list: 高级RAG流水线多查询检索 HyDE 重排序 # Step 1: 多查询检索queriesgenerate_multi_queries(query,n3)multi_docsmulti_query_retrieve(queries,vectorstore,k5)# Step 2: HyDE增强hyde_docshyde_retrieve(query,vectorstore,k3)# 合并两个结果集all_docsmulti_docshyde_docs# Step 3: 重排序final_docsrerank_documents(query,all_docs,top_ktop_k)returnfinal_docs# 使用示例final_resultsadvanced_rag_pipeline(苹果公司的总部在哪里,vectorstore)个人经验性建议不要盲目堆砌技术如果你的场景是FAQ问答单查询检索重排序就足够了。多查询和HyDE适合query多样性高、文档库大的场景。监控检索延迟多查询检索HyDE重排序整个流程可能增加200-500ms延迟。如果对实时性要求高考虑用异步处理或缓存。AB测试是王道不要相信直觉用离线评估如NDCG、MRR和在线指标如用户满意度来验证每个技术带来的提升。注意token消耗多查询和HyDE都会调用LLM一次检索可能消耗几百到上千token。如果API按量计费成本会显著增加。最后一条也是最重要的一条高级RAG技术解决的是“检索召回”问题但如果你的文档本身质量差、信息过时再好的检索技术也救不了。先把数据治理做好再谈技术优化。回到开头的那个问题“苹果公司的总部在哪里”。用了高级RAG流水线后系统终于正确返回了“Apple Park, Cupertino, California”。虽然多花了300ms但至少不会把用户气到摔手机了。