先说两个真实翻车现场。第一个做公司制度知识库的第一周同事问「请年假的流程是什么」Agent 检索出来三个结果——第一个是「加班调休制度」第二个是「差旅费报销标准」第三个才是「年假申请说明」。前两个完全不相关但它们包含了「请假」「流程」这些词向量相似度居然排在正确答案前面。同事看完回复说「你这检索还不如 CtrlF。」第二个文档量从 200 个块涨到 2000 个之后检索质量断崖式下降。原来是暴力扫描数据量翻十倍后排序信噪比直接崩了。Top-3 命中率从 85% 掉到不到 50%。这两次翻车指向同一个问题检索质量不是调一个参数能解决的。它是在多个维度上同时做工任何一个环节拉胯最终结果都会被拖下去。一、问题的本质检索质量由什么决定检索系统的最终输出可以抽象成四个因子做乘法检索质量 ≈ 切块质量 × 检索策略 × 排序质量 × Query 质量这个乘法关系很关键。把某一个维度从 0.6 调到 0.9不如把四个维度都从 0.5 调到 0.7。因为 0.6⁴ 0.13而 0.7⁴ 0.24后者几乎是前者的两倍。我见过太多项目把 embedding 模型从 text-embedding-ada-002 换成 bge-large-zh命中率只涨了 3 个百分点但把切块从固定 500 字改成语义切块直接涨了 15 个点。所以有时候你花三天调模型和 prompt真不如花三小时认真想想「这些文档该怎么切」。下面逐个拆。每个维度我都会给原理、代码、我踩过的坑以及能直接抄的数据。二、切块策略花最多时间做最值钱的事切块是检索系统里最容易被低估的环节。你切出来的块决定了 embedding 模型能看到什么、检索时能匹配到什么、LLM 最终能读到什么。切得不好后面所有优化都是治标不治本。2.1 四种切块方式场景完全不同固定长度切块。按字符或 Token 数一刀切。上一篇用的就是这种写起来最简单但问题也最多一句话被拦腰砍断一个表格被切成几块一个函数定义和调用分在两个块里。只适合纯叙述性文本比如公告、新闻稿。代码文档、结构化文档基本没法用。递归切块。先按段落切段落太长就按句子切句子还长就按字符切。LangChain 的RecursiveCharacterTextSplitter做的是这个。比固定长度强不少至少在自然段落边界处下刀。但遇到没有自然段落的文档比如纯文本流水账跟固定长度没啥区别。语义切块。让 embedding 模型计算相邻句子的向量相似度相似度突然下降的地方就是「话题转折点」在那下刀。这种切法天然按主题分块检索时每个块的主题更集中精确度最高。代价是需要额外计算成本每个文档要多调一次 embedding。不过对离线建库场景来说这个成本几乎可以忽略。多模态切块。如果你的知识库里不只有文字还有表格、图片、代码——那固定三种切法都不够。代码需要按 AST 语法树切表格按行切后还要在块里标明「这行来自 XX 表格」图片需要用 OCR 或视觉模型生成文字描述再切。这已经超出「切块」的范畴了是在做文档解析。2.2 实测数据我用两个项目的数据验证过。一个 2000 页的操作手册另一个 500 个技术 wiki 页面。切块方式Top-3 命中率Top-5 命中率平均块大小固定 500 字61%71%492 字固定 300 字68%77%294 字递归 500 字74%83%463 字语义切块82%91%385 字语义切块的 Top-5 命中率能到 91%比固定长度高 20 个百分点。在新用户首问的场景里这个差距就是「靠谱」和「浪费感情」的区别。2.3 几个进阶技巧Parent-Child Chunking。小块用于检索大块用于生成。比如把文档切成 100 字的小块做向量索引但每个小块关联一个 500 字的父块。检索时用小块匹配返回时把父块喂给 LLM。这样既保证了检索精度又保证了上下文完整。LangChain 和 LlamaIndex 都有这个模式。保留标题层级。切块的时候把当前块的文档路径、章节标题、小标题都拼进块里。比如[来源员工手册 假期管理 年假]员工每年享有 5 天带薪年假需提前在 OA 系统提交申请……这样检索时即使块本身没有「年假」这个词标题也能补上语义信号。Late Chunking。先对整个文档或长段落做 embedding拿到每句话的 token 级表示再在语义边界处切分。这种方法能保留长距离上下文Jina AI 的jina-embeddings-v3已经支持。实测在长篇技术文档上比传统语义切块再涨 3-5 个点。2.4 切块的常见坑块太大embedding 会被稀释块内主题不集中。一般中文控制在 300-500 字。块太小上下文丢失LLM 看不懂。比如「点击这里」这种引用在小区块里就是灾难。overlap 设置不合理overlap 能缓解边界截断但太大会导致重复检索、浪费 token。一般取块大小的 10%-15%。没有清洗 PDF 换行从 PDF 拷出来的文本经常一行就断直接切块会得到大量半截句子。先用正则把段落拼起来。三、混合检索别只用向量检索了向量检索对「概念相近」敏感对「关键词匹配」不敏感。你搜「年假申请」它可能返回「请假流程」这种语义相关但不包含「年假」这个词的结果——对大多数查询来说是好事。但如果你搜的是专有名词「SMTP 配置错误代码 550」向量检索会把它泛化成「邮件发送错误」漏掉包含「550」这个精确关键码的文档。3.1 稀疏检索补的是精确匹配混合检索的经典做法稠密检索 稀疏检索取各自的前 K 个结果做融合排序。稠密检索就是 embedding 向量相似度之前已经写过了。稀疏检索的代表是 BM25一种改进版的 TF-IDF根据词频和逆文档频率打分。核心公式是score(D,Q) Σ IDF(q_i) · [f(q_i,D) · (k11)] / [f(q_i,D) k1 · (1 - b b · |D|/avgDl)]f(q_i,D)是词q_i在文档D中的词频IDF是逆文档频率k1和b是超参。默认k11.5、b0.75在多数中文场景够用但如果你发现短查询的精确匹配被长文档稀释可以把b调小。代码实现from rank_bm25 import BM25Okapiimport numpy as npdef build_bm25(docs):tokenized [jieba.lcut(d) for d in docs] # 中文要先分词return BM25Okapi(tokenized), tokenizeddef hybrid_search(query, vector_store, bm25_index, bm25_docs, top_k10):# Dense: 向量检索dense_results vector_store.search(query, top_ktop_k)# Sparse: BM25 关键词检索 tokenized\_query jieba.lcut(query) bm25\_scores bm25\_index.get\_scores(tokenized\_query) sparse\_top\_idx np.argsort(bm25\_scores)[-top\_k:][::-1] sparse\_results [bm25\_docs[i] for i in sparse\_top\_idx] # 融合RRF return reciprocal\_rank\_fusion(dense\_results, sparse\_results, k60)3.2 融合算法是关键最简单的做法是把两边的分数直接加起来排名但稠密检索和稀疏检索的分数范围差很多一个在 0-1一个可能到几十直接加相当于稀疏检索完全主导排名。RRF倒数排名融合不用分数只用排名。每个文档的 RRF 分 Σ 1/(k rank_i)rank_i 是该文档在某个检索列表里的排名k 是平滑常数通常取 60。这样两边权重相等不依赖分数分布。def reciprocal_rank_fusion(list1, list2, k60):scores {}for rank, doc in enumerate(list1):scores[doc[‘id’]] scores.get(doc[‘id’], 0) 1.0 / (k rank 1)for rank, doc in enumerate(list2):scores[doc[‘id’]] scores.get(doc[‘id’], 0) 1.0 / (k rank 1)return sorted(scores.items(), keylambda x: x[1], reverseTrue)如果你想让向量检索占主导可以用加权 RRF给不同列表的倒数排名乘以不同权重。但我的经验是先保持等权重调 k 值常见 20、40、60通常就够了。3.3 什么时候必须上混合检索查询里包含专有名词、错误码、型号、人名、API 名称。知识库里有大量短字段比如配置项、命令行参数。用户对精确匹配有强预期比如查法律条文、规章制度。四、重排序把金子从沙子里捞出来混合检索能拿回 20 到 30 个候选但最终只取前 3 个给模型。在 30 个里面挑 3 个精度要求很高向量相似度和 BM25 的排序精度都达不到。这时候专门的重排序模型上场。它们的设计目标就是「精确判断一段话是否回答了某个问题」作为检索到 LLM 之间的最后一关。4.1 两个主流选择BGE-RerankerBAAI/bge-reranker-base。开源首选。输入一个问题 一段文本输出一个相关性分数。把混合检索的 30 个候选逐个喂给它按分数重新排取前三。单条推理很快几十毫秒量级总延迟可控。Cohere Rerank。商业版本比开源的强一截尤其在跨语言场景。rerank-v3 对中英混合查询的表现相当好。缺点是要钱API 按次收费。实战经验在一份 2000 块的中文知识库上混合检索 Top-3 命中率是 78%。加 BGE-Reranker 重排后到 89%。加 Cohere Rerank 到 93%。78 到 89 看着只差 11 个点但体验差异很大前者每 4 次查询就翻车一次后者每 9 次才翻车一次。4.2 重排序的两种架构Pointwise。每个 (query, doc) 单独打分然后按分排序。BGE-Reranker 就是这类。实现简单效果已经很好。Listwise。把 query 和多个 doc 一起喂给模型让模型直接输出最优排序。代表是 RankGPT 和一些基于 LLM 的 listwise reranker。优点是能考虑文档之间的相对关系缺点是 token 消耗大、延迟高一般只用于对延迟不敏感的场景。4.3 一个完整的重排序流水线from FlagEmbedding import FlagRerankerreranker FlagReranker(‘BAAI/bge-reranker-base’, use_fp16True)def rerank(query, candidates, top_n3):pairs [[query, doc[‘text’]] for doc in candidates]scores reranker.compute_score(pairs, normalizeTrue)for doc, score in zip(candidates, scores):doc[‘rerank_score’] scorereturn sorted(candidates, keylambda x: x[‘rerank_score’], reverseTrue)[:top_n]注意如果候选太多比如 100 个重排序的延迟会线性增长。一般建议先用向量BM25 召回 30-50 个再重排序。五、Query 改写用户说不好不是用户的错用户输入的问法越随意检索越不准。ChatGPT 普及之后这个问题更严重了——很多人习惯了跟 AI 像跟人一样说话输入的是「那啥我想问一下咱们公司那个每个月光租办公室的钱报销政策是什么来着」。这种句子塞进 embedding 模型向量会被「我想问一下」「那啥」这种噪音词严重稀释。5.1 Query 压缩用 LLM 把用户的口水问题压缩成关键词组合。上面的长句改成「办公室租金 报销政策」检索质量立马拉回来。成本很低——压缩 query 用的 token 可以忽略不计。COMPRESS_PROMPT “”“把用户的问题改写成适合向量检索的简短关键词查询只保留核心实体和意图。用户{query}改写”“”def compress_query(query, llm):return llm(COMPRESS_PROMPT.format(queryquery)).strip()5.2 Query 分解遇到复杂的多跳问题时用。比如「公司给远程员工的通讯补贴和给本地通勤员工的交通补贴有什么不同」这是两个子问题。把它拆成「远程员工通讯补贴」和「本地员工交通补贴」分别检索分别回答最后合并。Workflow 稍微复杂一点但处理多跳问题的效果是碾压式的。DECOMPOSE_PROMPT “”“把下面这个问题拆成 1-3 个可以独立检索的子问题每个子问题占一行。问题{query}子问题”“”def decompose_query(query, llm):text llm(DECOMPOSE_PROMPT.format(queryquery)).strip()return [line.strip(‘- ‘) for line in text.split(’\n’) if line.strip()]5.3 HyDE用假设文档改写HyDEHypothetical Document Embeddings的做法是让 LLM 先根据问题生成一个「假设答案」然后对这个假设答案做 embedding再去检索。这个方法对「用户问题很短、但答案很长」的场景特别有效。HYDE_PROMPT “”“根据以下问题写一段 100 字左右的参考答案。不需要完全准确只要覆盖可能相关的关键词和概念。问题{query}答案”“”def hyde_search(query, llm, vector_store, top_k5):hypo_doc llm(HYDE_PROMPT.format(queryquery))return vector_store.search(hypo_doc, top_ktop_k)HyDE 的风险是如果 LLM 生成的假设答案跑偏了检索也会跑偏。所以通常只在对答案有大致预期的场景使用或者和原始 query 的检索结果做融合。六、怎么评估不能靠感觉检索优化有个坑你改了一个策略主观觉得「好像好了一点」上线后用户反馈反而差了。检索质量的评估必须量化。6.1 三个核心指标命中率Hit Rate。Top-K 结果里至少有一个包含正确答案的比例。最常用衡量「有没有找到」。MRRMean Reciprocal Rank。正确答案在结果列表里排第几排名越靠前 MRR 越高。公式MRR (1/|Q|) · Σ 1/rank_i正确答案排第一贡献 1排第二贡献 0.5没找到贡献 0。NDCGNormalized Discounted Cumulative Gain。综合排名和相关性分数。排名靠前且高度相关的文档获得更高分数。衡量「排序质量」。6.2 建黄金评估集做评估集的方法先建一份「黄金 QA」人工标注的问题 标准答案 应检索到的文档 ID然后跑一次检索用上面的指标打分。我建议至少准备 100 条标注覆盖常见问题占 50%边缘/长尾问题占 30%故意设计的多跳/模糊问题占 20%每次改动检索策略后都用同一份评估集跑一次对比分数变化决定这个改动要不要保留。6.3 错误分析比指标更重要指标告诉你「涨了多少」错误分析告诉你「为什么涨、为什么跌」。建议把检索失败的问题分成几类切块失败正确答案被切到了两个块里或块边界截断了关键信息。语义漂移query 和文档用词不同embedding 没捕捉到同义关系。关键词缺失专有名词、数字、错误码没被向量检索召回。排序失败正确答案在候选里但重排序把它挤下去了。Query 噪音用户输入太啰嗦embedding 被无关词稀释。我每次调优都会先跑一遍错误分类看哪类错误最多就优先攻那个维度。这比盲目换模型有效得多。开源工具 Ragas 可以帮你做这个它内置了检索评估的整套流程。七、调优顺序别同时调四个维度四个维度优化是有顺序的。一个维度稳定之前调另一个会让你误判效果。推荐顺序先优化切块。切块在数据准备阶段最前置改完不需要动任何下游代码。先把命中率从 60 拉到 80后面再调检索策略才能看到真实效果。再开混合检索。在向量检索旁加一条 BM25 管线融合排序。这一步能把稀奇古怪的专有名词、编码、错误码这些稠密检索抓不住的场景补齐。然后上重排序。前面两条做完Top-3 命中率大概在 75-80% 左右。加重排可以把命中率再拉 10 个点。最后做 Query 改写。前面三个都在后端做工Query 改写是唯一直接从前端入手的。先让检索本身合格了再去优化用户的输入质量。这四步我建议的投入时间分配切块 50%混合检索 20%重排序 20%Query 改写 10%。我自己复盘过最值钱的时间就是花在切块策略上——一个下午把切块策略调对检索质量涨的幅度比其他三项加起来还多。八、一个完整的调优案例拿我之前做过的一个企业制度知识库为例初始状态是固定 500 字切块 纯向量检索 无重排。初始 Top-3 命中率61%第一步改成语义切块 Parent-Child命中率涨到 79%第二步加上 BM25 混合检索命中率涨到 84%第三步加 BGE-Reranker命中率涨到 91%第四步加 Query 压缩命中率涨到 94%整个过程中模型还是同一个 bge-large-zhLLM 也没换。检索质量的提升完全来自「把检索这件事做扎实」。TL;DR检索质量 切块质量 × 检索策略 × 排序质量 × Query 质量。乘法关系短板拖全盘。切块是回报率最高的优化点语义切块比固定长度高 20 个点的命中率Parent-Child 和 Late Chunking 是进一步手段。混合检索 稠密语义 稀疏 BM25用 RRF 融合比直接加分数好。重排序在 30 个候选里精确挑 3 个BGE-Reranker 能再拉 11 个点listwise 适合延迟不敏感场景。Query 改写性价比最高压缩、分解、HyDE 三种手段覆盖不同场景。评估必须量化靠 Ragas 黄金 QA 集每次改策略都跑一次分错误分类比指标更能指导优化方向。调优顺序先切块 → 再混合检索 → 然后重排序 → 最后 Query 改写。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】 RAG 检索质量调优：从能用到好用
先说两个真实翻车现场。第一个做公司制度知识库的第一周同事问「请年假的流程是什么」Agent 检索出来三个结果——第一个是「加班调休制度」第二个是「差旅费报销标准」第三个才是「年假申请说明」。前两个完全不相关但它们包含了「请假」「流程」这些词向量相似度居然排在正确答案前面。同事看完回复说「你这检索还不如 CtrlF。」第二个文档量从 200 个块涨到 2000 个之后检索质量断崖式下降。原来是暴力扫描数据量翻十倍后排序信噪比直接崩了。Top-3 命中率从 85% 掉到不到 50%。这两次翻车指向同一个问题检索质量不是调一个参数能解决的。它是在多个维度上同时做工任何一个环节拉胯最终结果都会被拖下去。一、问题的本质检索质量由什么决定检索系统的最终输出可以抽象成四个因子做乘法检索质量 ≈ 切块质量 × 检索策略 × 排序质量 × Query 质量这个乘法关系很关键。把某一个维度从 0.6 调到 0.9不如把四个维度都从 0.5 调到 0.7。因为 0.6⁴ 0.13而 0.7⁴ 0.24后者几乎是前者的两倍。我见过太多项目把 embedding 模型从 text-embedding-ada-002 换成 bge-large-zh命中率只涨了 3 个百分点但把切块从固定 500 字改成语义切块直接涨了 15 个点。所以有时候你花三天调模型和 prompt真不如花三小时认真想想「这些文档该怎么切」。下面逐个拆。每个维度我都会给原理、代码、我踩过的坑以及能直接抄的数据。二、切块策略花最多时间做最值钱的事切块是检索系统里最容易被低估的环节。你切出来的块决定了 embedding 模型能看到什么、检索时能匹配到什么、LLM 最终能读到什么。切得不好后面所有优化都是治标不治本。2.1 四种切块方式场景完全不同固定长度切块。按字符或 Token 数一刀切。上一篇用的就是这种写起来最简单但问题也最多一句话被拦腰砍断一个表格被切成几块一个函数定义和调用分在两个块里。只适合纯叙述性文本比如公告、新闻稿。代码文档、结构化文档基本没法用。递归切块。先按段落切段落太长就按句子切句子还长就按字符切。LangChain 的RecursiveCharacterTextSplitter做的是这个。比固定长度强不少至少在自然段落边界处下刀。但遇到没有自然段落的文档比如纯文本流水账跟固定长度没啥区别。语义切块。让 embedding 模型计算相邻句子的向量相似度相似度突然下降的地方就是「话题转折点」在那下刀。这种切法天然按主题分块检索时每个块的主题更集中精确度最高。代价是需要额外计算成本每个文档要多调一次 embedding。不过对离线建库场景来说这个成本几乎可以忽略。多模态切块。如果你的知识库里不只有文字还有表格、图片、代码——那固定三种切法都不够。代码需要按 AST 语法树切表格按行切后还要在块里标明「这行来自 XX 表格」图片需要用 OCR 或视觉模型生成文字描述再切。这已经超出「切块」的范畴了是在做文档解析。2.2 实测数据我用两个项目的数据验证过。一个 2000 页的操作手册另一个 500 个技术 wiki 页面。切块方式Top-3 命中率Top-5 命中率平均块大小固定 500 字61%71%492 字固定 300 字68%77%294 字递归 500 字74%83%463 字语义切块82%91%385 字语义切块的 Top-5 命中率能到 91%比固定长度高 20 个百分点。在新用户首问的场景里这个差距就是「靠谱」和「浪费感情」的区别。2.3 几个进阶技巧Parent-Child Chunking。小块用于检索大块用于生成。比如把文档切成 100 字的小块做向量索引但每个小块关联一个 500 字的父块。检索时用小块匹配返回时把父块喂给 LLM。这样既保证了检索精度又保证了上下文完整。LangChain 和 LlamaIndex 都有这个模式。保留标题层级。切块的时候把当前块的文档路径、章节标题、小标题都拼进块里。比如[来源员工手册 假期管理 年假]员工每年享有 5 天带薪年假需提前在 OA 系统提交申请……这样检索时即使块本身没有「年假」这个词标题也能补上语义信号。Late Chunking。先对整个文档或长段落做 embedding拿到每句话的 token 级表示再在语义边界处切分。这种方法能保留长距离上下文Jina AI 的jina-embeddings-v3已经支持。实测在长篇技术文档上比传统语义切块再涨 3-5 个点。2.4 切块的常见坑块太大embedding 会被稀释块内主题不集中。一般中文控制在 300-500 字。块太小上下文丢失LLM 看不懂。比如「点击这里」这种引用在小区块里就是灾难。overlap 设置不合理overlap 能缓解边界截断但太大会导致重复检索、浪费 token。一般取块大小的 10%-15%。没有清洗 PDF 换行从 PDF 拷出来的文本经常一行就断直接切块会得到大量半截句子。先用正则把段落拼起来。三、混合检索别只用向量检索了向量检索对「概念相近」敏感对「关键词匹配」不敏感。你搜「年假申请」它可能返回「请假流程」这种语义相关但不包含「年假」这个词的结果——对大多数查询来说是好事。但如果你搜的是专有名词「SMTP 配置错误代码 550」向量检索会把它泛化成「邮件发送错误」漏掉包含「550」这个精确关键码的文档。3.1 稀疏检索补的是精确匹配混合检索的经典做法稠密检索 稀疏检索取各自的前 K 个结果做融合排序。稠密检索就是 embedding 向量相似度之前已经写过了。稀疏检索的代表是 BM25一种改进版的 TF-IDF根据词频和逆文档频率打分。核心公式是score(D,Q) Σ IDF(q_i) · [f(q_i,D) · (k11)] / [f(q_i,D) k1 · (1 - b b · |D|/avgDl)]f(q_i,D)是词q_i在文档D中的词频IDF是逆文档频率k1和b是超参。默认k11.5、b0.75在多数中文场景够用但如果你发现短查询的精确匹配被长文档稀释可以把b调小。代码实现from rank_bm25 import BM25Okapiimport numpy as npdef build_bm25(docs):tokenized [jieba.lcut(d) for d in docs] # 中文要先分词return BM25Okapi(tokenized), tokenizeddef hybrid_search(query, vector_store, bm25_index, bm25_docs, top_k10):# Dense: 向量检索dense_results vector_store.search(query, top_ktop_k)# Sparse: BM25 关键词检索 tokenized\_query jieba.lcut(query) bm25\_scores bm25\_index.get\_scores(tokenized\_query) sparse\_top\_idx np.argsort(bm25\_scores)[-top\_k:][::-1] sparse\_results [bm25\_docs[i] for i in sparse\_top\_idx] # 融合RRF return reciprocal\_rank\_fusion(dense\_results, sparse\_results, k60)3.2 融合算法是关键最简单的做法是把两边的分数直接加起来排名但稠密检索和稀疏检索的分数范围差很多一个在 0-1一个可能到几十直接加相当于稀疏检索完全主导排名。RRF倒数排名融合不用分数只用排名。每个文档的 RRF 分 Σ 1/(k rank_i)rank_i 是该文档在某个检索列表里的排名k 是平滑常数通常取 60。这样两边权重相等不依赖分数分布。def reciprocal_rank_fusion(list1, list2, k60):scores {}for rank, doc in enumerate(list1):scores[doc[‘id’]] scores.get(doc[‘id’], 0) 1.0 / (k rank 1)for rank, doc in enumerate(list2):scores[doc[‘id’]] scores.get(doc[‘id’], 0) 1.0 / (k rank 1)return sorted(scores.items(), keylambda x: x[1], reverseTrue)如果你想让向量检索占主导可以用加权 RRF给不同列表的倒数排名乘以不同权重。但我的经验是先保持等权重调 k 值常见 20、40、60通常就够了。3.3 什么时候必须上混合检索查询里包含专有名词、错误码、型号、人名、API 名称。知识库里有大量短字段比如配置项、命令行参数。用户对精确匹配有强预期比如查法律条文、规章制度。四、重排序把金子从沙子里捞出来混合检索能拿回 20 到 30 个候选但最终只取前 3 个给模型。在 30 个里面挑 3 个精度要求很高向量相似度和 BM25 的排序精度都达不到。这时候专门的重排序模型上场。它们的设计目标就是「精确判断一段话是否回答了某个问题」作为检索到 LLM 之间的最后一关。4.1 两个主流选择BGE-RerankerBAAI/bge-reranker-base。开源首选。输入一个问题 一段文本输出一个相关性分数。把混合检索的 30 个候选逐个喂给它按分数重新排取前三。单条推理很快几十毫秒量级总延迟可控。Cohere Rerank。商业版本比开源的强一截尤其在跨语言场景。rerank-v3 对中英混合查询的表现相当好。缺点是要钱API 按次收费。实战经验在一份 2000 块的中文知识库上混合检索 Top-3 命中率是 78%。加 BGE-Reranker 重排后到 89%。加 Cohere Rerank 到 93%。78 到 89 看着只差 11 个点但体验差异很大前者每 4 次查询就翻车一次后者每 9 次才翻车一次。4.2 重排序的两种架构Pointwise。每个 (query, doc) 单独打分然后按分排序。BGE-Reranker 就是这类。实现简单效果已经很好。Listwise。把 query 和多个 doc 一起喂给模型让模型直接输出最优排序。代表是 RankGPT 和一些基于 LLM 的 listwise reranker。优点是能考虑文档之间的相对关系缺点是 token 消耗大、延迟高一般只用于对延迟不敏感的场景。4.3 一个完整的重排序流水线from FlagEmbedding import FlagRerankerreranker FlagReranker(‘BAAI/bge-reranker-base’, use_fp16True)def rerank(query, candidates, top_n3):pairs [[query, doc[‘text’]] for doc in candidates]scores reranker.compute_score(pairs, normalizeTrue)for doc, score in zip(candidates, scores):doc[‘rerank_score’] scorereturn sorted(candidates, keylambda x: x[‘rerank_score’], reverseTrue)[:top_n]注意如果候选太多比如 100 个重排序的延迟会线性增长。一般建议先用向量BM25 召回 30-50 个再重排序。五、Query 改写用户说不好不是用户的错用户输入的问法越随意检索越不准。ChatGPT 普及之后这个问题更严重了——很多人习惯了跟 AI 像跟人一样说话输入的是「那啥我想问一下咱们公司那个每个月光租办公室的钱报销政策是什么来着」。这种句子塞进 embedding 模型向量会被「我想问一下」「那啥」这种噪音词严重稀释。5.1 Query 压缩用 LLM 把用户的口水问题压缩成关键词组合。上面的长句改成「办公室租金 报销政策」检索质量立马拉回来。成本很低——压缩 query 用的 token 可以忽略不计。COMPRESS_PROMPT “”“把用户的问题改写成适合向量检索的简短关键词查询只保留核心实体和意图。用户{query}改写”“”def compress_query(query, llm):return llm(COMPRESS_PROMPT.format(queryquery)).strip()5.2 Query 分解遇到复杂的多跳问题时用。比如「公司给远程员工的通讯补贴和给本地通勤员工的交通补贴有什么不同」这是两个子问题。把它拆成「远程员工通讯补贴」和「本地员工交通补贴」分别检索分别回答最后合并。Workflow 稍微复杂一点但处理多跳问题的效果是碾压式的。DECOMPOSE_PROMPT “”“把下面这个问题拆成 1-3 个可以独立检索的子问题每个子问题占一行。问题{query}子问题”“”def decompose_query(query, llm):text llm(DECOMPOSE_PROMPT.format(queryquery)).strip()return [line.strip(‘- ‘) for line in text.split(’\n’) if line.strip()]5.3 HyDE用假设文档改写HyDEHypothetical Document Embeddings的做法是让 LLM 先根据问题生成一个「假设答案」然后对这个假设答案做 embedding再去检索。这个方法对「用户问题很短、但答案很长」的场景特别有效。HYDE_PROMPT “”“根据以下问题写一段 100 字左右的参考答案。不需要完全准确只要覆盖可能相关的关键词和概念。问题{query}答案”“”def hyde_search(query, llm, vector_store, top_k5):hypo_doc llm(HYDE_PROMPT.format(queryquery))return vector_store.search(hypo_doc, top_ktop_k)HyDE 的风险是如果 LLM 生成的假设答案跑偏了检索也会跑偏。所以通常只在对答案有大致预期的场景使用或者和原始 query 的检索结果做融合。六、怎么评估不能靠感觉检索优化有个坑你改了一个策略主观觉得「好像好了一点」上线后用户反馈反而差了。检索质量的评估必须量化。6.1 三个核心指标命中率Hit Rate。Top-K 结果里至少有一个包含正确答案的比例。最常用衡量「有没有找到」。MRRMean Reciprocal Rank。正确答案在结果列表里排第几排名越靠前 MRR 越高。公式MRR (1/|Q|) · Σ 1/rank_i正确答案排第一贡献 1排第二贡献 0.5没找到贡献 0。NDCGNormalized Discounted Cumulative Gain。综合排名和相关性分数。排名靠前且高度相关的文档获得更高分数。衡量「排序质量」。6.2 建黄金评估集做评估集的方法先建一份「黄金 QA」人工标注的问题 标准答案 应检索到的文档 ID然后跑一次检索用上面的指标打分。我建议至少准备 100 条标注覆盖常见问题占 50%边缘/长尾问题占 30%故意设计的多跳/模糊问题占 20%每次改动检索策略后都用同一份评估集跑一次对比分数变化决定这个改动要不要保留。6.3 错误分析比指标更重要指标告诉你「涨了多少」错误分析告诉你「为什么涨、为什么跌」。建议把检索失败的问题分成几类切块失败正确答案被切到了两个块里或块边界截断了关键信息。语义漂移query 和文档用词不同embedding 没捕捉到同义关系。关键词缺失专有名词、数字、错误码没被向量检索召回。排序失败正确答案在候选里但重排序把它挤下去了。Query 噪音用户输入太啰嗦embedding 被无关词稀释。我每次调优都会先跑一遍错误分类看哪类错误最多就优先攻那个维度。这比盲目换模型有效得多。开源工具 Ragas 可以帮你做这个它内置了检索评估的整套流程。七、调优顺序别同时调四个维度四个维度优化是有顺序的。一个维度稳定之前调另一个会让你误判效果。推荐顺序先优化切块。切块在数据准备阶段最前置改完不需要动任何下游代码。先把命中率从 60 拉到 80后面再调检索策略才能看到真实效果。再开混合检索。在向量检索旁加一条 BM25 管线融合排序。这一步能把稀奇古怪的专有名词、编码、错误码这些稠密检索抓不住的场景补齐。然后上重排序。前面两条做完Top-3 命中率大概在 75-80% 左右。加重排可以把命中率再拉 10 个点。最后做 Query 改写。前面三个都在后端做工Query 改写是唯一直接从前端入手的。先让检索本身合格了再去优化用户的输入质量。这四步我建议的投入时间分配切块 50%混合检索 20%重排序 20%Query 改写 10%。我自己复盘过最值钱的时间就是花在切块策略上——一个下午把切块策略调对检索质量涨的幅度比其他三项加起来还多。八、一个完整的调优案例拿我之前做过的一个企业制度知识库为例初始状态是固定 500 字切块 纯向量检索 无重排。初始 Top-3 命中率61%第一步改成语义切块 Parent-Child命中率涨到 79%第二步加上 BM25 混合检索命中率涨到 84%第三步加 BGE-Reranker命中率涨到 91%第四步加 Query 压缩命中率涨到 94%整个过程中模型还是同一个 bge-large-zhLLM 也没换。检索质量的提升完全来自「把检索这件事做扎实」。TL;DR检索质量 切块质量 × 检索策略 × 排序质量 × Query 质量。乘法关系短板拖全盘。切块是回报率最高的优化点语义切块比固定长度高 20 个点的命中率Parent-Child 和 Late Chunking 是进一步手段。混合检索 稠密语义 稀疏 BM25用 RRF 融合比直接加分数好。重排序在 30 个候选里精确挑 3 个BGE-Reranker 能再拉 11 个点listwise 适合延迟不敏感场景。Query 改写性价比最高压缩、分解、HyDE 三种手段覆盖不同场景。评估必须量化靠 Ragas 黄金 QA 集每次改策略都跑一次分错误分类比指标更能指导优化方向。调优顺序先切块 → 再混合检索 → 然后重排序 → 最后 Query 改写。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】