4. 模型需求分析与设计
精算模型开发失败，很少败在代码能力上，更多败在需求阶段：业务方说“要一个能算偿付能力的模型”，开发方直接开始写代码，结果交付时发现口径不一致、假设缺失、数据字段对不上。本章聚焦模型开发链条的起点——把业务语言翻译成可执行、可验证、可评审的模型设计资产。
一、核心原理：需求转化是一条“可追溯链”
业务需求到模型实现之间，必须建立一条双向可追溯的链路。业务需求（BR）→ 模型需求（MR）→ 模型假设（MA）→ 数据需求（DR）→ 模块设计（MD）→ 测试用例（TC）。任何一环断裂，回归验证时就无法判断“模型算得对不对”，只能判断“模型算得和上次一样不一样”。
需求转化的本质是消除三类歧义：口径歧义（“保费收入”是已赚还是实收）、粒度歧义（按月还是按保单）、时点歧义（评估日是月初还是月末）。精算模型对时点和粒度极其敏感，一个“期末”理解偏差可能导致准备金差异数十万。
二、方法流程：从需求到设计的五步法
- 需求访谈与拆解：与业务方逐条确认“输入、处理、输出、约束”。输出《业务需求清单》，每条需求有唯一编号。
- 模型假设文档化：将利率曲线、死亡率表、退保率、费用假设、税率等全部写入《模型假设文档》，注明来源、版本、生效日期和审批人。
- 数据字典编制：定义每个字段的名称、类型、长度、来源系统、业务含义、空值规则、校验规则。
- 模块化设计：按“数据准备→假设加载→计算引擎→结果输出”分层，每层内部高内聚、层间低耦合。
- 设计评审：组织业务、精算、IT、数据四方评审，输出评审意见和关闭记录。
三、关键交付物：模型假设文档与数据字典
模型假设文档不是“写给自己看的备忘录”，而是审计和监管检查的核心证据。每条假设必须可追溯、可版本化、可审批。数据字典则是模型与数据源之间的契约，字段口径不一致是回归验证失败的首要原因。
| 交付物 | 核心内容 | 常见缺陷 | 评审要点 |
|---|---|---|---|
| 模型假设文档 | 假设名称、取值、来源、版本、生效日、审批人 | 假设硬编码在代码中，无版本记录 | 每条假设是否有唯一编号和变更历史 |
| 数据字典 | 字段名、类型、来源、口径、空值规则、校验 | 字段含义模糊，空值处理未定义 | 字段口径是否与源系统一致，是否有校验规则 |
| 模块设计说明书 | 模块职责、输入输出、依赖关系、接口定义 | 模块边界不清，循环依赖 | 是否高内聚低耦合，接口是否稳定 |
| 追溯矩阵 | 需求→假设→数据→模块→测试的映射 | 缺失或事后补填 | 是否覆盖全部需求，变更时是否同步更新 |
四、模块化设计原则与评审要点
模块化设计的核心目标是可测试、可替换、可回归。一个合格的模块应满足：单一职责、明确接口、无隐藏状态、可独立测试。以下是一个典型的模块配置示例：
# model_config.yaml
modules:
data_loader:
input: "policy_data.csv"
output: "clean_policy"
validations:
- "policy_id not null"
- "issue_date <= valuation_date"
assumption_loader:
source: "assumptions_v2.3.xlsx"
effective_date: "2024-01-01"
calculation_engine:
method: "cohort_projection"
frequency: "monthly"
output: "reserve_result"
result_writer:
format: "parquet"
path: "/output/reserve/"五、案例复盘：一次准备金模型的返工
某寿险公司在开发新准备金模型时，业务方要求“按季度评估”，开发方理解为“按季度汇总数据”，而精算口径要求“按月计算、按季度汇总”。由于需求文档未明确粒度，模型上线后季度结果与月度结果无法对齐，导致全部回归用例失效，返工两周。
复盘结论：需求转化阶段必须用示例数据验证口径。让业务方对同一组样本数据手工计算预期结果，开发方用模型计算，两者比对一致后才进入开发。这个“黄金样本”同时成为后续回归验证的基准用例。
综上，模型需求分析与设计的本质是建立一条从业务语言到可执行资产的、可追溯、可评审、可回归的链路。假设文档、数据字典、模块设计和追溯矩阵四件套齐备，后续的开发测试与回归验证才有稳固的起点。