RAG 面试知识手册

检索增强生成 · 从原理到工程落地的完整学习文档
依据「卡码笔记 · RAG 系列」11 篇文章知识整理 · 2026 年 9 月

知识框架总览（先看这一节，建立全局观）

本手册的知识骨架是一条主线：「为什么需要 → 怎么搭 → 怎么优化 → 怎么排障 → 怎么评估 → 怎么答」。

学习路线建议：第一次学习按章节顺序通读（第 1→2→3→4→5 章是地基，必须先懂）；复习时按「链路 → 排障 → 优化 → 评估」的面试追问顺序自测；最后用第 11 章的高频八问做模拟问答。

第 1 章 为什么需要 RAG

一句话定位：RAG 不是大模型能力的升级，而是大模型的「外置数据库」——让模型在回答时能检索自己的 cheat sheet，有据可依。

1.1 从一个真实的困境说起

公司有几千份内部文档（产品手册、操作规范、历史项目经验、客户合同），想做一个 AI 问答系统。直接用大模型，第一轮测试效果不错，但很快发现四个绕不开的问题：

• 模型对公司内部文档一无所知，回答全靠「编」；
• 产品文档上周刚更新，模型说的还是老版本内容；
• 回答很流畅，但无法知道真假、无法追溯来源；
• 文档加载进 Prompt，token 成本高到无法接受。

这不是模型能力不够，而是大模型作为技术的根本性天花板——RAG 就是为突破这些天花板而诞生的。

1.2 大模型的四大局限 ⭐必背

（1）幻觉问题（Hallucination）

大模型本质是概率语言模型，生成每个 token 时做的是「预测下一个最可能的词」，而不是「从知识库里查询正确答案」。它不知道答案时不会说不知道，而是生成一个「听起来最合理」的答案——可能完全是捏造的，但语气坚定、格式工整，难以判别真假。企业场景里，它会以可信的方式传播错误信息，危害远比「回答错误」更严重。

（2）私有知识问题

大模型在公开数据上训练。内部文档、客户合同、产品手册、会议记录它从未见过。把文档全塞进 Prompt 的方案不可行：文档量到几百份、几千份时，token 成本和上下文长度成为瓶颈，且模型在极长上下文里注意力严重稀释，对中间内容利用率极低。

（3）知识更新问题

模型训练有截止日期，通常落后现实 6 个月到 1 年。价格变了、政策修订了、新对手出现了，模型全不知道。每隔几个月重训模型更新知识，在成本和时间上都不可接受。

（4）可追溯性问题

模型无法告诉你「这句话来自哪份文档的第几页」。法律、医疗、金融等对准确性要求极高的场景，没有来源引用的答案不可接受。

1.3 RAG 是怎么应对的 ⭐必背

RAG 全称 Retrieval-Augmented Generation（检索增强生成）。核心思路：在让模型回答之前，先去知识库检索出最相关的内容，作为上下文一起喂给模型，让模型「看着资料」回答。

1.4 适用与不适用场景 ⭐高频

适合 RAG 的场景：

• 知识密集型问答：企业知识库、产品手册问答、法律法规查询——事实准确性要求高、内容量大、需要来源追溯；
• 内容频繁更新的业务：新闻摘要、竞品分析、政策解读——知识库持续接入实时数据，模型本身不动；
• 长尾事实查询：「公司在上海的办公地址」「合同甲方是谁」——答案藏在特定文档里，必须检索。

不适合 RAG 的场景：创意生成、强推理任务、模型训练数据已良好覆盖的稳定领域——这些场景加 RAG 只是增加延迟和成本，没有实质收益。

1.5 常见误区

• 「RAG 能根治幻觉」——错。能显著缓解，无法根治：检索质量差时模型仍会「补充生成」，也可能在正确资料上做出错误推理。RAG 降低幻觉概率，不消灭幻觉根因。

1.6 面试怎么问

• Q：为什么有了大模型还需要 RAG？ 答：大模型有幻觉、私有知识盲区、知识时效性、无法溯源四大局限；RAG 在回答前先检索外部知识库，把相关片段注入上下文，让模型「看资料回答」，针对性缓解以上问题。
• Q：RAG 能解决幻觉问题吗？ 答：能显著缓解但不能根治——检索结果可作事实锚点、答案可附来源核查；但检索质量差时模型会补充生成，也可能在资料上错误推理。
• Q：什么场景用 RAG、什么场景不用？ 答：适合知识密集、频繁更新、需溯源的场景；不适合创意生成、强推理和训练数据已覆盖的稳定领域（只增加延迟和成本）。

第 2 章 RAG 完整链路拆解

一句话定位：RAG 不是一个算法，而是一条工程流水线。离线侧解决「知识怎么进去」，在线侧解决「知识怎么找出来、怎么用起来」。

2.1 链路总览 ⭐必背

离线阶段（把知识存进去）：

1. 文档加载：PDF / Word / 网页 / Markdown / 数据库记录 / 邮件，不同格式需不同解析方式。解析质量直接影响整个系统的上限——扫描件或排版混乱的 PDF 会带来噪声，「垃圾进，垃圾出」。
2. 文档处理（清洗与预处理）：去页眉页脚、无意义格式符号、重复内容；识别并保留标题结构；过滤表格乱码、图片占位符。这是工程量最大、最容易被低估的部分。
3. 切片（Chunking）：清洗好的文档切成更小的 chunk。整篇文档做检索单元会导致粒度太粗（相关内容被淹没）或上下文太长（放不进模型 / 注意力被稀释）。这是设计决策最多的环节。
4. 向量化（Embedding）：每个 chunk 经 Embedding 模型转成高维浮点向量，代表语义。关键约束：用户 Query 和文档 chunk 必须用同一个 Embedding 模型，两者才在同一语义空间，相似度计算才有意义。
5. 存元数据：chunk 来自哪份文档、哪一页、创建时间等。支撑「只看最近三个月的文档」这类过滤需求。
6. 存入向量数据库：Milvus / Weaviate / Chroma / Pinecone 等，同时向量与元数据分别存储。核心能力是 ANN 近似最近邻搜索，毫秒级找到 top-K。

