RAG大厂面试高频题：向量检索、混合检索、Rerank、幻觉处理

面试官通常会问：“为什么不让大语言模型直接回答，非要用RAG？”或者“大模型的知识截止问题你如何解决？”下面梳理了RAG的核心知识点，帮助你系统理解这一技术。

1. RAG是什么？为什么需要RAG？

大语言模型的三大知识缺陷

① 知识截止——训练数据存在截止日期，模型无法获知更新的事件。例如，当你询问“2026年3月发布的某框架有什么特性”时，模型可能给出虚构信息或表示不知情。

② 私有数据无法触达——公司内部文档、客户数据、业务规则等，模型从未见过，直接询问会导致错误回答。

③ 容易产生幻觉——当模型不确定答案时，可能会编造看似合理但实际错误的内容，尤其在没有外部知识验证的情况下更为严重。

RAG的核心思路

RAG（Retrieval-Augmented Generation，检索增强生成）的本质可以概括为：在大模型生成回答之前，先从外部知识库中检索相关信息，并将检索结果纳入提示词，让模型基于事实进行回答。

未使用RAG：用户问题 → 大模型 → 回答（可能包含幻觉）

使用RAG：用户问题 → 检索相关知识 → [问题 + 检索结果] → 大模型 → 回答（基于事实）

关键在于：RAG并不是替代大模型，而是为其补充外部知识。大模型负责理解和生成，RAG则负责提供事实依据。

2. RAG的完整链路是怎样的？

面试官常会追问：“你说你做过RAG项目，能完整描述从用户提问到最终回答的全过程吗？”这是基础但关键的问题，需要清晰阐述。

RAG七步链路

查询 → 文档处理 → 分块 → 嵌入 → 检索 → 重排序 → 生成

每一步的具体内容及关键决策如下：

步骤	具体操作	关键决策
文档处理	解析PDF、Word、Markdown等格式，提取文本内容	PDF表格如何处理？是否需要OCR？
分块	将长文档切割成小块	每块大小多少？重叠部分多少？按语义还是固定长度分割？
嵌入	将文本块转换为向量	使用哪种模型？向量维度多少？针对中文还是英文？
检索	根据用户问题检索最相关的文本块	使用纯向量检索还是混合检索？Top-K值设为多少？
重排序	对检索结果重新排序	使用哪种重排序模型？重排后取Top-N
生成	将检索结果与问题整合，输入大模型生成回答	如何设计提示词？如何约束幻觉？

需要关注的不是背诵步骤，而是能清晰说明每一步的决策依据。面试官更想听到的是你选择某技术的原因，比如“为什么选用Milvus而非FAISS，检索延迟要求是多少，为何Top-K设为5而不是10”。

3. 向量检索的原理是什么？

面试官可能会问：“向量检索与关键词检索有什么区别？”以及“嵌入（Embedding）的原理是什么？为何语义相似的文本向量距离较近？”

向量检索的本质

将文本转换为高维空间中的点，语义相似的文本在该空间中距离较近。检索过程就是找到离问题向量最近的若干个文档向量。

举例说明：

"如何优化数据库查询" → [0.12, -0.34, 0.56, ...]← 这些向量在空间中距离较近"数据库性能调优方法" → [0.11, -0.32, 0.55, ...]"今天天气不错" → [-0.45, 0.78, -0.23, ...]← 与上述向量距离较远

相似度计算

最常用的方法是余弦相似度，计算两个向量的夹角余弦值：

cos(A, B) = (A · B) / (|A| × |B|)

值域为[-1, 1]，数值越大表示越相似。1表示方向完全相同，0表示无关，-1表示方向相反。

你可能会好奇，为什么不使用欧氏距离？因为向量的模长受文本长度影响，长文本的向量模长较大，但语义不一定更相关。余弦相似度仅关注方向而不考虑长度，更适合语义检索。

近似最近邻检索（ANN）

当文档数量达到百万级以上时，逐一计算相似度效率过低。近似最近邻检索的思路是：不追求绝对最近邻，而是找到足够近的结果，以换取速度。

主流的ANN算法包括：

