三、RAG 检索增强生成

RAG 是大模型应用落地的第一主战场，也是面试中最容易从概念一路深挖到线上 bad case 的模块。复习时按"链路完整性 → 检索质量 → 生成质量 → 评估与治理"的主线展开，每道题都准备好量级数字和真实取舍。

23. 什么是 RAG？它和微调分别在什么场景下使用？两者能不能结合？

必刷 · 基础

参考答案

RAG（Retrieval-Augmented Generation）指生成前先从外部知识库检索相关内容，拼入上下文再让模型作答。本质是把"知识"从模型参数外置到可更新的存储里，模型只负责理解和组织语言。

两者定位不同：

• RAG 适合知识问题：知识频繁更新（政策、价格、文档）、需要引用溯源、私有数据量超出上下文窗口、上线后要快速增删知识。改库即生效，无训练成本，幻觉相对可控；
• 微调适合行为问题：改变输出风格与格式、固化业务流程话术、领域术语理解（医疗、法律）、压缩 prompt 提升小模型表现。知识写进权重，更新需重新训练；
• 判断口诀：问"模型知道什么"用 RAG，问"模型怎么说话/怎么做"用微调。微调不适合灌频繁变化的知识——成本高、时效差、还易引发灾难性遗忘。

两者可以且经常结合：微调让模型更擅长"读检索片段答题"（如 RAFT 思路，训练时带干扰文档），RAG 负责供事实；此外 embedding 和 reranker 模型通常也要在业务语料上微调，这本身也是"微调 + RAG"的配合。

面试官可能追问

• 长上下文模型（128K/1M）会取代 RAG 吗？（不会：成本、检索精度、知识时效、Lost in the Middle，RAG 仍是主流）
• 微调过的模型还需要 RAG 吗？（需要，微调改变能力不保证事实准确，两者正交）

24. 画一下标准 RAG 系统的完整链路，离线（索引）和在线（问答）各包含哪些环节？

必刷 · 基础

参考答案

标准链路分离线、在线两条：

离线（索引管道）

1. 数据接入：文档源（OSS、Confluence、工单）监听与同步，增量/全量策略；
2. 解析：PDF/Office/HTML → 结构化文本，含表格、图片的版面分析；
3. 清洗：去页眉页脚、去重、格式归一化；
4. 切分（Chunking）：按语义/结构切块，附元数据（来源、章节、权限、时间）；
5. 索引化：Embedding 模型向量化写入向量库；同时建 BM25 倒排（Elasticsearch 或向量库自带）；
6. 质检：抽样验证解析与切分正确性，监控索引 lag。

在线（问答管道）

1. Query 预处理：改写（多轮指代消解）、纠错、意图/路由判断（要不要检索、检索哪个库）；
2. 多路召回：向量检索 + BM25，各取 top 20~50，辅以元数据过滤；
3. 融合与重排：RRF 融合后，用 cross-encoder（bge-reranker、Cohere Rerank）精排出 top 3~10；
4. Prompt 组装：system + 检索片段（带编号）+ 对话历史 + 问题，注意 token 预算；
5. LLM 生成：要求仅依据资料回答并标注引用；
6. 后处理：引用校验、敏感词、流式返回；
7. 反馈闭环：记录 trace（query、召回结果、答案），供评估与 bad case 归因。

面试官可能追问

• 哪个环节最容易成为效果瓶颈？（多数坏在解析和切分，而不是模型）
• 线上延迟预算怎么分？（检索全程控制在几百毫秒级，生成看 TTFT，rerank 常是第二大头）

25. 文档切分（Chunking）有哪些策略？chunk 大小怎么定？为什么不能简单一刀切 512？

必刷 · 基础

参考答案

常见策略从粗到细：

• 固定长度切分：按 token/字符滑窗，最简单，语义易截断；
• 递归分隔符切分：优先按段落 → 句子 → 词逐级降级（LangChain RecursiveCharacterTextSplitter 的思路），保持语义边界，是默认起点；
• 结构感知切分：按 Markdown 标题、代码 AST、PDF 版面切，块天然带主题；
• 语义切分：用 embedding 相邻句子相似度找断点，成本高、收益不稳定，作进阶选项；
• 父子块 / 小块检索（详见第 32 题）、QA 化切分（FAQ 库一问一块）。

