很多人的第一个 RAG 系统是这样做的:
文档切块,转成向量,扔进向量数据库,然后祈祷它能搜对。
搜不对怎么办?
换一个更贵的 Embedding 模型,再祈祷一次。
但生产里的 RAG 往往不是“向量检索 + 大模型”这么简单。真正高频的面试追问是:为什么还需要 BM25、混合检索、融合和 Rerank?
今日面试题
💡
RAG 中为什么要做 BM25 与向量混合检索?为什么召回以后还需要 Rerank?
如果回答“因为这样更准”,方向没错,但面试官大概率会继续问:
💡
准在哪里?两路分数怎么合?Rerank 和召回有什么区别?
这时只会说“调个权重”就容易当场进入调参玄学频道。
先给出 30 秒标准答案
💡
BM25 擅长精确词项匹配,适合错误码、型号、专有名词和版本号;向量检索擅长语义匹配,适合同义表达和自然语言改写。混合检索通过多路召回提高候选证据的覆盖率。
召回阶段的目标是尽量别漏,Rerank 阶段的目标是把最能回答问题的证据排在前面。两路结果可以用 RRF 等排名融合方法合并,再用 Cross-Encoder、规则特征或 LLM 对较小候选集重排。
最终要分别评估召回、排序和生成,不能只看答案感觉不错。
一句话记忆:
💡
BM25 认字,向量懂意思,Rerank 负责从候选人里挑最能答题的。
一、为什么只用向量检索不够
向量检索会把 Query 和文档映射到向量空间,根据语义距离寻找相近内容。
它很擅长处理这种情况:
用户问:怎么取消已经提交的订单?文档写:已创建订单的撤销流程两句话用词不同,但意思接近,向量检索通常能把它们联系起来。
可遇到下面这些内容,向量检索可能不如关键词可靠:
- 错误码
E_CONN_1042 - 产品型号
XPS-9315 - API 名称
responses.create - 合同条款编号
7.3.2 - 人名、地名、版本号和缩写
用户要找的是E_CONN_1042,向量检索却热情推荐了“其他网络连接错误”。
语义确实很像,但报错的人只想知道眼前这个祖宗怎么修。
二、BM25 和向量检索分别擅长什么
# BM25:字面侦探
BM25 基于倒排索引和词项统计,重视词在文档中的出现情况及区分度。
它擅长:
- 精确关键词
- 稀有实体
- 编号与术语
- 法律条款
- 代码符号与产品名称
它的弱点是对同义表达不够敏感。用户说“退货”,文档只写“逆向物流”,单靠字面匹配可能擦肩而过。
# 向量检索:语义翻译官
向量检索擅长:
- 同义词
- 改写问题
- 自然语言描述
- 模糊意图
- 跨表达方式的语义匹配
它的弱点是可能把“主题相近”误当成“能回答当前问题”。
所以两者不是新旧技术之间的淘汰赛,而是两个特长不同的队友。
三、混合检索的标准执行链
一个常见流程是:
用户问题 ↓Query 改写与过滤条件提取 ↓BM25 召回 ─────┐ ├→ 去重与融合 → Rerank → 上下文构造 → 生成答案向量召回 ──────┘# 第一步:多路召回
BM25 与向量检索并行,各自返回 Top-K 候选。业务复杂时还可以加入标题检索、标签检索、知识图谱和结构化过滤。
召回阶段宁可适当多带候选,也不要过早把关键证据丢掉。
# 第二步:去重与归并
多路结果里可能出现相同文档、重复 Chunk 或相邻片段。需要按文档 ID、Chunk ID 和内容相似度去重,必要时合并连续片段。
否则上下文里会出现三段几乎一样的话,大模型还以为这是三位专家达成了共识。
# 第三步:结果融合
直接把 BM25 分数和余弦相似度相加通常不稳,因为两种分数的量纲与分布不同。
常见方法有:
- 分数归一化后加权
- Reciprocal Rank Fusion,简称 RRF
- Learning to Rank
RRF 不直接比较原始分数,而是根据每个结果在各路中的排名累计贡献:
score(d) = Σ 1 / (k + rank(d))它的优点是简单、对分数量纲不敏感,适合先建立一个稳健基线。参数仍应通过评测集选择,不要把某个常见默认值当成宇宙常数。
四、召回了为什么还要 Rerank
因为“相关”不等于“最适合回答”。
向量检索和 BM25 的主要任务是快速从海量文档中找出候选。它们需要速度和覆盖率,很难对每个 Query 与文档做细粒度联合理解。
Rerank 则在较小候选集上使用更强、更慢的方法判断:
💡
这段证据是否真的能回答当前问题?
可以把它们类比成招聘:
- 召回负责从十万份简历中筛出一百份
- Rerank 负责认真面试这一百个人
- 上下文窗口只录取最合适的几位
如果没有 Rerank,可能只是把“名字看起来像程序员”的人直接安排去修生产数据库。
五、常见 Rerank 方法
# 1. Cross-Encoder
把 Query 和候选文档一起输入模型,直接输出相关性分数。
它能同时观察问题和文档的细粒度关系,精度通常优于只比较两个独立向量,但计算更慢,所以适合对较小候选集精排。
# 2. LLM Rerank
让大模型根据问题比较候选证据,输出排序或相关性判断。
优点是能理解复杂标准,缺点是成本高、延迟大,还要防止位置偏差和输出不稳定。
# 3. 规则与业务特征
可以加入:
- 来源权威性
- 文档新鲜度
- 标题命中
- 用户权限
- 产品版本一致性
- 文档状态是否有效
这部分非常重要。技术相关性再高,过期政策也不应该排在最新制度前面。
# 4. Learning to Rank
利用人工标注或点击反馈训练排序模型,适合数据积累成熟的系统。
但没有高质量监督数据时,不要为了显得高级而强行上。算法名字很长,不代表线上收益自动很大。
六、RAG 优化要分层诊断
一个成熟回答不能只说“加 Rerank”。应该先问问题坏在哪一层。
# 如果相关证据根本没被找回来
重点检查:
- 文档解析是否正确
- Chunk 是否切坏
- Metadata Filter 是否误过滤
- Query 是否需要改写
- BM25 和向量召回是否互补
# 如果证据被找回但排得太后
重点检查融合与 Rerank,观察 MRR、NDCG 或关键证据排名。
# 如果正确证据已经在前面,答案仍然错误
重点检查:
- 上下文是否有冲突或噪声
- Prompt 是否要求基于证据回答
- 模型是否忠实引用证据
- 输出后处理和事实校验是否有效
不要召回坏了就换生成模型,也不要生成坏了就怪向量数据库。
RAG 是一条流水线,锅应该精准地分给对应工位。
七、面试官连续追问
# 追问一:混合检索一定比单路好吗?
不一定。
如果语料极小、查询高度固定,单路可能已经足够。是否增加链路,要看离线评测和线上收益,而不是看到“混合”两个字就自动加分。
# 追问二:Rerank 候选越多越好吗?
不是。
候选过少可能漏掉证据,过多会增加延迟和费用。应根据召回曲线、延迟预算和最终答案指标选择。
# 追问三:可以直接让大模型把所有文档排序吗?
小规模可以,海量文档不现实。通常仍需快速召回缩小范围,再把少量候选交给更强模型。
# 追问四:为什么不能只看最终答案正确率?
因为最终错误可能来自解析、召回、排序、上下文或生成。只看最终答案无法定位瓶颈,也无法知道一次优化到底改善了哪一层。
八、两分钟面试回答
💡
“BM25 和向量检索解决的是两类不同问题。BM25 擅长错误码、型号、条款号和专有名词等精确匹配;向量检索擅长同义表达和语义改写。真实查询通常同时包含这两类需求,所以会采用多路并行召回提高覆盖率。
两路结果不能简单把原始分数相加,因为量纲和分布不同。可以先去重,再使用归一化加权或 RRF 做融合。RRF 只依赖各路排名,对分数量纲不敏感,适合建立稳健基线。
召回阶段关注尽量别漏,Rerank 阶段关注把最能回答问题的证据排在前面。常见重排方法包括 Cross-Encoder、LLM Rerank、业务规则和 Learning to Rank。由于这些方法较慢,一般只对较小候选集使用。
优化时我会分别评估文档质量、Recall@K、排序指标、上下文质量和最终答案忠实度。只有逐层诊断,才能知道问题到底在召回、排序还是生成,而不是一出问题就换大模型。”
记忆口诀
💡
BM25 负责认准名字,向量负责听懂意思,Rerank 负责决定谁坐前排。
再缩短一点:
💡
先多路捞,再认真挑,最后少而精地喂给模型。
学AI大模型的正确顺序,千万不要搞错了
🤔2026年AI风口已来!各行各业的AI渗透肉眼可见,超多公司要么转型做AI相关产品,要么高薪挖AI技术人才,机遇直接摆在眼前!
有往AI方向发展,或者本身有后端编程基础的朋友,直接冲AI大模型应用开发转岗超合适!
就算暂时不打算转岗,了解大模型、RAG、Prompt、Agent这些热门概念,能上手做简单项目,也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料,手把手帮你快速入门!👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型(GPT、文心一言等)特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架(LangChain等)实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块,看似清晰好上手,实则每个部分都有扎实的核心内容需要吃透!
我把大模型的学习全流程已经整理📚好了!抓住AI时代风口,轻松解锁职业新可能,希望大家都能把握机遇,实现薪资/职业跃迁~