算法	原理	特点
HNSW	多层跳表图，从上层粗搜到下层精搜	查询速度快，内存占用大，Milvus默认使用
IVF	先聚类，仅搜索最近的几个簇	精度可控，适合超大规模
PQ（乘积量化）	压缩向量维度，降低内存消耗	节省内存，精度有所损失

如果你能说出HNSW的核心参数，如ef_construction（建图时的搜索宽度，值越大图质量越高但建图越慢）和M（每个节点的邻居数，值越大图越密集但内存占用越大），面试官会认可你具备实际调参经验。

4. 向量数据库如何选择？Milvus、FAISS、Qdrant各自适合哪些场景？

面试官常会问：“你们项目用了什么向量数据库？为什么选择它？”

三者对比

	FAISS	Milvus	Qdrant
类型	库（Library）	数据库（Database）	数据库（Database）
部署方式	嵌入应用进程	独立服务，支持分布式	独立服务，轻量级
持久化	需自行实现	原生支持	原生支持
适合规模	百万级以下	亿级	千万级
运维成本	低（无额外服务）	中（需部署集群）	低（单节点起步）
生产环境	适合原型验证	适合大规模生产	适合中小规模生产

通常的应对方式是：先说明你的选型理由，再提及你了解其他方案的优缺点。例如：“选择Milvus，因为生产环境需要多副本部署和持久化，FAISS不支持分布式，而Qdrant当时的生态还不够成熟。如果只是做Demo，我会用FAISS，速度快。”

5. 纯向量检索存在哪些问题？为何需要混合检索？

面试官常会问：“你们项目用的是纯向量检索还是混合检索？为什么？”这是RAG面试的高频考点。

纯向量检索的三大问题

① 精确匹配不足——用户搜索“RFC 7231”时，向量检索可能返回“HTTP协议规范”等语义相关但未提及“RFC 7231”的文档，因为它依赖语义相似度而非精确匹配。

② 专业术语召回率低——例如搜索“K8s的HPA怎么配置”，向量检索可能找到的是“Kubernetes自动扩缩容”相关内容，而实际包含HPA配置细节的文档反而排名靠后。专业术语的向量表示与口语描述的向量表示可能相距甚远。

③ 专有名词遗漏——产品名、人名、缩写等，向量检索容易遗漏。

混合检索 = 向量检索 + 关键词检索

混合检索同时执行两路检索：

• 向量检索：捕获语义相关的文档（如“数据库优化”与“SQL调优”能够匹配）
• 关键词检索（BM25）：捕获精确匹配的文档（如“RFC 7231”能够精确命中）

两路结果合并后，实现优势互补。

合并策略：RRF（Reciprocal Rank Fusion）

最常用的合并方法，公式如下：

RRF_score(d) = Σ 1 / (k + rank_i(d))

k通常设为60，rank_i(d)表示文档d在第i路检索中的排名。排名越靠前，贡献的分数越高。

def rrf_merge(vector_results, bm25_results, k=60):scores = {}for rank, doc in enumerate(vector_results):scores[doc.id] = scores.get(doc.id, 0) + 1 / (k + rank + 1)for rank, doc in enumerate(bm25_results):scores[doc.id] = scores.get(doc.id, 0) + 1 / (k + rank + 1)return sorted(scores.items(), key=lambda x: x[1], reverse=True)

核心要点：能清晰说明纯向量检索的三个问题，以及混合检索为何能解决这些问题，合并策略使用RRF。这才是面试官希望看到的深度。

6. 重排序（Rerank）是什么？为何检索后还需要重排序？

面试官可能会问：“你已经使用了混合检索，为什么还需要重排序？检索结果不够好吗？”

检索与重排序的区别

检索是粗筛——从海量文档中快速捞出Top-20，速度快但精度有限。使用向量相似度或BM25进行打分，这种打分是近似的，不一定能准确反映真实相关性。

重排序是精排——对Top-20的候选结果重新计算相关性分数，使用更精确的模型（通常是Cross-Encoder）逐一打分，将真正最相关的结果排到前面。

为什么检索的打分不够准确？

向量检索使用的是Bi-Encoder：将问题和文档分别编码成向量，再计算相似度。由于问题和文档在编码时互不知晓对方的存在，因此只能评估“大致相关”。

