FDE W3D1 学习手册 · AI 数据工程（元数据 / 血缘 / Golden Case）

W3 Day1 · A 级（必须掌握，面试核心）· 5h · 学完能讲透"企业 RAG 的数据底座：从一份 PDF 到可追溯、可重跑、可评测的索引"

一、企业 RAG 数据工程全景：为什么元数据是地基

很多人以为 RAG = "切 chunks → 灌向量库 → 检索"，但企业级 RAG 真正的难点不在模型，而在数据底座。一份《特药理赔手册》PDF 从上传到可检索，要经历「摄取（Ingestion）→ 解析 → 切片 → 向量化 → 入库 → 版本管理 → 评测」一长串环节，每一步都可能丢失信息或引入错误。

如果阶段之间没有可靠的元数据串联，就会出现：查到一个 chunk 却不知道它来自哪份文件、哪个版本；文件更新后旧向量还在；评测出错了却无法定位是哪份源文档导致的。元数据的本质就是数据血缘（Data Lineage）。

二、Document ID 与 Chunk ID：血缘的最小单元

2.1 设计原则

2.2 为什么 Chunk ID 不能简单用自增

如果用数据库自增主键，删除一个 chunk 后重建会改变所有后续 ID，导致已存的"评测标注""用户反馈"引用失效。正确做法是让 chunk_id 与内容强绑定（如 sha1(document_id + chunk_index + text)），内容不变 ID 就不变。

2.3 Chunk 还要挂哪些元数据

{
  "chunk_id": "c_8f3a...",
  "document_id": "d_1b2c...",
  "chunk_index": 12,
  "content": "特药『奥希替尼』限用于 EGFR 突变阳性...",
  "source_file": "特药理赔手册_2025Q2.pdf",
  "page_no": 38,
  "section": "第三章 靶向药报销范围",
  "doc_version": "v2025Q2",
  "embedding_version": "bge-large-zh-v1.5",
  "ingest_task_id": "task_20250701_009",
  "created_at": "2025-07-01T10:22:00Z"
}

三、文件 Hash 与摄取任务状态机

3.1 文件 Hash：去重与变更检测

对源文件计算 内容 Hash（如 SHA-256），是判断"要不要重新摄取"的唯一可靠依据。文件名相同、内容改了，Hash 不同 → 触发更新；文件名不同、内容一样 → Hash 相同 → 跳过重复。

3.2 摄取任务状态机

一个摄取任务从提交到完成，应有明确状态，便于可观测与失败重试：

四、文档版本与 Embedding 版本：变更可追踪

4.1 两套版本

• document_version：源文档内容的版本。如《特药理赔手册》2025Q1 → 2025Q2 因目录调整改版。改版后应保留旧版本可回滚，且新版本上线要失效旧 chunk。
• embedding_version：向量模型的版本。如 bge-large-zh v1.5 → v2。模型升级后所有 chunk 的向量都要重算，否则新模型检索空间里混着旧向量，召回质量崩。

4.2 版本与 Hash 的关系

4.3 旧版本怎么失效

不能物理删除旧 doc（要保留审计），而是把旧 version 的 chunk 标记为 status=deprecated，检索时 filter status=active 即可。回滚时把新版本标 deprecated、旧版本恢复 active。

五、结合 ETL / 数据治理经验设计血缘（医疗保险场景）

你有 Java + 大数据 + 医疗保险（ETL/数据治理）背景，这正是 RAG 数据工程的"现成资产"。把传统数仓血缘思想平移过来：

5.1 一个医疗理赔血缘示例

特药理赔手册_2025Q2.pdf
  └─ file_hash: 9f2a...            (去重/变更检测)
  └─ ingest_task: task_0701_009    (PARSING→CHUNKING→EMBEDDING→SUCCESS)
      └─ document_id: d_1b2c...   (doc_version=v2025Q2)
          ├─ chunk_12 (page 38, §靶向药报销范围) ─┐
          ├─ chunk_13 (page 39)                   ├─ embedding_version=bge-large-zh-v1.5
          └─ chunk_14 (page 39) ──────────────────┘      → vectors 写入 ES index=claim_kb
                                                      （全部挂 ingest_task_id，可整体回滚）

六、摄取管道骨架与解析策略（PDF / 特药手册）

6.1 典型摄取管道

6.2 切片策略（医疗手册特有关注）

• 固定窗口 + 重叠：通用做法，overlap 保留跨段语义。医疗条款常跨页，overlap 要够大。
• 按结构切：保留标题层级（§章/节），避免把"报销范围"和"免责条款"切到一个 chunk 而丢失上下文。
• 表格单独处理：理赔比例表、药品目录表要保留为结构化 chunk 或存为表格字段，别让模型从 OCR 噪声里猜数字。