在线阶段（找出来 + 用起来）：

1. Query 处理（可选）：Query 改写（口语化问题转检索友好形式、复杂问题拆成子问题分别检索）、Query 扩展（同义词扩展提高召回覆盖面）。
2. 检索（Retrieval）：Query 向量化后与库内向量做相似度计算（通常余弦相似度），召回 top-K（K 常取 3-10）。进阶做混合检索：向量检索（语义相似）+ 关键词检索（BM25 精确匹配）两路合并。
3. Rerank 精排：用 Cross-Encoder 模型对 (Query, Chunk) 对打分重排，只保留最相关的几条。最常见也最有效的优化之一，代价是多一次模型推理延迟。
4. 上下文构建（Context）：最终 chunk + 元数据（来源、页码）按格式拼装 Prompt。Prompt 结构通常包含：系统指令（区分指令与资料、要求资料不足时明确说明）、参考资料（带来源标注）、用户问题。
5. 生成（Generation）：LLM 基于上下文生成回答。Prompt 要有明确引导——优先依据资料回答，不依赖参数知识，并要求标注来源。

2.2 链路的核心认知 ⭐必背

• 每个环节都影响质量，但影响方式不同：Chunking 决定「能不能检索到相关内容」；Embedding 决定「语义理解是否准确」；Rerank 决定「top 结果是否真的最相关」；Prompt 设计决定「模型能否正确利用上下文」。优化 RAG 本质是找到当前系统的薄弱环节，不是无差别调参。
• 离线在线必须一致：Embedding 模型、文本清洗方式，离线建索引怎么做，在线就必须怎么做。A 模型建索引、B 模型做查询，向量空间不同，相似度计算完全失效。
• 检索的目标是精准，不是全面：top-3 高质量 chunk 通常优于 top-20 混杂结果。上下文越长，注意力越分散，信噪比越低。

2.3 常见误区 ⭐

2.4 面试怎么问

• Q：请描述完整的 RAG 链路。 答：分两段——离线：文档加载 → 清洗预处理 → Chunking → Embedding 向量化 → 存入向量数据库（同时存元数据）；在线：Query →（可选改写）→ Query 向量化 → 向量检索召回 top-K →（可选混合检索、Rerank 精排）→ 拼装 Context + Prompt → LLM 生成 → 输出带来源引用的答案。
• Q：哪些环节最影响效果？ 答：离线侧最关键是 Chunking 策略（检索粒度）和 Embedding 选型（语义理解质量）；在线侧最关键是 Prompt 设计；文档质量是前提。
• Q：Embedding 模型离线在线需要一致吗？ 答：必须一致。不同模型的向量空间不同，相似度计算会完全失效。

第 3 章 切片策略 Chunking

一句话定位：Chunking 是 RAG 里最「不起眼」却影响深远的设计决策——糟糕的 Chunking 会让后面所有优化努力都打折扣。

3.1 核心矛盾 ⭐必背

类比：把 500 页教材撕成复习卡片——切太细，每张卡片上下文不完整；切太粗，要找的那句话藏在一堆无关文字里。

• chunk 太小：单个片段语义不完整、孤立一句话缺乏上下文（例：「是的，这种做法符合规范。」——符合什么规范？）；同时 chunk 数量膨胀，索引变大、检索变慢。
• chunk 太大：话题太多、与问题相关度被稀释；无关内容占用上下文窗口、注意力难聚焦；chunk 越大向量表示越「平均化」，语义越模糊，检索精准度越低。

3.2 四种主流切分策略 ⭐必背

3.3 Overlap：被低估的关键参数 ⭐

• 问题：重要信息恰好落在两个 chunk 边界（前半句在 chunk 1、后半句在 chunk 2），单独命中任何一侧都是一半，答案会出错。
• 做法：相邻 chunk 保留重叠内容。例：chunk 512 token、overlap 64 token，则 chunk 2 的前 64 token 与 chunk 1 的后 64 token 完全相同。
• 效果：边界信息在两个 chunk 都有备份，命中哪个都能拿到完整上下文。
• 代价：索引体积增大（重叠内容存两次）、检索结果可能重复。一般推荐 overlap 为 chunk 大小的 10%~20%。

3.4 chunk 大小经验值（没有通用答案，需按业务效果调整）

3.5 策略选择决策框架 ⭐

• 文档有清晰结构（章节、标题、条款）→ 结构感知切分；
• 普通散文、无明确结构 → 递归字符切分（配好 chunk size 和 overlap）；
• 质量要求极高、话题切换频繁 → 语义切分（付计算成本）；
• 快速验证原型 → 固定长度够用（上线前换掉）。

3.6 面试怎么问

• Q：你们项目里 chunk 是怎么切的？ 答：先说策略及原因 → 再说参数（chunk size、overlap）→ 最后说如何评估调整。示例话术：「我们的文档是有章节结构的产品手册，所以用结构感知切分，按二级标题划分。每个 chunk 控制在 600 token 以内，overlap 设了 80 token。后来发现部分技术规格内容跨段落，把 overlap 调大到 120 token 后，相关问题的召回率有明显提升。」
• Q：chunk 过大过小分别有什么问题？ 答：过小——语义不完整、缺上下文、向量语义模糊、索引膨胀；过大——Context 噪声多、注意力分散、向量是多话题混合的平均、语义匹配变差。两个方向都直接影响生成质量。
• Q：为什么要设置 overlap？ 答：防止重要信息落在 chunk 边界被割裂，通过相邻 chunk 共享一段内容，保证边界信息在两侧都能被完整检索到。

第 4 章 Embedding 详解

一句话定位：Embedding 不是把文字变成数字的简单编码，而是把语义压缩进可计算的空间——让相似的意思在空间里相互靠近。

4.1 Embedding 是什么 ⭐必背