大小经验值：通用文本 256~512 token、重叠 10%~20% 起步，再按内容类型分化：表格整块不切、法律条款按条、代码按函数。

不能一刀切 512 的原因：

1. 内容结构差异：表格切两半、字段和表头分离后基本不可检索；
2. 向量稀释：块越长主题越杂，embedding 表征被平均，召回精度反而下降；
3. 模型约束：块长必须和 embedding 模型 max_seq_len（常见 512）对齐，超了会被静默截断，尾部内容永远召不回；
4. 生成侧需求不同：检索要小块（准），生成要大上下文（全），单一尺寸只能顾一头。

正确做法是评估驱动：留出黄金评估集，对 chunk 大小做网格搜索，看 Recall@k 和最终答案质量，按文档类型分参数配置，而不是拍一个数。

面试官可能追问

• overlap 的作用是什么？设多少？（防止关键句恰好被切断，10%~20%，过大导致重复召回浪费预算）

26. 表格、图片、公式这类非纯文本内容，在 RAG 里怎么解析和检索？

高频 · 中等

参考答案

核心思路：万物转文本代理（text proxy）+ 元数据 + 必要时多模态。

解析

• 版面分析工具：Unstructured、marker、MinerU、PP-Structure 等，识别标题/段落/表格/图片区域；扫描件走 OCR 或视觉模型；
• 表格：输出 HTML/Markdown 保结构（合并单元格、多级表头最易丢），严禁转成流水文本；
• 图片：用 VLM（Qwen-VL、GPT-4o）生成描述性 caption，图表要求数值化描述；
• 公式：转 LaTeX 表示，可附加一句话文字解释辅助召回。

索引与检索

• 表格整块入库不切分；宽表可按行切，但每行重复拼接表头和主键列；
• chunk 内加入 LLM 生成的内容摘要前置（"本表是 XX 产品 2024 年 Q1 销量"），显著提升召回；
• 图片存 caption + 原图 URL，caption 向量化，命中后前端回显原图；
• 元数据（文档类型、章节路径、表格名）用于过滤和多路召回。

Trade-off：表格行级切分召回更准但索引量和重复内容上升；VLM 解析质量高但离线成本高一个量级，通常只对高价值文档开启。数字精度要重点回归——OCR 和模型转述是金额、日期出错的重灾区，关键数值建议从原表格程序化提取而非靠模型转写。

面试官可能追问

• 用户问"表 3 里哪个最高"这种聚合问题怎么办？（检索到表格后走 Text-to-SQL 或让模型显式读全表再比较，不能只给片段）

27. 向量检索、BM25、混合检索（Hybrid Search）分别适用什么场景？为什么召回之后还要 Rerank？

必刷 · 中等

参考答案

三者互补，标准答案是"混合召回 + 精排"两段式：

• 向量检索：语义级匹配，能召回同义改写、跨语言内容，对口语化 query 友好；弱在精确词、低频专有名词、型号/编号/人名——这些恰是 BM25 强项；
• BM25：词频统计的稀疏检索，精确词匹配强、可解释、无需训练；弱在同义词和说法差异（"退款"搜不到"退货返还"）；
• Hybrid：两路各取 top 20~50，RRF 融合（公式 1/(k+rank)，k 经验取 60，免分数归一）或加权cos归一融合（如 0.7 向量 + 0.3 关键词，需调参）。生产知识库问答默认上混合，纯向量在专名查询上必翻车。

为什么还要 Rerank：召回用的双塔 embedding 是离线独立编码 query 和文档，交互浅、精度有天花板；cross-encoder（bge-reranker-v2-m3、Cohere Rerank）把 query 和文档拼在一起过模型，能捕捉细粒度相关性，精度显著更高，但每对都要实时推理，无法用于全库。所以工程上分工：粗排召回保效率（top 50~100，几十毫秒），精排保精度（rerank 到 top 3~10，百毫秒级）。经验上 rerank 带来的收益常大于换更大的 embedding 模型。

面试官可能追问

• RRF 和加权融合怎么选？（RRF 免调参、对分数分布不敏感，首选；有标注数据再上加权）
• rerank 延迟扛不住怎么办？（减小候选集、蒸馏小模型 reranker、只对高价值 query 开启）

28. Embedding 模型怎么选型？怎么评估一个 Embedding 模型在你们业务上的效果？

高频 · 中等

参考答案

选型维度：

