2026-06-09 RAG 基础概念 拷问复盘
本轮概览
- 知识点：RAG 基础概念
- 模块：6. RAG 检索架构
- 分数：78/100
- 是否过关：否
- 来源卡片：[[RAG 基础概念]]
这轮你的基础概念和主链路已经能讲出来，尤其第 2 题对离线索引、混合检索、RRF、Rerank 的回答有明显工程感。主要失分集中在两个地方：一是第 1 题把 RAG 的痛点收得太窄，没有把“知识时效性、私有数据接入、可追溯性”完整打出来；二是第 3 题的排查路径还不够工程化，后两类问题不能只归因到 Prompt，应该把上下文构建、证据边界、拒答机制、权限与版本过滤一起纳入。
第 1 题
题目：
你先不用讲实现细节，先像面试官解释一下：RAG 到底是什么，它和“让大模型直接回答”相比，核心差别在哪里？它主要解决哪几类痛点？
你的回答：
你回答了 RAG 是检索增强生成，分为离线索引和在线检索两部分，把知识库作为来源实时喂给大模型，解决训练数据未覆盖企业知识库的问题；也指出了直接让大模型回答会更容易幻觉，且内容不符合业务需求。
缺失点：
少了三个高频关键词：知识时效性、私有数据接入、可追溯引用。你提到了“符合业务需求”，但还不够像面试口径，面试里最好明确说成“让模型基于外部证据回答，而不是只靠参数记忆闭卷作答”。
推荐答案：
RAG 是检索增强生成，本质上是让大模型在回答前先去外部知识库找证据，再基于证据生成答案。它和大模型直答的核心差别在于：直答依赖参数里的旧知识，像闭卷考试；RAG 依赖动态检索到的外部资料，像开卷考试。它主要解决四类痛点：知识过期、企业私有知识模型不知道、长文档不能整本硬塞进上下文、回答需要引用来源和可审计。
项目口径：
在苍穹外卖 AI 客服里，RAG 主要处理退款规则、配送说明、FAQ 这类知识密集型问题。我的目标不是让模型“更会编”，而是让它基于检索到的规则片段作答，这样既能跟着知识库更新，也能降低幻觉，还能在出现争议时解释答案依据。
第 2 题
题目：
你把 RAG 的完整链路从前到后讲一遍，要求至少讲清楚这几个环节各自干什么：切块、embedding、召回、重排、上下文构建、生成。另外再回答一个追问：为什么很多线上 RAG 系统不能只做“向量检索 + 大模型生成”，中间还要加 rerank？
你的回答：
你从离线索引讲起，覆盖了文档解析、清洗、增强文档、分块、Embedding、写入向量数据库；在线检索阶段讲了查询扩展、HyDE、多 embedding、父块查询、BM25、RRF 融合、Reranker 重排、上下文加载和生成。你也解释了双编码器和交叉编码器的差别，并用“A 依赖 B 和 B 依赖 A”说明仅靠向量相似度无法做细粒度判断。
缺失点：
整体回答是对的，但有两个边界要更精确。第一，召回不是“把相关块加载到上下文”，而是先形成候选池；真正进入上下文的是重排和压缩之后的高质量证据。第二，Rerank 不一定非要说“大模型”，更稳的说法是专用 Cross-Encoder 或重排模型，因为面试官有时会抓这个点追问成本和延迟。
推荐答案：
RAG 的完整链路可以分成离线和在线两段。离线阶段先做文档解析、清洗、按语义边界切块，再把 chunk 做 embedding，并把内容、向量和 metadata 一起建索引。在线阶段先理解用户问题，必要时做 query rewrite、multi-query 或 HyDE，然后做召回，常见是向量检索加 BM25 的混合检索，先粗召回一批候选片段。接着用 rerank 模型重排，把真正能回答问题的证据顶到前面，再做去重、压缩、排序和引用组织，最后交给 LLM 生成答案。之所以不能只做“向量检索 + 生成”，是因为向量相似度只能说明语义接近，不能保证这段文本真的能回答当前问题；Rerank 的价值是把“相关”重新排成“可回答”。
项目口径：
如果我在苍穹外卖 AI 客服里回答这个问题，我会强调线上链路不会把 Top-K 原样塞给模型，而是先做混合召回，再靠重排和上下文压缩控制信噪比。否则 FAQ、规则、旧版本政策一混在一起，模型就很容易答偏。
第 3 题
题目：
如果线上一个 RAG 系统效果很差，你会怎么排查？不要泛泛而谈，按一个工程化排查路径来回答。至少覆盖这几类情况：
- 完全召回不到正确资料
- 召回到了，但排序靠后
- 正确证据进了上下文，但答案还是不对
- 本来应该拒答，却硬答了
最后再补一个项目追问：如果把这套排查思路放到你的苍穹外卖AI客服里，你会优先盯哪几个指标或日志？
你的回答：
你先给出了 RAGAS 的四类指标：忠实度、答案相关性、上下文精度、上下文召回率。随后你把第一类问题归因到召回率低，并给出查询扩展、HyDE、父子块扩展、调整 TopN、相似度阈值和分块策略等手段；第二类问题归因为排序问题，提出引入重排；第三、第四类则主要归因到提示词设计问题。项目里你表示会重点盯上下文精度和上下文召回率。
缺失点：
这题的主要问题不是“指标不对”，而是排查路径还不够分层。第 3 类“证据进上下文但答案还是不对”除了 Prompt，还可能是上下文顺序错误、噪声太多、版本冲突、引用边界不清、证据压缩失真。第 4 类“应该拒答却硬答”也不只是 Prompt，通常还涉及低置信召回阈值、拒答策略、权限过滤、版本过滤和安全兜底。最后项目指标不应只盯两个离线评测指标，线上还要盯检索候选、Rerank 分数、最终上下文内容、引用命中、拒答率、P95 延迟、缓存命中率等日志。
推荐答案：
工程化排查要先分层定位，而不是一上来改 Prompt。第一步先看正确证据有没有进候选池。如果完全没召回到，优先查文档是否入库、解析是否坏了、chunk 是否切断语义、metadata 过滤是否过严，以及 query 是否需要改写、分解或混合检索。第二步，如果召回到了但排序靠后，就看是否缺少 Rerank、Rerank 模型不合适，或者候选池太脏。第三步，如果正确证据已经进上下文但答案还是不对，就查上下文排序、去重、压缩、版本冲突、Prompt 的证据边界和引用要求。第四步，如果本该拒答却硬答，说明系统缺少低置信拒答、追问或升级人工机制，也可能是权限过滤、版本过滤或证据质量判断没有做好。评估上要把检索指标和生成指标拆开看，比如 Hit Rate@K、MRR、Context Precision、Context Recall、Faithfulness、Citation Accuracy、Latency。
项目口径：
放到苍穹外卖 AI 客服里，我会重点盯这几类日志：原始 query 和改写 query、Top-K 候选片段、Rerank 前后分数、最终喂给模型的上下文、引用到的规则片段、是否触发 FAQ 语义缓存短路、P95 延迟、Token 成本，以及“低置信是否拒答/追问”的分支日志。这样才能判断问题到底出在数据、检索、重排、上下文还是生成。
下次复习动作
- 把第 1 题收敛成一句稳定口径：RAG 是让模型基于外部证据开卷作答，核心价值是时效性、私有知识、可追溯和降幻觉。
- 二刷第 2 题时，把“召回候选池”和“最终进入上下文”这两个阶段彻底分开，不要混说。
- 第 3 题按“召回 -> 排序 -> 上下文 -> 生成/拒答”四层排查路径背一遍，别把后两类问题都收缩成 Prompt 问题。