拓冰网站定制 
RAG检索实战从切分到精排的5个关键环节【免费下载链接】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 项目把三十多种检索技术做成了可运行的 notebook覆盖切分、建索引、混合召回、重排序到答案校验的完整链路。本文不按技术点横着铺而是让一条查询顺着数据流水线走一遍先看一个专有名词查询把向量检索坑进死角的真实案例再逐环节过切分参数、两级索引、分数归一化、重排阈值和评估闭环每一步用表格标出参数与代价所有代码都能从仓库 notebook 里直接跑通。从一个失败开始专有名词查询在向量检索里丢了仓库 data 目录里有一份 Nike 2023 年报。拿Nike 的气候变化影响去查向量检索命中的 top chunk 里根本不出现 Nike 这个词——公司名只写在文档标题里没写进分块正文。repo 里 contextual chunk headers notebook 用 reranker 实测这个 chunk 对该查询的相关性只有 0.1把文档标题拼回 chunk 头部之后分数直接到 0.92。反过来同样会翻车问 FAISS 的 ntotal 是什么向量检索给你一堆语义相近但答非所问的内容而关键词匹配能精确命中。两种方法各自有死角单一检索方式盖不住全部查询类型。RAG_Techniques 的 notebook 按环节拆开本文就按数据流转的顺序一个环节一个环节地过。把文档切到合适的粒度chunk分块既是检索单位也是送给生成模型LLM的上下文单位。切太大一个块横跨两个话题embedding把文本压成向量的模型得到的是一个指向什么都不明确的平均值切太小句子缺了主语和上下文LLM 拿到也接不上。最典型的坑按 1000 字符硬切大概率在段落甚至表格里拦腰截断200 字符的 overlap重叠能缓解边界截断但救不回被切断的语义。from langchain.document_loaders import PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain.vectorstores import FAISS from langchain_openai import OpenAIEmbeddings loader PyPDFLoader(data/Understanding_Climate_Change.pdf) docs loader.load() splitter RecursiveCharacterTextSplitter( chunk_size1000, # 每块字符数不是 token 数 chunk_overlap200, # 约 20% 重叠防止边界截断 ) texts splitter.split_documents(docs) # 省略异常处理与保存 vectorstore FAISS.from_documents(texts, OpenAIEmbeddings())开头那个 0.1 的 chunk 还有一个补救动作入库前把文档标题拼到每个 chunk 前面。信息密度决定检索上限这一步把块里没写的词补了回来。参数起点值调整方向chunk_size800–1200 字符表格多则调小长论证多则调大chunk_overlapchunk_size 的 15–20%只升不降别超过 25%召回数量 k3–5先放大到 10 再靠精排收窄切分参数不用完美但它给后面每个环节定了上限。建两级索引先查摘要再查细节块几百个 chunk 时全库暴力检索无所谓chunk 上到十万级就不能每次都把整个向量库过一遍。两级索引的思路用 LLM 给每页文档生成一段摘要单独建一个摘要向量库查询先打摘要层定位候选页再带着页码到细节块层里检索。这里有个坑摘要层和细节层必须用元数据页码串起来否则细节层检索还是全库扫分层等于白做。仓库 hierarchical_indices notebook 的做法gpt-4o-mini 用 map_reduce 链逐页摘要两个 FAISS 库分开存检索时用摘要的 page 元数据过滤细节库每页再取 top-k 个块。项取值说明k_summaries3摘要层召回数k_chunks5每条摘要下细节层召回数建索引代价每页一次 LLM 摘要一次性离线跑检索代价两次向量检索在线阶段不耗 LLM建议单文档超过两三百页再上摘要层否则平铺索引更省事多一层摘要只是白花建库成本。融合两路分数把专有名词召回拉回来开头的痛点怎么解给关键词检索和向量检索各算一路分加权融合。BM25Best Matching 25按词频和逆文档频率打分的经典排序函数管精确匹配向量管语义。最隐蔽的坑在加这个字上BM25 分数无上界FAISS 返回的是距离0–2越小越近两者单位不同直接相加会让 BM25 一路压过向量路融合退化回纯关键词检索。所以两边必须先各自归一化而且向量那路要记得翻转距离方向。def fusion_retrieval(vectorstore, bm25, query, k5, alpha0.5): eps 1e-8 # 取全库文档保证两路分数一一对应 all_docs vectorstore.similarity_search(, kvectorstore.index.ntotal) bm25_raw bm25.get_scores(query.split()) vec_raw np.array([s for _, s in vectorstore.similarity_search_with_score(query, klen(all_docs))]) # min-max 归一化到 [0,1]距离要翻转1 - 归一化距离 vec 1 - (vec_raw - vec_raw.min()) / (vec_raw.ptp() eps) bm (bm25_raw - bm25_raw.min()) / (bm25_raw.ptp() eps) fused alpha * vec (1 - alpha) * bm top np.argsort(fused)[::-1][:k] return [all_docs[i] for i in top]alpha 不用每次拍脑袋按查询类型给默认值alpha适用查询主导方0.7抽象概念、同义改写多向量0.5混合型默认用这个平衡0.3专有名词、代码、产品名BM25仓库的 fusion_retrieval notebook 里 alpha 固定 0.5 就够用想要自适应可以先用一个便宜的 LLM 调用判断查询类型再选 alpha。另外repo 里还有把实体和关系也存进向量库、两路召回后再走 LLM 重排的图检索变体整条在线流水线长这样三种方案放在一张表里看维度纯向量纯BM25融合检索语义改写查询好差好专有名词查询差好好计算开销低低约为向量路两倍校验召回结果的顺序重排与过滤召回结果到手了顺序就一定对吗k10 的融合结果里最相关的那条未必排在第 1 位——相似度检索的分数对意图匹配是钝感知的。重排序reranking补的就是这一刀用更贵的模型只给候选集打分而不是全库。两条路线cross-encoder交叉编码器把查询和文档拼在一起整体打分快且稳LLM 直接打分更灵活还能顺手做判断。repo 的 CRAGCorrective RAG纠正式 RAG把 LLM 打分做成了一个决策点分数够高就精炼后送生成不够高就不信召回、改写查询去外部搜索。打分用结构化输出约束成 0–1 的浮点数方便和阈值比较低分分支先从原文提取要点再用改写后的查询补外部信息两路合并进上下文。项取值代价召回 k10精排后留 3–5候选越多精排越贵打分阈值0.5 起阈值越低越依赖内部召回精排调用量每候选文档一次可批量合并进单次请求阈值 0.5 不是普适常数它跟着你评分 prompt 的严格程度走。怎么知道自己选对了得靠下一环节的评估集。用评估集验证答案前面所有调参没有标尺都是猜。repo 自带 data/q_a.json 问题集和基于 deepeval 的评估流程同一组问题喂给不同流水线用分数比较。坑在于样本量五六个问题评出来的提升大概率是噪声repo 的 notebook 题量也只是演示级别别把 notebook 里的数字当结论。# 省略检索器与嵌入模型的初始化 from evaluation.evalute_rag import evaluate_rag # 每改一处流水线重跑一次对比两个版本的指标 evaluate_rag(retriever)重点看三个指标它们对应流水线的不同环节指标看什么对应环节上下文相关性召回有没有打中正确的块切分 召回答案相关性答案有没有正面回答问题生成忠实度答案有没有编造生成改完一处后分数差只在百分位说明这个改动没起作用差在十分位才是值得留下的变更。落地清单什么时候上哪个环节按先跑通、再逐项换的顺序推进每换一项重跑一次评估git clone https://gitcode.com/GitHub_Trending/ra/RAG_Techniques环节notebook 入口引入时机基线跑通all_rag_techniques/simple_rag.ipynb第一步先有对照语义切分all_rag_techniques/semantic_chunking.ipynb硬切截断语义严重两级索引all_rag_techniques/hierarchical_indices.ipynb单文档两三百页以上混合召回all_rag_techniques/fusion_retrieval.ipynb专有名词查询多重排与纠偏all_rag_techniques/reranking.ipynb、crag.ipynbtop-1 经常排错多模态all_rag_techniques/multi_model_rag_with_captioning.ipynb文档含图表截图评估evaluation/ 目录每次改参之前而不是之后一个实用的推进顺序simple_rag 基线 → fusion_retrieval 换召回 → reranking 换精排。三次替换每步用同一组问题评估哪个环节真正贡献了分数表格里看得一清二楚。【免费下载链接】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检索实战：从切分到精排的5个关键环节
RAG检索实战从切分到精排的5个关键环节【免费下载链接】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 项目把三十多种检索技术做成了可运行的 notebook覆盖切分、建索引、混合召回、重排序到答案校验的完整链路。本文不按技术点横着铺而是让一条查询顺着数据流水线走一遍先看一个专有名词查询把向量检索坑进死角的真实案例再逐环节过切分参数、两级索引、分数归一化、重排阈值和评估闭环每一步用表格标出参数与代价所有代码都能从仓库 notebook 里直接跑通。从一个失败开始专有名词查询在向量检索里丢了仓库 data 目录里有一份 Nike 2023 年报。拿Nike 的气候变化影响去查向量检索命中的 top chunk 里根本不出现 Nike 这个词——公司名只写在文档标题里没写进分块正文。repo 里 contextual chunk headers notebook 用 reranker 实测这个 chunk 对该查询的相关性只有 0.1把文档标题拼回 chunk 头部之后分数直接到 0.92。反过来同样会翻车问 FAISS 的 ntotal 是什么向量检索给你一堆语义相近但答非所问的内容而关键词匹配能精确命中。两种方法各自有死角单一检索方式盖不住全部查询类型。RAG_Techniques 的 notebook 按环节拆开本文就按数据流转的顺序一个环节一个环节地过。把文档切到合适的粒度chunk分块既是检索单位也是送给生成模型LLM的上下文单位。切太大一个块横跨两个话题embedding把文本压成向量的模型得到的是一个指向什么都不明确的平均值切太小句子缺了主语和上下文LLM 拿到也接不上。最典型的坑按 1000 字符硬切大概率在段落甚至表格里拦腰截断200 字符的 overlap重叠能缓解边界截断但救不回被切断的语义。from langchain.document_loaders import PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain.vectorstores import FAISS from langchain_openai import OpenAIEmbeddings loader PyPDFLoader(data/Understanding_Climate_Change.pdf) docs loader.load() splitter RecursiveCharacterTextSplitter( chunk_size1000, # 每块字符数不是 token 数 chunk_overlap200, # 约 20% 重叠防止边界截断 ) texts splitter.split_documents(docs) # 省略异常处理与保存 vectorstore FAISS.from_documents(texts, OpenAIEmbeddings())开头那个 0.1 的 chunk 还有一个补救动作入库前把文档标题拼到每个 chunk 前面。信息密度决定检索上限这一步把块里没写的词补了回来。参数起点值调整方向chunk_size800–1200 字符表格多则调小长论证多则调大chunk_overlapchunk_size 的 15–20%只升不降别超过 25%召回数量 k3–5先放大到 10 再靠精排收窄切分参数不用完美但它给后面每个环节定了上限。建两级索引先查摘要再查细节块几百个 chunk 时全库暴力检索无所谓chunk 上到十万级就不能每次都把整个向量库过一遍。两级索引的思路用 LLM 给每页文档生成一段摘要单独建一个摘要向量库查询先打摘要层定位候选页再带着页码到细节块层里检索。这里有个坑摘要层和细节层必须用元数据页码串起来否则细节层检索还是全库扫分层等于白做。仓库 hierarchical_indices notebook 的做法gpt-4o-mini 用 map_reduce 链逐页摘要两个 FAISS 库分开存检索时用摘要的 page 元数据过滤细节库每页再取 top-k 个块。项取值说明k_summaries3摘要层召回数k_chunks5每条摘要下细节层召回数建索引代价每页一次 LLM 摘要一次性离线跑检索代价两次向量检索在线阶段不耗 LLM建议单文档超过两三百页再上摘要层否则平铺索引更省事多一层摘要只是白花建库成本。融合两路分数把专有名词召回拉回来开头的痛点怎么解给关键词检索和向量检索各算一路分加权融合。BM25Best Matching 25按词频和逆文档频率打分的经典排序函数管精确匹配向量管语义。最隐蔽的坑在加这个字上BM25 分数无上界FAISS 返回的是距离0–2越小越近两者单位不同直接相加会让 BM25 一路压过向量路融合退化回纯关键词检索。所以两边必须先各自归一化而且向量那路要记得翻转距离方向。def fusion_retrieval(vectorstore, bm25, query, k5, alpha0.5): eps 1e-8 # 取全库文档保证两路分数一一对应 all_docs vectorstore.similarity_search(, kvectorstore.index.ntotal) bm25_raw bm25.get_scores(query.split()) vec_raw np.array([s for _, s in vectorstore.similarity_search_with_score(query, klen(all_docs))]) # min-max 归一化到 [0,1]距离要翻转1 - 归一化距离 vec 1 - (vec_raw - vec_raw.min()) / (vec_raw.ptp() eps) bm (bm25_raw - bm25_raw.min()) / (bm25_raw.ptp() eps) fused alpha * vec (1 - alpha) * bm top np.argsort(fused)[::-1][:k] return [all_docs[i] for i in top]alpha 不用每次拍脑袋按查询类型给默认值alpha适用查询主导方0.7抽象概念、同义改写多向量0.5混合型默认用这个平衡0.3专有名词、代码、产品名BM25仓库的 fusion_retrieval notebook 里 alpha 固定 0.5 就够用想要自适应可以先用一个便宜的 LLM 调用判断查询类型再选 alpha。另外repo 里还有把实体和关系也存进向量库、两路召回后再走 LLM 重排的图检索变体整条在线流水线长这样三种方案放在一张表里看维度纯向量纯BM25融合检索语义改写查询好差好专有名词查询差好好计算开销低低约为向量路两倍校验召回结果的顺序重排与过滤召回结果到手了顺序就一定对吗k10 的融合结果里最相关的那条未必排在第 1 位——相似度检索的分数对意图匹配是钝感知的。重排序reranking补的就是这一刀用更贵的模型只给候选集打分而不是全库。两条路线cross-encoder交叉编码器把查询和文档拼在一起整体打分快且稳LLM 直接打分更灵活还能顺手做判断。repo 的 CRAGCorrective RAG纠正式 RAG把 LLM 打分做成了一个决策点分数够高就精炼后送生成不够高就不信召回、改写查询去外部搜索。打分用结构化输出约束成 0–1 的浮点数方便和阈值比较低分分支先从原文提取要点再用改写后的查询补外部信息两路合并进上下文。项取值代价召回 k10精排后留 3–5候选越多精排越贵打分阈值0.5 起阈值越低越依赖内部召回精排调用量每候选文档一次可批量合并进单次请求阈值 0.5 不是普适常数它跟着你评分 prompt 的严格程度走。怎么知道自己选对了得靠下一环节的评估集。用评估集验证答案前面所有调参没有标尺都是猜。repo 自带 data/q_a.json 问题集和基于 deepeval 的评估流程同一组问题喂给不同流水线用分数比较。坑在于样本量五六个问题评出来的提升大概率是噪声repo 的 notebook 题量也只是演示级别别把 notebook 里的数字当结论。# 省略检索器与嵌入模型的初始化 from evaluation.evalute_rag import evaluate_rag # 每改一处流水线重跑一次对比两个版本的指标 evaluate_rag(retriever)重点看三个指标它们对应流水线的不同环节指标看什么对应环节上下文相关性召回有没有打中正确的块切分 召回答案相关性答案有没有正面回答问题生成忠实度答案有没有编造生成改完一处后分数差只在百分位说明这个改动没起作用差在十分位才是值得留下的变更。落地清单什么时候上哪个环节按先跑通、再逐项换的顺序推进每换一项重跑一次评估git clone https://gitcode.com/GitHub_Trending/ra/RAG_Techniques环节notebook 入口引入时机基线跑通all_rag_techniques/simple_rag.ipynb第一步先有对照语义切分all_rag_techniques/semantic_chunking.ipynb硬切截断语义严重两级索引all_rag_techniques/hierarchical_indices.ipynb单文档两三百页以上混合召回all_rag_techniques/fusion_retrieval.ipynb专有名词查询多重排与纠偏all_rag_techniques/reranking.ipynb、crag.ipynbtop-1 经常排错多模态all_rag_techniques/multi_model_rag_with_captioning.ipynb文档含图表截图评估evaluation/ 目录每次改参之前而不是之后一个实用的推进顺序simple_rag 基线 → fusion_retrieval 换召回 → reranking 换精排。三次替换每步用同一组问题评估哪个环节真正贡献了分数表格里看得一清二楚。【免费下载链接】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），仅供参考