RAG 面试题
高频问题地图
- 什么是 RAG？
- 一个完整 RAG 系统流程是什么？
- RAG 主要解决什么问题？
- RAG 和微调有什么区别？
- 文档切割怎么做？
- 如何避免语义被切断？
- Embedding 如何选择和评估？
- 向量数据库如何选型？
- 向量检索和关键词检索有什么区别？
- Query Rewrite 的目的是什么？
- 什么是多路召回？
- Reranking 解决什么问题？
- 如何规避 RAG 幻觉？
- 如何评估 RAG 效果？
- 知识库如何动态更新？
核心概念速记
RAG（Retrieval-Augmented Generation）：检索增强生成，在 LLM 生成答案前先从外部知识库检索相关信息，注入上下文后让模型基于检索结果生成回答。
文档切割（Chunking）：把长文档切分成适合检索的小片段。关键考虑：切割粒度、重叠窗口、语义完整性。
Embedding：把文本转化为向量表示，用于语义相似度计算。选择时考虑维度、多语言支持、领域适配。
向量数据库：存储和检索向量的专用数据库，如 Milvus、Qdrant、Chroma、FAISS、pgvector。
Query Rewrite：对用户原始查询进行改写，提升检索命中率。包括同义词扩展、问题拆解、意图澄清。
多路召回：同时使用多种检索方式（向量检索、关键词检索、知识图谱检索），取并集或加权合并。
Reranking：对召回结果重新排序，用更精确的模型（如 Cross-Encoder）评估 query-doc 相关性。
Q1：什么是 RAG？一个完整 RAG 系统的流程是什么？
标准回答
RAG（Retrieval-Augmented Generation）是检索增强生成的缩写。核心思想是：在 LLM 生成答案之前，先从外部知识库中检索相关信息，把检索结果注入到模型的上下文中，让模型基于这些信息生成回答。这样做的好处是让模型能够回答训练数据中没有覆盖的问题，同时让回答有据可依、可溯源。
一个完整的 RAG 系统流程包含离线和在线两条链路。离线链路负责知识库建设：原始文档经过解析、清洗、切割成小片段，每个片段通过 Embedding 模型转化为向量，存入向量数据库。在线链路负责查询应答：用户输入问题后，先经过 Query Rewrite 优化查询，然后通过向量检索和关键词检索从知识库中召回相关片段，再经过 Reranking 精排，最后把排序靠前的片段作为上下文注入 Prompt，让 LLM 生成最终答案。
面试官追问
- 离线链路和在线链路各有哪些工程挑战？
- 如果用户的问题和知识库中的表述差异很大，RAG 怎么处理？
- RAG 的延迟主要在哪里？怎么优化？
工程化理解
离线链路的工程挑战在于文档解析的多样性（PDF、Word、HTML、表格、代码块各有不同的处理方式）、切割策略的选择（太大检索不准，太小上下文断裂）、Embedding 的批量生成和增量更新。在线链路的工程挑战在于检索延迟（向量检索 + 关键词检索 + Reranking 的总延迟）、上下文窗口管理（召回内容太多放不下）、以及结果质量的实时监控。通常在线链路的延迟目标在 1-3 秒以内，需要在检索精度和响应速度之间权衡。
常见误区
- 认为 RAG 就是"把文档塞进向量库"：忽略了文档解析、切割、Embedding、检索优化、Reranking、Prompt 工程等环节。
- 只关注检索环节，不关注生成环节：检索到的内容如何组织成 Prompt、如何引导模型基于检索结果回答，同样重要。
- 不做端到端评估：单独优化某个环节可能不会提升最终效果，需要端到端评估。
背诵版总结
RAG 是在 LLM 生成前先检索外部知识库的架构模式。完整流程分离线链路（文档解析→切割→Embedding→入库）和在线链路（Query Rewrite→检索→Reranking→Prompt 注入→生成）。RAG 的核心价值是让模型能回答训练数据未覆盖的问题，同时让回答有据可依。工程挑战在于文档处理的多样性、检索精度和延迟的平衡、以及端到端效果评估。
Q2：RAG 主要解决什么问题？和直接问 LLM 有什么区别？
标准回答
RAG 主要解决三个问题。第一是知识时效性：LLM 的训练数据有截止日期，无法回答训练之后发生的事件或信息。RAG 通过接入外部知识库，让模型能访问最新信息。第二是知识准确性：LLM 在训练数据未覆盖的领域容易产生幻觉，编造看似合理但实际错误的内容。RAG 让模型基于检索到的真实文档生成回答，大幅降低幻觉率。第三是知识可溯源：RAG 的回答可以标注信息来源，让用户验证答案的可靠性。
和直接问 LLM 的区别在于信息来源。直接问 LLM 时，模型只能依赖训练时学到的知识，如果问题超出训练范围，模型要么编造、要么拒绝回答。RAG 给模型提供了一个"参考资料"，让模型基于参考资料回答，而不是凭空生成。
面试官追问
- RAG 能完全消除幻觉吗？什么情况下 RAG 仍然会产生幻觉？
- 如果知识库本身有错误信息，RAG 会不会放大这个问题？
- RAG 和长上下文模型（如 128K/1M token 窗口）有什么关系？长上下文能替代 RAG 吗？
工程化理解
RAG 的工程价值在于让 LLM 应用能接入企业私有知识库。直接问通用 LLM 无法回答企业内部的文档、规范、流程等问题，RAG 让这些私有知识成为模型的参考资料。但 RAG 也有局限：检索质量直接影响生成质量，如果检索不到相关内容，RAG 的效果可能不如直接问 LLM。长上下文模型虽然可以塞入更多文档，但成本和延迟随上下文长度线性增长，不适合大规模知识库场景。
常见误区
- 认为 RAG 能解决所有 LLM 的问题：RAG 只解决知识相关的问题，推理能力、数学计算等问题 RAG 帮不上忙。
- 认为 RAG 一定比直接问 LLM 好：如果问题在 LLM 训练数据覆盖范围内，直接问可能更快更准。
- 忽略知识库质量的影响：RAG 的效果上限取决于知识库的质量，垃圾进垃圾出。
背诵版总结
RAG 解决三个问题：知识时效性、知识准确性、知识可溯源。和直接问 LLM 的区别在于信息来源：RAG 给模型提供外部参考资料，而不是让模型凭记忆回答。RAG 不是万能的，只解决知识相关的问题，效果上限取决于知识库质量。长上下文模型不能完全替代 RAG，因为成本和延迟随上下文长度线性增长。
Q3：RAG 和微调有什么区别？什么时候选 RAG，什么时候选微调？
标准回答
RAG 和微调是让 LLM 适应特定领域知识的两种不同方式。
RAG 通过检索外部知识库，在推理时把相关信息注入上下文，让模型基于参考资料回答。RAG 不改变模型权重，知识更新只需要更新知识库，不需要重新训练。
微调通过在领域数据上继续训练模型，让模型把领域知识"学进"权重里。微调后的模型在回答领域问题时不需要外部检索，但更新知识需要重新训练。
选择策略取决于场景。RAG 适合知识频繁更新的场景（如产品文档、内部规范），因为更新知识库比重新训练模型快得多。RAG 也适合需要引用来源的场景，因为检索结果本身就是来源。微调适合需要改变模型行为风格的场景（如输出格式、语气、领域术语），因为这些很难通过检索来实现。微调也适合知识相对稳定、查询频率极高的场景，因为推理时不需要额外的检索步骤。
面试官追问
- RAG 和微调能不能同时用？什么场景下需要两者结合？
- 微调后的模型还需要 RAG 吗？
- 微调的训练数据怎么准备？有什么质量要求？
工程化理解
从工程角度看，RAG 的优势是部署简单、知识更新快、可溯源。缺点是检索延迟增加、检索质量影响最终效果、上下文窗口限制了注入信息量。微调的优势是推理延迟低、不需要额外的检索系统、能改变模型行为。缺点是训练成本高、知识更新需要重新训练、可能出现灾难性遗忘。实际项目中，两者经常结合使用：用微调让模型适应领域术语和输出格式，用 RAG 提供最新的领域知识。
常见误区
- 认为 RAG 和微调是互斥的：两者可以结合，微调改变模型行为，RAG 提供动态知识。
- 认为微调能让模型"记住"所有训练数据：微调是参数更新，不是精确记忆，模型可能会遗忘部分训练内容。
- 低估微调的数据质量要求：微调对训练数据质量要求很高，噪声数据会导致模型表现下降。
背诵版总结
RAG 通过检索注入知识，不改模型权重，适合知识频繁更新和需要溯源的场景。微调通过训练改变模型权重，适合需要改变行为风格和知识稳定的场景。两者可以结合：微调让模型适应领域风格，RAG 提供动态知识。选择的核心权衡是知识更新频率、推理延迟要求和部署复杂度。
Q4：文档切割怎么做？Chunk 太大或太小会有什么问题？
标准回答
文档切割是把长文档切分成适合检索的小片段的过程。切割策略直接影响检索质量，是 RAG 系统中最关键的预处理环节。
常见的切割方式包括按固定长度切割、按段落/章节切割、按语义边界切割。固定长度切割最简单，但容易在句子中间切断，破坏语义完整性。按段落切割保留了文档的自然结构，但段落长度差异大，可能导致有些 Chunk 太大、有些太小。按语义边界切割通过检测语义变化点来确定切割位置，效果最好但实现复杂。
Chunk 太大会导致三个问题：检索时一个 Chunk 包含太多不相关信息，干扰模型判断；注入 Prompt 时占用过多上下文窗口，留给其他信息的空间减少；Embedding 向量被稀释，语义表达不够精确。Chunk 太小也会导致问题：单个 Chunk 缺乏足够上下文，模型无法理解其含义；检索时需要召回更多 Chunk 才能覆盖完整信息，增加检索和 Reranking 的开销。
通常工程实践中，Chunk 大小在 200-1000 token 之间，配合 10-20% 的重叠窗口来缓解边界切断问题。
面试官追问
- 重叠窗口的作用是什么？设置多大合适？
- 表格、代码块、图片怎么处理？能用同样的切割策略吗？
- 切割后怎么评估 Chunk 质量？有没有自动化评估方法？
工程化理解
工程中的文档切割需要处理多种文档格式。PDF 需要先解析为结构化文本，表格需要特殊处理以保留行列关系，代码块需要按函数或类切割而不是按行数切割。重叠窗口的作用是让相邻 Chunk 有共同内容，避免语义在边界处断裂，通常设置为 Chunk 大小的 10-20%。Chunk 质量评估可以通过人工抽检（检查 Chunk 是否语义完整）和自动化指标（Chunk 长度分布、去重率、检索命中率）来进行。
常见误区
- 认为切割策略可以一刀切：不同类型的文档（技术文档、法律文书、代码仓库）需要不同的切割策略。
- 忽略表格和代码的特殊处理：按行切割会破坏表格结构和代码逻辑。
- 不做切割效果评估：切割策略的好坏需要通过检索命中率和最终回答质量来验证。
背诵版总结
文档切割是 RAG 预处理的关键环节。切割方式包括固定长度、按段落、按语义边界。Chunk 太大导致信息稀释和上下文浪费，太小导致上下文断裂和检索碎片化。工程实践中通常 200-1000 token 配合 10-20% 重叠窗口。表格和代码需要特殊处理，不同文档类型需要不同切割策略。
Q5：Embedding 在 RAG 中起什么作用？如何选择和评估 Embedding 模型？
标准回答
Embedding 在 RAG 中的作用是把文本转化为向量表示，使得语义相似的文本在向量空间中距离更近。这支撑了 RAG 的核心能力——语义检索：用户的查询和知识库中的文档片段都被转化为向量，通过计算向量相似度（如余弦相似度）来找到最相关的文档片段。
选择 Embedding 模型需要考虑几个维度。维度数量：高维向量表达能力更强但存储和计算成本更高，通常 768-1536 维是常见范围。多语言支持：如果知识库包含多种语言，需要选择支持多语言的模型。领域适配：通用 Embedding 模型在特定领域（如医学、法律）可能表现不佳，需要在领域数据上微调或选择领域专用模型。推理速度：在线链路中 Embedding 生成是延迟的一部分，需要在精度和速度之间权衡。
评估 Embedding 模型主要看检索质量指标。Recall@K 表示在前 K 个检索结果中包含正确答案的比例，是最常用的评估指标。MRR（Mean Reciprocal Rank）衡量正确答案在检索结果中的排名，排名越靠前得分越高。实际评估时需要构建一个 query-document 标注数据集，用这个数据集对比不同模型的检索效果。
面试官追问
- 向量维度越高越好吗？维度选择有什么权衡？
- 用户查询和文档内容的表述差异很大时，Embedding 能处理吗？
- Embedding 模型需要定期更新吗？更新后存量向量怎么处理？
工程化理解
工程中 Embedding 的选择需要平衡精度、速度和成本。高精度模型（如大维度、大参数量）推理慢、成本高，不适合高频查询场景。向量维度还影响向量数据库的存储成本和检索速度。当知识库内容更新时，需要重新生成新增文档的 Embedding，但存量向量通常不需要全部重新生成，除非更换了 Embedding 模型。更换模型是一个高成本操作，因为所有存量向量都需要重新生成。
常见误区
- 认为 Embedding 模型越大越好：模型大小和检索效果不是线性关系，需要在目标数据集上实测。
- 忽略 Embedding 的领域适配问题：通用模型在专业领域的语义区分能力可能不足。
- 不做模型对比评估：不同 Embedding 模型在不同数据集上表现差异很大，不能只看论文排名。
背诵版总结
Embedding 把文本转化为向量，支撑 RAG 的语义检索能力。选择时考虑维度、多语言支持、领域适配、推理速度。评估指标主要是 Recall@K 和 MRR，需要在目标数据集上实测。工程中需要平衡精度和成本，更换 Embedding 模型是高成本操作。不同领域的文档可能需要不同的 Embedding 策略。