RAG面试必考：Agent Offer核心问答覆盖分块、召回与生成质量三大主干问题
RAG面试必考：Agent Offer核心问答覆盖分块、召回与生成质量三大主干问题
Agent Offer 是一份面向 Java 后端转 AI Agent 方向的公开面试复习资料库，其中 RAG 核心问答 把高频面试题重组为「分块策略、召回优化、生成质量」三大主干问题，配合口述版答案与常见追问，非常适合用来系统复习 RAG 面试。
💡 一句话记忆：RAG = 先检索、后生成。面试考的不是"跑通过没有"，而是你能不能讲清每一步为什么这么做、怎么权衡。
一、为什么 RAG 是面试必考？先看它在解决什么问题
面试官问 RAG，本质上想确认你理解它和直接微调的分工。对照资料里的标准答案，RAG 主要解决三件事：
| 核心问题 | 直接微调 | RAG 的做法 |
|---|---|---|
| 知识过时 | 需要重新训练 | 更新文档→更新索引即可 |
| 领域私有知识缺失 | 成本高、效果有限 | 任意私有文档接入知识库 |
| 幻觉不可控 | 仍是黑盒 | 答案可溯源到来源片段 |
标准工作流程三步走，面试口述时按顺序展开即可：
- 检索（Retrieve）：把用户问题当作 Query，到向量知识库中找出最相关的 Top-K 片段；
- 增强（Augment）：把召回片段与原始问题拼接成增强 Prompt；
- 生成（Generate）：LLM 基于上下文作答，回答"锚定"在事实依据上。
完整链路可以拆成离线和在线两段，这也是资料里推荐的口述框架：
- 离线（索引）阶段：数据加载 → 清洗切块 → Embedding 向量化 → 写入向量库建索引
- 在线（推理）阶段：查询改写 → 向量检索 → 重排（Rerank）→ 上下文组装 → 生成回答
⚠️ 加分项：主动提到「检索前处理（查询改写）」和「检索后重排」这两个质量提升点，再补一句线上要有评估回流与索引更新机制，否则质量会逐步衰减。
二、主干一：分块策略——切块大小与重叠长度怎么定？
分块（Chunking）是 RAG 面试中最容易深挖的环节，核心答案一句话：没有固定最优值，是语义完整性与检索精度的平衡。
2.1 切块大小的选择依据
| 维度 | 实践建议 |
|---|---|
| 嵌入模型能力 | 多数模型在 256–512 token 区间效果最好 |
| 文档类型 | 结构化文档按标题/段落语义切块；代码按函数或类切；FAQ 偏短块 |
| 查询类型 | 问题具体→句子级小块；问题宽泛→需要更大块综合上下文 |
2.2 重叠长度（Overlap）
- 作用：防止关键概念在块边界被"腰斩"；
- 经验值：块大小的 10%–20%（如 1024 token 的块配 128–256 token 重叠）；
- 重叠不是越大越好，过大只增加冗余和存储成本。
2.3 大小块的权衡（高频追问）
- 大块：上下文更完整，但噪声多、检索精度下降、成本高，还容易触发 Lost in the Middle；
- 小块：信息密度高、匹配更精确，但容易语义割裂、单块答不完整；
- 进阶答案：实践里常采用多尺度切块——小块用于精确检索，同时保留对"父块"的引用（Small-to-Large Chunking），把更完整的上下文交给 LLM。
📌 口述收尾话术：基线从 chunk_size=512, overlap=64 起步，用 Recall@K + 人工抽检迭代参数，按文档类型分策略而不是一套参数打天下。
详细问答见：docs/interview_prep/01_AI/03_RAG/01_核心问答.md
三、主干二：召回优化——如何持续提升检索质量？
资料给出的优化路径是九个字："召回更准、排序更稳、上下文更干净"。工具箱按三块整理：
3.1 嵌入模型怎么选？
- 看基准：参考 MTEB / C-MTEB 排行榜，优先检索（Retrieval）任务得分高的模型；
- 看场景：领域（医疗/金融）、语言支持、时延预算、私有部署还是 API；
- 看指标：Recall@K、MRR、nDCG，再叠加线上延迟与成本。
常见坑：离线分数高 ≠ 线上最优，长尾 query 和专业术语场景必须用业务数据集验证。
3.2 检索技术工具箱
| 技术 | 解决的问题 |
|---|---|
| 混合检索（BM25 + 向量） | 关键词/ID 精确匹配 + 语义模糊匹配兼得 |
| 重排 Rerank（Cross-Encoder） | 先粗召 Top-50，再精排 Top-5，上下文质量大幅提升 |
| 多查询改写 / 子问题拆分 | 复杂问题拆成多个简单查询，合并去重 |
| HyDE | 先让 LLM 生成"假设答案"，再拿答案向量去检索 |
| 元数据过滤 | 权限、时间等过滤条件不重建向量索引 |
| 知识图谱增强 | 多跳推理（如"作者公司的 CEO"）与可解释证据链 |
3.3 Lost in the Middle 现象
模型在长上下文中更关注开头和结尾，中间证据容易被忽略——片段明明召回了却没被用上。缓解四招：
- 重排时把最相关文档放首尾；
- 严格控制 Top-K（如 Top-3/5）降噪；
- Prompt 中明确要求"基于全部证据回答"；
- 必要时做长上下文微调（成本最高）。
3.4 向量库选型（追问高频）
| 方案 | 定位 |
|---|---|
| pgvector | 向量与关系数据强耦合，SQL 联查方便，接入成本最低 |
| Milvus | 大规模在线检索、高并发服务化，扩展性最好但运维最重 |
| FAISS | 库级方案，单机高性能、适合快速实验 |
资料里的参考策略：先用 pgvector 快速落地，规模和 QPS 上来后再迁 Milvus，FAISS 留给算法实验。
四、主干三：生成质量——RAG 系统怎么评估？
评估是区分"背过流程"和"做过工程"的分水岭。资料把它拆成检索、生成两阶段：
4.1 检索阶段：找得对、找得全
- 上下文精确率：召回片段里有多少真相关（信噪比）；
- 上下文召回率：相关文档有多少被找回（全面性）；
- 排名类指标：Hit Rate、MRR、nDCG@k（最常用，同时考虑相关性与排序）。
4.2 生成阶段：忠实、准确、有用
- 忠实性（Faithfulness）：答案是否完全基于上下文、有无捏造；
- 答案相关性：是否直接回答了原始问题；
- 答案正确性：事实层面是否准确（比忠实性更严格）。
工程上常用 RAGAS、ARES、TruLens 这类开源框架，用 LLM-as-a-Judge 把上述指标自动化，大幅降低评估成本。
4.3 Top-K 怎么设？
不是拍脑袋定死的：事实问答 K 取小、复杂推理 K 取大；观察正确率-时延-成本三条曲线的拐点，通过离线评测 + 线上 AB 找最优点。原则是先保召回，再通过重排提信息密度，最后才调 K。
五、进阶追问：RAG 上线后怎么治理？
这部分是高级工程师必问区，三大生产挑战与对策：
| 挑战 | 典型表现 | 治理策略 |
|---|---|---|
| 数据新鲜度 | 文档更新了却"答旧不答新" | 增量索引（chunk_id + content_hash）、索引版本化 |
| 稳定性 | 链路抖动导致时延高、空召回 | 灰度发布、回滚开关、双索引蓝绿切换、热冷分层 |
| 可解释性 | 回答不可追溯，业务不信任 | 输出引用片段与来源、可观测看板 |
📌 一句话口述："先保障召回，再优化生成"，并用线上 bad case 持续回流，形成检索与提示词的双闭环。
六、怎么用这份资料复习？
仓库目录已按面试主题重组，推荐复习路径：
- 入口导航：docs/interview_prep/README.md
- AI 板块总览（Agent 基础 / RAG / 上下文工程 / 评测监控等 9 个主题）：docs/interview_prep/01_AI/README.md
- RAG 核心问答（本文全部素材来源）：docs/interview_prep/01_AI/03_RAG/01_核心问答.md
- 配合项目表达练口述：docs/interview_prep/05_项目表达/01_AI应用平台/01_核心问答.md
仓库同时覆盖后端（MySQL/Redis/Kafka 等）、系统设计、算法四大板块，完整目录见 README.md。每个问题末尾都标有来源，方便回查；资料以主题问答而非题海方式组织，更适合系统复习 + 口述演练 + 追问深挖的使用方式。
🎯 复习建议：先按本文三大主干各写一版 300 字口述稿（资料里已提供现成范本），再针对每个"常见追问"清单自问自答，一轮下来 RAG 面试主干问题基本全覆盖。