📚 课程目录第1章课程导入

1. 课程导入

欢迎进入《精算模型审计轨迹与结果可追溯实战》。在正式动手改造模型之前，我们需要先建立一套共同的认知坐标系：什么是审计轨迹，什么是结果可追溯，监管为什么反复强调它们，以及它们在精算模型生命周期中究竟处于什么位置。本章不涉及复杂代码，但会决定你后续29章的学习方式——因为如果概念边界不清，后面所有的日志设计、参数快照、版本管理都会变成"为了做而做"。

一、核心定义：审计轨迹与结果可追溯不是同一件事

很多团队把"审计轨迹"和"结果可追溯"混用，导致落地时职责错位。我们先做一次严格区分。

审计轨迹（Audit Trail）关注的是"过程留痕"：谁、在什么时间、对哪个模型、做了什么操作、依据是什么。它是一条按时间顺序记录的事件链，核心价值在于可回放、可追责、可举证。典型内容包括：模型版本变更记录、参数修改审批、假设调整理由、执行人身份、审批人身份。

结果可追溯（Result Traceability）关注的是"结果反查"：给定一个最终输出（如某张保单的责任准备金、某个险种的偿付能力资本），能否沿着数据流、参数流、代码流一路回溯到最原始的输入和假设。它的核心价值在于可解释、可复现、可验证。

两者的关系可以这样理解：审计轨迹是"时间轴上的证据链"，结果可追溯是"数据流上的血缘链"。一个合格的模型治理体系，必须同时具备这两条链，并且两条链之间能够互相索引——比如从某次参数修改的审计记录，能直接跳到受影响的输出结果。

一句话记忆：审计轨迹回答"发生了什么"，结果可追溯回答"这个数字从哪来"。前者面向过程，后者面向结果；前者服务于合规检查，后者服务于模型验证与业务解释。

二、监管要求：从"建议"到"硬约束"

审计轨迹与可追溯性并非精算行业自发的"最佳实践"，而是被监管文件逐步固化为硬性要求。下表梳理了主要监管框架中的相关条款定位。

监管框架	核心要求	对审计轨迹/可追溯的指向
偿二代二期（C-ROSS II）	模型风险管理、假设管理、验证与文档	要求模型变更可追溯、假设调整有审批记录、结果可复现
IFRS 17	计量方法一致性、假设变更披露	要求合同组层面的计量结果可回溯至假设与数据
精算师协会模型治理指引	模型全生命周期管理	明确审计轨迹应覆盖开发、验证、上线、变更、退役
银保监会/金融监管总局相关办法	数据治理、模型风险管理	要求关键模型输出具备可解释性与可审计性

从趋势看，监管的关注点正在从"你有没有文档"转向"你能不能现场演示一次完整的回溯"。这意味着审计轨迹不能是事后补写的Word文档，而必须是模型运行过程中自动产生的结构化记录。

常见误区：把"模型文档"等同于"审计轨迹"。文档是静态的、人工维护的；审计轨迹是动态的、系统生成的。监管现场检查时，更看重后者——因为静态文档无法证明某次具体运行的真实过程。

三、精算模型生命周期中的价值定位

把审计轨迹与可追溯性放进精算模型生命周期（开发→验证→上线→运行→变更→退役），可以看到它们不是某个阶段的附属品，而是贯穿始终的基础设施。

开发阶段：记录假设来源、数据版本、代码提交，避免"这个参数当初为什么这么设"的失忆。
验证阶段：独立验证人员需要沿着可追溯链复现结果，否则验证只能停留在"看代码"层面。
上线阶段：生产环境与开发环境的差异必须留痕，防止"开发能跑、生产报错"却查不到原因。
运行阶段：每次批量运行的输入快照、参数集、输出摘要自动归档，支撑月度、季度结账的审计需求。
变更阶段：变更前后结果对比、影响分析、审批链，是审计轨迹价值最集中的场景。
退役阶段：历史结果仍需可追溯，满足监管留存年限要求。

换句话说，审计轨迹与可追溯性是精算模型的"黑匣子"和"血缘图谱"。没有它们，模型就是一个只能给出数字、却无法解释数字的黑箱；有了它们，模型才具备被信任、被验证、被监管接受的资格。

四、整体学习框架：本课程将带你走完的路径

本课程共30章，整体遵循"概念→设计→实现→验证→复盘"的推进逻辑。第1章建立认知基础后，后续内容将围绕以下四条主线展开：

设计线：审计轨迹的数据模型、日志规范、版本编号规则、运行ID体系。
实现线：在精算模型代码中嵌入轨迹记录、参数快照、结果血缘采集的具体技术手段。
验证线：如何用审计轨迹支撑独立验证、如何做结果复现测试、如何应对监管现场检查。
复盘线：真实场景中的失败案例、常见反模式、治理成熟度评估与持续改进。

为了让你对"一次完整的可追溯运行"有直观感受，下面给出一个最小化的审计轨迹记录示例。它展示了一次模型运行中应当被自动捕获的关键字段：

{
  "run_id": "RUN-20250612-0037",
  "model_name": "TermLife_Reserve_Model",
  "model_version": "v3.2.1",
  "code_commit": "a1b2c3d4",
  "operator": "zhang.wei",
  "approver": "li.na",
  "run_time": "2025-06-12T09:14:22+08:00",
  "input_data": {
    "source": "policy_mart_202506",
    "snapshot_id": "SNAP-20250610-001",
    "record_count": 128430
  },
  "assumptions": {
    "mortality_table": "CL2020-2023",
    "interest_rate": 0.025,
    "expense_inflation": 0.03
  },
  "output_summary": {
    "total_reserve": 4823910000,
    "policy_count": 128430,
    "output_hash": "sha256:9f2c..."
  },
  "audit_note": "季度结账常规运行，假设与上季度一致"
}

这段记录同时承载了两条链：operator、approver、run_time、audit_note属于审计轨迹；input_data、assumptions、code_commit、output_hash属于结果可追溯。当监管或内审要求解释"4,823,910,000这个数字怎么来的"，你可以从output_hash反查到输出文件，再沿assumptions和input_data回溯到假设表和原始数据快照，最后用code_commit定位到确切的代码版本。

学习建议：在进入第2章之前，请先在你当前负责的一个精算模型中，尝试回答三个问题——最近一次运行是谁执行的？当时用的假设版本是什么？如果现在要复现那次结果，你需要哪些信息？如果你无法完整回答，说明你的模型正缺少本课程要构建的能力。

本章的核心结论可以浓缩为一句话：审计轨迹与结果可追溯不是额外的文档负担，而是精算模型从"能算"走向"可信"的必要条件。接下来的章节，我们将把这套认知逐步转化为可落地的设计、代码与流程。