• 将文本（或图片、音频）映射到高维向量空间的技术。一个句子变成几百到几千个浮点数的数组（维度常见 384、768、1536 维）。
• 关键不在数字本身，而在空间位置：语义相似的文本向量距离近，不相关的距离远。核心承诺：用空间距离表达语义相似度。
• 向量检索的本质：Query 向量化后，计算它与所有文档向量的距离，找最近的几个。

4.2 Embedding 不是生成文本，是压缩语义 ⭐高频辨析

• 生成式大模型（GPT、Claude）：目标是输出文字。
• Embedding 模型：输出是向量表示，把语义压缩到固定维度的数组里——保留语义信息，丢掉格式和措辞细节。同一语义换不同说法，好模型给出的向量应非常接近——这是语义搜索能跨越措辞差异（「飞机」vs「民用航空器」）的根本原因。

4.3 模型选型四维度 ⭐必背

4.4 中文 vs 通用场景

• 分词边界：中文没有天然空格分词，通用模型对中文语义捕捉明显弱于专门训练的中文模型。
• 专业术语：法律条款、医疗术语、金融名词，通用模型难以精准表达语义关系。
• 评估基准：看 MTEB（Massive Text Embedding Benchmark）中文 Retrieval 子任务榜单；开源中文模型中 BGE 系列（BAAI/bge-large-zh-v1.5、bge-m3 等）和 E5 系列表现较出色。
• 双语需求：bge-m3 专门针对多语言检索优化，适合中英双语文档。

4.5 Embedding vs Rerank ⭐⭐最高频

两者是流水线关系：Embedding 快速召回候选池 → Rerank 精排过滤出最终上下文。

4.6 常见误区 ⭐

4.7 面试怎么问

• Q：Embedding 模型怎么选？ 答：四个维度——语言场景（中文优先 BGE/M3E）、输入长度（token 上限决定 chunk 上限）、向量维度（768 起步）、任务类型（非对称/对称检索最优模型不同）。
• Q：Embedding 和 Rerank 有什么区别？ 答：Bi-Encoder 分别独立编码、可离线预计算、毫秒级百万量级召回、适合粗筛；Cross-Encoder 拼接联合输入、深度交互打分、精度更高但需逐对推理、只适合少量候选精排。流水线关系：粗筛召回 → 精排过滤 → 进 Context。

第 5 章 向量数据库

一句话定位：向量数据库解决一个传统数据库根本没有设计来解决的问题——在海量高维向量中快速找到相似的那些。

5.1 解决的核心问题 ⭐

100 万个 768 维向量中找与 Query 向量最相似的 top-5：

• 暴力搜索：逐一计算余弦相似度再排序，普通服务器需几百毫秒到几秒——实时对话不可接受；向量到 1000 万、1 亿时耗时线性增长，无法用于生产。
• 向量数据库要解决的核心问题：在海量高维向量中，毫秒级找到最相似结果。

5.2 为什么不能用 MySQL 做向量检索 ⭐⭐高频

• 功能层面：传统关系库的查询是精确匹配 / 范围扫描（如 WHERE age > 25 AND city='北京'），靠 B-Tree / Hash 索引快速定位行；而向量搜索问的是「哪些向量和查询向量最接近」——是高维连续空间里的几何问题，B-Tree/Hash 对此完全无效。
• 性能层面：即便用 pgvector 等扩展支持向量，大规模场景下全量计算复杂度 O(N)，远不如专用向量库通过 ANN 索引把复杂度降到近似 O(log N)。

5.3 ANN：在速度和精度之间取平衡 ⭐必背

ANN（Approximate Nearest Neighbor，近似最近邻搜索）：预先构建索引结构，检索时只访问一小部分向量。「近似」= 不保证绝对最近邻，但实践精度通常 95%+（用 recall@K 衡量），速度提升是数量级的。

HNSW（分层可导航小世界图）

• 结构：顶层少量节点形成「高速公路」，底层全量节点形成「街道网络」；检索从顶层入口进入，沿邻居边导航逐层下降，像 GPS 导航越来越精细。
• 优点：查询极快、精度高；是 Milvus、Qdrant、Weaviate 等主流向量库的默认索引。
• 缺点：构建索引内存占用较大。
• 超参数：M（每个节点最大连接数）、efConstruction（建图搜索深度）——越大精度越高，但内存和构建时间成比例增加。不是越大越好，要找精度/速度/内存的平衡点。

IVF（倒排文件索引）

• 结构：先对全量向量做 K-Means 聚类分「货架」；检索先找最近的几个货架，只在货架内精细查找。
• 优点：内存占用低，适合超大规模数据集。
• 缺点：Query 落在两个货架边界时可能漏掉相关结果（边界效应）。

5.4 向量数据库的附加能力 ⭐

• 元数据过滤：向量附带结构化元数据（来源、时间、部门、类型），检索时叠加条件——「语义相关 + 业务过滤」的组合查询。
• 混合检索（Hybrid Search）：同时跑向量搜索和关键词搜索，用融合算法（如 RRF，Reciprocal Rank Fusion）合并两路结果。对中文专业术语场景尤其有用——专有名词语义表示弱，必须靠关键词精确匹配。
• 向量更新和删除：知识库持续更新，索引也要对应更新；不同产品支持成本差异大，选型要考虑业务更新频率。

5.5 主流选型 ⭐

选型决策：几十万向量以内 → Chroma 或 pgvector 足够；百万以上、需要元数据过滤和混合检索 → Milvus / Qdrant；云端托管免运维 → Pinecone。

5.6 常见误区 ⭐

5.7 面试怎么问

• Q：为什么不用 MySQL 做相似检索？ 答：两层——功能上，B-Tree/Hash 索引无法支持高维几何相似度问题；性能上，pgvector 全量计算 O(N) 无法满足毫秒级检索，专用向量库用 HNSW/IVF 把复杂度降到近似 O(log N)。
• Q：向量数据库为什么能加速召回？ 答：核心是 ANN 预建索引避免全量计算。以 HNSW 为例：分层可导航图从顶层稀疏图快速导航、逐层定位，只访问极少数节点即得近似最近邻，快几个数量级；代价是「近似」，但 95%+ 的 recall 满足 RAG 需求。