• 榜单初筛：MTEB / C-MTEB 看检索类子任务分数，但榜单≠业务，只做候选过滤；
• 硬性约束：语言覆盖（中文选中文优化模型）、max_seq_len（是否覆盖 chunk 长度）、向量维度（影响存储与检索成本，768/1024 常见，Matryoshka 降维是加分项）、许可证、推理成本与吞吐；
• 候选池参考：bge-m3（多语言 + 稠密/稀疏/多向量三模态）、bge-large-zh、gte 系列、text-embedding-3 系列、jina-embeddings-v3（支持任务指令前缀）；
• 是否支持指令前缀（instruct embedding）：query 和 document 用不同前缀，部分模型收益明显。

业务评估方法（关键考点）：

1. 构造黄金评估集：从真实日志抽 query（几百条起步），人工标注相关 chunk（或用"query → 来源文档"天然标注）；
2. 指标：Recall@k（k 取线上实际使用的值，如 5/10）为主，MRR / nDCG 辅助；
3. 同一套候选模型 + 同一份 chunk 库跑对比，注意控制 chunk 策略变量一致；
4. 消融：分类型看（专名类、语义类、长尾类），比总分更能暴露短板；
5. 业务 gap 大且数据可积累时，用难负例（同文档易混淆块）做对比学习微调，通常还能再抬一截。

面试官可能追问

• Embedding 模型升级换代，线上怎么无感迁移？（双写新旧向量、灰度切读、验证召回对齐后下线旧索引）

29. 向量数据库怎么选？Milvus、FAISS、Qdrant、pgvector 各自的特点和适用规模？

高频 · 中等

参考答案

先给结论：千万级以下、团队有 Postgres 优先 pgvector；快速原型用 FAISS；中等规模自建服务选 Qdrant；亿级以上、多副本多分片、需要完整运维体系选 Milvus。

方案	定位	规模量级	特点
FAISS	算法库，非数据库	单机百万~千万	ANN 索引最全（IVF/HNSW/PQ）、性能标杆；无分布式、无服务化、增删改弱，需自己包一层
Milvus	分布式向量数据库	亿~百亿	K8s 云原生架构、存算分离、分片副本、支持 DiskANN 省内存；组件多（etcd/Pulsar/MinIO），运维成本高
Qdrant	单二进制服务	千万级	Rust 实现、部署极简、filtered HNSW 性能好、payload 过滤和混合检索内置；超大规模生态弱于 Milvus
pgvector	PG 扩展	百万~千万	复用 PG 的 ACID、join、权限、备份；向量与业务数据同库join是杀手锏；HNSW 索引下千万级 P99 仍可接受，再往上吃力

选型还要看：过滤检索（metadata filter）性能、是否原生支持混合检索与多租户 partition、增量更新与 compaction 机制、备份恢复、云托管版（Zilliz、Qdrant Cloud）。别只跑 ANN benchmark，带业务过滤条件 + 真实数据分布压测才有意义。

面试官可能追问

• HNSW 的 ef/M 参数怎么理解？（图搜索的候选队列宽度和建图连接度，换 recall 换内存/延迟，压测调参）
• 为什么不少团队最后还是回到 Elasticsearch？（已有 ES 运维体系 + BM25，加 kNN 能一并解决混合检索）

30. 用户 Query 很口语化甚至有错别字，检索前要做哪些处理？（Query 改写、扩展、HyDE 等）

必刷 · 中等

参考答案

Query 预处理目标：把"用户语言"翻译成"检索语言"。手段按层次：

1. 规范化：纠错（拼音/形近错字，可用小模型或规则）、去语气词、口语转书面、统一中英文/全半角；
2. 改写（Rewrite）：多轮场景做指代消解和省略补全，产出独立完整的 standalone query（详见第 35 题）；关键词抽取辅助 BM25 一路；
3. 扩展（Expansion）：LLM 生成同义变体或多视角子查询（2~3 条），各自检索再融合，召回覆盖面明显提升；代价是多次 embedding 调用，可用小模型 + 并行控制延迟；
4. HyDE：先让 LLM 生成一段"假设性答案"，用它的向量去检索。原理是答案与文档的语义空间比"短问题对长文档"更对齐，对专业术语鸿沟（用户说白话、文档说黑话）特别有效；失效场景：模型对领域完全没概念时，编出的答案反而带偏检索；
5. 分解（Decomposition）：复杂比较类问题拆成多个子问题分别检索；
6. 路由前置：先判断是否需要检索、检索哪个索引，别什么都查库。

