# FDE W3D1 评测题 · AI 数据工程（元数据 / 血缘 / Golden Case） > 配套手册：《FDE-W3D1-AI数据工程-学习手册.html》 > 定位：W3 Day1 · A 级（必须掌握，面试核心） > 场景背景：医疗保险 / 特药理赔 / 保险知识库（候选人 36 岁，Java + 大数据 + 医疗，有 ETL / 数据治理经验） ## 评测说明 - 共 **13 题**，按难度分 4 级：**L1 基础（3 题）/ L2 进阶（4 题）/ L3 深度（3 题）/ L4 场景（3 题）**。 - 每题含：**考察点**、**评分维度**、**参考答案（`
` 折叠，点击展开）**。 - 评分采用 5 分制（0=不会 / 1=方向错 / 2=关键点缺 / 3=基本正确 / 4=完整 / 5=完整且有工程洞察）。 - 达标线见文末「评分汇总表 + 达标线」。 --- ## L1 基础（概念与定义） ### Q1（L1 基础）企业 RAG 为什么要先做数据工程，而不是先调模型？ **考察点**：理解"数据底座决定 RAG 质量天花板"，能讲清元数据/血缘解决的核心痛点。 **评分维度**： - 能否指出"检索到的 chunk 错了/旧了/版本不对，模型再强也答错"； - 能否联系医疗强合规场景谈"可溯源/可审计"的必要性； - 是否点出数据工程 ≈ ETL/数据治理经验平移。
参考答案 企业 RAG 的稳定性 80% 取决于数据工程而非模型。若 chunk 来自错误版本、被重复摄取、或无法溯源到源文件，模型再强也会基于错误上下文生成错误答案。在医疗保险这种强合规场景，每条答案都要能回答"依据哪版文件、第几页"，没有元数据与血缘就无法审计。候选人的 ETL/数据治理经验（主键、checksum、任务状态、血缘图）可直接平移到 RAG 数据工程，这是差异化优势。
### Q2（L1 基础）什么是 Document ID 和 Chunk ID？各自作用是什么？ **考察点**：区分文档级与切片级主键，理解其为血缘最小单元。 **评分维度**： - 能否说明 document_id 是一份源文档的稳定主键； - 能否说明 chunk_id 是一个切片的主键； - 是否提到 chunk 还应挂 source/page/version 等血缘字段。
参考答案 `document_id` 是一份源文档（一份 PDF/网页）的稳定主键，首次摄取生成后长期不变，可同时存业务编号。`chunk_id` 是一个切片 chunk 的主键，应由 `document_id + chunk_index + content` 派生（而非自增），保证内容不变则 ID 不变、可重建。每个 chunk 还要挂 source_file、page_no、section、doc_version、embedding_version、ingest_task_id 等血缘字段，使检索命中后能溯源与审计。
### Q3（L1 基础）文件 Hash 在摄取流程里解决什么问题？ **考察点**：理解 checksum 在去重与变更检测中的作用。 **评分维度**： - 能否说清"内容相同则 hash 相同→跳过重复"； - 能否说清"内容改了则 hash 变→触发重新摄取/失效旧版"； - 是否点出"不能靠文件名/修改时间判断变更"。
参考答案 对源文件算 SHA-256 内容指纹 `file_hash`，是判断"要不要重新摄取"的唯一可靠依据：同一内容 hash 相同→跳过重复摄取；内容修改 hash 不同→触发重新摄取并失效旧版本。不能用文件名或文件修改时间判断变更——手动 copy 会改时间、同名不同内容会漏更新。hash 还用于去重，避免同一手册被多次向量化浪费资源。
--- ## L2 进阶（设计与机制） ### Q4（L2 进阶）为什么 Chunk ID 不能用数据库自增主键？正确的派生方式是什么？ **考察点**：理解稳定 ID 对血缘/评测的重要性，能给出正确方案。 **评分维度**： - 能否指出自增主键在删除/重建后会全错位，使评测标注与引用失效； - 能否给出 `hash(document_id + chunk_index + content)` 派生方案； - 是否说明"内容不变则 ID 不变"带来的可重建好处。
参考答案 自增主键在删除某个 chunk 后重建，会让后续所有 ID 改变，导致已存的评测标注、用户反馈引用、下游引用全部错位。正确做法是让 chunk_id 与内容强绑定：`chunk_id = hash(document_id ‖ chunk_index ‖ content)`。这样内容不变 ID 就不变，删除重建不会破坏引用，且能幂等重建（同一输入必得同一 ID）。医疗理赔场景一条评测引用错位就可能导致错误结论，稳定 ID 是底线。
### Q5（L2 进阶）描述一个完整的摄取任务状态机，并说明每态要做什么。 **考察点**：能设计可观测的摄取流程，理解失败处理。 **评分维度**： - 是否列出 PENDING→PARSING→CHUNKING→EMBEDDING→INDEXING→SUCCESS/FAILED； - 每态是否对应明确动作（解析/切片/向量化/写库）； - 是否提到状态要落库、FAILED 要有去向（重试/死信）。
参考答案 状态机：`PENDING`（入队）→ `PARSING`（调 PyMuPDF/unstructured 解析）→ `CHUNKING`（切片）→ `EMBEDDING`（向量化）→ `INDEXING`（bulk 写入 ES）→ `SUCCESS`（标记 doc 可检索）或 `FAILED`。关键工程点：① 状态必须落库（任务表），进程重启/多 worker 不丢状态、不重复摄取；② FAILED 不能静默消失，要进死信队列+告警+重试；③ 每态变更记录时间戳，用于排查"用户搜不到是哪步卡住"。
### Q6（L2 进阶）document_version 和 embedding_version 有什么区别？各自变化要触发什么动作？ **考察点**：区分内容版本与向量模型版本，理解两者更新的不同处理。 **评分维度**： - 能否区分"内容改版"vs"向量模型升级"； - doc_version 变化：重摄取+软失效旧 chunk； - embedding_version 变化：全量重 embed，版本漂移率应为 0。
参考答案 `document_version` 跟踪源文档内容（如理赔手册 2025Q1→Q2 改版），变化通常伴随 file_hash 变，应触发重新摄取并将旧 version 的 chunk 标 `status=deprecated`（软失效，便于回滚审计）。`embedding_version` 跟踪向量模型（如 bge-large-zh v1.5→v2），变化意味着向量空间改变，必须对全部 chunk 重算向量，否则新旧向量混用会使召回率莫名下跌——索引中版本漂移率应为 0。旧版本用软失效而非物理删除，支持回滚。
### Q7（L2 进阶）把你的 ETL / 数据治理经验平移到 RAG 数据工程，怎么对应？ **考察点**：考察候选人差异化优势，能否用熟悉概念讲清 RAG 血缘。 **评分维度**： - 能否逐项映射（主键/checksum/任务状态/血缘/资产目录）； - 是否给出具体医疗场景示例（如特药手册血缘链）； - 是否点出"方法论相同，不是新领域"。
参考答案 一一对应：源系统/ODS 贴源层 = 原始 PDF/工单(raw_bytes)；主键/代理键 = document_id/chunk_id；checksum 校验 = file_hash；调度任务状态 = 摄取任务状态机；数据血缘图 = 源文件→解析→chunk→向量→索引全链路；元数据资产目录 = 文档元数据表+评测集版本管理。示例：一份《特药理赔手册》从 PDF 到每个 chunk 都挂 `ingest_task_id`，出问题时能定位到哪个任务的哪一步，甚至整体回滚。核心是同一套数据可信方法论，别被"AI"标签吓到重造轮子。
--- ## L3 深度（原理与权衡） ### Q8（L3 深度）切片策略会怎么影响医疗 RAG 的召回质量？给出你的设计。 **考察点**：理解切片对语义完整性的影响，能针对医疗手册设计。 **评分维度**： - 是否提到结构感知切片（保留章节层级）； - 是否提到 overlap 取值与跨页条款； - 是否提到表格单独结构化处理。
参考答案 切片直接决定召回质量。"无脑按 512 token 切"会切断"条件-例外"逻辑（如把"报销范围"和"免责条款"切到不同 chunk），模型只看半句易错误赔付。设计：① 结构感知切片，保留 §章节 层级；② overlap 取 64~128 token，避免跨页条款断裂，但不宜过大以免向量库膨胀、召回重复；③ 理赔比例表、药品目录表单独结构化存储或配多模态解析，别让模型从 OCR 噪声猜数字；④ 解析后过滤空 chunk/超短 chunk 噪声。医疗手册结构复杂，结构感知是硬要求。
### Q9（L3 深度）为什么标准答案（Golden Case 的 expected_answer）必须人工写，不能用 LLM 生成？ **考察点**：理解评测污染风险，把握评测集质量底线。 **评分维度**： - 能否指出 LLM 生成的答案本身可能错，污染评测； - 是否提到医疗答案需双人标注评审、可引用条款； - 是否区分"LLM 可辅助造问题"vs"答案必须人工"。
参考答案 Golden Case 是评测的"标尺"，若用 LLM 生成答案当 ground truth，答案本身可能含幻觉/错误，会反向污染评测——你以为系统答对了其实标准答案就错了。医疗答案更不可由模型定，必须人工撰写且可引用具体条款，最好双人标注+评审。LLM 可辅助"生成候选问题"（扩写问法），但标准答案始终人工定。这是评测集质量的铁律。
### Q10（L3 深度）评测集从 10 个长到 50 个，你怎么保证"长大"而非"注水"？ **考察点**：理解评测集覆盖度与分布，版本化管理。 **评分维度**： - 是否给出 4 种增长手段（改写/badcase/条款穷举/LLM 辅助）； - 是否强调分布贴近真实、分层覆盖； - 是否提到评测集版本化做回归对比。
参考答案 增长靠四种手段：① 问题改写（paraphrase，同意图多种口语/错别字问法）测鲁棒；② 回收线上 badcase（用户点"没帮助"/答错）针对性补强；③ 按理赔条款矩阵逐条穷举覆盖全业务；④ LLM 辅助造问（答案仍人工）。关键是"长大"要提升覆盖度而非堆数量——分布要贴近真实用户，每加一个 case 想清楚"测什么短板"，避免 50 个里 40 个问同一种药。评测集要版本化（eval_v1/v2），每次改链路跑同版做回归，前后分数才可比较。
--- ## L4 场景（医疗保险实战） ### Q11（L4 场景）运营反馈"用户搜不到最新版特药手册的内容"，请定位可能原因并给出排查链路。 **考察点**：综合应用元数据/版本/状态机知识做故障定位。 **评分维度**： - 能否从"文件改了但没重摄取"（hash 未变/任务未触发）排查； - 能否从"旧 chunk 未失效/新 chunk 未就绪"（status/deprecated）排查； - 能否从"摄取任务 FAILED/死信堆积"或"向量覆盖度<100%"排查； - 是否给出用 ingest_task_id / doc_version 定位的具体动作。
参考答案 排查链路：① 查该手册 `file_hash` 是否变化——若源文件改了但 hash 没变或摄取任务未触发，说明变更检测漏了；② 查 `doc_version` 与 chunk 的 `status`，新版本 chunk 是否都 `active`、旧版本是否 `deprecated`，可能新 chunk 没写库或旧 chunk 未失效导致检索仍命中旧版；③ 查摄取任务状态机，是否卡在 PARSING/EMBEDDING 或 FAILED 进死信；④ 查"向量覆盖度"指标，是否成功入库但 embed 失败留空向量；⑤ 用 `ingest_task_id` 拉出该次任务全链路日志定位具体步骤。每个 chunk 挂的版本与任务号是定位依据。
### Q12（L4 场景）监管要审计"某条拒赔结论依据的是哪一版、哪页的条款"，你的数据工程如何支撑？ **考察点**：理解血缘/可审计性在医疗合规中的落地。 **评分维度**： - 能否说明 chunk 挂 source_file/page_no/section/doc_version； - 能否说明答案引用回 chunk_id→document_id→版本； - 是否提到旧版本软失效保留审计链、可回滚。
参考答案 每个 chunk 在 metadata 中挂 `source_file / page_no / section / doc_version / document_id / chunk_id / ingest_task_id`。检索命中后，答案可直接附"依据《特药理赔手册》v2025Q2 第 38 页 第三章"。监管追问时，用 chunk_id→document_id→doc_version 完整回溯到源文件与生效时间。旧版本用 `status=deprecated` 软失效而非物理删除，保留完整审计链，必要时一键回滚到指定版本应对质疑。这正是血缘设计在强合规场景的价值。
### Q13（L4 场景）你要为特药理赔知识库设计前 10 个 Golden Case，给出配方与其中 2 个示例（含应召回 chunk 与标签）。 **考察点**：能落地构造高质量种子评测集。 **评分维度**： - 配方：6 正常 + 2 边界 + 2 拒答，覆盖不同章节，双人评审； - 示例是否含 query/expected_answer/expected_chunks/标签； - 是否体现医疗场景真实性（靶向药/ICD/保单号）。
参考答案 配方：6 个高频正常问答（靶向药报销/住院/门急诊）+ 2 个边界值 + 2 个应拒答（should_refuse=true），覆盖不同章节，双人标注评审，先小而精当标尺。 示例1（正常）：query="EGFR 突变的肺癌患者用奥希替尼能报多少？"；expected_answer="限用于 EGFR 突变阳性晚期 NSCLC，年度报销上限 X 万，需事前审批"；expected_chunks=[c_8f3a...（第三章靶向药报销范围）]；标签=场景:特药,难度:中。 示例2（拒答）：query="我买的境外游意外险能报特药吗？"；expected_answer="知识库未收录境外游意外险特药条款，无法判断"；expected_chunks=[]；标签=should_refuse:true,场景:拒答。覆盖"该拒答时拒答"的能力测试。
--- ## 评分汇总表 | 题号 | 等级 | 考察点 | 满分 | |------|------|--------|------| | Q1 | L1 基础 | 数据工程为什么优先 | 5 | | Q2 | L1 基础 | Doc/Chunk ID 定义与作用 | 5 | | Q3 | L1 基础 | file_hash 去重与变更检测 | 5 | | Q4 | L2 进阶 | chunk_id 派生 vs 自增 | 5 | | Q5 | L2 进阶 | 摄取任务状态机 | 5 | | Q6 | L2 进阶 | doc_version vs embedding_version | 5 | | Q7 | L2 进阶 | ETL 经验平移 RAG | 5 | | Q8 | L3 深度 | 切片策略与医疗召回 | 5 | | Q9 | L3 深度 | 标准答案必须人工 | 5 | | Q10 | L3 深度 | 评测集 10→50 不注水 | 5 | | Q11 | L4 场景 | 搜不到最新版排查 | 5 | | Q12 | L4 场景 | 合规审计血缘支撑 | 5 | | Q13 | L4 场景 | 前 10 个 Golden Case 设计 | 5 | | **合计** | — | — | **65** | ### 达标线 - **合格线（L1+L2 全对 + L3 基本正确）**：总分 ≥ 45，且 L1/L2 不得有 0~1 分题。能讲清元数据设计为什么重要（达标线①）。 - **优秀线（面试通过）**：总分 ≥ 55，L3/L4 能完整回答并展现工程洞察（如版本漂移、评测污染、合规审计）。能讲清 Golden Case 怎么造、评测集怎么从 10 长到 50（达标线②）。 - **一票否决**：无法解释 chunk_id 为何不能自增、或认为可用 LLM 生成标准答案当 ground truth —— 直接判不合格（基础认知错误）。 > 自评方法：先口头作答，再展开 `
` 对照；L3/L4 答不全的回到手册对应章节（s2/s3/s4/s9/s10/s12/s13）重读「🎤面试话术」「⚠易错点」。