第 6 章 RAG 优化思路全景

一句话定位：RAG 优化没有万能药——先诊断问题出在哪个环节，再选择对应手段；「加个 Rerank 就搞定」很多时候是拿锤子找钉子。

6.1 优化框架：四大类 ⭐必背

• Query 侧：让问题更适合被检索；
• 检索侧：改善召回质量；
• 精排侧（Rerank）：把真正相关的排到前面；
• Context / 生成侧：改善喂给 LLM 的上下文。

6.2 Query 侧优化 ⭐

• Query 改写（Query Rewrite）：检索前先用 LLM 处理用户问题——扩展同义词、修正表述、补全隐含条件。例：「这个合同能退吗」→「合同解除条款、退款政策、合同撤销条件」多个角度检索，覆盖率明显更好。
• Multi-Query 多角度查询：一个问题生成多个版本分别检索，结果合并去重。例：「我们产品的 SLA 是多少」→ 展开「服务等级协议内容 / 故障响应时间 / 可用性承诺 / 赔偿条款」四路检索，召回率显著提升。

6.3 检索侧优化 ⭐

• 混合检索（Hybrid Search）：向量检索擅长语义，但专有名词、精确匹配（人名、产品型号、法规编号）不如关键词准确。混合检索同时跑向量检索 + BM25，用 RRF（Reciprocal Rank Fusion） 融合：文档在两路排名都靠前则融合分数高，只在一路靠前则打折。RRF 对超参数不敏感、实现简单、效果稳定，是工程首选。
• 元数据过滤（Metadata Filtering）：相似度检索叠加结构化条件（「只搜 2024 年之后的文档」「只搜合同类」）。不改变检索算法，但大幅缩小范围——既提精度又降开销。

6.4 精排优化：Rerank ⭐⭐

• 位置：向量检索召回 top-K 之后，Cross-Encoder 对每个 (Query, Chunk) 对精细打分、重排，只保留真正高相关的 top-N 给 LLM。
• 核心价值：向量检索是独立编码，无法完整捕捉 Query 与文档的深度语义关联；Cross-Encoder 能看到完整交互，打分更精准。
• 成熟组合：混合检索 + Rerank 是工程上最成熟的检索优化组合——两路各召回候选 → RRF 融合 → Cross-Encoder 精排 → 最终只有 3-5 条高质量 chunk 进 Context。
• 什么时候该加 Rerank：Recall@K 已经足够好（相关内容确实被召回），但答案精准度不高——问题在排序不在召回。
• 什么时候不急着加：Recall@K 本身很低，相关内容根本没被召回——加 Rerank 没有意义，先解决召回问题。

6.5 Context 侧优化 ⭐

• 父子块检索（Parent-Child Retrieval）：解决 Chunking 经典矛盾——小 chunk 利于精准匹配但上下文不完整，大 chunk 上下文完整但检索精准度差。做法：建两级索引——用小 chunk（子块）做检索，命中后返回包含它的大 chunk（父块）给模型。例：2000 字文章按段落切 5 个 400 字子块做索引，命中后传整篇文章或更完整的部分。
• Context 压缩（Context Compression）：用 LLM 阅读召回的 chunk，提取与 Query 高度相关的句子、丢弃无关内容，再拼最终 Context。显著减噪，但多一次 LLM 调用的延迟和成本，适合准确性要求极高、延迟容忍度较高的场景。

6.6 初学者优化方法论 ⭐⭐必背

1. 先建立 baseline，做好评估：用 Recall@K + 答案质量指标（LLM 打分或人工评估）建立可量化基线。没有基线就无法判断优化是否有效。
2. 优先解决「能不能找到」，再解决「找到了对不对」：Recall@5 低先优化召回（换 Embedding、调 Chunk 策略、加混合检索），而不是先加 Rerank。
3. 每次只改一个变量：同时改 Chunk 大小、Embedding 模型和 Rerank，永远不知道哪个起了作用。
4. 按成本/收益排优先级：混合检索成本低覆盖广，通常是性价比最高的第一步；Query 改写、Rerank 增加延迟成本，按业务 SLA 决定。

6.7 面试怎么问

• Q：你们 RAG 系统做了哪些优化？ 答：按 Query 侧 / 检索侧 / 精排侧 / Context 侧分类，说清每个优化针对的问题、前后效果变化和取舍。示例：「我们发现 Recall@5 在 60% 左右，先引入混合检索，Recall@5 提升到 78%；再加 Rerank，答案精准率提升了约 15%。」有数据有逻辑才是好回答。
• Q：混合检索怎么实现？两路结果怎么融合？ 答：向量检索用 Embedding + 向量库；关键词用 BM25（Elasticsearch 或向量库关键词功能）；融合用 RRF——文档在两路的名次取倒数相加得融合分、重排。RRF 对超参不敏感、实现简单，工程首选。

第 7 章 长文档与代码检索

一句话定位：检索单位 ≠ 返回单位；相关 ≠ 可用。可用 = 完整 + 当前 + 有权限。结构不能断、版本不能错、权限不能漏。

7.1 三大硬问题 ⭐必背

「按 512 token 切 + overlap + 向量检索」适合原型，不适合真实系统：

• 固定切片会把标题和正文、函数签名和函数体拆开（结构不能断）；
• 不记录分支与提交，可能拿旧代码回答（版本不能错）；
• 不在检索前做权限过滤，受限内容可能进入候选集（权限不能漏）。

7.2 长文档：按标题树建层级 ⭐

• 需求文档通常是「章节 → 小节 → 条款 → 表格」的层级。子块里只有「退款周期为 7 个工作日」，适用范围却写在父标题「企业版年付客户」里——只返回子块答案缺条件，返回整篇噪声和 token 太多。
• 所以不能只保存文本，还要保存它在标题树中的位置，如：产品手册 / 计费规则 / 企业版 / 退款政策。这条路径既能参与检索和 Rerank，也能在命中后帮助找到父章节、相邻条款和表格说明。

