3. 数据准备
长期险种尾部赔付发展建模的成败，往往在建模之前就已决定。尾部赔付数据具有长尾、稀疏、延迟报告、口径多变四大特征，任何一处数据缺陷都会在尾部外推时被指数级放大。本章围绕“数据从哪里来、如何变干净、缺失怎么补、异常怎么判、质量如何量化”五个环节，构建一套可复用的数据准备流水线。
一、核心原理：尾部建模对数据的特殊要求
与短险不同，长期险尾部赔付建模关注的是发展因子在长尾段的稳定性。这意味着数据准备必须满足三个额外约束：其一，时间轴一致性——事故期、报告期、赔付期三者口径必须统一，否则发展三角会出现错位；其二，尾部可观测性——越靠近尾部，样本越少，任何异常值都会主导外推结果；其三，口径可追溯——准备金评估、再保分摊、通胀调整等口径变更必须留痕，否则历史数据不可比。
二、方法流程：五步数据准备流水线
建议将数据准备拆解为五个可独立验证的步骤，每步产出可审计的中间结果：
- 数据来源梳理：明确理赔系统、再保账单、财务总账、外部行业数据四类来源的字段映射与更新频率。
- 数据清洗：统一险种代码、事故期口径、币种与通胀基准，剔除重复报案与撤销案件。
- 缺失值处理：区分“结构性缺失”（如未到报告期）与“随机缺失”（如字段漏填），分别处理。
- 异常值识别：在赔付金额、发展因子、报告延迟三个维度分别设阈值与规则。
- 数据质量评估：用完整性、一致性、时效性、准确性四类指标打分，形成质量报告。
下面是一段典型的数据清洗配置示例，用于统一事故期口径并标记异常：
# 数据清洗配置示例
accident_period:
source_field: "accident_date"
granularity: "month" # 统一到月
cutoff: "2024-12-31" # 数据截止
reporting_lag:
max_months: 60 # 超过60个月标记为长尾延迟
flag_field: "lag_flag"
amount:
currency: "CNY"
inflation_base: "2020-01"
outlier_rule: "median ± 3*IQR"
missing:
structural: ["report_date", "close_date"]
random: ["claim_type", "handler_id"]
三、案例/场景：某终身寿险尾部赔付数据准备
某寿险公司终身寿险业务，2015—2024年共积累约12万条理赔记录。建模团队发现，2019年之前的案件报告延迟普遍在18个月以上，而2020年之后因系统升级缩短至6个月。若直接合并，发展三角会出现“人为加速”的假象。
处理方案：以2019年为界分段建模，并在数据质量报告中标注口径变更点。同时，对赔付金额超过500万元的案件单独标记，避免大额案件主导尾部外推。最终，尾部发展因子从原来的1.42修正为1.28，更符合实际经验。
四、缺失值处理与异常值识别
缺失值处理的核心是先分类、再决策。结构性缺失通常由业务规则决定，例如未到报告期的案件本就没有报告日期，这类缺失不应填补，而应保留为“右删失”状态。随机缺失则可采用中位数填充、同险种均值填充或模型预测填充。
异常值识别建议采用“规则+统计”双轨制：规则用于捕捉业务上不可能的值（如赔付金额为负、报告日期早于事故日期）；统计方法用于捕捉分布上的极端值（如IQR、Z-score、分位数截断）。下表给出常见异常类型与处理建议：
| 异常类型 | 识别方法 | 处理建议 |
|---|---|---|
| 赔付金额为负 | 规则校验 | 直接剔除并回溯源系统 |
| 报告日期早于事故日期 | 规则校验 | 标记为逻辑错误，人工复核 |
| 发展因子突变 | IQR或Z-score | 缩尾处理或单独建模 |
| 大额案件集中 | 分位数阈值 | 分层建模，避免主导尾部 |
| 报告延迟异常长 | 业务阈值 | 保留但标记，用于尾部形态分析 |
五、数据质量评估与误区复盘
数据质量评估应形成量化报告，建议从四个维度打分：完整性（关键字段缺失率）、一致性（跨系统口径一致率）、时效性（数据更新延迟）、准确性（异常值占比）。每个维度设定阈值，低于阈值的数据集不得进入建模环节。
最后，数据准备不是一次性工作，而应随建模迭代持续更新。建议每次建模前重新运行质量评估，并保留历史版本，以便追溯尾部因子变化的原因。