工程取舍：每加一步 LLM 调用就加延迟和成本，用小模型（7B 级或廉价 API）做改写、并行化、且只对"检索失败过的 query"升级到重策略。改写质量要单独建评估集回归，改写错会污染整条链路。

面试官可能追问

• 怎么判断改写模块有没有收益？（A/B：原始 query vs 改写后 query 的 Recall@k 和最终答案质量对比）
• HyDE 和 query expansion 各适合什么场景？（术语鸿沟用 HyDE，宽泛模糊问题用扩展）

31. RAG 效果不好，你的排查思路是什么？说说你的分层诊断方法（先查检索还是先查生成）。

必刷 · 较难

参考答案

先给结论：按"检索层 → 生成层"二分定位，用黄金评估集驱动，逐环节用数据说话，不凭感觉调 prompt。

第一步：bad case 分类定性

拿一个失败案例，人工回答两个问题：库里有没有正确知识？top-k 里有没有正确 chunk？由此分四类：

• A. 库里根本没有 / 解析坏了 → 数据与索引问题；
• B. 库里有但没召回 → 检索问题（占大头，约六七成）；
• C. 召回了但模型没用/用错 → 生成问题；
• D. 答案其实对但用户不认可 → 评估口径问题。

第二步：检索层诊断（B 类）

按链路顺序排查，先查"内容在不在"再查"找不找得到"：

1. 解析：源文档转出来的文本对不对（表格烂、乱码、双栏 PDF 串行）；
2. 切分：关键信息是否被切断、chunk 是否过大导致稀释；
3. 索引：embedding 输入是否超长被截断、索引是否更新到位（增量同步 lag）；
4. 召回：单路向量丢的专名换 BM25 能不能找回；query 改写是否反而带偏；
5. 量化：在标注评估集上跑 Recall@k，对比历史基线，定位是"全局退化"还是"特定类型退化"。

第三步：生成层诊断（C 类）

正确 chunk 已在上下文里，看模型行为：

• 没用上 → 忠实度问题：prompt 约束是否明确"仅依据资料"、片段是否太长触发 Lost in the Middle（把关键片段换到头尾位置试一下）、片段过多互相干扰；
• 用了但答错 → 推理能力问题：换更强模型交叉验证；
• 过度拒答 → 指令过严或片段相关但表述不匹配；
• 量化：跑 RAGAS 忠实度、答案相关性，对比检索层指标做"归因切分"。

排查清单

• 索引 lag 与文档版本（改了文档没重建索引是最常见低级错误）
• embedding / reranker 模型与索引是否配套一致
• top-k、阈值、过滤条件是否最近改过
• 失败是否集中在特定文档类型 / query 类型
• trace 里逐跳看：改写后的 query → 各路召回 → 融合排序 → 最终 prompt

加分点

• 平时就把 Langfuse/LangSmith 全链路 trace 埋好，排查时回放而非复现；
• 修复后必须过黄金评估集回归，防止"修好一处、改坏三处"；
• 建立 bad case 归因看板（检索问题 vs 生成问题占比趋势），指导投入方向。

面试官可能追问

• 检索和生成都达标但整体仍差，还可能是什么？（评估口径、知识覆盖缺口、多跳问题需要拆解检索）
• 怎么快速区分是"检索不到"还是"检索到了排序太后"？（看 gold chunk 的召回排名分布：不在 top-k 是召回问题，在 50 名开外是排序问题）

32. 什么是父块检索（Parent Chunk / Small-to-Big）？解决什么问题？

中频 · 较难

参考答案

核心矛盾：检索要小块，生成要大块。小块（如 128~256 token）主题聚焦、embedding 表征集中，召回准；但交给 LLM 时上下文不完整，指代、前提、条件都在别的段落里。大块（如 1024+ 或整节）上下文完整，但多主题混杂导致向量稀释，检索反而变差。

Small-to-Big 方案：两层切分解耦——

1. 子块（small）建向量索引，用于检索；
2. 命中子块后，通过 parent_id 回查其父块（big，如整个章节或 4 倍大小的窗口），把父块送入 LLM 生成。

变体：句子窗口检索（命中的句子向前后扩窗口 N 句）、层级多层回溯（子 → 段 → 节）。