7.3 代码：按 AST 切分，不能按字符硬切 ⭐

• 代码的自然边界不是句号和换行，而是模块、类、函数、方法、语句块。固定切片从函数中间切开，chunk 里可能只有实现没有函数名/参数/返回类型，或只有调用点没有被调用函数的定义。
• 做法：先用解析器生成语法树，再按 AST 节点切分。Tree-sitter 可为源码构建具体语法树并支持文件编辑后的增量更新。
• 工程中通常保留：函数/方法签名、注释和函数体；所属类、模块、文件路径和符号全名；起止行号、语言、导入关系和被调用符号；仓库、分支、提交哈希与内容哈希。
• AST 负责「不把结构切坏」，但不解决所有检索问题：README、配置、SQL、错误日志仍要用对应的结构解析器或文本切分策略。

7.4 Parent-Child 两级节点：找得准 + 读得懂 ⭐必背

• Child：函数、短条款、小段落——负责 Embedding、关键词召回、Rerank；
• Parent：类、章节、完整规则——负责最终返回给模型补齐上下文；
• Document：文件或整篇——跨章节任务才按需向上扩展。

每个 Child 保存 parent_id。命中 Child 后不是机械返回整篇文档，而是根据问题取父节点、标题路径、必要的相邻节点。

父级扩展是预算决策，不是固定动作：

• 30 行的函数可以返回整个函数；3000 行的类只补签名、字段、目标方法和直接依赖；两页的章节可返回完整章节，几十页的章节只补标题路径和相邻条款。
• 设三个门槛：父块最大 Token、允许扩展的层级、相邻节点数量。超预算时优先保留定义、约束、输入输出和直接依赖，不要粗暴截断末尾。

7.5 版本与权限必须进索引 ⭐⭐

代码不是静态文本：同一路径在 main、功能分支和历史 commit 上可能完全不同。索引至少保存：

{
  "repo": "payment-service",
  "path": "src/refund/RefundService.java",
  "symbol": "RefundService.apply",
  "branch": "feature/refund-v2",
  "commit": "a1b2c3d",
  "parent_id": "class:RefundService",
  "acl": ["team:payment"]
}

原则：先过滤（版本/路径/ACL），后相似度召回。 如果先召回再删权限不匹配的结果：受限内容仍可能进入候选缓存、Rerank 服务或调试日志；且删除后候选数量不足，召回质量突然下降。访问控制要在检索边界生效。

7.6 在线检索链路（可落地版本）⭐

1. 从会话或 IDE 获取 repo + branch/commit + user/tenant；
2. 解析 Query，识别符号名、文件名、错误码和自然语言意图；
3. 先做版本、路径和 ACL 过滤；
4. 同时跑向量检索与 BM25，合并候选；
5. 在 Child 粒度 Rerank（避免大父块稀释相关度）；
6. 根据 parent_id 取父级、标题路径或必要的相邻节点；
7. 去重并按 Token 预算组装 Context，附带路径、行号和 commit 作为引用。

易错点：第五、六步最容易写反——先在小块上排序，再向父级扩展。如果先把所有 Child 展开成大块再 Rerank，相关信号会被大量父级文本冲淡，延迟也会上升。

7.7 落地与评估 ⭐

• 最小方案 baseline：结构化切分 + Child 混合检索 + Parent 补全 + 版本/ACL 前置过滤。不要一开始就加调用图、摘要树和复杂 Agent。
• 评估集专门覆盖五类问题：跨小节答案、精确符号查找、同文件不同分支、历史 commit、无权限访问。
• 专有指标：父级补全正确率（命中 Child 后是否拿到正确父节点）、版本错误率（是否引用了目标 commit 之外的内容）、越权召回率（目标必须是 0）、Context 有效率（进入上下文的 token 中有多少真正支持答案）、索引新鲜度（代码更新到可检索之间的延迟）。
• 增量更新：用 commit + path + content_hash 判断增删改，只重建受影响节点及父子关系——否则每次全量重建，代码库一大成本和更新延迟失控。

7.8 知识拓展四问 ⭐

• 有了 AST 切分还需要关键词检索吗？ 需要。函数名、类名、错误码、配置键和路径是精确符号，BM25 或符号索引通常比纯向量更稳；自然语言描述和业务意图交给向量检索，两路召回后统一 Rerank。
• Parent-Child 和 overlap 有什么区别？ Overlap 只缓解相邻切片的边界断裂，不知道标题、类和函数的真实父子关系；Parent-Child 是显式结构关系，可跨多个子块补回完整父级，但索引和存储更复杂。
• 代码依赖是不是全部展开进 Context？ 不是。调用图会迅速扩散；先返回目标符号，再按问题补一跳直接依赖，只有测试失败分析、跨模块重构等任务才逐层扩展并设深度与 token 上限。
• 多个分支会不会让索引膨胀？ 会。常见做法：长期保留默认分支和活跃分支，历史版本按需构建或设过期策略；相同内容按内容哈希去重，但版本、路径和 ACL 关系不能丢。

第 8 章 Agentic RAG

一句话定位：混合检索/Rerank 解决「这一次怎么查得更准」；Agentic RAG 解决「该不该查、查几次、查什么、不够时怎么办」——系统知道自己为什么查、还缺什么、什么时候算查完。

8.1 演进路径：四个阶段 ⭐必背

演进对比：传统——路径写死、检索 1 次、带错误结果继续生成；Advanced——写死更多优化、固定若干次、依赖预设策略；自适应——分类器或模型判断、0 到多次、评估后改写补充检索；Agentic——Agent 按目标和状态决定、动态次数、换 Query 换工具补证据或拒答。

8.2 Agentic RAG 解决什么问题 ⭐必背（与混合检索/Rerank 不同层）