def chunk_document(doc, max_tokens=512, overlap=64):
    blocks = doc.structure_aware_blocks()   # 保留 §章节 结构
    chunks, buf, idx = [], [], 0
    for b in blocks:
        if len(buf) + len(b) > max_tokens:
            chunks.append(build_chunk(doc.doc_id, idx, buf))
            buf = buf[-overlap:]; idx += 1
        buf += b
    if buf: chunks.append(build_chunk(doc.doc_id, idx, buf))
    return chunks

七、LangChain Document 元数据规范

LangChain 的 Document 对象天然是 { page_content, metadata } 结构，正好承载我们的血缘字段。规范好 metadata schema 是团队协力的前提。

from langchain_core.documents import Document

doc = Document(
    page_content="特药『奥希替尼』限用于 EGFR 突变阳性...",
    metadata={
        "document_id": "d_1b2c...",
        "chunk_id": "c_8f3a...",
        "chunk_index": 12,
        "source_file": "特药理赔手册_2025Q2.pdf",
        "page_no": 38,
        "section": "第三章 靶向药报销范围",
        "doc_version": "v2025Q2",
        "embedding_version": "bge-large-zh-v1.5",
        "file_hash": "9f2a...",
        "ingest_task_id": "task_0701_009",
        "status": "active"
    }
)

7.1 为什么要收敛 metadata schema

• 检索可过滤：metadata 是后续 metadata_filter（按部门/版本/状态过滤）的数据基础（W3D3 权限章节要用到）。
• 可观测：所有 chunk 字段一致，监控系统才能统一统计。
• 可迁移：换向量库（ES→Milvus）时 schema 稳定，迁移成本低。

八、PyMuPDF / unstructured 解析实战

8.1 PyMuPDF（pymupdf）：精确控制 PDF

• 优点：快、能精确拿到 page number、坐标、表格，适合结构化要求高的医疗手册。
• 用法：逐页 page.get_text("dict") 拿到带层级的文本块，可保留章节结构。

import fitz  # PyMuPDF
doc = fitz.open("特药理赔手册_2025Q2.pdf")
for i, page in enumerate(doc):
    blocks = page.get_text("dict")["blocks"]   # 带层级结构
    for b in blocks:
        if b["type"] == 0:   # 文本块
            text = b["text"]
            # 记 page_no=i+1，可定位到手册页码

8.2 unstructured：多格式统一抽取

• 优点：一套 API 处理 PDF/HTML/Word/图片，自动做标题识别、表格提取，适合数据源杂的企业。
• 用法：partition_pdf(..., strategy="hi_res") 配合 OCR 处理扫描件（医疗理赔常遇扫描件）。

from unstructured.partition.pdf import partition_pdf
elements = partition_pdf("特药理赔手册.pdf", strategy="hi_res",
                         infer_table_structure=True)
for el in elements:
    print(el.category, el.text)   # Title / NarrativeText / Table

九、Golden Case 的构成与采集方法

Golden Case（黄金样本）是人工精心构造的"标准答案评测对"，是评测集的种子。一个合格的 Golden Case 至少包含：

9.1 怎么"造"前 10 个

1. 从真实日志挖：翻客服工单、搜索日志，挑高频 + 有代表性的问题。
2. 从业务规则反推：每条理赔条款写 1~2 个对应问题（如"靶向药报销范围"→ 问奥希替尼）。
3. 覆盖边界与拒答：至少 2 个"知识库没有"应拒答的 case，测拒答能力。
4. 双人标注 + 评审：医疗答案不能一人说了算，答案要可解释、可引用条款。

十、评测集从 10 → 50 的演进策略

Golden Case 是种子，评测集（Evaluation Set）要长大才能反映真实分布。演进路径：

10.1 增长手段

10.2 评测集要像代码一样版本化

评测集本身也要有版本（eval_v1 / eval_v2），每次改 RAG 链路都跑同一版本评测集，才能横向对比。这就是"评测即回归测试"。

十一、数据质量与血缘可观测性

数据工程上线后要有"体检指标"，否则你不知道知识库是健康还是腐烂。

十二、面试达标线①：企业 RAG 数据工程的元数据设计为什么重要

十三、面试达标线②：Golden Case 怎么造、评测集怎么从 10 长到 50

1. Golden Case 构成：query + 标准答案（人工）+ 应召回 chunk_id + 标签（场景/难度/should_refuse）。
2. 前 10 个配方：6 正常 + 2 边界 + 2 拒答，覆盖不同章节，双人评审。
3. 长到 50：改写扩鲁棒、badcase 补强、条款矩阵穷举、LLM 造问人工筛；评测集版本化，每次改动跑同版做回归对比。
4. 铁律：标准答案必须人工写，绝不用 LLM 生成答案当 ground truth；评测集分布要贴近真实，不为凑数。

十四、W3D1 自测清单

十五、高频面试题速记卡