工程实现：docstore 存父块原文，向量库只存子块及其 parent_id 指针；LlamaIndex 有现成的 ParentDocumentRetriever / SentenceWindowNodePostprocessor。

代价与注意：

• 父块占 token，多个子块命中同一父块要去重合并，否则上下文重复膨胀；
• 父块过大又回到稀释和 Lost in the Middle 问题，父块大小同样要评估驱动（经验 1~2K token 起步）；
• 索引与存储复杂度翻倍，FAQ 类短知识库没必要上。

面试官可能追问

• 父块大小怎么定？（以"回答所需的最小完整语义单元"为准，按文档结构切章节优于固定长度）
• 和直接加大 top-k 拉更多小块比，优势是什么？（上下文连贯、token 利用率高、避免碎片互相干扰）

33. 知识库规模到千万级文档，索引和检索架构上要怎么演进？

中频 · 较难

参考答案

演进主线：单机 → 服务化 → 分布式分片，同步链路异步化，索引分级省内存。

存储与索引层

• 百万级：pgvector / 单机 Qdrant / FAISS 自包装即可，HNSW 全内存扛得住；
• 千万级起：上分布式（Milvus 集群或 ES），按业务维度 partition/分片（租户、类目、时间），查询侧先路由再检索，避免全集群扇出；
• 内存压力：HNSW 全量内存成本高，改用 DiskANN 或 IVF + PQ 量化（内存可降一个量级，recall 损失 1~3 个点，需压测权衡）；冷数据降级到低召回率索引、热数据保高配。

检索链路

• 混合检索规模化：BM25 走 Elasticsearch 集群，向量走向量库，RRF 在应用层融合；
• 强过滤场景（权限、类目）优先用引擎的 pre-filter，避免先召回后过滤把 top-k 过滤空；
• 多级缓存：热点 query 结果缓存、embedding 结果缓存；
• 召回 recall 定期回归，防止索引参数调整造成无感退化。

数据同步链路

• 文档更新走 CDC + 消息队列削峰，消费端做解析、切分、双索引写入，监控索引 lag；
• 全量重建用双索引蓝绿切换：新索引建好、验证 recall 对齐后原子切 alias，不中断服务。

运维

• 指标：QPS/P99、recall 漂移、索引 lag、内存水位；容量按峰值 QPS × 分片副本规划。

加分点

• 租户隔离不只是性能问题，也是权限安全底线：跨租户检索事故是红线；
• 规模上来后"检索路由"价值凸显：先用分类器/轻量检索定位子库，精度和成本双收益。

面试官可能追问

• embedding 模型升级时千万级文档怎么迁移？（离线批量重算 + 双写双读灰度，按分片滚动切换）
• PQ 量化掉点怎么补？（rerank 用原始向量或提升 rerank 候选数兜底）

34. 了解 GraphRAG 吗？和传统向量 RAG 相比优缺点是什么？什么场景值得上？

低频 · 较难

参考答案

GraphRAG（微软 2024 提出的方案最知名）在向量索引之外增加一层知识图谱 + 层级摘要。离线阶段用 LLM 从文档抽取实体、关系、声明，构建图谱；对图做社区检测（Leiden 算法），分层生成社区摘要。在线分两种查询模式：Local Search（从 query 实体出发取邻接子图 + 原文块）和 Global Search（用高层社区摘要做 map-reduce 式的全局性问题回答）。

对比传统向量 RAG

优点：

1. 多跳推理：A 和 C 的关系分散在多篇文档时，向量检索只能召回局部，图上两三跳即可串起来；
2. 全局性/总结性问题："这批文档的主要风险主题是什么"——直接对海量 chunk 检索没法答，社区摘要天然适配；
3. 关系型查询：人物、组织、事件的关联网络分析。

缺点：

1. 索引成本高：每篇文档都要 LLM 抽取实体关系，索引开销比纯 embedding 高一个数量级（经验上百万字文档即产生可观的 token 成本）；
2. 更新昂贵：增量文档入库要重跑抽取并可能影响社区结构，全量重建更贵；
3. 工程复杂：图谱 schema、抽取 prompt、社区层级参数都要调，检索时图、向量、原文三路融合，链路重；
4. 对简单事实型问答没有收益，纯增加成本。

值得上的场景：情报/案件分析、合规审查、生物医药文献综述、企业知识中关系密度高的分析型需求。判断标准：问题是否需要"跨文档关联"或"全局归纳"——是则值得，普通 FAQ 坚决用向量 RAG。