• 一个 Query 装不下复杂问题：多子问题整句向量化，每个方向都查不准 → 拆解分别找证据；
• 第一次检索错不会自救：传统 RAG 只能在错误候选集里挣扎 → Agent 评估证据后重写 Query / 扩范围 / 换源 / 拒答；
• 不同问题要不同数据源：文档库 / 数据库 / 网页 / 业务 API → Agent 在多个受控工具间路由；
• 不是所有问题值得检索：「把上一段改口语化」直接回答，避免白跑延迟；
• 多跳问题：后一次检索依赖前一次结果，预写死的 Query 做不到。

8.3 核心原理：五个角色 ⭐必背

1. 规划与路由：判断复杂度——直接回答 / 单次检索 / 多步拆解；
2. 检索工具：向量 / BM25 / 数据库 / 网页 / API，各自能力清晰；
3. 状态记录：子问题、已查来源、候选证据、冲突点、剩余预算；
4. 证据评估：相关性、完整性、来源可靠性、相互一致性；
5. 停止与生成：证据够 → 带引用回答；不够且预算尽 → 拒答或请用户补充。

运行循环：理解目标 → 决定是否检索 → 拆子问题 → 选源 → 执行检索 → 评估证据 → 不够则改写/换工具/继续，足够则整合/标来源/生成【递进 = ReAct 落地】。

反思不能只靠模型拍脑袋：生产要加确定性规则——最少几类证据 / 命中版本 / 引用回原文 / 数值来自结构化数据 / 最大轮数 / 耗时费用上限。Agent 负责动态决策，规则负责兜底。

示例（对比 2025/2026 差旅政策 + 上海特殊规定）：识别三个证据槽位 → 分别生成 Query 并行检索 → 检查版本号 / 生效日期 / 适用组织 / 来源权限（不只看相似度）→ 缺 2025 版查归档库、来源冲突核对正式发布记录 → 齐全后做差异比较，每条结论带回来源。

8.4 关键辨析：Agentic RAG ≠ 多 Agent ⭐高频

单 Agent + 几个工具 + 状态机 + 证据检查已经是 Agentic RAG。只有职责边界稳定（不同权限/不同模型）才拆多 Agent；多 Agent 带来通信、上下文复制、错误传播、调试成本。先跑稳单 Agent。

8.5 落地权衡 ⭐

代价：路径动态难预测、多轮调用延迟波动、成本随轮数涨、调试要看完整决策轨迹、多数据源逐工具鉴权。

六条守则：限制循环（最大步骤/超时/Token 预算）、工具要窄（用途清晰 Schema 稳定）、权限前置、证据可回放、失败可降级（退回固定 RAG/澄清/拒答）、分层评估。

适用场景：适合多跳推理、多子问题拆解、知识多源分散、高证据完整性要求、问题模糊需澄清；不适合（固定 RAG 更划算）FAQ 单跳、数据源单一命中率高、首字延迟严格、Workflow 可完成。

升级顺序：先做好传统 RAG（文档切片检索评估）→ 加路由与纠错 → 最后开放 Agent 循环。基础召回差就套 Agent = 更贵更慢地找不到。

第 9 章 排障诊断方法论

一句话定位：答案不好 = 检索崩了（没找到/找错了）或生成崩了（找到没用好）。不先定位，所有优化都是治标不治本。

9.1 检索侧五类问题 ⭐必背

9.2 生成侧四类问题 ⭐必背

9.3 系统诊断三步法 ⭐⭐必背

1. 第一步·分流：手动查 top-K 是否含正确答案 → 含但答错 = 生成侧；不含 = 检索侧。
2. 第二步·检索侧定位：Recall@K 量化；相似度分数普遍低 = Embedding 空间不匹配；分数高但内容无关 = 领域理解偏差。
3. 第三步·生成侧定位：把正确 chunk 手动构造 Prompt 喂模型 → 能答对 = 检索问题；答不对 = Prompt / 模型能力问题。

经验值：Recall@5 低于 70% 说明检索侧有明显问题，优先优化。

9.4 面试怎么问

• Q：RAG 答不准怎么排查？ 答：先看 top-K 证据分流检索/生成侧，再用 Recall@K 等指标量化，针对性单变量调整。
• Q：如何评估召回效果？ 答：构造评估集（已知有答案的问题 + 正确 chunk），计算 Recall@K（K 常取 5 或 10）；Recall@5 < 70% 需优先优化检索侧。

第 10 章 评估体系与指标

一句话定位：检索侧保证能找到，生成侧保证用得好。没有评估的优化 = 拿锤子找钉子。离线指标是过程指标（方向盘），线上采用率是结果指标（目的地）。

10.1 为什么必须有评估体系

• 无法量化优化效果（提升 5% 还是 50%？哪些场景变差了？）；
• 无法对比不同方案（混合检索 vs Rerank 哪个适合业务？只能猜）；
• 无法发现退化（加了新功能，老场景效果有没有变差？）；
• 面试答不上（「感觉更好了」不是工程师的回答）。

10.2 检索侧四大指标 ⭐⭐必背

例：知识库有 3 个 chunk 含正确答案，top-5 含其中 2 个 → Recall@5 = 2/3 ≈ 66.7%，Precision@5 = 2/5 = 40%。

工程平衡：先用较大 K（20-50）保 Recall → Rerank 把 Precision 拉回来 → 最终 3-5 条高质量 chunk 进 LLM。

10.3 生成侧：RAGAS 四维度 ⭐⭐必背

RAGAS（Retrieval Augmented Generation Assessment）是基于 LLM 的自动化评估框架，已成 RAG 生成评估事实标准。

四指标关系：Context Recall + Context Relevancy = 检索质量（从生成角度看）；Faithfulness + Answer Relevancy = 生成质量。Context Recall 低，其他指标再高也没用（关键信息根本没检索到）；Context Relevancy 低会拉低 Faithfulness 和 Answer Relevancy（噪声干扰生成）。

Faithfulness 示例：上下文「年假 10 天，工龄满 3 年增加到 15 天」，答案多编了「满 5 年 20 天」→ 3 条陈述中 2 条可推导 → Faithfulness = 2/3 ≈ 66.7%。

10.4 评估集构建 ⭐

