FDE W3D7 学习手册 · 第一轮模拟面试
W3 Day7 · A 级（综合模拟，面试冲刺）· 4h · 学完能流畅回答"RAG 全流程 + Chunk/ES/BM25/Rerank/ACL/更新/评估/拒答"全部核心问题，并完成简历 v1 与市场验证
本日定位：本周前 6 天学了采样/检索/生成/Query/评测/作品打磨，W3D7 是第一轮模拟面试——把零散知识点串成"被追问也不慌"的流畅表达，同时本周完成简历 v1 并开始少量市场验证投递。
学完能回答：① RAG 完整流程、Chunk 策略、为什么用 ES、BM25 vs 向量、为什么 Rerank、ACL、文档更新、检索评估、无答案处理、防越权；② 简历 v1 里作品一怎么写、市场验证投递怎么做。
使用方法：把每节当"面试口述稿"朗读一遍 → 重点看「面试话术」「易错点」→ 做自测清单 → 配合《FDE-W3D7-评测题.md》与《FDE面试备战手册》20 道模拟题。
参考资源：B站 Spring AI 第 57-77 集 RAG 全套 BV1GfyGBqEm6（Java 体系 RAG 实战）；《FDE面试备战手册》20 道模拟题。
一、第一轮模拟面试总览：要串起来的是什么
第一轮面试（技术面）核心是把 RAG 全链路讲顺：从文档进来到答案出去，每个环节"为什么这么做、不这么做会怎样、生产怎么兜底"。本节把这周的知识点整合成一张"问题地图"：
| 环节 | 必会问题 | 对应前面 |
|---|
| 文档/Chunk | Chunk 怎么切、为什么用 ES | 检索基础 |
| 检索 | BM25 vs 向量、为什么 Rerank | 检索基础 |
| 查询 | Query 优化、无答案拒答 | W3D4 |
| 生成/可靠 | 引用准确、防越权 ACL | W3D4/作品一 |
| 运维 | 文档更新、检索评估 | 评测/作品一 |
第一轮技术面 = 把 RAG 全链路讲顺：文档→Chunk→检索(BM25+向量+Rerank)→Query优化→生成(引用/拒答/ACL)→评估/更新。每个环节都要能答"为什么、不这样会怎样、生产怎么兜底"。
作为 Java+大数据背景候选人，被问"为什么用 ES"时，可以顺势展示你在搜索/索引/吞吐上的积累——这是你的差异化优势，要比纯算法背景的人讲得更"工程"。
二、RAG 完整流程（端到端口述稿）
文档 → 解析/切分(Chunk) → 双写索引(ES+向量) → 用户问 → Query优化 → 混合检索(BM25+向量) → Rerank → topK → LLM生成(引用/拒答/ACL) → 后校验 → 答案 + Trace
- 离线：文档解析 → 按策略切 Chunk → 写入 ES（BM25）与向量库（语义）两个索引。
- 在线：Query 优化 → 混合检索召回候选 → Rerank 重排 → 取 topK 作为 context。
- 生成：LLM 基于 context 生成，强制引用（chunk_id）、判定 should_refuse、过 ACL。
- 校验：引用校验、拒答校验、敏感/越权校验 → 落 Trace。
RAG 完整流程一句话：离线把文档切 Chunk 双写 ES+向量；在线做 Query 优化→混合检索→Rerank→取 topK→LLM 生成（带引用/拒答/ACL）→后校验→落 Trace。离线管"建库"，在线管"问答"。
① 别把"检索"和"生成"混着讲，面试官常故意打断让你"只讲检索那段"——要能随时切块讲。② 口述时主动点出每个环节的降级（Rerank 挂了降级纯向量、Query 优化挂了降级原 query），显生产经验。③ 别忘了"离线"那半，很多人只讲在线，被问"文档怎么进来的"就卡。
三、Chunk 策略如何选 + 为什么用 ES
3.1 Chunk 策略
| 策略 | 做法 | 适用 |
|---|
| 固定长度 | 按 token/字符数切，带 overlap | 通用、简单，overlap 防截断 |
| 语义切分 | 按句子/段落/标题结构切 | 结构化文档（条款、章节） |
| 递归切分 | 按分隔符逐级切（段落→句→词） | 长文档、保结构 |
| 父文档检索 | 用小块召回、返回大块 | 既要精准又要上下文完整 |
- 大小权衡：太小→上下文碎、语义不全；太大→噪声多、超 token、召回不精准。保险条款常用 512~1024 token + 重叠。
- 重叠（overlap）：相邻 chunk 重叠一部分，避免关键信息被边界切断。
3.2 为什么用 ES（Elasticsearch）
- BM25 关键词检索：保险条款含大量精确术语（条款号、病名、药品编码、金额），BM25 对"精确词命中"极准，向量易把"相似但不同"的条款混淆。
- 成熟稳定：ES 在搜索/索引/高并发上久经考验，Java 生态契合团队栈，运维成本低。
- 混合检索底座：ES 既能存 BM25 也能存向量（dense_vector），一套系统做混合，省维护。
Chunk 策略：固定长度(带 overlap)/语义/递归/父文档检索，按文档结构选；大小权衡碎 vs 噪。为什么用 ES：保险条款有精确编码，BM25 关键词命中极准，且 ES 成熟、Java 生态契合、可一套做混合检索。
用 ES 做混合检索底座，对 Java 背景是天然加分：你懂它的分片、索引、近实时刷新、并发模型，能讲"为什么 ES 比另起一个向量库更适合我们团队"。生产落地成本直接下降。
① Chunk 大小没有"标准答案"，要结合评测调（不同大小看 Recall@K）；别拍脑袋说"512 最好"。② 用 ES 不是"不用向量"——是"ES 承载 BM25 + 向量混合"，纯 ES 也救不了语义召回，要讲清混合定位。③ 重叠太大→重复内容多、成本涨；太小→语义断，要平衡。
四、BM25 和向量检索差异
| 维度 | BM25（稀疏/关键词） | 向量检索（稠密/语义） |
|---|
| 匹配方式 | 词面精确匹配 + TF-IDF 加权 | 语义向量相似度（近义/改写也能匹配） |
| 优势 | 精确术语、专有名词命中准；可解释 | 语义泛化好；同义/措辞不同也能召回 |
| 劣势 | 不理解语义；同义改写召回差 | 精确编码易混淆；耗算力；黑盒 |
| 适用 | 保险条款号、病名、金额等精确词 | 口语化、多表述、跨表述语义 |
BM25 分数 = 词频(TF) × 逆文档频率(IDF) × 长度归一化
向量 = cosine(query_vec, doc_vec) 或 dot product
BM25 是关键词精确匹配（TF-IDF 加权），对保险条款号/病名等精确词极准、可解释；向量是语义相似，同义改写也能召回但易混淆精确编码、耗算力。两者互补，故用混合。
① 面试常问"只用向量不行吗"——答：纯向量在保险精确编码场景会把"相似条款"排前导致答错（呼应 W3D6 失败案例），BM25 补精确命中。② 别把 BM25 说成"过时"——它在精确匹配上仍是最强之一。③ 混合的"融合"方式（RRF/加权）也要能讲（见下节）。
五、为什么需要 Rerank
5.1 问题
混合检索召回的是"候选集"（BM25 一批 + 向量一批），各自分数量纲不同、不能直接比，且 top 结果里可能混着不相关的。需要一步统一精排。
5.2 Rerank 做什么
- 用交叉编码器（cross-encoder）或重排模型对 (query, 每个 candidate chunk) 算精细相关性，重排。
- 比双塔向量更准（query 和 doc 交互计算），但慢，所以只用在召回后的少量候选上（先粗排后精排）。li>
- 融合方式：RRF（Reciprocal Rank Fusion）合并多路排名，或直接用 Rerank 模型统一打分。
为什么不直接用 Rerank 替代检索？ 交叉编码器要对 query 和每个 doc 两两算，复杂度高，无法对全库亿级文档实时跑；所以"向量/BM25 粗排召回 topN → Rerank 精排 topK"是标准两段式。
Rerank 解决"混合召回候选量纲不一、需统一精排"。用 cross-encoder 对(query,chunk)算精细相关性，比双塔准但慢，故只排召回后的少量候选（粗排→精排两段式）。融合可用 RRF。
① "Rerank 一定提升"是误区——候选集质量太差时 Rerank 也救不了，要先保召回。② Rerank 增加延迟/成本，要权衡（只对 topN 重排、可降级）。③ 别把"Rerank 模型"和"embedding 模型"搞混：前者交互式精排，后者双塔召回。
六、如何实现 ACL、防止知识库越权
6.1 什么是 ACL（访问控制）
ACL = 控制"谁能看哪些文档"。保险知识库里，不同角色（投保人/代理人/内勤/合规）可见范围不同，且不能查他人的保单信息。
6.2 实现层次
| 层 | 做法 |
|---|
| 索引层 | 文档打 role/document_scope 标签；检索时按角色过滤候选（metadata filter） |
| 检索层 | 召回后用 ACL 过滤器剔除越权 chunk（前置，越早拦越好） |
| 生成层 | 生成前校验问题是否涉及越权实体（如他人保单号）；should_refuse 拦截 |
| 审计层 | 记录谁查了什么、是否触发越权拦截（Trace） |
6.3 防越权要点
- 前置拦截：越权在检索前就拦，不把越权内容送进 context（防泄露 + 防模型借题发挥）。
- 最小权限：默认只能看自己权限内文档，跨权限需显式授权。
- 评测：用 allowed_roles 字段构造越权 case，验证 ACL 拦截率 100%（呼应 W3D5）。
ACL = 控制谁能看哪些文档。实现：索引层打 role 标签、检索层 metadata 过滤 + 前置拦截越权 chunk、生成层校验越权实体并拒答、审计层记 Trace。关键是"越早拦越好"，并用 allowed_roles 越权 case 验拦截率。
保险场景越权 = 合规事故（泄露他人健康/保单信息）。ACL 不是"锦上添花"而是"上线前提"。在简历和面试里把它当一等公民讲，比讲花哨的 prompt 更显生产成熟度。
① 只在生成层"嘴上拒答"不够——必须检索前就过滤，否则越权 chunk 进了 context 模型可能无意泄露或借题发挥。② 过滤逻辑放 metadata filter，别靠模型自觉。③ 越权 case 必须进评测集，否则"号称防越权"无法证明。
七、如何处理文档更新
知识库（条款/目录）会迭代，文档更新要避免"脏数据"和"答案漂移"。
- 版本化：每篇文档带
document_version（呼应 W3D5 Case 字段），更新生成新版本，旧版可回滚。
- 增量索引：只重新解析/切分变更文档，更新对应 chunk，不重建全库（省算力）。
- 双写同步：ES 与向量库一起更新，避免一侧旧一侧新导致混合结果错乱。
- 失效与回流：旧 chunk 标记失效（不物理删，便于审计）；评测集对变更文档的 case 重标。
- 更新后回归：跑评测集确认指标未退化，再放量。
文档更新 = 版本化(document_version) + 增量索引(只更变更chunk) + 双写同步(ES与向量一致) + 旧chunk标记失效 + 更新后跑评测回归。避免脏数据和答案漂移。
① 只更新向量库忘更新 ES（或反之）→ 混合检索一边旧一边新，结果乱。必须双写原子同步。② 物理删除旧 chunk 会丢审计能力，应标记失效。③ 更新后不回归评测 → 悄悄退化，用户先发现。④ 并发更新要处理锁/队列，避免索引半更新状态。
八、如何评估检索
评估检索（呼应 W3D5）聚焦"召回对不对、排得好不好"：
| 指标 | 看什么 | 怎么用 |
|---|
| Hit Rate@K | 有没捞到相关 | 快速看召回覆盖 |
| Recall@K / Precision@K | 漏没漏 / 噪声多不多 | 调 Chunk 大小、topK |
| MRR / nDCG@K | 排第几 / 排序质量 | 看 Rerank 是否生效 |
| 分类型细分 | 事实/多跳/拒答各子集 | 定位短板环节 |
离线 vs 在线评估：离线用标注集（expected_chunk_ids）算上述指标；在线用 Trace 抽样 + 用户反馈（点赞/点踩）+ bad case 回流。两者互补，构成检索迭代闭环。
评估检索 = Hit/Recall/Precision 看覆盖与噪声，MRR/nDCG 看排序（验证 Rerank 生效），分类型细分定位短板。离线用标注集，在线用 Trace 抽样 + 用户反馈 + bad case 回流。
九、如何处理无答案（拒答）
知识库没有依据时，必须拒答而非硬编（详 W3D4/W3D5）：
- 检索信号：topK 相关分全低于阈值 → 直接判无答案，不进生成。
- 字段约束：输出
should_refuse=true + 理由，prompt 明确"无依据就拒"。
- 置信兜底：生成后无引用来源 → 强制拒答。
- 给出口：说明缺什么信息、建议联系谁/查哪（如"未在知识库找到该城市异地细则，请联系保单客服"）。
- 评测：should_refuse 子集测拒答精确率/召回率/F1。
无答案处理 = 检索分数阈值直接判无答案 + should_refuse 字段约束 + 无引用强制拒 + 给出口（缺什么/找谁）+ 评测拒答 P/R/F1。保险场景拒答不准比答错更危险，必须可测。
十、简历 v1 怎么写（作品一）
- 顶部摘要：36 岁，Java + 大数据 + 医疗保险背景，主导企业保险知识库 RAG（检索/生成/评测全链路）。
- 作品一：一句话成果（Faithfulness 0.94 / 拒答 F1 0.91 / 引用准确率 0.97）+ 技术栈（ES+向量混合、Rerank、Query 优化、引用溯源、角色 ACL、RAGAS/LangSmith 评测）+ 量化价值（误答降 X%、成本降 Y%）。
- 职责模块：明确你负责的（检索编排 / 评测闭环 / 拒答与 ACL），不模糊不夸大。
- 其他经历：大数据/Java 相关项目挑 1~2 个，突出"工程落地 + 数据规模"。
简历 v1：顶部摘要亮背景与作品定位；作品一用数字说话（Faithfulness/拒答/引用）+ 技术栈 + 量化价值；明确个人负责模块；其他挑 1~2 个大数据/Java 项目。每个数字口径要能当场解释。
36 岁候选人的简历策略：不讳言年龄，反而把"保险业务理解 + Java/大数据工程能力 + 能扛生产"做成差异化卖点——FDE 这类岗位恰恰需要"既懂业务又懂工程"的人，而非纯应届算法背景。
十一、市场验证投递怎么做
"市场验证"= 用真实投递检验简历与目标岗位的匹配度，而非空想。
- 少量起步：先投 5~10 个目标岗位（FDE / RAG 工程师 / AI 应用架构），观察回应率与面试官关注点。
- 分层投放：一类冲标杆公司（验证上限），一类保底匹配岗（验证下限），避免全押。
- 反馈回收：记录每家问了什么、卡在哪，回补手册薄弱点（如被深挖 ES 调优就补 W3D7 s3）。
- 迭代简历：根据面试反馈微调简历措辞与作品呈现重点。
- 不裸投：优先内推/社群，FDE 类岗位内推命中率远高于海投。
市场验证 = 少量（5~10 个）真实投递检验匹配度：分层（标杆+保底）、回收面试反馈补薄弱点、迭代简历、优先内推。目的是"用市场反馈倒逼学习"，不是海投碰运气。
① 市场验证是"少量、有回收"，不是海投 200 份——前者给你信号，后者只给你焦虑。② 投了不复盘等于白投，必须记录"被问住的点"回补。③ 别因几封拒信否定自己，FDE 岗位少而精，反馈周期长，看趋势不看单次。
十二、模拟面试常见坑
- 只讲在线不讲离线 → 被问"文档怎么进来"卡壳。
- Chunk 大小拍脑袋 → 应结合评测调。
- 说"只用向量就行" → 保险精确编码需 BM25 补。
- Rerank 和 embedding 搞混 → 前者精排交互式，后者召回双塔。
- ACL 只在生成层拒 → 必须检索前过滤。
- 文档更新只更一侧索引 → 双写同步，否则混合结果乱。
- 无答案靠关键词检测 → 应阈值+字段+评测。
- 简历数字无口径 → 被深挖就虚。
- 市场验证变海投 → 少量+回收+迭代。
十三、面试达标线①：流畅回答全部 RAG 面试问题
以下问题要能不打磕巴、有结构、带权衡、点降级地回答：
| 问题 | 核心答点 |
|---|
| RAG 完整流程 | 离线建库 + 在线问答，每环节降级点 |
| Chunk 策略怎么选 | 固定/语义/递归/父文档；大小权衡+overlap；结合评测 |
| 为什么用 ES | BM25 精确命中保险编码；成熟；Java 生态；混合底座 |
| BM25 vs 向量 | 精确匹配 vs 语义；互补 → 混合 |
| 为什么 Rerank | 混合候选量纲不一需精排；粗排→精排两段式 |
| 如何实现 ACL | 索引打标签+检索前过滤+生成校验+审计；越权 case 验 |
| 文档更新 | 版本化+增量+双写同步+失效+回归 |
| 评估检索 | Hit/Recall/Precision/MRR/nDCG + 分类型 + 在线 Trace |
| 无答案处理 | 阈值+should_refuse+给出口+评测 P/R/F1 |
| 防越权 | 检索前过滤 + 最小权限 + 评测拦截率 100% |
达标线① = 上述 10 类问题每个都能"结构化 + 带权衡 + 点降级"答出。关键不是背结论，而是讲清"为什么、不这样会怎样、生产怎么兜底"——这就是区分候选人与背题者的分水岭。
十四、面试达标线②：简历 v1 + 市场验证
14.1 简历 v1 里作品一怎么写
一句话成果(量化) + 技术栈(ES+向量混合/Rerank/Query优化/引用/ACL/评测) + 量化价值(误答降X%/成本降Y%) + 明确负责模块
- 数字可当场解释口径（Faithfulness/拒答 F1/引用准确率怎么测的）。
- 不模糊（不用"参与"）、不夸大（每个模块能深挖）。
- 突出"保险业务 + Java/大数据工程"差异化。
14.2 市场验证投递怎么做
- 少量（5~10）分层投放（标杆 + 保底），优先内推。
- 回收面试反馈，记录"被问住的点"回补手册。
- 据反馈迭代简历，看趋势不看单次拒信。
达标线② = 简历 v1 用数字讲作品一、口径可深挖、突出差异化；市场验证少量分层投放+回收反馈+迭代，用市场信号倒逼学习。两者都体现"工程闭环思维"。
十五、W3D7 自测清单
- 能口述 RAG 完整流程（离线建库 + 在线问答），并对任意环节单独展开。
- 能讲清 Chunk 策略四种及大小权衡，并说"结合评测调"。
- 能讲清为什么用 ES（BM25 精确命中 + 成熟 + Java 生态 + 混合底座）。
- 能对比 BM25 与向量检索的差异与互补，解释"只用向量不行"。
- 能讲清为什么需要 Rerank（混合候选量纲不一、粗排→精排）。
- 能区分 Rerank（交互精排）与 embedding（双塔召回）。
- 能讲清 ACL 四层实现与"检索前过滤"的必要性。
- 能讲清文档更新的版本化/增量/双写同步/失效/回归。
- 能讲清如何评估检索（指标 + 分类型 + 在线 Trace）。
- 能讲清无答案处理的完整链路与拒答评测口径。
- 能写简历 v1 里作品一（数字 + 技术栈 + 量化价值 + 负责模块）。
- 能讲清市场验证投递的做法（少量分层 + 回收 + 迭代）。
十六、高频面试题速记卡
Q：RAG 完整流程一句话？
离线把文档切 Chunk 双写 ES+向量；在线 Query优化→混合检索→Rerank→取topK→LLM生成(引用/拒答/ACL)→后校验→落Trace。
Q：Chunk 怎么切？
固定长度(带overlap)/语义/递归/父文档检索，按文档结构选；大小权衡"碎 vs 噪"，结合评测调，保险常用 512~1024 token+重叠。
Q：为什么用 ES 而不是纯向量？
保险条款有精确编码，BM25 关键词命中极准，纯向量易混淆相似条款；ES 成熟、Java 生态契合、可一套做混合检索。
Q：BM25 和向量检索区别？
BM25 关键词精确匹配(TF-IDF)，精确词准、可解释；向量语义相似，同义改写也能召回但易混淆编码、耗算力。互补→混合。
Q：为什么需要 Rerank？
混合召回候选量纲不一需统一精排。cross-encoder 对(query,chunk)交互计算更准但慢，故只排召回后的少量候选（粗排→精排）。
Q：Rerank 和 embedding 模型什么关系？
embedding 是双塔召回（快但粗），Rerank 是交互式精排（准但慢）。先 embedding 粗排召回，再 Rerank 精排 topK。
Q：怎么实现 ACL 防越权？
索引打role标签→检索前metadata过滤+前置拦截越权chunk→生成层校验越权实体并拒答→审计记Trace。越早拦越好，越权case验拦截率。
Q：文档更新要注意什么？
版本化(document_version)+增量索引+双写同步(ES与向量一致)+旧chunk标记失效+更新后跑评测回归。防脏数据和答案漂移。
Q：怎么评估检索？
Hit/Recall/Precision看覆盖与噪声，MRR/nDCG看排序(验Rerank)，分类型细分定位短板；离线标注集+在线Trace抽样+用户反馈。
Q：无答案怎么处理？
检索分数阈值直接判无答案+should_refuse字段约束+无引用强制拒+给出口(缺什么/找谁)+评测拒答P/R/F1。
FDE W3D7 学习手册 · 第一轮模拟面试（面试级）· 配合《FDE-W3D7-评测题.md》与《FDE面试备战手册》20 道模拟题
📌 待查★ 重要