尧图网站建设 
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_TechniquesRAG_Techniques 是收录了 40 多个可运行 RAG 高级技巧教程的开源项目。如果你的 RAG 系统经常查不到、查不准这篇指南带你按 4 个阶段逐级升级检索链路从混合检索到分层索引把召回实打实拉起来。先说一个让你皱眉的 case你问退款政策是什么它返回了一大段注册流程你问这个报错怎么处理它给你背了一段版本历史。这类问题多半不在生成而在检索该出现在上下文里的文档根本没出现后面 LLM 再强也救不回来。那怎么办先别急着换更大的模型。下面 4 个阶段按代价从轻到重排仓库 all_rag_techniques/ 目录里每个阶段都有对应的 notebook可以跟着一路跑。第一阶段让该出现的先出现 单一搜索为什么会漏向量搜索擅长换个说法它也能懂但查询里带精确术语——产品名、报错码、参数名——时嵌入模型经常把它拉向语义相近却错误的概念BM25 关键词搜索正好相反精确匹配是它的强项换个说法就抓瞎。两条路互补所以混合检索的思路很直接同一个查询走两路各自给全部文档打分再把分数归一化到同一尺度加权合并。核心就几行来自仓库的可运行脚本 all_rag_techniques_runnable_scripts/fusion_retrieval.pyvector_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_scores alpha * vector_scores (1 - alpha) * bm25_scores sorted_indices np.argsort(combined_scores)[::-1] return [all_docs[i] for i in sorted_indices[:k]]这里有个坑向量搜索给的是距离越小越好BM25 给的是词频分越大越好直接相加等于让谁分值大谁赢所以归一化一步省不了。权重 alpha 按查询类型调精确术语多的降到 0.3 让关键词主导抽象问题升到 0.7 让向量主导大多数混合型查询 0.5 就够。完整 notebook 在 all_rag_techniques/fusion_retrieval.ipynb。第二阶段把最相关的顶上来 双路召回之后顺序常常还是错的真正最相关的那块内容排在第 8 位而上下文窗口只拿前 3。重排序就是干这个的思路是先海选再精选——先用快速的向量搜索捞 30 个候选海选池再让 LLM 逐篇给文档-查询对打分只留前 2~3 名。关键在评分 prompt 的设计别让模型做相关/不相关的二选一让它出分并且在指令里明确看查询的意图而不是数关键词命中。仓库里的写法prompt_template PromptTemplate( input_variables[query, doc], templateOn a scale of 1-10, rate the relevance of the following document to the query. Consider the specific context and intent of the query, not just keyword matches. Query: {query} Document: {doc} Relevance Score: ) llm_chain prompt_template | llm.with_structured_output(RatingScore)输出用结构化约束收成单个浮点数排序取 Top-N 即可。两个实操建议时延和成本敏感时可以换 cross-encoder/ms-marco-MiniLM-L-6-v2 这类轻量 cross-encoder 做重排reranking.py 里两种都有实现对比QPS 高的话给查询-文档对的评分加缓存同样的问题别二次花钱。这张图出自仓库里的 Graph RAG 教程骨架和上面的两阶段架构一致左侧召回是海选中间的 LLM rerank 是精选右侧才是生成。第三阶段把不相关的挡在外 前两阶段解决选得准过滤解决剔得干净。过滤有 3 类这里只讲实战里最常命中的元数据过滤用文档自带的属性页码、来源、日期硬性圈定检索范围。仓库的分层索引脚本里就有现成用法——下钻到细节块时直接给 FAISS 传一个页码过滤器检索空间瞬间缩小到目标页page_filter lambda metadata: metadata[page] page_number page_chunks detailed_vectorstore.similarity_search(query, kk_chunks, filterpage_filter)另外两类各一句带过相似度阈值过滤是分数过线才收多样性过滤是用 MMR 之类的手法防止 5 条命中全是近义重复。阈值不是玄学大致参考阈值区间行为适合场景0.8 以上宁缺毋滥容易漏合规问答等出错代价高的场景0.6~0.8精度召回平衡日常问答多数项目的起步区0.5 以下尽量多捞噪声偏多探索性查询配合重排序兜底阈值定太高会漏结果绕回第一阶段的老问题太低则等于没过滤。建议从 0.6 起步拿自己的 bad case 往上往下各试一次。第四阶段大文档别暴力扫 文档有 300 页时对全量块做向量搜索又贵又噪。分层索引就是先翻目录再翻正文先用 LLM 给每一页生成一句话摘要摘要和细节块各建一个向量库查询时先在摘要层命中 top 3再只往摘要对应的页里下钻取细节块。检索空间从全书缩到3 页该进前 3 的命中基本都进来了。仓库的实现是两层摘要层 细节层同样的模式可以扩成章→节→段三层就像图书馆先按书库找、再按书架找。这里有个坑摘要层靠 LLM 生成构建成本比扁平索引高而且某页摘要写偏了这页就永远搜不中——所以生成摘要的 prompt 要覆盖页内关键实体和数据。构建流程在 hierarchical_indices.ipynb代码不贴了核心就是批量摘要 → 建两个 FAISS。收尾按症状选药方 ✅你的症状优先升级的阶段精确术语、专名命中不了第一阶段混合检索结果对但顺序乱重点被埋第二阶段LLM 重排序无关内容混得多第三阶段过滤文档长、检索慢、命中偏题多第四阶段分层索引落地顺序给 3 条建议先做混合检索只加一个 BM25 索引和十来行代码当天见效不依赖任何新模型。双路召回稳了再上重排序它是后劲环节但要付 LLM 调用费海选池质量一般时加它也是白精选。过滤和分层索引都属于缩小检索空间等文档规模上千页、或 bad case 集中爆发时再上知道该拧哪个旋钮。现在就打开 all_rag_techniques/fusion_retrieval.ipynb 跑一遍和纯向量搜索对比一次命中情况——这药对不对你的数据10 分钟就有答案。【免费下载链接】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），仅供参考 RAG 检索总是查不准？4 个阶段把召回拉起来的完整指南
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_TechniquesRAG_Techniques 是收录了 40 多个可运行 RAG 高级技巧教程的开源项目。如果你的 RAG 系统经常查不到、查不准这篇指南带你按 4 个阶段逐级升级检索链路从混合检索到分层索引把召回实打实拉起来。先说一个让你皱眉的 case你问退款政策是什么它返回了一大段注册流程你问这个报错怎么处理它给你背了一段版本历史。这类问题多半不在生成而在检索该出现在上下文里的文档根本没出现后面 LLM 再强也救不回来。那怎么办先别急着换更大的模型。下面 4 个阶段按代价从轻到重排仓库 all_rag_techniques/ 目录里每个阶段都有对应的 notebook可以跟着一路跑。第一阶段让该出现的先出现 单一搜索为什么会漏向量搜索擅长换个说法它也能懂但查询里带精确术语——产品名、报错码、参数名——时嵌入模型经常把它拉向语义相近却错误的概念BM25 关键词搜索正好相反精确匹配是它的强项换个说法就抓瞎。两条路互补所以混合检索的思路很直接同一个查询走两路各自给全部文档打分再把分数归一化到同一尺度加权合并。核心就几行来自仓库的可运行脚本 all_rag_techniques_runnable_scripts/fusion_retrieval.pyvector_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_scores alpha * vector_scores (1 - alpha) * bm25_scores sorted_indices np.argsort(combined_scores)[::-1] return [all_docs[i] for i in sorted_indices[:k]]这里有个坑向量搜索给的是距离越小越好BM25 给的是词频分越大越好直接相加等于让谁分值大谁赢所以归一化一步省不了。权重 alpha 按查询类型调精确术语多的降到 0.3 让关键词主导抽象问题升到 0.7 让向量主导大多数混合型查询 0.5 就够。完整 notebook 在 all_rag_techniques/fusion_retrieval.ipynb。第二阶段把最相关的顶上来 双路召回之后顺序常常还是错的真正最相关的那块内容排在第 8 位而上下文窗口只拿前 3。重排序就是干这个的思路是先海选再精选——先用快速的向量搜索捞 30 个候选海选池再让 LLM 逐篇给文档-查询对打分只留前 2~3 名。关键在评分 prompt 的设计别让模型做相关/不相关的二选一让它出分并且在指令里明确看查询的意图而不是数关键词命中。仓库里的写法prompt_template PromptTemplate( input_variables[query, doc], templateOn a scale of 1-10, rate the relevance of the following document to the query. Consider the specific context and intent of the query, not just keyword matches. Query: {query} Document: {doc} Relevance Score: ) llm_chain prompt_template | llm.with_structured_output(RatingScore)输出用结构化约束收成单个浮点数排序取 Top-N 即可。两个实操建议时延和成本敏感时可以换 cross-encoder/ms-marco-MiniLM-L-6-v2 这类轻量 cross-encoder 做重排reranking.py 里两种都有实现对比QPS 高的话给查询-文档对的评分加缓存同样的问题别二次花钱。这张图出自仓库里的 Graph RAG 教程骨架和上面的两阶段架构一致左侧召回是海选中间的 LLM rerank 是精选右侧才是生成。第三阶段把不相关的挡在外 前两阶段解决选得准过滤解决剔得干净。过滤有 3 类这里只讲实战里最常命中的元数据过滤用文档自带的属性页码、来源、日期硬性圈定检索范围。仓库的分层索引脚本里就有现成用法——下钻到细节块时直接给 FAISS 传一个页码过滤器检索空间瞬间缩小到目标页page_filter lambda metadata: metadata[page] page_number page_chunks detailed_vectorstore.similarity_search(query, kk_chunks, filterpage_filter)另外两类各一句带过相似度阈值过滤是分数过线才收多样性过滤是用 MMR 之类的手法防止 5 条命中全是近义重复。阈值不是玄学大致参考阈值区间行为适合场景0.8 以上宁缺毋滥容易漏合规问答等出错代价高的场景0.6~0.8精度召回平衡日常问答多数项目的起步区0.5 以下尽量多捞噪声偏多探索性查询配合重排序兜底阈值定太高会漏结果绕回第一阶段的老问题太低则等于没过滤。建议从 0.6 起步拿自己的 bad case 往上往下各试一次。第四阶段大文档别暴力扫 文档有 300 页时对全量块做向量搜索又贵又噪。分层索引就是先翻目录再翻正文先用 LLM 给每一页生成一句话摘要摘要和细节块各建一个向量库查询时先在摘要层命中 top 3再只往摘要对应的页里下钻取细节块。检索空间从全书缩到3 页该进前 3 的命中基本都进来了。仓库的实现是两层摘要层 细节层同样的模式可以扩成章→节→段三层就像图书馆先按书库找、再按书架找。这里有个坑摘要层靠 LLM 生成构建成本比扁平索引高而且某页摘要写偏了这页就永远搜不中——所以生成摘要的 prompt 要覆盖页内关键实体和数据。构建流程在 hierarchical_indices.ipynb代码不贴了核心就是批量摘要 → 建两个 FAISS。收尾按症状选药方 ✅你的症状优先升级的阶段精确术语、专名命中不了第一阶段混合检索结果对但顺序乱重点被埋第二阶段LLM 重排序无关内容混得多第三阶段过滤文档长、检索慢、命中偏题多第四阶段分层索引落地顺序给 3 条建议先做混合检索只加一个 BM25 索引和十来行代码当天见效不依赖任何新模型。双路召回稳了再上重排序它是后劲环节但要付 LLM 调用费海选池质量一般时加它也是白精选。过滤和分层索引都属于缩小检索空间等文档规模上千页、或 bad case 集中爆发时再上知道该拧哪个旋钮。现在就打开 all_rag_techniques/fusion_retrieval.ipynb 跑一遍和纯向量搜索对比一次命中情况——这药对不对你的数据10 分钟就有答案。【免费下载链接】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），仅供参考