1. 课程导入

在保险精算、准备金评估、偿付能力计量与经营分析中，模型结果往往被直接用于定价、分红、再保安排和监管报送。但一个现实问题是：当监管问“这个数是怎么来的”，或者业务方问“为什么上个月和这个月差这么多”，很多团队只能给出“模型跑出来的”这种回答。本课程要解决的，正是让保险模型从“算得出”走向“算得清、算得稳、可复现”。

学习目标

完成本课程后，你应当能够独立完成以下四类任务：

• 看得见：为保险模型建立字段级、表级、任务级的数据血缘，明确每个指标的上游来源与下游影响。
• 说得清：用统一口径描述模型输入、参数、假设、计算逻辑与输出，形成可审计的模型链路。
• 算得稳：通过版本锁定、环境隔离、随机种子与参数快照，保证同一输入在任意时间重跑得到一致结果。
• 查得快：当结果异常时，能沿血缘反向定位到具体源表、字段、参数或代码提交，而不是全链路盲查。

三个核心概念

数据血缘（Data Lineage）：描述数据从产生、加工、流转到消费的全路径关系。在保险场景中，它既包括“保费收入→已赚保费→未到期责任准备金”这类指标级链路，也包括“保单表.缴费频率→现金流引擎→退保假设”这类字段级依赖。血缘不是一张静态图，而是随模型版本、参数集和运行批次变化的动态关系。

可重复计算（Reproducible Computation）：指在给定输入数据、模型代码、参数配置和运行环境的前提下，任意时间、任意节点重跑都能得到一致结果。它要求四个要素同时锁定：数据快照、代码版本、参数版本、运行环境。缺一个，复现就可能失败。

模型链路（Model Chain）：保险模型通常不是单一程序，而是“数据准备→假设管理→现金流引擎→结果汇总→报表输出”的链路。链路中任一环节的口径变化，都会沿血缘向下游传播。理解链路，是理解血缘和复现的前提。

整体框架：四层结构

本课程按“数据层—模型层—运行层—治理层”四层展开，每层解决不同问题，又通过血缘和版本标识相互衔接。

四层不是割裂的。数据层的字段血缘会向上支撑模型层的假设映射；运行层的每次执行会生成带版本标识的结果快照；治理层则通过变更影响分析，把一次参数调整沿血缘传播到所有受影响指标。下面的 SVG 展示了这一整体关系。

一个典型场景：准备金结果为何对不上

某寿险公司月末评估未到期责任准备金，精算与财务两个口径相差 3.7%。传统排查方式是逐表核对，耗时两天。引入血缘与复现机制后，排查路径变为：

1. 从差异指标“未到期责任准备金”出发，沿血缘反查至“已赚保费”中间表。
2. 发现精算侧使用了当月最新退保假设，财务侧仍使用上月假设版本。
3. 进一步定位到假设表 assumption_mortality 的两个版本号：v202406_01 与 v202405_03。
4. 通过运行清单确认两次运行的参数快照不同，差异根因明确。

整个过程从两天缩短到二十分钟。关键不在于工具多先进，而在于血缘把“指标—中间表—假设版本—运行批次”串成了一条可追踪的链。

常见误区与复盘

• 误区一：血缘等于ETL调度图。调度图只说明任务先后顺序，不说明字段级依赖。真正的血缘要能回答“这个字段被哪些下游字段使用”。
• 误区二：能重跑就是可复现。能重跑只说明程序可执行；可复现要求输入、代码、参数、环境四者同时锁定，否则结果仍可能漂移。
• 误区三：血缘一次建好就一劳永逸。模型迭代、假设更新、表结构变更都会使血缘失效，必须把血缘维护纳入变更流程。
• 误区四：只关注结果表，忽略中间表。保险模型中大量差异发生在中间汇总环节，中间表血缘缺失会导致排查断链。