4. 批次概念与批次数据特征
说实话，做知识图谱的人，很多人一上来就盯着实体、关系、属性这些概念。但做了几年你就会发现，批次这个事儿才是质控的根基。它不炫酷，可一旦乱了，后面怎么做都是空中楼阁。
什么叫批次？说白了，就是我们给药学数据打的“生产批号”。我当年刚接触这个领域时，也犯过糊涂，觉得不就是一批数据么，有什么好说的。直到有一次，一个质控同事问我：“这批数据提取的版本是多少？” 我才意识到，没有批次，连版本都说不清。
4.1 什么是“批次”
在药物知识图谱里，批次不是产品包装上的那个生产批号。它是我们从源头采集到结构化加工，再到质检的一个完整数据单元。你把一批数据看作一次“生产动作”的结果就好理解了。
举个例子：
- 从某药企官网，用爬虫抓取了全部药品说明书
- 用NLP模型抽取出成分、适应症、禁忌这些信息
- 按照图谱schema做结构化入库
这一整条链路下来的产出，才算一个完整的批次。我个人的习惯，每个批次里都会记录这几个字段：
| 字段 | 含义 |
|---|---|
| batch_id | 批次唯一标识，比如 BATCH_20240510_A |
| source_name | 数据来源，比如“CDE官网”“某药企API” |
| pipeline_version | 处理管线的版本号，比如 v2.3.1 |
| run_timestamp | 批次开始执行的时间戳 |
| record_count | 本批次包含的记录数 |
4.2 为什么要引入批次概念
你想想看，没有批次会怎样？
数据每天都在更新，昨天抓的说明书和今天的可能不一样。如果它们混在一起，你根本没法定位问题。比如某条药品的“用法用量”字段突然变成了空值，到底是抽取模型出了bug，还是源头页面改了结构？
批次就是帮我们做“版本化”的。 我建议每个批次的边界要足够清晰。通常我们按这个规则划分：
- 按来源拆分：不同来源的数据不要混成一个批次
- 按时间窗拆分：比如每天凌晨跑一次，每个天窗就是一个独立批次
- 按处理管线拆分：不同版本的处理流程，产出的数据应分属不同批次
我曾经遇到一个项目，为了图省事，把CDE官网和某个开源数据集合在一起建了个大批次。结果后面发现一半的“生产单位”字段对不上，排查了整整两天才知道是两套数据源的定义冲突了。从那以后，我再也不敢合并批次了。
4.3 批次数据的核心特征
我接触过的项目中，批次数据有四个特征最需要关注。你可以拿这个清单去检查自己的批次设计：
- 一致性：同一个批次内，数据处理管线、参数、模型权重必须一致。哪怕只改了一个阈值，也要开新批次。
- 可复现性：给定批次ID，我们可以用同样的配置和数据源，重新跑出一模一样的结果。
- 可追溯性：从最终图谱的任意一条三元组，都能查到它属于哪个批次，以及该批次的处理日志。
- 不变性：批次一旦完成质检并发布，其内容不能修改。要改，就生成新批次。
核心原则：批次是只写的。写入后只能查询，不能删除或更新。
我的经验：在数据库设计里，给批次表加一个 is_published 字段。只有 is_published=false 时允许回滚和重跑。发布后马上锁定。
4.4 批次划分的常见模式
不同场景下，批次划分的策略不太一样。我整理了几个常用模式：
避免这两个坑：
- 不要用“全量+增量”混在一个批次里
- 不要用日期作为唯一批次标识，万一当天跑了两遍呢？
# 一个简单的批次划分规则，用Python伪代码表示
if source == "CDE":
batch_id = f"CDE_{date}_{run_seq}"
elif source == "DrugBank_dump":
batch_id = f"DBANK_{version}_{sha256[:8]}"
else:
raise ValueError("未知来源，需分配新批次方案")你可能会问，为什么要加 run_seq？我记得有一次，调度系统因为网络抖动，同一个来源一天内重跑了三次。如果没有 run_seq，后面三个批次的数据会完全覆盖彼此的记录，根本没法对账。
4.5 批次数据质量检查清单
每个批次生成后，我一般会先跑几项快速检查。这些检查不需要很复杂，但能拦住绝大多数低级错误：
| 检查项 | 检查方法 | 预期值 |
|---|---|---|
| 记录数波动 | 对比上一批次记录数 | 差异不超过 ±20% |
| 必填字段缺失率 | 扫描全部三元组 | 缺失率 < 1% |
| 数据源一致性 | 抽查 100 条实体，确认来源字段 | 全部匹配 |
| Schema 合规 | 使用预定义的类型约束校验 | 0 条违规 |
一个小技巧：把检查清单写成可执行的脚本，每次批次生成后自动触发。我习惯在 CI/CD 的 pipeline 里加一个 stage 叫 batch_health_check，不通过就不允许发布。
4.6 批次生命周期与质控全景
来看一张图，这是批次从创建到归档的完整流向，也是后续各章节的系统性框架。每个方框代表一个可执行步骤，红框表示质控干预点：
这张图里你可能注意到了，整条链路中红框都是质控节点。每个批次走过这些节点时，必须停下来接受检查。我见过很多团队只在一个节点做质控——通常是入库前。结果下游问题不断，改起来加倍吃力。
嗯，回到批次概念本身。今天我们讲的很多东西，在后面的章节都会反复用到。尤其是当你开始写规则引擎、做数据校验、跑统计分析时，你会发现批次的边界越清晰，质控的执行就越简单。