RAG 检索优化实战4 层漏斗让召回、排序、过滤、分层各司其职【免费下载链接】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 检索优化RAG_Techniques 这个开源项目值得翻一遍混合检索、LLM 重排序、过滤、分层索引四套技术每个都配了独立的 notebook。这篇文章不按教科书顺序走而是把这四层串成一条检索漏斗逐层拆给你看每层拦掉什么、出问题时该拧哪个旋钮。先把翻车现场摆出来为什么回答总差一步用户问怎么重置密码系统返回 3 段注册流程。模型没变笨是喂给它的材料错了。检索不准是 RAG 的第一死因——LLM 再强拿着错误的上下文也答不出正确的事。问题往往不出在生成层而在检索端召回漏了、排序乱了、噪声没拦、文档规模把索引打爆。下面按漏斗顺序一层一层修。让召回更准关键词 × 语义的双通道设计alpha 权重到底怎么调想象一下用户搜退款政策纯向量搜索吐回来 3 段产品介绍——语义上很近但答非所问。这类翻车几乎都出在单通道召回上。我的习惯是把两条通道分开理解向量通道像语义 GPS 定位不要求字面相同靠嵌入距离找语义近邻擅长处理为什么登录总是失败这种口语化意图BM25 通道像精确词典查词按词频和文档长度打分专门抓住型号、报错码、专有名词这种一字不能差的词。两条通道各扫各的盲区。坑在于两者的分数不同尺度FAISS 返回的是距离BM25 返回的是词频加权分直接相加等于拿米和秒做加法。所以核心动作只有四步vector_scores minmax_norm(vector_scores) # 距离统一映射到 [0,1] bm25_scores minmax_norm(bm25.get_scores(q_tokens)) combined alpha * vector_scores (1 - alpha) * bm25_scores top_k argsort_desc(combined)[:k]alpha 就是两通道的天平。查什么类型的问题天平就往哪边压查询形态alpha 参考值主导通道例子型号/版本/报错码密集0.2~0.4词典查词vLLM 0.4.1 怎么配量化混合型术语意图0.5两通道平权混合检索怎么落地抽象意图、口语化0.7~0.8语义定位怎么让搜索快一点落地要点两通道并行跑完再合并归一化必须发生在加权之前这个顺序错了后面全错完整示例见 fusion_retrieval notebook。别执着于一个固定值。先拿 20 条线上坏查询对 alpha ∈ {0.3, 0.5, 0.7} 做一轮人工评估哪组命中多就用哪组。上线后把用户追问了一遍的会话当作负样本定期回收这是调 alpha 最便宜的数据源。召回准了只是找出来了接下来还得排得对。让排序更懂你用 LLM 给候选文档打分Top-K 和 Top-N 的取舍召回回来的 5 篇候选里最对的那篇排在第 3而 LLM 往往只认真看前两段——排名就是命中率。这套做法是两阶段的第一阶段用便宜的通道向量或上面那套混合检索粗筛出 Top-KK 取 20~50第二阶段让 LLM 当面试官二面对每篇文档单独打分、重排只取 Top-NN 取 3~5。为什么要分两步让 LLM 直接对整个文档库逐篇判断既慢又烧钱而且它本来就不擅长找擅长的是判。粗排负责把候选圈出来精排负责判断谁真的相关各干各的活。精排的全部秘密就藏在这段 prompt 里prompt 在 1~10 分范围内给文档与查询的相关性打分。 重点看查询意图而不是关键词重合度。 查询: {query} 文档: {doc} 相关性分数: chain prompt | llm.with_structured_output(RatingScore) score chain.invoke({query: q, doc: d}).relevance_score两个阶段的分工可以摆成一张表粗排第一阶段精排第二阶段职责把候选圈出来判断谁真的相关规模Top-20~50Top-3~5单文档成本毫秒级一次 LLM 调用容忍度漏 1~2 篇可接受头部必须准落地要点K 可以大方一点因为粗排通道便宜N 必须抠着点因为精排后的文档要整个塞进生成上下文。LLM 温度设 0输出走结构化解析解析失败按 0 分处理——宁可少给一篇别让流程崩掉。把 (query, doc) 的打分结果做缓存。客服场景里 80% 的问法其实重复出现缓存命中率会高得超出你的预期。排名理顺后还得把混进来的垃圾清掉。让结果更干净三道过滤器想象一下top-5 结果里有 2 段几乎重复的内容、1 段去年的旧版本、还有 1 段风马牛不相及的边缘匹配——上下文窗口就这么被垃圾占满了。三道过滤器各管一摊顺序建议是元数据 → 阈值 → 多样性越靠前拦掉得越多。元数据过滤器搜索发生前按来源、年份、类目这些字段圈定范围。它拦掉的是根本不属于这个类别的文档。比如只允许命中 2025 年发布的安全更新旧版说明再相关也别进来。相似度阈值搜索发生后把相似度低于下限的文档直接拒掉。它拦掉的是语义上擦边、内容上无关的长尾匹配。0.6~0.8 是常见区间调太高召回会漏调太低等于没设。多样性过滤选最终 N 篇时每篇都要和已入选的文档算一次语义距离。它拦掉的是三篇说同一件事的冗余结果保证结果集在观点、来源上铺得开。落地要点阈值先粗设 0.6跑一周线上查询专门看用户不满意的那批漏召回多就往下调噪声多就往上调。多样性权重从 0.2~0.3 起步压得太高会把相关但重复的文档挤出排名得不偿失。过滤器是廉价操作能前置就前置元数据条件直接下推进度引擎别等结果回来再在内存里筛。过滤保证了干净但如果文档库涨到十万级前面的通道本身就会开始打架。让大规模检索不打架分层索引层级数量怎么选文档库到 20 万 chunk 之后每次查询都是全库向量比对慢而且一篇强相关文档的信号会被另外 19 万 9 千篇稀释掉。把它类比成图书馆你查资料不会把整栋楼的书全翻一遍。先看书架总目录锁定 3 本候选书再翻那几本书的章节摘要最后才到具体段落。分层索引就是这个结构——顶层是全书摘要中层是章节概览底层才是正文块。每一层的检索空间比上一层小一个数量级而且上层命中天然带着上下文章节摘要告诉模型我们在谈这本书的哪部分这比孤零零的 chunk 信息量大得多。导航逻辑本身非常朴素books summary_store.similarity_search(query, k3) # 总目录先锁定书 for book in books: secs section_store.similarity_search( query, filter{book_id: book.id}, k5) # 章节摘要 for s in secs: results chunk_store.similarity_search( query, filter{section_id: s.id}, k3) # 落到具体段落落地要点两层摘要 chunk通常够用文档上万、层级结构复杂时再上三层。两层示例可直接参考 hierarchical_indices notebook。关键在 metadata 联动上层命中的 doc_id / section_id 必须能直接过滤下层检索范围否则分层就退化成多建了几个索引。将来要接图片、音频等多模态数据时给每种模态并行建一套同构索引共享同一套导航路径即可。四层漏斗都修完剩下的事就是按顺序把它们装进你自己的项目里。落地路线一份 3 周清单第 1 周 · 检索层给现有向量检索并联一条 BM25 通道归一化后按 alpha0.5 融合同时收集 20 条真实坏查询用户追问、点踩、无点击的会话都算记录每条的召回命中情况作为基线。第 2 周 · 排序层 过滤层接上 LLM 重排序K30、N3温度 0加上元数据过滤和 0.6 的相似度阈值。用同一批 20 条坏查询复测和基线对比——这一步通常能立刻看到命中率变化也是最有正反馈的一周。第 3 周 · 架构层 回归机制文档量到几万级就建摘要→chunk两层索引把这批坏查询固化为回归集之后每次改索引、改参数、换嵌入模型先跑回归集再上线。最后一句收束召回决定天花板排序决定命中率过滤决定干净度分层决定规模上限。修的顺序也建议照这个漏斗来别跳级。【免费下载链接】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），仅供参考