RAG 八股：AI PM 面试必会的 7 个检索术语
📍 AI 求职速查
你会遇到的开场
Section titled “你会遇到的开场”只要你简历写过「做过 AI 产品」,RAG 几乎一定问:
「简单讲一下 RAG 是啥，流程长啥样？」
或者升级：
「RAG 答跑偏怎么 debug？」
「Chunking 怎么切？切 500 还是 1000？」
「Reranking 加不加，加哪个？」
「Context Window 都 1M 了，是不是越大越好？」
这一篇把 7 个 RAG 核心术语讲清楚 —— 不只是定义，还配带 debug 判断口径（面试最能拿分的部分）。
先建立大局观
Section titled “先建立大局观”RAG 解决的核心问题:LLM 训练数据是死的(截止某个日期)，公司的私有知识 / 实时数据它不知道。
RAG = 给 LLM 装个「私人图书馆」 —— 答问题前先去图书馆翻资料，再带着资料回答。
跟微调相比的两个根本优势：
- 知识可以实时更新(改库就行，不用重训模型)
- 答案可追溯(每个答案能 link 回原文档，合规友好)
下面 7 个术语就是构成这个「私人图书馆 + 检索 + 喂答案」的完整链条。
一、RAG(Retrieval-Augmented Generation)总览
Section titled “一、RAG(Retrieval-Augmented Generation)总览”是啥：给 LLM 答问题前，先从知识库搜相关文档，把文档当作上下文喂给 LLM。
4 步流程:
用户提问："公司退款政策是啥？" ↓1. 编码：用向量模型把问题变成查询向量 ↓2. 检索：向量数据库搜出最相关的头部 K 个文档 (FAISS / Pinecone / Chroma) (可选)再用重排模型二次排序，精选头部 N 个 (Reranker) ↓3. 增强：把文档和问题拼成 prompt 交给 LLM <context>检索到的文档</context> <question>用户原问题</question> ↓4. 生成：LLM 基于上下文生成答案FAISS 是 Meta 开源的向量检索库，Pinecone、Chroma 是向量数据库（国内也常用 Milvus）。
RAG 的 4 大调优点(下面 6 个术语都对应这 4 个点):
- 向量模型(Embedding)—— 决定语义相似度判断准不准
- 切分(Chunking)—— 决定每个检索单元的粒度
- 重排(Reranking)—— 决定最终送 LLM 的文档质量
- 上下文窗口(Context Window)—— 决定能送多少文档
面试怎么答:
「RAG 4 步走 —— 编码 / 检索 / 增强 / 生成。调优通常先从前两步的检索环节下手。如果用户反馈『答案不准』，我会先看是不是没搜到对的文档（召回率），再看『是不是搜到了但太多噪声』（精确率）。这两个都对了，再考虑模型生成环节。」
二、召回率(Recall)
Section titled “二、召回率(Recall)”先用图书馆员的故事看懂：你跟图书管理员说「我想找一本讲咖啡历史的书」，图书馆真有 10 本相关书。
- 管理员只搬回来 6 本 → 召回率 60%(漏了 4 本)
- 管理员搬回来全 10 本 → 召回率 100%(一本不漏)
是啥:知识库里真有 100 篇相关文档，系统搜回 80 篇 = 80% 召回率。
公式:Recall = 搜回的相关数 / 知识库中所有相关的总数
召回率低意味着:
- 重要文档没搜到 → LLM 答案缺关键信息 → 用户体验差
- 用户提的问题在知识库里明明有答案，但 RAG 答不出来
怎么优化:
- 换更合适的向量模型（拿自己的标注问题比 2–3 个候选，中文可以比 Qwen3-Embedding 和 BGE-M3，见第七节）
- 加大头部 K(原来取头部 5，改成头部 20-50，相当于让管理员多搬几本)
- 加 BM25 + 语义混合搜索（BM25 是经典的关键词匹配打分算法：关键词搜召回长尾词 + 语义搜召回语义相近）
- 加元数据过滤(按文档类型 / 时间 / 部门预筛)
- 给切块补上下文（Anthropic 2024 年提出的 Contextual Retrieval：入库前给每一块加一两句说明，讲清它在整篇文档里说的是什么）
三、精确率(Precision)
Section titled “三、精确率(Precision)”还是图书馆员的故事：管理员这次很积极，搬回来 20 本书。
- 但其中只有 8 本真讲咖啡历史，12 本是混进来的(讲咖啡冲泡 / 茶叶 / 农产品) → 精确率 8/20 = 40%
- 你被一堆无关书淹没，没耐心翻
是啥:搜回 100 篇，真相关的 70 篇 = 70% 精确率。
公式:Precision = 搜回的相关数 / 搜回的总数
精确率低意味着:
- 搜回了一堆噪声文档 → 上下文被无关内容污染
- LLM 答跑偏(被噪声带节奏)+ token 浪费
怎么优化:
- 加 Reranker(下一节详讲，相当于让管理员搬来后再筛一遍)
- 提高相似度阈值（只要相似度分数 score > 0.7 的文档）
- 加元数据过滤(精排掉时间过期 / 类别不符的)
关键认知:
Recall ↑ 和 Precision ↑ 通常互相打架 —— 多搜回点(K 加大)Recall 升 + Precision 跌。RAG 调优本质就是平衡这两个。
四、Reranking(重排)
Section titled “四、Reranking(重排)”是啥：向量搜回头部 K 个(比如 K=50)后，用一个更精细的「交叉编码器」模型再排一次，取头部 N 个(N=5)喂给 LLM。
为啥需要两阶段:
| 阶段 | 用啥 | 速度 | 精度 |
|---|---|---|---|
| 1. 召回 | 双塔编码器(问题 / 文档独立编码) | 快（向量库一次能比对上百万条） | 一般 |
| 2. 重排 | 交叉编码器(问题 + 文档一起编码) | 慢 | 高 |
双塔编码器 像「先粗看简介」,交叉编码器 像「对照问题逐句精读」 —— 后者精度高但慢，所以只对头部 50 个用。
主流 Reranker（截至 2026-09-26）：
- Qwen3-Reranker（阿里开源，Apache-2.0 许可；官方测试的中文重排榜 CMTEB-R 上，8B 版 77.45，BGE-reranker-v2-m3 是 72.16）
- BGE-Reranker（智源开源，国内用得多）
- Cohere Rerank（海外商用，效果稳）
- Voyage Rerank（海外商用，Voyage 现属 MongoDB）
面试怎么答(高频题):
「面试官问『RAG 答不准怎么办』，我不会上来就调，先用评估集判断是召回问题还是排序问题：对的文档根本没搜回来，就改向量模型、加混合检索或者改切分；搜回来了但排在后面、被噪声淹没，就先加 Reranker。Reranker 是纯增量（在检索流程后面插一层），不用像改切分那样重新灌库，投入产出比高。要举数字，就引公开实验：Anthropic 2024 年的 Contextual Retrieval 实验里，给切块补上下文并配合 BM25，前 20 条结果漏掉关键内容的比例降了 49%；再加重排，一共降了 67%（原文）。」
五、上下文窗口(Context Window)
Section titled “五、上下文窗口(Context Window)”是啥:LLM 单次 prompt 能装多少 token。决定 RAG 能塞多少检索文档。
主流模型（截至 2026-10-19，按各家官方文档）：
| 模型 | 上下文 |
|---|---|
| Claude Fable 5.1 / Opus 5.5 / Sonnet 5.5 / Haiku 5.5 | 1M |
| Claude Haiku 4.5（上一代轻量款，已转为旧版，仍可调用） | 200K |
| Gemini 4 Argon（2026-10-13 起付费 API 可用）、Gemini 3 系列（如 3.8 Flash、3.1 Pro Preview） | 1M（1,048,576；Argon 是输入和输出合计） |
| GPT-6 系列（Astra / 6.1 Sol / Luna） | 约 1.05M（1,050,000） |
| DeepSeek（deepseek-flash / deepseek-v4-pro） | 1M |
主流旗舰已经基本拉平到 1M 左右（Gemini 没有 2M 档，那是 Gemini 1.5 Pro 时期的规格），Claude 的轻量款也跟上了：2026-10-07 发布的 Haiku 5.5 是 1M，上一代 Haiku 4.5 只有 200K。要留意 Haiku 5.5 按提示长度分两档计价，提示超过 10 万 token 的请求单价更高，往里塞检索文档时要算这笔账。表里另外几处是 9 月底以来的变化：Sonnet 5.5 于 2026-09-28 发布（上一代 Sonnet 5 同样是 1M），OpenAI 在 9-29 把 Sol 升级成 GPT-6.1 Sol（窗口不变），Google 的 Gemini 4 Argon 在 10-13 对付费 API 开放（1,048,576 token 是输入和输出合计的上限，留给检索文档的比这个数少）。官方来源：Claude、Gemini、OpenAI、DeepSeek。
3 个权衡:
- 上下文越长越贵(按输入 token 算钱)
- 上下文越长越慢（模型处理的延迟上升）
- 「中间丢失」效应 —— 太长上下文里中间的内容模型 注意力弱化，常常被忽略(Stanford 2023 年研究)
什么时候不用 RAG：资料总量小于约 20 万 token（大约 500 页）时，Anthropic 建议直接整份放进提示词，配合提示词缓存又快又省（原文）。知识量大、更新频繁、需要标出处时，RAG 仍是主流做法。
面试怎么答(进阶题):
「长上下文（Long Context）不是魔法 —— 窗口有 1M，不代表塞满都有效。我一般把送进去的检索内容控制在 50K–100K token（经验值），再长就上分层摘要（把 100K 先压成 10K 的主旨，再喂模型）。比硬塞效果好，成本也低。资料本身不到 20 万 token 的话，我会先试整份放进上下文加缓存，未必要上 RAG。」
六、知识库切分(Chunking)
Section titled “六、知识库切分(Chunking)”是啥：把长文档切成小块(chunk)，每块单独做向量 + 存到向量库。
为啥要切:
- 整本文档 200 页一次性做向量 → 信息被平均化 → 检索时找不到具体段落
- 切成 500-token 一块 → 每块是特定话题 → 检索更精准
5 种切分策略:
| 策略 | 怎么切 | 适合 |
|---|---|---|
| 定长切 | 每 500 token 一刀 | 简单，但可能截断语义 |
| 按句子切 | 按句号分，凑到 500 token | 保留语义 |
| 递归切 | 先按段落，段落太长再按句 | LangChain 默认推荐 |
| 语义切 | 用向量看相邻句子语义跳跃在哪，在跳跃点切 | 最精，但慢 |
| 结构切 | 按 markdown 标题 / Word 章节 | 适合结构化文档 |
Chunk size 怎么选:
| size | 问题 |
|---|---|
| 太小(100 token) | 上下文不够，LLM 答缺信息 |
| 太大(2000 token) | 检索不精，且 token 浪费 |
| 推荐 | 500-1000 token + 100-200 token 重叠 |
重叠的作用：防止关键信息正好被切在两个 chunk 边界(切一半)。
面试怎么答(超高频题):
「面试问『RAG 答跑偏，但文档明明有答案』，我会先看对的那一段有没有被搜回来。没搜回来，常见原因是切分切坏了（答案被切断在两块之间，或者一块里混了太多话题），也可能是向量模型不合适；搜回来了但排在后面，再加重排。切分的常规组合：递归切 + 500-800 token + 150 token 重叠，先跑一版评估；不行再换语义切。」
七、向量模型(Embedding Model)
Section titled “七、向量模型(Embedding Model)”是啥：把文本转成高维向量(比如 1536 维)的模型。向量距离 ≈ 语义距离。
主流向量模型（截至 2026-09-26）：
| 来源 | 模型 | 适合 |
|---|---|---|
| OpenAI | text-embedding-3-small / large | 英文 / 多语言 通用 |
| Cohere | Embed 4（embed-v4.0，2025-04） | 多语言强 |
| 阿里 | Qwen3-Embedding（开源，0.6B / 4B / 8B） | 中文和多语言都强；官方公布的中文榜 C-MTEB 上，8B 版 73.84，高于 BGE 系列最好的 bge-multilingual-gemma2（67.64） |
| 智源 | BGE 系列（如 BGE-M3，开源） | 中文常用，生态成熟 |
| Voyage（2025 年被 MongoDB 收购） | Voyage 4（2026-01） | 海外商用，长文档强 |
以前常见的 M3E 在 2023 年之后就没再更新，新项目不建议再选。
评估基准：MTEB（Massive Text Embedding Benchmark）—— 业界常用的向量模型综合评测榜，中文看 C-MTEB。名次变得很快：Qwen3-Embedding-8B 在 2025-06-05 拿过 MTEB 多语言榜第一，后来已被超过。所以别背「谁最强」，先在自己的 50–200 条标注问题上比 2–3 个模型，再参考 MTEB / C-MTEB。
面试怎么答:
「选向量模型按 3 个维度：任务 / 语言 / 成本。候选先列 2–3 个：英文通用场景从 OpenAI 起，中文把 Qwen3-Embedding 和 BGE-M3 都拉进来，多语言再加上 Cohere。然后拿自己的 50–200 条标注问题跑一遍召回率，再参考 MTEB / C-MTEB 排名。成本敏感场景把开源模型本地部署，延迟敏感场景上 API。别盲目追新：换向量模型要把整个库重新编码，瓶颈也常常在切分和重排，不一定在向量模型。」
RAG Debug 决策树(超实用)
Section titled “RAG Debug 决策树(超实用)”把上面 7 个术语串起来，就是一棵 debug 树 —— 这是面试现场最容易拿分的部分。你能现场在白板上画出这棵树，基本就拉开了跟其他候选人的差距:
用户反馈"答案不准" ↓先看 Groundedness(答案是否真用了检索内容) ↓┌──── Groundedness 高 但 准确率低 ────┐│ = 检索没拿对内容 ││ → 看 Recall: ││ 低 → 改向量模型 / 加大 K / ││ 混合检索 / 检查切分 ││ 高 → 看 Precision: ││ 低 → 加 Reranker ││ 高 → 看 Chunking 切分 ││ │├──── Groundedness 低 ────────────────┤│ = 模型自己幻觉 ││ → 加 prompt 约束 ││ → 换更强模型 ││ → 或者强制 "只用提供文档作答" │└─────────────────────────────────────┘面试加分:不是看到准确率低就瞎调，而是先定位是哪一环出问题。
总结：7 个术语怎么记
Section titled “总结：7 个术语怎么记”按 RAG 4 步流程组织：
| 流程步骤 | 涉及术语 |
|---|---|
| 编码 | Embedding 向量模型（入库前先做 Chunking 切分） |
| 检索 | Recall / Precision 衡量这一步；检索后可选 Reranking 重排精选 |
| 增强 | Context Window 决定能塞多少文档 |
| 生成 | 答案有没有真用上检索内容，看 Groundedness（见数据与评估八股） |
记完之后，看「RAG Debug 决策树」练习 —— 从准确率倒推每个术语在哪个位置救火。
面试加分小贴士
Section titled “面试加分小贴士”- 能讲 Recall vs Precision 互相打架 > 单独讲一个(显示你做过调优)
- 能讲 Reranker 投入产出比 > 单纯说「有用」（要举数字就引公开实验，比如 Anthropic 的 Contextual Retrieval）
- 能讲先定位再动手（先分清是召回问题还是排序问题，再决定改切分还是加重排）> 泛泛说「chunking 重要」
- 能现场画 RAG Debug 决策树 > 背术语清单