RAG 全链路 · 深度¶
企业级百万级 RAG 设计、65%→92% 评测口径、长尾问句优化、幻觉治理组合、全链路 Trace 的深度问答。每题含参考答案 + 面试官追问/红旗。
Q1: 请设计一个企业级 RAG 知识库（百万级文档、秒级检索），讲讲完整链路与关键优化点。¶
深度 | RAG | 📖 相关讲解
考察点：能否端到端设计生产级 RAG，覆盖离线入库、在线检索、规模化、可观测，而非停留在单机 demo。
参考答案
背景对标：许峰案例——百万级文档知识管理，秒级检索响应，"余弦 + BM25 → ReRank"链路。
完整链路：
离线入库（百万级吞吐优化）：
- 并行解析 + Embedding：单机串行处理百万文档是天文延迟，用 Spark / 多机并行跑解析和 Embedding。
- 增量 + 去重：维护文档哈希（MD5），重入库时只对变更文档增量 Embedding；文档更新按 doc_id 删旧块插新块。
- 分块：递归分块（384~512 token，Overlap 10%~20%），表格行级语义化，每块带 metadata（来源/页码/章节/权限）。
向量库选型（百万级）：
- Qdrant / ES kNN（已有 ES）/ Milvus（要分布式）。HNSW 索引，
M=16, ef_construction=200, ef_search=128起步。 - 内存预算：100 万 × 1024 维 float ≈ 4GB 裸数据，加图索引翻倍，提前规划分片/磁盘卸载。
在线检索（秒级响应）：
- Query Rewriting（LLM 改写，带缓存控延迟）。
- 混合检索：BM25 + 向量各召回 Top-20~50。
- RRF 融合（k=60）→ Top-N 候选。
- cross-encoder Rerank 精排 → Top-5。
- 置信度阈值 + 引用回溯 + 护栏 Prompt → LLM 生成。
关键优化点：
| 维度 | 优化 |
|---|---|
| 吞吐 | 并行入库 + 增量更新 + 去重 |
| 检索质量 | 混合检索 + RRF + Rerank + Query Rewriting 全链路 |
| 规模 | HNSW 内存预算 + 分片/磁盘卸载 |
| 可信 | metadata 过滤 + 引用回溯 + 置信度阈值 + 护栏 |
| 可观测 | 全链路 Trace（见 Q5） |
| 性能 | Embedding/Rerank 结果缓存；向量库连接池 |
面试官追问 / 红旗
- 追问：百万级文档入库要多久？怎么加速？（并行+增量，给出量级估算和加速手段）
- 追问：检索秒级怎么保证？哪些环节是延迟瓶颈？（Embedding、向量检索、Rerank、LLM 生成；缓存+并行+小批量 Rerank）
- 红旗：只讲在线检索生成，漏掉离线并行入库/增量/去重——说明没做过真实百万级；或答"加机器就行"无具体优化点——空洞。
Q2: "召回率 65%→92%" 里的 Hit Rate@5 评测集是怎么建的？各环节分别贡献了多少？¶
深度 | RAG | 📖 相关讲解
考察点：能否讲清评测指标定义、评测集构建方法，以及拆解各环节贡献——这是验证量化数字真实性的核心追问。
参考答案
指标定义（Hit Rate@5）：对每条测试问题，系统检索 Top-5 结果，如果"应该被命中的正确文档"出现在 Top-5 里就算命中。Hit Rate@5 = 命中条数 / 总条数。彭超案例是 300 条标注测试集 上的 Hit Rate@5 评测。
评测集怎么建：
- 从真实用户 query 中采样（覆盖高频 + 长尾），避免只测简单题。
- 每条 query 由人工标注"正确答案/正确来源文档"作为 ground truth。
- 规模要够（300 条是合理起点），覆盖多领域、多问法（同义改写、口语化、带专有名词）。
各环节贡献拆解（一个可能的分解口径）：
| 阶段 | 起点→终点 | 贡献 |
|---|---|---|
| 基线（单向量检索） | 65% | — |
| + 混合检索（BM25+向量+RRF） | → ~72% | 补回精确符号/语义改写的漏召回 |
| + cross-encoder Rerank | → ~85% | 召回到了但排序错导致的 Top-5 漏掉被修正 |
| + Query Rewriting | → 92% | 口语化/缺关键词的长尾问句从源头召回改善 |
要点：① 92% 是全链路叠加，不是单点魔法，缺任一环都到不了；② 拆解时必须逐环节累加测量（先只开混合检索测，再叠加 Rerank 测，再叠加 Query Rewriting 测），才能证明每环贡献；③ 测试集要固定，否则 65 和 92 不可比。
这个口径经得起追问——能说清"300 条、Hit Rate@5、逐环节累加测量"，量化才是真实的。
面试官追问 / 红旗
- 追问：Hit Rate@5 和 MRR、NDCG 有什么区别？（Hit Rate 只看是否进 Top-K 不看排名；MRR 看排名位置；NDCG 看排序质量，可加权）
- 追问：92% 还能继续提升吗、瓶颈在哪？（长尾、标注边界、知识库覆盖；边际递减）
- 红旗：说不出"300 条测试集""逐环节累加测量"这类口径，只给个数字——报告 §5.5 明确"量化是真实性试金石"，口径经不起追问的数字要打问号；或把 65→92 归因于单一环节——不符合全链路事实。
Q3: 长尾问句召回不准，给出从分块到 Rerank 的完整优化方案。¶
深度 | RAG | 📖 相关讲解
考察点：能否系统性地定位长尾召回问题，并沿链路给出多环节组合优化，而非单点修补。
参考答案
长尾问句召回不准，根因通常是"问得不好（口语化/缺词/歧义）"叠加"单一检索盲区"。完整优化按链路逐环排查：
1. 查询侧（Query Rewriting）——从源头改善输入：
- 术语标准化：把口语/简称换成文档规范术语。
- 意图补全：补上检索必需关键词。
- 子查询分解：复杂问题拆成子问题分别召回再合并。
2. 检索侧（混合检索 + RRF）——补召回盲区：
- 加 BM25 与向量混合检索（若只有单向量），用 RRF 融合。
- 扩大单路 Top-K（如 20→50），召回宁多勿漏，交给 Rerank 收敛。
3. 分块侧——提升可命中性：
- 调 chunk_size（扫参看 Hit Rate 拐点，过粗过细都伤召回）。
- 加合理 Overlap（防边界信息丢失）。
- 表格行级语义化（整表 Embedding 是长尾召回重灾区）。
- "小块检索 + 大块返回"提升命中精度同时保上下文完整。
4. Rerank 侧——精排去噪：
- cross-encoder Rerank 把真正相关的顶到 Top-5，修正"召回到了但排序错"。
5. 评测闭环：
- 专建长尾评测子集（口语化、低频领域、歧义 query），每项优化前后测 Hit Rate，定位瓶颈在哪一环，避免盲目调参。
关键思路：长尾优化是多环节叠加，不是单点。先定位是"问得不好（靠 Query Rewriting）"还是"检索盲区（靠混合检索）"还是"分块粒度（靠调参）"还是"排序错（靠 Rerank）"，对症下药。
面试官追问 / 红旗
- 追问：怎么知道长尾问题出在哪个环节？（全链路 Trace + 分环评测，逐环开关测量贡献）
- 追问：如果改了分块要重 Embedding 吗？（是，分块变了 chunk 内容变，必须重 Embedding，注意成本）
- 红旗：只给一个手段（如"加个 Rerank"）——长尾是多环节问题，单点修补无效；或答不出"怎么定位瓶颈在哪环"——无方法论。
Q4: RAG 的幻觉如何治理？引用回溯、置信度阈值、知识边界如何组合？江旭 0.1% 可能是怎么做到的？¶
深度 | RAG | 📖 相关讲解
考察点：是否认清"RAG 仍会幻觉"、能否讲清多重护栏的组合逻辑，并合理拆解江旭 0.1% 的工程可能。
参考答案
先纠正误区：RAG 仍会幻觉。三类来源：①召回缺失型（知识库没有，LLM 编）；②召回噪声型（召回不相关，LLM 张冠李戴）；③生成发散型（文档对但 LLM 过度推断）。治理靠多重护栏组合，单点不够。
三大手段及组合逻辑：
| 手段 | 作用层 | 拦截的幻觉类型 | 单独局限 |
|---|---|---|---|
| 引用回溯 | 生成中 | 生成发散型（强制有出处） | LLM 不保证 100% 标对出处 |
| 置信度阈值 | 检索后/生成前 | 召回缺失 + 低质量（证据不足不生成） | 阈值高则拒答率高，需权衡 |
| 知识边界 + 意图分类 | 检索前 | 召回缺失型（范围外直接拒答） | 边界划分要准，否则误拒 |
组合方式（多层防御）：范围外先被知识边界拦（意图分类），召回到但证据不足被置信度阈值拦（不出答案），生成时被引用回溯 + 护栏 Prompt 约束（有出处、超范围不答），生成后被 Multi-Agent 审核/规则复核兜底（金额/合规校验，不通过回退或转人工）。任一环节漏过的幻觉被下游兜住，残余概率才能逼近 0.1%。
江旭 0.1% 的可能做法（尽调场景，6 子 Agent 协同）：
- 尽调是高风险场景，必然用高置信度阈值——证据不足不出报告（宁可成功率受影响，也不编造；实际从 78%→93%，说明质量提升反而提升采纳率）。
- 引用回溯贯穿报告生成，每条结论可溯源到尽调底稿。
- Multi-Agent 审核：6 子 Agent 协同中必有校验/审核角色，基于规则（金额阈值、合规约束）复核，不通过回退重规划。
- 护栏 Prompt 严格限定"只基于底稿、数字必须一致、不支持就承认"。
要点：0.1% 不是单点，是"高阈值 + 引用 + 审核 + 护栏"叠加的结果。
面试官追问 / 红旗
- 追问：置信度阈值定多少合适？太高太低各有什么问题？（高风险场景宁高，拒答好过编造；太低幻觉反弹）
- 追问：引用回溯怎么实现？LLM 不标出处怎么办？（文档编号随上下文喂入 + Prompt 要求引用；或用 Citation 模块对齐 token 与来源；后处理校验引用是否真实存在）
- 红旗：以为"用了 RAG 就不幻觉"——这是最大认知误区，报告和本节都强调 RAG 仍需幻觉治理；或把 0.1% 归因于单一手段——不符合多重护栏事实。
Q5: 全链路 Trace（会话/消息/推理日志/工具调用/检索日志/反馈）如何支撑 RAG 的评估与迭代？¶
深度 | RAG | 📖 相关讲解
考察点：是否理解 RAG 的迭代闭环依赖可观测数据，能否讲清各 Trace 模块对评估和优化的具体支撑作用。
参考答案
RAG 的效果优化不是一次性调参，而是"看数据 → 定位瓶颈 → 改链路 → 再看数据"的持续迭代闭环，全链路 Trace 是这个闭环的眼睛。对标彭超案例的全链路可观测、许峰"全链路 Trace 支撑效果评估与迭代"。
各 Trace 模块的作用：
| Trace 模块 | 记录内容 | 支撑的评估/迭代 |
|---|---|---|
| 会话/消息 | 会话 ID、消息序列、时间 | 多轮上下文分析、用户行为路径、会话级成功率 |
| 推理日志 | LLM 输入 Prompt、输出、耗时、token | 幻觉归因、Prompt 迭代、成本与延迟优化 |
| 工具调用 | 调用了哪个工具、参数、返回、成功与否 | 工具成功率（彭超 98%）、失败归因、工具注册优化 |
| 检索日志 | query、召回文档、Rerank 分数、是否命中标注 | Hit Rate 分析、长尾定位、检索各环贡献拆解 |
| 反馈 | 点赞/点踩、人工标注、采纳率 | 真实满意度、负样本挖掘、评测集扩充 |
如何支撑评估与迭代：
- 效果评估：检索日志 + 反馈算 Hit Rate/采纳率，定位"哪类 query 召回差"（长尾子集）。
- 瓶颈定位：一次失败案例，沿 Trace 回溯——是 query 没改写好？召回没命中？Rerank 排序错？还是 LLM 生成发散？逐层定位。
- 负样本挖掘：点踩/低分案例 + AI 审计 + CoT 归因，挖出 bad case 喂回 Prompt/SFT 迭代（彭超的数据飞轮）。
- 成本/延迟优化：推理日志的 token 和耗时数据驱动 Prompt 精简、缓存策略、模型选型。
关键设计：用统一 trace_id 串联一次请求的"检索日志→推理日志→工具调用→反馈"，才能从用户反馈一路定位到检索环节的具体问题。没有贯通的 trace_id，各模块日志是孤岛，无法归因。
面试官追问 / 红旗
- 追问：怎么从一条用户点踩定位到检索环节的问题？（trace_id 串联，回溯检索日志看召回/Rerank，看推理日志看生成）
- 追问：检索日志要记哪些字段才能做 Hit Rate 分析？（query、召回文档 ID 及分数、Rerank 排序、是否命中 ground truth）
- 红旗：只说"加日志监控"，讲不清各模块对评估/迭代的具体支撑作用——报告把"无量化/无可观测"列为红旗，能讲清 Trace→评估→迭代闭环才是真懂 RAG 工程化。