重排序使用的是Cross-Encoder：将问题和文档拼接后输入模型，模型可以同时看到双方内容，从而做出更精确的相关性判断。代价是速度较慢——Cross-Encoder无法预计算，每个（问题，文档）对都需要单独计算，因此只能针对少量候选进行精排。

重排序的效果

在实际项目中，重排序带来的提升非常显著：

指标	检索后（无重排序）	重排序后
Top-5召回率	71%	89%
Top-3准确率	65%	84%

常用重排序模型

模型	特点
BGE-Reranker (bge-reranker-v2-m3)	中文效果优秀，开源免费
Cohere Rerank	API调用，效果好，以英文为主
bce-reranker-base_v1	中文场景，轻量级

实践中的标准流程是：“检索是粗筛快捞，重排序是精排提准。检索使用Bi-Encoder速度快但精度有限，重排序使用Cross-Encoder速度慢但精确。先通过检索从百万级文档中捞出Top-20，再通过重排序精排后取Top-5，这是生产环境的标准配置。”

7. 文本块（Chunk）如何分割？分割过大或过小分别有哪些问题？

面试官可能会问：“你们的Chunk策略是如何设计的？Chunk大小设为多少？为什么？”这是判断你是否具备实际RAG项目经验的关键问题。

分割过大的问题

信息稀释——一个Chunk中包含过多内容，检索时真正相关的部分被其他无关内容淹没，导致相似度分数降低，排名靠后。

分割过小的问题

上下文丢失——一个完整的论述被分割成碎片，检索出的片段可能断章取义，大模型拿到后无法理解完整含义，生成质量下降。

三种主流Chunk策略

① 固定长度分割——最简单的做法，每512个Token切一块。优点是简单，缺点是不考虑语义边界，可能将一句话切成两半。

② 递归分割——按段落→句子→字符的优先级递归切割，尽量在自然边界处断开。这是生产环境中最常用的方案。

