# FDE W3D7 评测题 · 第一轮模拟面试（A 级） > candidate: 36 岁，Java + 大数据 + 医疗保险背景，目标 FDE。 > 场景统一用「医疗保险 / 特药理赔 / 保险知识库」。 > 评分维度通用：①结构化表达 ②带权衡与降级 ③结合业务 ④可深挖。每题满分 5 分。 --- ## L1 基础（流程与召回） ### Q1. 请口述 RAG 完整流程，并能单独把"离线建库"那段讲清楚。 - **考察点**：全链路表达 + 离线环节。 - **评分维度**：在线/离线都覆盖；能单独展开文档解析→切分→双写索引；点出降级。
参考答案 完整流程：离线把文档解析→按策略切 Chunk→双写 ES(BM25)与向量库；在线用户问→Query 优化→混合检索(BM25+向量)→Rerank→取 topK→LLM 生成(引用/拒答/ACL)→后校验→落 Trace。离线那段：文档解析（RAGFlow 深度解析表格/扫描件）→递归/语义切分(512~1024 token+overlap)→分别写入 ES 与向量索引，保证两套同步。任一环节要有降级（Rerank 挂降级纯向量、Query 优化挂降级原 query）。
### Q2. Chunk 策略有哪几种？怎么选大小？为什么不能拍脑袋定？ - **考察点**：Chunk 策略与调参方法。 - **评分维度**：四种策略；大小权衡(碎vs噪)；结合评测调而非拍脑袋。
参考答案 策略：固定长度(带 overlap)、语义切分(按句/段/标题)、递归切分(逐级)、父文档检索(小块召回大块返回)。大小权衡：太小语义断、上下文碎；太大噪声多、超 token、召回不精。保险条款常用 512~1024 token + 重叠防边界切断。不能拍脑袋——要用评测集看不同 Chunk 大小下的 Recall@K，选指标最优且成本可接受的，并配合 overlap 平衡。
### Q3. 为什么用 Elasticsearch 而不是只用向量库？ - **考察点**：ES/BM25 的选型理由。 - **评分维度**：BM25 精确命中保险编码；成熟稳定；Java 生态；可一套做混合。
参考答案 保险条款含大量精确术语（条款号、病名、药品编码、金额），BM25 关键词命中极准、可解释，纯向量易把"相似但不同"的条款混淆（如奥希替尼 vs CAR-T 比例）。ES 成熟稳定、与 Java 团队栈契合、运维成本低，且能同时存 BM25 与 dense_vector，一套系统做混合检索，省维护。所以选 ES 做底座而非另起纯向量库。
--- ## L2 进阶（检索机制） ### Q4. BM25 和向量检索的本质区别是什么？为什么需要混合？ - **考察点**：两种检索的差异与互补。 - **评分维度**：BM25 关键词/TF-IDF vs 向量语义；各自优劣；互补→混合。
参考答案 BM25 是词面精确匹配，按 TF-IDF 加权，对精确术语/专有名词极准、可解释，但不懂语义、同义改写召回差。向量检索是语义相似（近义/改写也能匹配），但精确编码易混淆、耗算力、黑盒。二者优劣互补：BM25 补精确命中、向量补语义泛化，故用混合检索（ES+向量），再 Rerank 融合，兼顾"准"与"全"。
### Q5. 为什么需要 Rerank？它和 embedding 模型是什么关系？ - **考察点**：Rerank 的必要性及与召回模型区别。 - **评分维度**：混合候选量纲不一需精排；Rerank=交互式精排、embedding=双塔召回；粗排→精排。
参考答案 混合检索召回的是多路候选，分数量纲不同不能直接比，且 top 里可能混不相关，需统一精排。Rerank 用 cross-encoder 对(query, chunk)交互计算精细相关性，比双塔 embedding 准但慢，所以只排召回后的少量候选。关系：embedding 是双塔召回（快但粗，先粗排召回 topN），Rerank 是交互式精排（准但慢，再精排 topK），标准两段式。融合可用 RRF。
### Q6. 怎么评估检索效果？离线评估和在线评估分别怎么做？ - **考察点**：检索评估方法论。 - **评分维度**：指标(Hit/Recall/Precision/MRR/nDCG)+分类型；离线标注集 vs 在线 Trace/反馈。
参考答案 离线：用标注集（expected_chunk_ids）算 Hit Rate@K（有没捞到）、Recall@K/Precision@K（漏没漏/噪声）、MRR/nDCG@K（排序质量，验证 Rerank 生效），并分类型（事实/多跳/拒答）细分定位短板。在线：Trace 抽样看实际召回与分数、用户点赞/点踩反馈、bad case 回流。两者互补成检索迭代闭环。
--- ## L3 深度（ACL / 更新 / 拒答） ### Q7. 如何实现 ACL、防止知识库越权？为什么不能在生成层"嘴上拒答"就完事？ - **考察点**：ACL 实现层次与前置拦截必要性。 - **评分维度**：四层（索引标签/检索过滤/生成校验/审计）；检索前过滤；越权 case 验。
参考答案 四层：①索引层给文档打 role/document_scope 标签；②检索层用 metadata filter 按角色过滤 + 前置拦截越权 chunk（越早拦越好）；③生成层校验问题是否涉及越权实体（如他人保单号）并 should_refuse 拒答；④审计层记录谁查了什么、是否触发拦截。不能只在生成层拒：越权 chunk 一旦进 context，模型可能无意泄露或借题发挥，必须从检索前就过滤，并用 allowed_roles 越权 case 验证拦截率 100%。
### Q8. 文档更新（如条款修订）要怎么处理，才能避免脏数据和答案漂移？ - **考察点**：文档更新工程。 - **评分维度**：版本化/增量/双写同步/失效/回归；五点齐全。
参考答案 ①版本化：每篇文档带 document_version，更新生成新版本可回滚；②增量索引：只重解析变更文档、更新对应 chunk，不重建全库；③双写同步：ES 与向量库一起更新，避免一侧旧一侧新导致混合结果错乱（原子同步）；④旧 chunk 标记失效而非物理删（保留审计）；⑤更新后跑评测集回归确认指标未退化再放量。并发更新要处理队列/锁防半更新。
### Q9. 无答案时怎么处理？拒答的"该拒却答"和"该答却拒"怎么平衡？ - **考察点**：无答案处理与拒答权衡。 - **评分维度**：阈值+should_refuse+给出口+评测；P/R 平衡两类错误。
参考答案 处理：①检索分数阈值——topK 相关分都低于门槛直接判无答案不进生成；②结构化 should_refuse 字段 + prompt 约束"无依据就拒"；③置信度兜底——生成后无引用来源强制拒；④给出口（缺什么信息、建议找谁）；⑤评测 should_refuse 子集测精确率/召回率/F1。平衡：阈值太高→该答却拒（漏答，查召回）；太低→该拒却答（幻觉，查精确率），用评测集校准，同时看 P 和 R。
--- ## L4 场景（医疗保险 + 简历 + 市场） ### Q10. 场景：面试官问"如果只用向量检索，你的保险知识库会出什么具体问题？"请举例。 - **考察点**：结合业务讲技术选型后果。 - **评分维度**：能举"相似条款混淆"实例（如奥希替尼 vs CAR-T 比例）；联系失败案例。
参考答案 纯向量会把语义相近但不同的条款排前。例如用户问"奥希替尼报销比例"，向量可能把"CAR-T 疗法定向药报销 80%"的条款排到前面（二者都是肿瘤靶向治疗、语义接近），导致答成 80% 而实际奥希替尼是 60%，且引用错位。BM25 靠精确命中"奥希替尼"病名/编码可避免。这正是我们作品一早期失败案例，修复用混合检索+Rerank+引用校验。
### Q11. 场景：现场画架构讲"企业保险知识库"，并说明每个环节的降级点。 - **考察点**：架构讲解 + 生产降级意识。 - **评分维度**：分层清晰；每个环节标降级；结合保险合规(ACL/Trace)。
参考答案 架构：文档解析(RAGFlow)→双写 ES+向量→Query 优化→混合检索→Rerank→生成(引用/拒答/ACL)→评测闭环。降级点：Query 优化挂→降级原 query；Rerank 挂→降级纯向量 topK；某索引挂→另一索引单路兜底；生成超时→返回"暂无法回答"并落 Trace。可靠性：ACL 前置防越权、Trace 全链路可审计（保险合规硬要求）。结合 Java 栈讲 ES 编排可控。
### Q12. 场景：简历 v1 里作品一怎么写，被追问"Faithfulness 0.94 怎么测的"怎么答？ - **考察点**：简历呈现与口径可深挖。 - **评分维度**：数字+技术栈+量化价值+负责模块；能解释 Faithfulness 测法(RAGAS/LLM裁判+人工抽检)。
参考答案 简历：一句话成果（Faithfulness 0.94/拒答 F1 0.91/引用 0.97）+ 技术栈（ES+向量混合、Rerank、Query 优化、引用溯源、角色 ACL、RAGAS/LangSmith 评测）+ 量化价值（误答降 X%、成本降 Y%）+ 明确负责模块。被追问口径：Faithfulness 基于 50 条测试集，用 RAGAS 的 claim 抽取+逐 claim 验证（LLM 裁判）算"答案被上下文支持的比例"，关键子集人工抽检校准偏差，document_version 固定保证可比。
### Q13. 场景：你准备怎么做"市场验证投递"？为什么强调"少量 + 回收"？ - **考察点**：市场验证方法论。 - **评分维度**：少量分层投放+内推；回收反馈补薄弱点；迭代简历；反对海投。
参考答案 做法：先投 5~10 个目标岗位（FDE/RAG 工程师/AI 应用架构），分层（标杆公司验上限 + 保底匹配验下限），优先内推/社群（命中率高于海投）。回收：记录每家问了什么、卡在哪，回补手册薄弱点（如被深挖 ES 调优就补 W3D7 s3）；据反馈迭代简历措辞与作品呈现。强调"少量+回收"是因为市场验证目的是"用信号倒逼学习"，海投 200 份只制造焦虑、无有效反馈，看趋势不看单次拒信。
--- ## 评分汇总表 | 题号 | 层级 | 主题 | 满分 | 候选得分 | 备注 | |------|------|------|------|----------|------| | Q1 | L1 | RAG 完整流程 | 5 | | | | Q2 | L1 | Chunk 策略 | 5 | | | | Q3 | L1 | 为什么用 ES | 5 | | | | Q4 | L2 | BM25 vs 向量 | 5 | | | | Q5 | L2 | Rerank 必要性 | 5 | | | | Q6 | L2 | 检索评估 | 5 | | | | Q7 | L3 | ACL 防越权 | 5 | | | | Q8 | L3 | 文档更新 | 5 | | | | Q9 | L3 | 无答案处理 | 5 | | | | Q10 | L4 | 纯向量后果举例 | 5 | | | | Q11 | L4 | 架构+降级讲解 | 5 | | | | Q12 | L4 | 简历 v1 口径 | 5 | | | | Q13 | L4 | 市场验证投递 | 5 | | | | **合计** | | | **65** | | | ### 达标线 - **L1+L2 全对（基础达标）**：能口述 RAG 流程、讲清 Chunk 策略与 ES 选型、对比 BM25 与向量、解释 Rerank 与检索评估。 - **L3 两题以上达标（进阶达标）**：能讲清 ACL 四层实现、文档更新五要点、无答案拒答的 P/R 平衡。 - **L4 两题以上达标（实战达标 / 面试通过线）**：能结合保险举例讲技术后果、现场画架构带降级、用数字写简历且口径可深挖、讲清市场验证方法。 - **总分建议**：≥52/65（80%）为"熟练"；40~52 为"基本掌握需补强"；<40 为"不达标，重学手册"。 --- > 配套学习手册：`FDE-W3D7-第一轮模拟面试-学习手册.html` > 参考：《FDE面试备战手册》20 道模拟题；B站 Spring AI 第 57-77 集 RAG 全套 BV1GfyGBqEm6。