RAG 检索不准混合检索、重排序到分层索引的完整指南【免费下载链接】RAG_TechniquesThis repository showcases various advanced techniques for Retrieval-Augmented Generation (RAG) systems. Each technique has a detailed notebook tutorial.项目地址: https://gitcode.com/GitHub_Trending/ra/RAG_Techniques做过 RAG 的人大概都被这个问题坑过用户问的是产品代号 Fusion 模块怎么配置检索器却返回了一堆讲融合概念的段落——向量搜索看得懂语义但抓不住确切词汇换成关键词搜索它又只认死词换个说法就漏。开源项目 RAG_Techniques 收录了 40 多个可运行的 RAG 技巧 notebook本文挑其中检索侧最能打的四招——混合检索、重排序、多面过滤、分层索引——按召回 → 粗排 → 精排 → 导航的顺序拆开讲。双路召回让向量搜索和 BM25 互相兜底 一句话一个查询同时跑向量搜索和 BM25 关键词搜索各自打分再加权合并排序。两个分数不能直接相加。FAISS 返回的是距离越小越近BM25 返回的是词频相关分越大越相关量纲完全不同。所以先各自做 min-max 归一化到 0~1再乘权重vector_scores 1 - (vector_scores - np.min(vector_scores)) / (np.max(vector_scores) - np.min(vector_scores)) bm25_scores (bm25_scores - np.min(bm25_scores)) / (np.max(bm25_scores) - np.min(bm25_scores)) combined alpha * vector_scores (1 - alpha) * bm25_scoresalpha 是向量分数的权重直接决定这路检索偏科的方向alpha行为适合≈ 0.7偏语义抽象概念、口语化提问≈ 0.5均衡大多数日常查询≈ 0.3偏关键词产品代号、专有名词、代码片段单路方案各有短板纯向量搜索对精确术语容易失手纯关键词换个说法就漏召回融合后两头的短板都能补上一截代价是索引要维护两套、每次查询跑两遍检索。工程上可以并行执行两路检索再用 LRU 缓存按查询串缓存融合结果重复问题就不必重算。完整 notebook 见 fusion_retrieval.ipynb。给候选集做精排先向量粗排再 LLM 精排向量相似度是各扫一段的打分查询和文档各自编码成向量再算距离。它快但读不懂这句话到底答没答上这个问题。RAG_Techniques 里的重排序 notebook 有个很直白的例子。问 what is the capital of france?一堆段落里混着The capital of France is great. ——词汇全对但毫无信息量一段讲巴黎旅游的游记 ——词不贴但语义上真正在回答纯向量检索会把前两类排前面。重排序的做法是两阶段initial_docs vectorstore.similarity_search(query, k30) # 粗排多召回 score llm_chain.invoke({query: query, doc: doc.page_content}).relevance_score # 1-10 打分 reranked sorted(scored_docs, keylambda x: x[1], reverseTrue)[:top_n] # 取前 2~3打分提示词要求 LLM 考虑查询的具体上下文和意图而不只是关键词匹配并强制结构化输出relevance_scoretemperature 设 0 保证稳定。精排是二次成本30 个候选就要 30 次 LLM 调用。两个常用降法批量调用合并请求对延迟敏感的场景换 cross-encoder把 query 和 doc 拼成一对直接打分本项目里cross-encoder/ms-marco-MiniLM-L-6-v2和 LLM 打分是并列的两条路线效果和开销自己权衡。代码入口在 reranking.ipynb。三层过滤元数据、相似度阈值、多样性召回回来的东西不都是好货。过滤分三道位置不同干的活也不同元数据过滤发生在检索之前按页码、年份、来源、置信度这些附加字段收窄搜索范围。FAISS 的similarity_search直接吃filter参数等于把检索空间先切小一圈响应时间也跟着降。相似度阈值是检索后的质量闸门。阈值不是越严越好严了0.8 以上召回会塌松了0.4 以下噪声进 prompt。经验上 0.6~0.8 起步文档量越大、查询越复杂越要往上调并设 0.95 封顶。多样性过滤防的是三条上下文全在说同一句话。贪心选文档第一条选最相关的之后每选一条都按相关性×(1-λ) 多样性×λ打分多样性用候选与已选文档的平均余弦距离的补数来算λ 取 0.3 左右即可。顺序别反先元数据把无关空间切掉再阈值卡质量最后多样性保角度——早期多砍一批后面的计算量小得多。分层索引先看摘要再下钻细节文档一多平铺索引的毛病就来了几十万碎片躺在一个向量库里查询只能在全部碎片里硬扫既慢又容易钻进无关区域。分层索引的思路是建两个层级的向量库摘要库 详细块库。项目里的 hierarchical_indices.ipynb 实现是两版两层的结构——先给每页文档生成摘要进 summary_store原文切块进 detailed_store两边共享页码元数据top_summaries summary_store.similarity_search(query, k3) # 先定位页面 for s in top_summaries: page s.metadata[page] chunks detailed_store.similarity_search( query, k5, filterlambda m: m[page] page) # 只在该页内细找这就是逐层下钻 剪枝摘要层没命中的页面底层块压根不会被搜到搜索空间从全库缩到命中页。索引构建时摘要由map_reduce摘要链按批并行生成带指数退避扛限流一次构建、两个 store 落盘复用构建成本是一次性的。适合大 PDF、年报这类页内主题高度聚集的文档如果文档各页主题完全交织收益会打折。四招怎么拼把四招放进同一条流水线位置和分工就清楚了落地的几个提醒归一化必须在融合之前做两路分数量纲不同直接加权等于白算融合跑全库时注意候选集别无限放大k 和 alpha 用验证集网格扫别拍脑袋重排序延迟按候选数 × 单次打分延迟估算SLA 紧张就上 cross-encoder 或收紧粗排 k过滤顺序固定元数据 → 阈值 → 多样性顺序反了省不了算力分层索引先量文档规模十万块以下没必要上构建摘要的时间和 token 费不值四招没有必选顺序按瓶颈挑答非所问先上混合检索排名不对加重排序噪声多补过滤库大到扫不动再分层。每个技巧的完整 notebook、评测脚本都在all_rag_techniques/下评测方法可参考 evaluation 目录。【免费下载链接】RAG_TechniquesThis repository showcases various advanced techniques for Retrieval-Augmented Generation (RAG) systems. Each technique has a detailed notebook tutorial.项目地址: https://gitcode.com/GitHub_Trending/ra/RAG_Techniques创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考