加分点

• 折中路线：先向量 RAG 召回相关文档，只对召回子图做轻量图谱增强（成本可控）；LightRAG 等变体在成本上做了优化，可以对比提及。

面试官可能追问

• 索引成本怎么降？（限制实体类型、小模型抽取、只对高价值文档子集建图）
• 实体抽取错了会不会污染图？（会，需要消歧与置信度过滤，图质量是 GraphRAG 的生命线）

35. 多轮对话下的 RAG 怎么做？Query 里的指代（"它""第二个方案"）怎么解析？

高频 · 中等

参考答案

核心问题：检索器只该看到当前轮的独立完整 query，而用户说话默认带着上下文（指代、省略、话题延续）。标准做法是在检索前加一层 Conversational Query Rewriting：

1. 用 LLM（小模型即可）输入"最近几轮对话 + 当前问题"，输出改写后的 standalone query，如"它的价格多少" + 上文讨论产品 A → "产品 A 的价格是多少"；
2. 改写要处理三类现象：指代消解（它/这个/第二个方案）、省略补全（"那保修呢" → 补主语）、话题切换检测（用户跳新话题时不能被旧上文带偏，改写器要显式允许"忽略无关历史"）;
3. 改写后的 query 走正常检索，原始对话历史仍然只进生成侧 prompt。

工程细节：

• 改写只送最近 3~6 轮，历史太长既贵又引入误改写；
• 是否每轮都检索要有判断：纯寒暄、追问上一轮答案细节（上下文里已有）可跳过检索，靠意图判断或"检索必要性"分类器；
• "第二个方案"这类序数指代，光改写不够，需要把上一轮答案的结构（如列举项）带入改写 prompt，或显式维护会话状态（已提到的实体、候选列表），改写时查表回填；
• 改写错误会污染检索，要有"改写质量"评估集（多轮 bad case 重点回归），并允许用户自然纠正——改写器对纠正语义敏感。

进阶：上下文相关检索（拿历史 query 拼接扩展当前 query 再 embedding）也是低成本改进，与改写不冲突。

面试官可能追问

• 每轮都改写会不会太慢？（小模型 + 并行，几十毫秒级；或先用规则/分类器判断需要改写才调用）
• 改写错了用户骂"你答非所问"怎么办？（会话状态显式化 + 用户纠错回流评估集，高频错误模式加规则兜底）

36. RAG 的效果怎么评估？召回率、忠实度、答案相关性分别怎么测？

必刷 · 中等

参考答案

结论：分层评估——检索层看召回指标，生成层看忠实度和相关性，离线自动化 + 人工抽检 + 线上反馈三层闭环。

检索层（需要标注 gold chunk）

• Recall@k：top-k 里命中相关 chunk 的比例，RAG 最核心指标（召不回，后面全白搭）；
• Precision@k / MRR / nDCG：看排序质量和噪声比例；
• 数据来源：人工标注几百条 query→相关块；或利用"答案源自哪个文档"的天然标注。

生成层（RAGAS 是事实标准之一）

• 忠实度（Faithfulness）：答案是否忠于检索内容。RAGAS 做法：LLM 把答案拆成原子声明，逐条判断能否被上下文支持，得分 = 支持的声明数 / 总声明数，本质是自动化 NLI；
• 答案相关性（Answer Relevency）：答案是否切题。RAGAS 用 LLM 从答案反向生成问题，与原问题算相似度；
• 上下文精确率/召回率（Context Precision/Recall）：检索片段本身的相关性与噪声比；
• 通用框架还有 TruLens、DeepEval，指标口径大同小异。

落地流程

1. 建 100~500 条黄金评估集，覆盖主要 query 类型和历史 bad case；
2. 接入 CI：改 chunk 策略、换 embedding、改 prompt 都自动跑分离线报告；
3. LLM as Judge 要校准：抽样人工复核一致性，警惕长度偏差、位置偏差；
4. 线上指标兜底：引用点击率、用户点赞/点踩、转人工率、拒答率，与离线指标对齐。

面试官可能追问

• 没有标注数据怎么冷启动？（用强模型生成合成 query + 人工抽检校准，逐步替换为真实日志）
• 忠实度高但答案没用（正确地废话）怎么办？（忠实度只测"有没有依据"，必须配合答案相关性和任务级指标）

