3、RAG 全链路
Q3-1. 请描述一个完整的 RAG 流水线。
完整 RAG 一般分索引阶段和检索阶段。
索引阶段是：文档加载、清洗、切块、向量化、写入向量库，并补充元数据。检索阶段是：接收问题、必要时做 query 改写、检索召回、重排过滤、上下文组装、交给模型生成答案，最后再做引用、脱敏和格式化输出。
工程上真正难的通常不在“把模型接起来”，而在三件事：文档是否被正确解析，切块是否保留语义，检索结果是否真的对当前问题有帮助。线上效果差，大多数时候也是卡在这三层，而不是卡在最后那一轮生成。
常见追问：
- chunk 应该怎么切？
- metadata 应该存哪些字段？
- 为什么要加 rerank？
重要度：必刷（出现次数：3次） | 难度：中等
**考察点：**是否真正理解 RAG，而不是只会说“检索增强生成”。
对应章节：19 RAG检索增强生成 §1、RAG 简介；19 RAG检索增强生成 §2、RAG 文本处理核心知识
Q3-2. 文本切块应该怎么设计？有哪些常见坑？
切块的目标不是“切得均匀”，而是“尽量保留对检索有意义的语义单元”。
通常会结合固定长度、段落边界、标题层级和重叠窗口来设计。太大，会导致噪声多、命中不准；太小，会丢上下文，检索回来也无法回答。对于手册、FAQ、制度文档、图文混排 PDF，这些文档往往不能只按字符数切，还要结合版面结构、标题、表格和语义边界。
常见坑包括：切块过碎、忽略标题层级、重叠不足、纯 OCR 文本脏乱不清洗、表格内容被打散，以及把多个主题塞进一个 chunk 导致向量语义污染。
重要度：高频（出现次数：3次） | 难度：中等
**考察点：**RAG 基础功是否扎实。
对应章节：19 RAG检索增强生成 §2、RAG 文本处理核心知识；2-RAG 搭建企业私有&个人知识库 §2、知识库的概述
Q3-3. RAG 效果不好时，你会怎么排查？
排查时可按“检索前、检索中、检索后”三层展开。
- 检索前：看 query 是否表达清楚，是否需要改写、拆问、补充上下文。
- 检索中：看切块、Embedding、向量库索引参数、top_k、过滤条件、重排是否合理。
- 检索后：看拼给模型的上下文是否过长、是否有噪声、是否出现关键信息被淹没、生成提示是否要求“无依据就拒答”。
如果是企业知识库，还要额外查文档质量、版本是否最新、权限过滤是否误伤。很多所谓“模型不聪明”的问题，最后都能定位到文档解析脏、chunk 太碎、召回噪声大或者上下文组装差。
常见追问：
- top_k 是不是越大越好？
- 如何识别是召回问题还是生成问题？
- 什么是 Lost in the Middle？
重要度：必刷（出现次数：1次） | 难度：中等
**考察点：**排障能力、定位思路是否分层。
对应章节：19 RAG检索增强生成 §2、RAG 文本处理核心知识；19 RAG检索增强生成 §3、RAG 综合案例：智能运维助手
Q3-4. 混合检索、重排序和查询改写分别解决什么问题？
这三者解决的是三个不同层次的问题。
- 查询改写解决“用户问题表达得不够像检索语句”的问题。
- 混合检索解决“只靠稠密向量可能漏掉关键词命中”的问题。
- 重排序解决“召回了一批候选，但顺序还不够准”的问题。
真实项目里，尤其是制度、产品参数、订单字段、错误码这类知识，关键词常常非常重要，所以仅靠 dense retrieval 往往不够。比较稳的方案通常是“query 改写 + 稠密检索 + 稀疏检索 + rerank”，再结合 metadata 过滤做收口。
常见追问：
- 稠密检索和稀疏检索的区别是什么？
- Rerank 放在哪一层最合适？
- 混合检索会不会更贵？
重要度：高频（出现次数：1次） | 难度：中等
**考察点：**是否理解检索优化的职责分工。
对应章节：18 向量数据库与Embedding实战 §6、向量库的写入与检索；19 RAG检索增强生成 §2、RAG 文本处理核心知识
Q3-5. RAG 应该如何接入 Agent 执行链路？
RAG 接到 Agent 里，不能只理解成“先查一遍资料再回答”，更稳的做法通常是把检索能力做成 Agent 可按需调用的一环。
常见有三种接法：
- 前置检索：用户问题一进来先统一检索，再把证据交给 Agent 继续规划。
- 按需检索：把 Retriever / Search 封成工具，Agent 在需要事实依据时主动调用。
- 后置校验：先生成结果，再用检索做证据核对或引用补全。
真实项目里，通常更推荐“按需检索为主，前置检索为辅”。因为不是每一步都需要查知识库，有些步骤是规划、路由、参数确认或工具执行。把 RAG 做成可调用能力，能减少无效检索，也更适合多步任务。后置校验可以作为增强，但通常不适合作为主链路，否则会增加延迟，而且一旦前面已经跑偏，后面再校验修正成本会更高。
常见追问：
- 你了解生成过程中多次检索、自适应检索或 Agentic RAG 吗？它和“先检索一次再生成”有什么区别？
- 什么情况下应该从“一次检索”升级成“多轮检索 + 中途补检”？
重要度：高频（出现次数：1次） | 难度：中等
**考察点：**是否理解 Agentic RAG 的接入方式，而不是只会把 RAG 当成固定前置流水线。
对应章节：19 RAG检索增强生成 §1、RAG 简介；21 Agent智能体 §6、小结：Agent、Tool、Function Calling、RAG、MCP 的区别与联系
Q3-6. 为什么企业项目里的 RAG 必须重视权限、版本和引用？
因为企业知识不是“能查到就行”，而是“要查对、查对权限范围、还能追溯来源”。
权限上，向量检索必须做租户隔离、角色过滤、文档级或段落级权限控制，不能把安全寄希望于模型“自觉不回答”。版本上，索引和源文档要可追踪，文档更新后要知道哪些向量需要增量重建。引用上，如果答案不能回溯到原文片段，业务方很难建立信任，也不利于审计和复盘。
所以在企业里，RAG 不只是检索效果问题，更是数据治理问题。
重要度：中频（出现次数：1次） | 难度：中等
**考察点：**企业落地意识，不只停留在 Demo。
对应章节：2-RAG 搭建企业私有&个人知识库 §2、知识库的概述；19 RAG检索增强生成 §3、RAG 综合案例：智能运维助手
Q3-7. 什么是 Lost in the Middle？它对 RAG 设计有什么启示？
Lost in the Middle 指的是：上下文一长，模型往往更容易利用开头和结尾的信息，而把中间那部分关键证据“看见了但没用好”。
它对 RAG 的启示非常直接：不是把更多 chunk 塞进上下文就一定更好。如果中间噪声太多，真正关键的证据反而更容易被淹没。
因此，工程上通常采用以下处理方式：
- 先做 rerank 和过滤，再决定谁能进上下文。
- 尽量减少低价值片段，别把“可能相关”都塞进去。
- 重要证据优先放前面，必要时做摘要或结论前置。
- 对复杂问题采用分阶段检索，而不是一次性把大段材料全塞进去。
总结来说：长上下文不等于高质量上下文，RAG 的核心仍然是“把最有用的证据放到最容易被模型用到的位置”。
重要度：中频（出现次数：1次） | 难度：中等
**考察点：**长上下文理解能力，以及检索、重排、上下文组装之间的联动意识。
对应章节：19 RAG检索增强生成 §2、RAG 文本处理核心知识；19 RAG检索增强生成 §3、RAG 综合案例：智能运维助手
Q3-8. 有了超长上下文模型，还需要 RAG 吗？
多数场景下仍然需要，因为“能塞进去”和“应该塞进去”完全不是一回事。
超长上下文模型确实让长文理解、少量文档内推理变得更方便，但企业场景里更常见的问题不是“模型窗口不够大”，而是：
- 知识总量太大，没法每次都全塞。
- 长上下文成本和延迟都更高。
- 权限过滤、租户隔离、版本控制不能只靠窗口硬塞解决。
- 审计和引用追溯更适合通过检索链路来做。
所以更合理的理解通常是：长上下文扩大了可处理范围，但没有消灭检索的价值。 它更适合少量长文档分析、上下文整合和复杂推理；RAG 更适合海量知识缩圈、权限过滤、证据引用和持续更新。
如果压缩成一句话，可以概括为：长上下文不是 RAG 的替代品，更接近 RAG 的补充能力。
重要度：中频（出现次数：1次） | 难度：中等
**考察点：**是否理解“长窗口能力”和“检索系统价值”不是同一层问题。
对应章节：19 RAG检索增强生成 §1、RAG 简介；1-1 大模型认知与工程概览 §1、认识大模型
Q3-9. 复杂文档 RAG 或多模态 RAG 应该怎么做？
这类场景最大的坑，是把 PDF、扫描件、表格、图片、网页全都当成“普通纯文本”来处理。
更稳的做法通常是先把解析层单独看待：
- 先做版面分析、OCR、表格提取、标题层级恢复，而不是一开始就按字符切块。
- chunk 尽量按结构块切，比如标题、段落、表格、图注，而不是把一张表切成几段残缺文本。
- metadata 要保留页码、章节标题、文档版本、来源文件、坐标或结构位置信息，方便引用和追溯。
- 查询时必要时走多路召回，例如文本召回、表格召回、图片说明召回，再统一重排和组装。
如果是企业知识库，复杂文档 RAG 往往比“模型选型”更影响上限。因为解析错了、表格碎了、图文对应关系丢了，后面再强的模型也很难补回来。
常见追问：
- 为什么很多设备手册、制度 PDF 特别难做 RAG？
- OCR 准确率和最终问答效果是什么关系？
- 多模态 RAG 什么时候值得上，什么时候纯文本就够？
重要度：中频（出现次数：1次） | 难度：较难
**考察点：**是否意识到 RAG 不只是检索问题，还包括文档解析、结构恢复和引用追踪。
对应章节：19 RAG检索增强生成 §2、RAG 文本处理核心知识；2-RAG 搭建企业私有&个人知识库 §2、知识库的概述
Q3-10. 什么是 Agentic RAG？它和“一次检索后直接生成”有什么区别？
传统 RAG 更接近固定流水线：先检索一次，再把结果交给模型生成答案；Agentic RAG 则更接近一个闭环过程，模型或 Agent 会根据当前进展决定要不要检索、检索什么、是否改写 query、是否继续补检，甚至在发现证据不足时主动回头重查。
两者最大的区别，不在于“有没有检索”，而在于检索是不是被当成一个动态决策过程来管理。
- 传统 RAG：流程稳定、成本更可控、实现简单，适合单轮问答和大多数标准知识库场景。
- Agentic RAG：更适合复杂问题、多跳证据、需要自检补检的场景，但代价是链路更长、成本更高、失控风险也更高。
所以工程上通常不会一开始就上 Agentic RAG，而是先看 badcase 是否真的集中在这些问题上：
- 一次检索经常拿不到足够证据。
- 问题本身需要拆问、多轮求证或多源交叉验证。
- 生成前需要先判断“到底该查知识库、查网页，还是查业务系统”。
如果真的要落地 Agentic RAG，我一定会同时补上步数上限、预算限制、失败退出条件和可观测性，否则它很容易从“更聪明的检索”变成“更贵的随机游走”。
常见追问：
- 什么情况下应该坚持固定 RAG，而不是升级成 Agentic RAG？
- Agentic RAG 的收益通常体现在哪些 badcase 上？
- 如何防止多轮补检把延迟和成本拉得太高？
重要度：中频（出现次数：1次） | 难度：较难
**考察点：**是否真正理解 RAG 从固定流水线向智能检索闭环演进的边界和代价。