from langchain.text_splitter import RecursiveCharacterTextSplittersplitter = RecursiveCharacterTextSplitter(chunk_size=500,chunk_overlap=200,# 相邻 Chunk 重叠 200 字符separators=["nn", "n", "。", "！", "？", "；", "，", " ", ""])

③ 语义分割——使用嵌入向量计算相邻句子的语义相似度，在语义断点处进行分割。理论上效果最好，但计算量较大，生产环境中使用较少。

重叠（Overlap）的作用

相邻Chunk之间重叠一部分文本，可以避免关键信息正好在切割点处被截断。重叠量通常设为Chunk大小的10%-20%。

不同文档类型的处理策略

文档类型	处理策略
Markdown	按标题层级分割，保留标题层级信息
PDF	先解析表格和图片，再按段落分割
代码	按函数或类分割，保留完整代码块
FAQ	每个问答对作为一个Chunk，不拆开

实战经验：能够清晰说明Chunk大小的权衡（过大导致信息稀释，过小导致上下文丢失），以及重叠量的作用。最好能结合实际调参经历，例如“将Chunk大小从1000降到500后，召回率提升了15%”。

8. 嵌入模型如何选择？中文场景应选择哪种？

面试官可能会问：“你们使用了哪种嵌入模型？为什么选择它？与OpenAI的ada-002相比如何？”

选型维度

选择嵌入模型需考虑三个维度：语言支持、向量维度、检索效果（MTEB排名）。

中文场景主流模型

模型	维度	特点
bge-large-zh-v1.5	1024	中文效果最佳，开源，可本地部署
bge-m3	1024	多语言支持，支持稠密+稀疏+多向量三种检索
text-embedding-3-large (OpenAI)	3072	效果好，但API调用有成本，中文效果不如bge
text-embedding-3-small (OpenAI)	1536	价格较低，效果够用，英文场景首选

维度越高越好吗？

并非如此。维度越高，表达能力越强，但存储和检索成本也随之增加。1024维是当前性价比最优的选择，3072维的检索效果提升有限，但存储成本增加3倍。

选型建议：“中文场景选用bge-large-zh，因为它在MTEB中文榜单上排名靠前，且开源可本地部署，无需调用API。如果是英文场景或对延迟要求不严格，OpenAI的嵌入更便捷。”

9. RAG的幻觉问题如何处理？

面试官常会问：“RAG检索到了正确信息，但大模型还是编造了不存在的内容，怎么办？”幻觉是RAG项目面临的最大工程挑战，也是面试中的必问问题。

幻觉的两种类型

① 内在幻觉——检索结果中包含正确信息，但大模型生成的内容与检索结果相矛盾。例如，检索结果中显示“准确率91%”，但大模型回答“准确率95%”。

② 外在幻觉——大模型生成了检索结果中没有的内容。例如，检索结果只提到了A，但大模型自行编造了B。

六种幻觉处理策略

1、提示词约束——在提示词中明确要求“只能基于检索结果进行回答，检索结果未包含的信息不要编造”。

2、输出自校验——大模型生成回答后，再次使用大模型检查：回答中的每一条信息是否都能在检索结果中找到依据？找不到的依据标注为“未验证”。

VERIFICATION_PROMPT = """请检查以下回答是否每一条都能在参考资料中找到依据。对于每条声明，标注： 有依据 / 无依据 / 部分依据回答：{answer}参考资料：{context}"""

3、引用标注——要求大模型在回答时标注每条信息的来源Chunk，便于人工核查。

4、降低温度——将temperature设为0.1-0.3，降低大模型的随机性，减少“编造”倾向。

5、检索结果与生成结果的对齐——生成回答后，将回答与检索结果进行相似度对比。如果回答中存在大段内容与所有检索结果都不相关，则很可能存在幻觉。

6、兜底回答——当检索结果的相似度均低于设定阈值时，直接回答“未找到相关信息”，而不是让大模型强行编造。

工程要点：不要只说“使用了提示词约束”，要说明你采用了哪几种策略组合及其效果。例如“提示词约束 + 输出自校验 + 降低温度，幻觉率从30%降至12%”。

10. RAG检索效果不佳如何优化？

面试官可能会问：“你们RAG项目的检索准确率是多少？效果不理想时你是如何优化的？”这是考察工程经验的关键问题，没有标准答案，但需要清晰阐述优化思路。

优化思路：从链路的每一步寻找问题

文档处理阶段——PDF表格提取准确率是否足够？图片中的文字是否进行了OCR处理？不同格式（PDF/Word/Markdown）分别采取了哪些适配措施？

Chunk阶段——Chunk大小是否合理？是否针对不同文档类型调整了参数？重叠量设置了多少？

检索阶段——使用了纯向量还是混合检索？Top-K设为多少？是否加入了重排序？

生成阶段——提示词如何编写？幻觉问题如何解决？

四种高级优化策略

① 查询改写——用户的问题可能表述不清或过于简短，先使用大模型将其改写成更适合检索的查询语句。

原始问题：怎么调优？改写后：RAG系统中向量检索准确率低，有哪些优化方法？

② 多路召回——对同一问题使用多种方式进行检索：原始问题检索、改写后问题检索、提取关键词检索、拆分子问题检索，最后合并结果。

③ 父子（Parent-Child）检索——检索时使用较小的Chunk（实现精确匹配），返回时使用较大的Chunk（保留上下文）。具体操作：小Chunk建立向量索引用于检索，每个小Chunk关联一个父Chunk，检索命中后返回父Chunk的完整内容。

④ 上下文窗口扩展——检索到一个Chunk后，将其前后的Chunk也一并返回，确保上下文完整。

实践效果：能够说出实际使用过的优化策略及其量化效果。例如“加入重排序后，Top-5召回率从71%提升至89%”、“混合检索相比纯向量检索，在专业术语场景下准确率提升了25%”。

11. Agentic RAG是什么？与普通RAG有何区别？

面试官可能会问：“你了解Agentic RAG吗？它与普通RAG有什么区别？”

普通RAG的局限性

普通RAG采用固定流程：用户提出问题后，仅检索一次，然后生成回答。如果首次检索结果不佳，它不会自行纠正，而是直接生成回答。就像一个不会反思的人，错就错到底。

Agentic RAG：让RAG自行决定如何检索

Agentic RAG将Agent的规划能力引入RAG——大模型自行判断需要检索哪些数据源、检索结果是否足够。如果不够，便换个角度重新检索。

	普通RAG	Agentic RAG
检索次数	固定1次	动态，由大模型决定
检索策略	固定流水线	大模型自主选择
结果不理想	直接生成	更换策略重新检索
复杂问题	容易答偏	可拆解为子问题分步检索
Token消耗	低	高（需多次推理）

Agentic RAG的工作流程

用户问题 → Agent规划：这个问题需要检索什么？ → 第一次检索 → 结果不够？ → Agent判断：换个查询再检索 → 第二次检索 → 结果够了？ → Agent判断：够了，生成回答

核心要点：Agentic RAG适用于复杂知识问答场景（如法律、医疗、金融），简单问答使用普通RAG即可，无需过度设计。能够说出这一判断，面试官会认可你具备工程判断力。

12. 大厂真实面试追问汇总

以下是各大厂在RAG方向的真实追问整理汇总。

检索策略类

Q：你们的混合检索权重如何调整？向量检索和BM25各占多少？

两种常见做法：一是手动调整权重（向量0.7 + BM25 0.3），在验证集上测试出最佳比例；二是使用RRF合并，不设权重，依赖排名融合，更稳健。生产环境推荐RRF，因为不同查询的最佳权重差异较大，固定权重效果不一定好。

Q：Top-K设为多少？设得过大或过小分别有哪些问题？

设得过小（K=3）：可能遗漏相关文档，召回不足。设得过大（K=20）：过多无关信息干扰大模型，增加幻觉风险和Token消耗。通常K=5-10是比较好的平衡点，加入重排序后，可先用K=20检索再通过重排序取Top-5。

Q：如果用户的问题非常模糊，检索效果不理想，怎么办？

查询改写：使用大模型将模糊问题改写成更具体的检索查询。多路召回：同时使用原始查询、改写后查询、提取关键词分别检索，再合并结果。追问确认：如果问题过于模糊，Agent可先通过追问澄清用户需求。

工程落地类

Q：RAG系统的端到端延迟如何优化？

优化链路包括：使用vLLM部署推理服务（减少大模型推理延迟）、复用KV Cache（相似问题不重复计算）、采用流式输出（用户无需等待全部生成完成）、压缩提示词（减少Token数量以降低延迟）、优化HNSW索引（将向量检索延迟控制在50ms以下）。

Q：文档更新后，向量索引如何更新？

三种策略：全量重建（简单但速度慢，适合日级更新）、增量更新（仅重新嵌入变更的文档，适合实时更新）、双写（新文档同时写入旧索引和新索引，切换时实现零停机）。

Q：RAG的Token成本如何控制？

提示词压缩：裁剪检索结果中的冗余内容。上下文窗口管理：仅保留与当前问题相关的历史信息。模型路由：简单问题使用小模型，复杂问题才使用大模型。缓存：相同或相似问题的检索结果可缓存复用。

场景设计类

Q：设计一个面向10万用户的RAG知识库系统，你会如何设计？

可从五个维度展开：数据层（文档解析→Chunk→嵌入→向量库 + ES双写）、检索层（混合检索 + 重排序，Top-20检索 + Top-5精排）、生成层（vLLM部署 + 提示词模板 + 幻觉约束）、工程层（Redis缓存热点查询、异步处理文档更新、监控检索准确率和幻觉率）、安全层（文档权限隔离、提示词注入防御、敏感信息过滤）。

写在最后

RAG已成为大模型领域不可回避的话题。字节、阿里、百度、腾讯等公司的面试官，不会仅仅询问“你做过RAG吗”，而是会进一步追问“检索策略如何设计的”“混合检索为何优于纯向量检索”“重排序解决了什么问题”“幻觉如何处理”——这些都不是记忆概念就能通过的。

本文已系统梳理RAG面试的核心知识点：

• 基础层：RAG是什么、为什么需要、完整链路的七步流程
• 检索层：向量检索原理、混合检索策略、重排序、Chunk分割、嵌入模型选型
• 优化层：六种幻觉处理策略、四种检索效果优化方法、Agentic RAG进阶
• 工程层：延迟优化、成本控制、索引更新、系统设计

这些知识点并非孤立存在，面试时需要将它们串联起来。面试官询问“你们RAG怎么做的”时，你不能只回答“用了Milvus + LangChain”，而应从检索策略设计、Chunk参数调优、混合检索 + 重排序、幻觉处理、延迟优化五个维度展开，才能获得高分。