2. 保险数据体系概览
在保险模型的生命周期中，数据血缘与可重复计算之所以困难，根源并不在算法本身，而在于保险数据体系本身的复杂性。保险是典型的“长周期、多主体、强监管、高异构”行业：一份保单从投保、核保、承保、缴费、保全、理赔到再保结算，跨越数年甚至数十年，数据在数十个系统之间流转、复制、加工和沉淀。理解这套体系的全貌，是后续建立血缘追踪与可重复计算能力的前提。
一、核心原理：保险数据的三个来源层次
保险数据并非来自单一数据库，而是按“产生方式”分为三个层次，每一层的血缘特征和可重复性要求截然不同。
- 业务交易层（OLTP）：核心承保系统、理赔系统、收付费系统、保全系统。数据由业务动作直接产生，是血缘的“源头”。特点是强事务、强一致性、字段规范，但表结构高度范式化，单条记录信息碎片化。
- 数据仓库与集市层（DW/Data Mart）：通过ETL/ELT将交易层数据按主题域整合，形成保单粒度、客户粒度、险种粒度的宽表。这一层是模型训练的主要数据来源，也是血缘最复杂、最容易断裂的地方。
- 外部与衍生层：包括再保公司结算数据、第三方渠道数据、精算假设表、监管报送口径、以及由模型自身产出的特征与评分。这一层往往缺乏统一的主键，是数据质量问题的重灾区。
核心判断：血缘追踪的起点不是“表”，而是“业务事件”。一张保单的保费变化，可能同时来自批改、退保、红利分配三个事件，若只按表级血缘追踪，必然丢失语义。
二、数据类型：结构化、半结构化与非结构化并存
保险数据体系中的数据类型跨度极大，直接决定了血缘解析与重算策略的差异。
| 数据类型 | 典型内容 | 血缘特征 | 重算难点 |
|---|---|---|---|
| 结构化 | 保单主表、缴费流水、理赔明细、准备金结果 | 字段级血缘清晰，可解析SQL | 口径变更后历史数据是否回溯 |
| 半结构化 | 核保问卷JSON、渠道回传报文、理赔影像索引 | 字段动态，血缘依赖解析规则 | Schema漂移导致重算结果不一致 |
| 非结构化 | 理赔病历、事故照片、客服录音、条款PDF | 血缘以“引用关系”存在 | 模型输入不可复现，需版本化存储 |
| 衍生/特征 | 风险评分、客户标签、精算因子 | 血缘跨模型，存在循环依赖风险 | 特征版本与模型版本必须绑定 |
值得注意的是，非结构化数据在保险模型中的占比正在快速上升，尤其是理赔反欺诈和核保风险识别场景。这类数据一旦进入特征工程，血缘就不再是“字段到字段”，而是“文件版本到特征版本到模型版本”的链式关系。
三、方法流程：从数据源到可重算的链路梳理
建立保险数据体系概览，建议按以下流程推进，而不是一上来就画全量血缘图。
- 识别关键业务事件：列出承保、批改、理赔、给付等核心事件，作为血缘的语义锚点。
- 映射事件到数据表：明确每个事件写入哪些系统、哪些表、哪些字段，形成“事件—表”矩阵。
- 标注数据层级与类型：区分交易层、仓库层、衍生层，标注结构化程度。
- 定义重算边界：确定哪些数据可重放、哪些只能快照、哪些必须版本化冻结。
- 建立质量规则与血缘联动：每条质量规则绑定到具体字段和上游来源，便于问题定位。
-- 示例：保单保费血缘的最小可重算视图
SELECT
p.policy_id,
p.effective_date,
e.event_type, -- 承保/批改/退保
e.event_time,
e.premium_delta,
SUM(e.premium_delta) OVER (
PARTITION BY p.policy_id
ORDER BY e.event_time
) AS cumulative_premium
FROM policy_master p
JOIN premium_event e
ON p.policy_id = e.policy_id
WHERE e.event_time <= :as_of_date;
这段SQL体现了一个关键原则：可重复计算依赖于“事件序列+时间切片”，而不是依赖某张宽表的当前状态。只要事件表完整且时间戳可信，任意历史时点的保费都可以重算。
四、数据质量挑战与常见误区
保险数据质量问题的特殊性在于：很多问题不是“脏数据”，而是“语义不一致”和“时间不一致”。
- 主键不统一：同一客户在承保、理赔、客服系统中可能有三个不同ID，导致血缘断裂。
- 时间戳口径混乱：发生时间、入账时间、系统写入时间、批处理时间混用，重算时无法对齐。
- 口径漂移：监管报送口径、精算假设、渠道结算规则每年调整，历史数据未回溯，导致新旧结果不可比。
- 缺失值被“默认填充”：如职业类别缺失填“其他”，看似完整，实则引入系统性偏差。
- 衍生数据反向污染：模型评分被写回业务表后，又被下一轮训练当作原始特征使用，形成隐性循环。
复盘提示：在多个保险数据项目中，最容易被忽视的不是ETL报错，而是“批处理重跑后结果不一致”。根因往往不是代码，而是上游某个外部接口数据在两次运行之间发生了变化，而该接口没有版本快照。
实践建议：对每一个进入模型的关键字段，至少记录三项元数据——来源系统、首次写入时间、最近一次口径变更时间。这三项信息足以支撑80%的血缘排查场景。
这张图揭示了保险数据体系的一个基本规律：越靠近业务交易层，数据越规范、血缘越清晰；越靠近外部与衍生层，数据越异构、血缘越脆弱、质量风险越高。因此，血缘治理和可重复计算的投入，应当优先放在仓库层与衍生层的交界处——那里既是模型的主要输入，也是问题最集中的地方。