评估集三要素：问题（Query）+ 标准答案（Ground Truth，可选）+ 相关文档片段（Relevant Chunks）。

工程实践：先用 LLM 生成快速搭框架 → 再人工构造核心场景 50-100 条 → 用日志采样持续扩大覆盖。

10.5 离线评估 vs 在线评估 ⭐

• 离线评估：测试集上跑指标、优化前后对比。优点：可控、可重复、成本低；缺点：测试集可能不代表真实场景。
• 在线评估：真实用户反馈。显式反馈（点赞/点踩/纠错）+ 隐式反馈（是否追问、是否复制、停留时长）。
• 关系：离线评估是必要条件，在线评估是充分条件。

10.6 线上采用率（Adoption）⭐⭐

强信号：复制率（复制次数/总回答次数）、点赞率、引用率——主动采用行为。

弱信号（规模大）：无追问率（需结合停留时长判断）、停留时长（3-10 秒可能是扫一眼，30 秒以上可能是认真阅读）、跳出率。

负向信号：重复提问率（换问法再问一遍）、点踩率、人工接管率。

综合采用率 =（复制次数 + 点赞次数 × 2 − 点踩次数 × 2）/ 总回答次数。点赞/点踩权重 ×2 是因为用户主动点击的成本比复制高，信号更强。

离线指标升但采用率降的常见原因 ⭐：

• 测试集偏差（测试集问题分布与真实用户不一致）；
• 延迟变长（加了 Rerank 和多轮检索，P95 从 2 秒涨到 5 秒，用户等不及）；
• 答案变长（把检索内容都塞进答案，用户看不完）；
• 语气变硬（Prompt 约束太强，答案变成「根据资料显示…」的八股文）。

10.7 评估的延迟与成本 ⭐

• RAGAS 各指标都需要 LLM 调用：Faithfulness 2-3 次、Answer Relevancy 1-2 次、Context Relevancy 每个 chunk 一次、Context Recall 1-2 次；评估一个答案可能额外 1-2 秒；评估 Token 可能是原问答的 4-8 倍。
• 分级评估策略（工程化回答模板）：高风险查询（约 5%，涉及金额/法律条款）→ 实时 RAGAS 全量评估，延迟 +2 秒可接受；中风险（约 20%）→ 实时 Faithfulness 单项，+500ms；低风险（约 75%）→ 只记日志离线评估，无额外延迟。
• 省钱方法：采样评估（每天随机 1%-5% 跑完整评估）、分级评估、只跑当前优化目标单项、用便宜模型做评估（如 GPT-4o-mini / Claude-Haiku，成本降 10 倍、准确率只降约 5%）。
• 工具：检索指标自写脚本或 ranx 库；RAGAS 用 ragas 库；实验跟踪用 LangSmith / Weights & Biases。

10.8 评估驱动的优化闭环 ⭐⭐必背

1. 建立 baseline：评估集上跑当前系统，记录所有指标作基准；
2. 定位瓶颈：Recall 低 → 先优化召回；Recall 高但 Precision 低 → 加 Rerank；Context Relevancy 低 → 改 Chunking 或减 top-K；Faithfulness 低 → 改 Prompt 约束；Answer Relevancy 低 → 检查 Query 理解和模型能力；
3. 针对性优化：每次只改一个变量；
4. 对比验证：新指标更好 → 采纳；更差或部分场景退化 → 回滚或继续调整；
5. 持续迭代：新问题加入评估集、定期重评、监控线上。

10.9 知识拓展精选

• Recall 和 Precision 哪个更重要？ 看场景：答不上代价高（医疗/法律）→ Recall 重要；噪声代价高（客服答错被投诉）→ Precision 重要。通常：大 K 保 Recall + Rerank 保 Precision，两头都要。
• RAGAS 依赖 LLM 判断会不会不准？ 会有偏差；在核心评估集上对比 LLM 评估与人工评估一致性，一致性高（85% 以上）就可信任 LLM 做大规模自动化。
• 评估集要多大？ 简单场景（FAQ 类）50-100 条可建可信 baseline；复杂场景（开放域）可能需 300-500 条。关键是有代表性，不是一味追求数量。

第 11 章 面试回答框架

一句话定位：面试官真正想听的不是技术名词，而是你有没有完整做过「发现问题 → 做出取舍 → 验证结果」这条工程链路。

11.1 项目面试的五大落点 ⭐必背

1. 业务目标：知识从哪来、为什么需要 RAG、不用 RAG 会出什么问题；
2. 完整链路：离线怎么建库，在线怎么检索、重排、拼接、生成；
3. 选型取舍：Chunk、Embedding、向量库、Top-K、混合检索为什么这么选；
4. 问题诊断：答案不准时，先区分检索没找到还是模型没用好；
5. 指标证据：用检索、生成、线上业务三层指标证明方案有效。

面试官会沿项目逐层下钻：简历「做过 RAG 项目」→ 业务（为什么需要）→ 链路（离线在线怎么串）→ 选型（参数为什么这样定）→ 排障（答案不准先查哪侧）→ 证据（哪些指标证明有效）。链路、选型、排障、指标是应用岗必答线；索引源码、Embedding 训练等底层细节知道原理和工程影响即可。拉开差距的不是背到多底层，而是必答区每一层都有项目证据。

11.2 通用回答五步法 ⭐⭐必背

结论 → 项目事实 → 方案取舍 → 指标证据 → 适用边界。

反面示例（「为什么加 Rerank」只答「Rerank 能提高准确率」）；正面示例：「我们先看评估集，发现相关 Chunk 多数已进入 Top-20，但真正能回答问题的片段经常排不到前 5，所以问题不在召回覆盖，而在候选排序。我们保留前面的快速召回，再用 Rerank 做精排，只把 Top-N 交给模型。代价是多一段推理延迟，所以候选数和 Top-N 是根据离线排序指标、端到端答案质量和 P95 延迟一起定的。」——有症状、有判断、有方案、也有代价。

11.3 高频八问要点 ⭐⭐必背

