2. 精算建模基础

在进入参数假设与版本管理的实战之前，必须先建立三个基础认知：精算模型有哪些常见类型、参数假设在模型中究竟扮演什么角色、版本管理的基本概念与术语是什么。这三者构成了后续所有实操工作的共同语言。缺少这层基础，参数调整容易变成“凭感觉改数”，版本管理也容易退化为“文件名加日期”的伪管理。

一、核心原理：模型是结构，假设是输入，版本是状态

精算模型可以理解为一种“结构化计算器”：它把业务规则、概率规律和财务逻辑固化为可复用的计算结构，再通过输入参数驱动运算，输出准备金、保费、资本占用等结果。因此，模型本身不等于结果，模型是“函数”，参数假设是“自变量”，结果是“因变量”。

参数假设在模型中的作用可以归纳为三点。第一，决定量级：死亡率、退保率、折现率等假设的微小变动，会通过长期复利和大量保单聚合被放大。第二，承载不确定性：假设是对未来的估计，必然带有偏差与波动，模型需要通过敏感性测试来暴露这种不确定性。第三，形成审计线索：每一个假设都应能回答“为什么是这个值、谁批准的、何时生效”，这正是版本管理要解决的问题。

版本管理的基本概念包括：基线（被正式确认、可用于对外报告的模型状态）、分支（为试验或监管场景单独开辟的修改线）、提交（一次可追溯的变更记录）、标签（给特定提交起的稳定名称，如“2024Q4-监管报送”）、合并（把分支变更并入主线）以及回滚（恢复到历史状态）。这些术语在 Git 等工具中有对应实现，但精算场景还额外要求“参数与代码同版本”“结果可复现”。

二、方法流程：从模型选型到版本落地的四步法

实际工作中，建议按以下流程推进，避免“先改数、后补文档”的倒置操作。

1. 模型选型：根据业务目的选择模型类型。定价用现金流模型，准备金用随机或确定性模型，资本计量用情景模拟模型。选型错误会导致后续假设无处安放。
2. 假设设定：区分“经验假设”（来自历史数据）与“管理假设”（来自公司策略或监管要求）。每项假设记录来源、置信区间和责任人。
3. 版本固化：将模型代码、参数文件、运行配置一并提交，打上标签，形成基线。禁止只提交代码而把参数留在个人电脑里。
4. 变更与复盘：任何假设调整都走分支，经过复核后合并；定期回看历史版本，分析假设偏差对结果的影响。

三、案例/场景：一次退保率假设调整的完整链路

某寿险公司在季度评估中发现实际退保率高于定价假设，决定将退保率假设从 5% 上调至 7%。如果缺少版本管理，常见做法是直接修改参数文件、重跑模型、发结果邮件。问题在于：三个月后监管问“当时用的哪个版本”，团队无法回答。

规范做法如下：从基线拉出分支 feature/lapse-7pct，修改参数文件并提交，提交信息写明依据与审批人；运行模型生成结果，将结果文件与提交哈希一起归档；经复核后合并回主线并打标签 2024Q4-lapse-update。这样，任何时点都能复现当时的计算。

# 参数文件示例（YAML）
lapse_rate:
  base: 0.05
  updated: 0.07
  effective_date: 2024-10-01
  source: "2024Q3 经验分析报告"
  approver: "精算部-张明"
  confidence_interval: [0.06, 0.08]

# 版本操作示意
git checkout -b feature/lapse-7pct
git add assumptions/lapse.yaml
git commit -m "上调退保率至7%，依据2024Q3经验分析"
git tag 2024Q4-lapse-update

四、误区/复盘：三个高频错误