37. RAG 回答如何给出可信的引用来源？怎么保证答案有据可依、可追溯？

中频 · 较难

参考答案

目标拆成两件事：让模型标注引用（生成侧）和保证引用真实可信（校验侧）。

生成侧：结构化引用

1. 检索片段带稳定编号与元数据（chunk_id、文档标题、章节、页码/URL）注入 prompt；
2. 指令要求"每句话后的关键结论标注来源编号，如 [1][3]"，可给 few-shot 示范；句子级引用比段级引用可信度高，但指令遵循难度上升，需强模型配合；
3. 展示层：引用可点击跳转原文高亮，原文档可回看——可追溯性是 RAG 相对纯 LLM 的核心卖点，要把它做穿。

校验侧：防"乱标引用"

模型会编造引用或标错编号，必须后处理校验：

• 引用存在性校验：解析输出中的 [n]，核对 n 是否在本次注入的片段集合内，非法引用直接剔除或触发重写；
• 支撑性校验：对"答案句 ↔ 被引片段"做 NLI 或 LLM judge，判断片段是否真的支持该句，不支持的降级处理（删引用、加限定语或拒答）；
• 覆盖率指标：监控"有据句占比"（带合法引用的陈述句比例），作为线上忠实度代理指标，纳入告警。

治理兜底

• prompt 明确"资料无依据时回答'未找到'"，给拒答出口降低编造动机；
• 引用粒度做到 chunk 级即可，页码级依赖解析阶段保留定位信息（版面坐标），要在离线管道预留；
• 灰度期人工抽检"引用-原文"一致性，校验器本身也要定期评估。

加分点

• 全链路留 trace：query、召回列表、最终 prompt、答案、引用映射全部落库，出问题可完整回放，这也是审计合规的基础。

面试官可能追问

• 句级引用和段级引用怎么权衡？（句级可信度高、token 与指令成本高；折中方案是答案末尾统一列"主要依据"）
• 多个 chunk 说的是同一件事，引用怎么呈现？（按文档维度去重合并，避免同义引用刷屏）

38. Agentic RAG 是什么？和固定管道式 RAG 的本质区别在哪里？

低频 · 较难

参考答案

本质区别一句话：控制流归属不同。固定管道式 RAG 里"是否检索、检索什么、检索几轮、结果怎么用"都由代码写死，LLM 只在最后做一次生成；Agentic RAG 把这些决策交给模型，LLM 成为检索循环的决策者：它判断信息缺口、选择工具与数据源、评估中间结果、决定继续检索还是作答。

典型模式（可组合）：

• 路由式：模型先判断意图，选择知识库 / SQL / web 搜索等不同工具；
• 迭代式 / 多跳：复杂问题先拆解，检索→读结果→再生成新 query 补检索，循环直至信息齐备（如"对比 A、B 两供应商的召回事件"，先查 A 再查 B 再汇总）；
• 自反思式：Self-RAG（训练模型生成反思 token 判断"是否需要检索、结果是否相关、答案是否有据"）和 CRAG（Corrective RAG，评估检索质量，不达标时改写 query 或回退 web 搜索）是两个代表工作；
• Agentic 分层：一个 planner 拆任务，多个检索/执行子 agent 完成后汇总。

收益：应对模糊意图、多跳问题、多源异构数据；固定管道一次检索失败就整体失败，Agentic 有自纠机会。

代价（必须主动讲）：

1. 延迟与成本：多轮循环意味着多次 LLM 调用 + 检索，延迟从秒级升到十几秒级，token 消耗数倍；
2. 不可控性：路径不确定，可能死循环、过度检索、跑偏，必须加护栏：最大迭代轮数（如 3~5 轮）、token/时间预算、循环检测、强制出口；
3. 评估复杂：除了最终答案，还要评估轨迹（决策是否合理），回归测试更难做。

选型建议：FAQ、单跳事实问答用固定管道——便宜、快、可控；多跳分析、多源聚合、意图开放的场景才值得 Agentic 化，且通常做成"管道为主、agent 兜底"的混合架构。

面试官可能追问

• 怎么防止 agent 无限检索？（轮数与预算硬上限 + 每轮检索收益递减即停的停止条件）
• Agentic RAG 怎么评估？（结果指标 + 轨迹指标：工具选择正确率、检索轮数效率、自纠成功率）