• Q1 为什么用 RAG：业务缺口 → RAG 能力 → 不选其他方案的原因。RAG 解决的是外部知识接入，不是给所有模型问题贴创可贴（固定格式用 Prompt，必要时才微调）。
• Q2 完整链路：离线建库 + 在线问答 + 质量控制（引用 / 拒答 / 权限 / 日志）。
• Q3 Chunk 多大：不报神奇数字，讲数字怎么来——文档结构 → 问题粒度 → 参数候选 → 评估结果。Overlap 只用来保护边界信息，不是越大越好（过大会重复召回、浪费上下文）。
• Q4 Embedding / 向量库怎么选：Embedding 看检索效果 + 部署约束（语言匹配、自有评估集 Recall、维度成本、合规）；向量库看规模 + 工程能力（数据量并发量、索引类型与延迟、持久化/扩缩容/高可用、元数据过滤/增量更新/多租户、运维成本）。
• Q5 为什么混合检索 + Rerank：混合检索补召回（产品型号、错误码、法规编号、人名等精确词向量可能漏；BM25 擅长关键词但不理解改写和近义），Rerank 提排序（找到了但真正有用的排得不够靠前）。主动说代价；「没有无条件标配，只有指标和约束下的选择」。
• Q6 答不准怎么排查：先看 Top-K 证据分流——没有 → 查解析/索引覆盖/Chunk/Embedding/召回策略；有但靠后 → 查融合/Rerank/Top-K/上下文噪声；有且位置合理仍错 → 查 Prompt 拼接/引用约束/上下文冲突/模型能力；知识库本来没有 → 拒答或转人工，不能逼模型编答案。
• Q7 做了哪些优化：只选 1-2 个讲透四件事——优化前症状、如何定位根因、为什么选这个方案、哪些指标变化。每次单变量。
• Q8 怎么证明有效：三层指标——检索侧（Recall@K / Precision@K / MRR / NDCG）+ 生成侧（忠实度 / 答案相关性 / 引用正确率 / 正确拒答率）+ 线上业务（任务成功率 / 转人工率 / P95 / 成本 / 越权风险）。

万能句式 ⭐：「优化前，评估集上的 [指标] 是 [基线]；定位到 [根因] 后，我们做了 [单一改动]，该指标变成 [结果]。同时 [延迟/成本/风险指标] 变化了 [真实数据]，所以最终选择 [上线/灰度/放弃]。」方括号必须换成项目真实数据；忘了数值就讲统计口径和大致区间，不能编。

11.4 面试里最容易暴露的四个问题 ⭐

11.5 只做过 Demo 怎么答 / 被问没负责的环节 ⭐

• 只做过 Demo：诚实说明边界——「做到离线 Demo，没有真实线上流量」，然后继续讲：如何构造测试问题和标准证据、对比过哪些方案、失败样本暴露了什么、上线还要补哪些监控/安全/容量工作。诚实讲清边界比虚构生产项目更像工程师。
• 追问没负责的环节：说明责任边界 + 讲你理解的接口和影响，不揽团队成果。例：「索引集群由基础设施同学维护，我负责检索策略和评估；我关注索引参数对召回、延迟和内存的影响，但没有改过底层实现。」

附录 A · 重点难点速查（考前必看）

1. 四大局限 ↔ 四大应对：幻觉→事实锚点（缓解非根治）；私有知识→自建知识库；时效→更新文档重建索引（与训练解耦）；溯源→引用来源。
2. 离线在线一致性铁律：Embedding 模型与清洗方式必须离线在线完全一致。
3. Chunking：太小语义不完整、太大信噪比低；四种策略（固定/递归/语义/结构感知）；overlap 10%~20%；经验值 256-512（对话）/ 512-1024（知识库）/ 1500-2000（长文摘要）。
4. Bi-Encoder vs Cross-Encoder：分别编码可预计算适合粗筛 vs 拼接联合更准但逐对推理只适合精排。
5. 为什么不用 MySQL：B-Tree/Hash 不支持高维几何相似度 + 全量 O(N) vs ANN 近似 O(log N)。
6. HNSW vs IVF：分层导航图快而准但内存大 vs 聚类货架省内存但有边界效应。
7. Rerank 该不该加：Recall 够好但精度差 → 加；Recall 本身低 → 先解决召回。
8. 优化顺序：先 baseline → 先解决「能不能找到」→ 单变量 → 按成本收益排优先级（混合检索性价比第一）。
9. 诊断三步法：查 top-K 分流 → Recall@K 量化 → 手动喂正确 chunk 验证生成侧；Recall@5 < 70% 优先修检索。
10. 评估核心数字：Recall@5 < 70% 有问题；综合采用率 = (复制 + 点赞×2 − 点踩×2)/总数；评估 Token 为原问答 4-8 倍；分级评估 5%/20%/75%。
11. 代码检索：检索单位 ≠ 返回单位；先过滤（版本/ACL）后召回；先 Child 排序再父级扩展；越权召回率必须为 0。
12. Agentic RAG：解决「该不该查、查几次、查什么、不够怎么办」；单 Agent + 工具 + 状态机 + 证据检查已经是；先跑稳单 Agent；基础召回差别套 Agent。

附录 B · 复习建议

• 第 1 遍（通读建框架）：按章节顺序读，重点记住每章「一句话定位」和 ⭐ 必背表格；配合思维导图 HTML 对照层级记忆。
• 第 2 遍（按面试线自测）：遮住答案，依次回答——完整链路两段式、Chunk 怎么切、Embedding vs Rerank 区别、为什么不用 MySQL、优化怎么排序、答不准怎么排查、评估用什么指标、高频八问。
• 第 3 遍（数字与易错点）：背附录 A 的 12 条速查；特别核对易错点——换 Embedding 必须重建索引、RAG 不能根治幻觉、FAISS 不是数据库、Context Recall 低其他指标再高也没用。
• 模拟表达：用第 11 章的五步法和万能句式，对自己的项目做一次完整口头复述；每个工具名后面都补上「解决什么问题、为什么适合」。