🚨 重要提醒
本文围绕 RAG（检索增强生成）系统的面试核心知识展开，涵盖从基础架构到生产优化的关键要点。关键词：RAG、Embedding、向量检索、BM25、Hybrid Search、Rerank、幻觉抑制、多轮对话、知识索引、低延迟架构。
1. RAG 系统概述
RAG，全称 Retrieval-Augmented Generation，中文通常叫“检索增强生成”。它的核心思想很简单：不要让大模型只依赖参数记忆回答问题，而是先从外部知识库中检索相关资料，再把检索结果和用户问题一起交给大模型，让模型基于真实资料生成答案。
一句话概括：
RAG = 先检索，再生成。
它主要用来解决大模型在企业私有知识、实时知识、专业知识场景中的不足，并尽可能降低幻觉。
2. RAG 系统的核心结构
一个标准 RAG 系统通常可以分为五个核心模块：
文档加载解析 ↓ 文本切分 Chunk ↓ 向量化入库 ↓ 检索召回 ↓ Prompt 组装与大模型生成可以记成一句口诀：
加载解析 → 文本分块 → 向量化入库 → 检索召回 → Prompt 组装生成
2.1 文档加载与解析
文档加载与解析模块负责接入原始数据，例如：
- Word
- TXT
- 网页
- 数据库
- 内部 Wiki
- 企业知识文档
这一阶段要做的事情不只是“读取文本”，还包括解析、去重、过滤无效内容、清洗脏数据，并把不同格式的原始文档转成可处理的文本。
RAG 效果好不好，源头数据质量非常关键。如果知识库本身是错的、旧的、重复的，后面的检索和生成都会被污染。
2.2 文本切分 Chunk
大文档不能直接整篇送去向量化，通常需要切成多个文本块，也就是 chunk。chunk 不能太大，也不能太小：
- 太大：一个向量里混入太多语义，检索精度会下降。
- 太小：上下文不完整，容易把一个完整语义切断。
常见切分策略包括：
- 固定长度切分
- 递归字符切分
- 语义切分
- 标题感知切分
生产环境中，切分时最好保留章节标题、文档来源、版本、生效时间等元数据。否则 chunk 脱离原文上下文后，语义会变得不完整。
2.3 向量化与向量库
向量化阶段会调用 Embedding 模型，把每一个 chunk 转成向量。随后将下面三类信息一起存入向量数据库：
- 向量
- 原始文本块
- 元数据
常见向量数据库或向量检索组件包括 Milvus、Chroma、FAISS 等。这一阶段通常属于离线预处理。知识库构建完成后，用户每次提问时不需要重新处理原始文档，只需要处理用户 query。
2.4 检索召回
用户输入问题后，系统会把问题也转成向量，然后在向量库中匹配相似度最高的文本片段。除了向量检索，也可以搭配关键词检索，例如 BM25。生产系统里经常使用混合检索，把语义召回和关键词召回结合起来。
2.5 Prompt 组装与生成
检索到相关上下文后，系统会把用户问题和参考资料一起组装成 Prompt，再交给大模型生成答案。此时模型应该优先基于检索资料回答，而不是自由发挥。实际系统中还会增加引用来源、答案校验、拒答策略等后处理机制。
3. RAG 的主流检索方式
RAG 的检索方式主要有四类：
- 向量检索
- 关键词检索
- 混合检索
- Rerank 重排序
面试中需要重点讲清楚它们的原理、优缺点和适用场景。
3.1 向量检索：语义检索
向量检索也叫稠密检索，核心是用 Embedding 模型把问题和文档都转成向量，然后计算向量相似度，例如余弦相似度或欧氏距离。它的优势是可以理解语义，不依赖字面关键词匹配。例如用户问“怎么申请退款”，文档里写的是“售后退费流程”，向量检索依然可能召回相关内容。
优点：
- 能召回语义相近但表达不同的内容
- 适合问答、总结、知识检索等语义场景
- 对自然语言提问比较友好
缺点：
- 对专有名词、数字、ID、编号等精确匹配效果较差
- 依赖 Embedding 模型质量
- 模型和业务领域不匹配时，召回效果会下降
3.2 关键词检索：BM25
关键词检索也叫稀疏检索，典型算法是 BM25。它基于词频、逆文档频率等统计信息，判断哪些文档包含了用户问题中的关键词。
优点：
- 对专有名词、编号、数字、实体匹配效果好
- 不需要向量模型
- 速度快，工程成熟
缺点：
- 不理解语义
- 对同义词、转述式提问不友好
- 用户表达和文档表达不一致时，容易召回不到
3.3 混合检索：工业界常用方案
混合检索通常会同时做两路召回：
向量检索 + BM25 关键词检索然后使用 RRF，也就是倒数排名融合，把两组结果融合排序，得到最终候选列表。
优点：
- 兼顾语义理解和关键词精确命中
- 召回质量更稳定
- 更适合生产环境
缺点：
- 计算量略大
- 需要维护两套检索链路
- 排序融合策略需要调参和评测
工业界落地 RAG 时，混合检索通常是更稳妥的选择。
3.4 Rerank：二次精筛
Rerank 不属于初次召回，而是检索之后的二次精筛。流程通常是：
先召回 Top-K 候选片段 ↓ 送入 Rerank 模型 ↓ 对“问题-文档块”做相关性打分 ↓ 选出最相关的 Top-N ↓ 送给大模型生成答案Rerank 的作用是过滤掉相关性低的片段，提升进入 LLM 上下文的质量，减少无效上下文干扰，同时节约 token。
面试中可以这样总结：
RAG 检索方式主要有向量语义检索和 BM25 关键词检索。生产环境常用混合检索，用 RRF 融合两者结果，再通过 Rerank 做二次筛选，把更高质量的上下文交给大模型生成答案。
4. RAG 如何缓解大模型幻觉
大模型幻觉主要有两类：
- 知识幻觉：模型参数中没有相关知识，于是编造事实、数据或引用。
- 推理幻觉：上下文中有资料，但模型理解错误、篡改内容或乱拼接。
RAG 不能 100% 消除幻觉，但可以最大程度抑制幻觉，把回答约束在检索资料范围内。
4.1 索引阶段：保证知识库质量
幻觉控制的第一步不是 Prompt，而是知识库本身。索引阶段需要：
- 清洗原始文档
- 去重
- 过滤无效内容
- 合理分块
- 补充元数据
- 保证知识来源可靠
如果知识库本身错误，RAG 只会让模型“基于错误资料认真回答”。
4.2 检索阶段：提升上下文相关性
检索阶段可以通过这些手段降低幻觉：
- 使用向量检索 + BM25 的混合检索
- 使用 Rerank 过滤无关片段
- 设置相似度阈值
- 检索不到相关内容时直接拒答
一个关键原则是：
没有可靠资料就不要强行回答。
4.3 Prompt 阶段：约束模型行为
Prompt 中需要明确要求模型：
- 只能基于检索上下文回答
- 上下文没有的信息要说明不知道
- 关键结论需要输出引用来源
- 不要编造文档中不存在的内容
这一步不是万能的，但能减少模型自由发挥。
4.4 生成后：事实校验
生成后可以做后处理，例如：
- 校验答案是否能被引用资料支持
- 检查引用是否真实存在
- 删除不合理引用
- 对高风险答案做人工审核
所以，RAG 抑制幻觉应该是全链路设计，而不是只靠某一句 Prompt。
5. 多轮对话中的上下文依赖检索
多轮 RAG 最大难点是：用户后续提问经常是省略式、指代式的。例如：
用户：BGE-M3 怎么做混合检索？ AI：BGE-M3 可以同时输出稠密向量与稀疏向量，再用 RRF 融合结果。 用户：那参数怎么调？如果直接拿“那参数怎么调？”去检索，向量模型并不知道“那”指的是什么，召回结果很可能很差。
5.1 核心方案：Query 重写
主流方案是 Query Rewrite，也就是结合最近几轮对话，让 LLM 把当前问题补全为完整查询。例如：
原始问题：那参数怎么调？ 重写后：BGE-M3 做混合检索时相关参数如何调优？然后拿重写后的 query 去检索知识库。
5.2 检索 query 和生成上下文要区分
这里有一个容易混淆的点：
- 检索阶段：用改写后的完整 query。
- 生成阶段：仍然给大模型原始对话历史和当前问题。
因为检索器本身不会记住历史，每次检索都是独立的，所以需要 query 重写。但大模型生成回答时，可以理解完整对话上下文，因此不一定要只看改写后的问题。
同时，多轮对话不能无限塞历史，需要做轮次截断或摘要压缩，避免上下文膨胀和噪声增加。
6. 噪声知识库中的一致性与可信度机制
生产环境的知识库经常不干净，常见问题包括：
- 版本混乱：新旧文档并存，旧文档没有下线。
- 多源口径不一致：不同部门上传的文档说法不同。
- 脏数据：错误、残缺、复制改写的文档进入知识库。
- 缺少元数据：不知道来源、生效时间、权威等级。
一个常见错误做法是：把冲突文档全部丢给 LLM，让大模型自己判断谁对谁错。这很危险。模型可能会强行把冲突内容“合成”一个错误答案。
6.1 一致性和可信度的区别
一致性解决的是：
同一个业务事实，知识库内部不要互相矛盾。
可信度解决的是：
哪一份资料更值得相信。
一致性依赖版本管理、文档生命周期、冲突检测。可信度则依赖来源、时间、权威等级等元数据。
6.2 入库层：源头治理
入库阶段是最关键的一层，预防大于补救。每个 chunk 都应该绑定可信度相关元数据，例如：
- 版本号
- 生效时间
- 失效时间
- 来源权威等级
- 文档状态
- 所属部门
- 原始文档地址
可信度不是靠向量算出来的，而是来源、时间、版本和权威等级共同决定的。
入库时还需要做：
- 语义去重
- 冲突预检测
- 新旧版本管理
- 作废文档软删除
- 定期清理孤儿向量
例如文档更新时，旧切片不要直接物理删除，可以标记为失效；新版本切片重新入库。检索时默认过滤失效文档。
6.3 检索层：不要只看向量相似度
检索排序不能只看向量相似度。更合理的方式是：
最终检索分数 = 向量相似度分数 + 元数据可信度加权分新的、官方的、高权威的文档，即使向量相似度略低，也应该有机会排在前面。
检索层可以做：
- 元数据过滤下推到向量库
- 默认过滤作废和过期文档
- Rerank 阶段融合来源、时间、版本权重
- 对多个召回 chunk 做冲突检测
例如同时召回 2024 旧版规则和 2026 新版规则时，应优先采信新版规则，而不是让模型自己猜。
6.4 生成层：冲突处理
召回结果存在冲突时，可以按业务场景处理。
第一种：有明确权威优先级。例如企业制度、官方手册。Prompt 中应要求模型优先采信高权威、最新版本文档，旧版本仅作为参考。
第二种：多方观点并存，没有唯一标准答案。这种情况下不要让模型强行融合成一个统一结论，而是结构化列出多方观点，并附带来源、版本和时间。
第三种：冲突严重，无法判定。应该明确提示用户：检索资料存在矛盾，建议人工确认，必要时转人工处理。
一个生产级 RAG 系统，应该强制输出溯源引用，让每条关键结论都能追溯到来源文档。
7. 如何构建高质量知识索引
高质量知识索引的目标是：
该召回的能召回，不该召回的不召回。
它不是简单地把文档向量化入库，而是由源头数据、切分策略、向量模型、索引参数、评测迭代共同决定。
7.1 核心流程
构建高质量知识索引，可以从几个环节入手：
- 数据清洗与预处理：去除无关内容、广告、页眉页脚、重复段落，统一格式和编码。
- 切分策略调优：根据文档类型（技术文档、FAQ、长文章）选择合适的分块大小和边界策略，避免语义断裂。
- Embedding 模型选型：选择与业务领域匹配的 Embedding 模型，必要时进行微调。
- 元数据设计：为每个 chunk 附加来源、版本、时间、权威等级等结构化信息。
- 索引构建与调参：根据向量库特性（如 Milvus、Chroma）调整索引参数（如 HNSW 的 M、efConstruction）。
- 评测与迭代：建立评测集，定期评估召回率、准确率，根据反馈优化索引。
7.2 常见陷阱与优化点
- 陷阱 1：一刀切分块。不同文档类型（如 API 文档、FAQ、长文章）需要不同的分块策略。
- 陷阱 2：忽略元数据。没有元数据的 chunk 在召回后难以溯源和评估可信度。
- 陷阱 3：索引不更新。知识库更新
)
