工作总结

发布时间：2026-04-22

精算研究岗工作总结。

先给个结论：今年我把自己逼了一把，把准备金评估的数据处理流程从手工搬到了自动化轨道。往年这个时候，我还在为二季度压力测试的表格发愁，今年能提前两周交差，而且复核时只改了三个参数。

说一个具体的。去年九月，我用老方法做车险准备金评估——链梯法，手动选发展因子，每个季度数据量大概50万条赔付记录。我干了三天两夜，最后出的报告，领导圈了一堆问题：赔付趋势分析只做到季度粒度，没有月度滚动；某些险种的选代因子跟实际偏差超过10%。当时我就想，这路子走不下去了。

今年一季度，我拆了三个阶段重新搭。第一步是数据清洗。以前手工做，靠Excel筛选异常值，比如赔付金额为负或者超过保额10倍的，肉眼扫。我写了套Python脚本，用pandas读业务库的赔付明细表，按事故季度、险类、区域三个维度分组，计算每个组内的赔付金额均值与标准差，自动标记偏离均值3个标准差以上的记录。脚本跑一遍，输出异常报告，我只需要核查那些标记出来的记录——今年一季度跑下来，50万条记录里异常值87条，其中78条是业务系统重复录入，9条是真实的高额赔案需要单独建模。光这一步，把以前两天的活压缩到15分钟。

第二步是参数拟合。老方法用固定36个月窗口期加权平均，权数是经验值——说白了就是老师傅觉得最近三个月重要就多给点权重。我改成了滚动交叉验证：用过去24个月的数据做训练集，预测下个月的发展因子，再跟实际值比对，计算MAPE（平均绝对百分比误差）。我把窗口期从12个月到48个月挨个跑了一遍，发现24个月的效果最好，MAPE从老方法的8.7%降到4.3%。为什么24比36好？因为车险的赔付模式在疫情后变了，36个月窗口里含了太多异常时期的低赔付数据，拉低了因子的敏感性。

然后问题来了。今年三月底，我跑一季度的最终评估，发现模型输出的预期赔付率跟财务系统实际入账数差了6.8个百分点。第一反应是脚本逻辑写错了，查了两天没查出问题。后来没办法，我只能把数据处理环节每一步都打日志——从业务库拉原始数据，到清洗、归集、计算发展因子，最后出结果，一共12步。我写了个SQL，把每个产品线的赔付记录按事故日期和报案日期分别汇总，然后对比两个汇总表。你猜怎么着？有两个产品线（代码C021和C045）的业务系统里，报案日期字段存的是客户首次来电的时间，而事故日期字段大部分是空的。我们的模型默认按事故季度归集，结果这两个产品线的赔案，因为事故日期为空，全被脚本过滤掉了，根本没进模型。

我给IT部门发了工单，要求他们在数据接口层做映射：如果事故日期为空，则用报案日期减去一个平均报案延迟天数（这个天数按每个产品线过去12个月的中位数计算）。同时我在ETL脚本里加了校验规则：跑数据前先抽100条记录做人工比对，确认归集逻辑正确后再全量跑。这个事之后，我把所有上游数据源的字段规则整理了一张表，贴在共享文档里，每次跑批前先看一遍有没有变更。

还有一个不算精算主业但绕不开的事。我们的精算服务器是共享的，每年二季度压力测试期间，CPU经常跑到100%，模型跑到一半就卡死。以前的做法是等，或者半夜爬起来跑。今年我改了备份和调度策略：把每周六的全量备份改成每天凌晨2点的增量备份+异地快照，备份时间从6小时压到12分钟。另外写了个调度脚本，把模型拆成四个并行任务，按险种拆分数据，跑完再合并。今年六月的压力测试，原来要跑一整天的模型，四个小时就出结果了。

【一起合同网】熬夜必刷内容: