怎样才算“良好”的Prophet模型？(1) —— 避免黑箱模型

如果你在寿险公司的精算部门的actuarial valuation团队工作，想必你已经和Prophet打过很多交道了。Prophet确实是一个我们用来做现金流预测和计算储备金，功能相当强大工具。然而，你有没有想过，你所使用的Prophet模型是否是一个“良好”的精算模型呢？

老实说，在我使用Prophet的前十年里，我是与很多人一样单纯是个模型“使用者”，而不是模型开发者。我会输入保单相关的数据、执行运算程序，然后就完全信任所得到结果了。呵呵，这听起来是不是很熟悉？

当时，我当时所使用的Prophet模型里有好几千个variables——多到我根本不可能逐一详细研究的。更甚的是，随着时间推移，负责开发和维护精算模型的同事还加入了不少自定义的variables和修改原有的代码。然后，某一天我心血来潮去检查某个variable所用的程式，霎时间我不得不面对使用“黑箱”模型的风险和后果。

其实，我所找到隐藏在几千个variables之中的，说实在的是一个简单的错误。问题出在哪里呢？一个简单的除法错误：分母本该是有效的保单数量（no. of in force policies），结果不知为何却被设为了1。结果呢？这个小小的错误造成了差不多马币一百万美元的差误。那时我深刻地意识到，深入理解我们依赖的精算模型是非常重要的，不能仅仅停留在表面。

在这个“怎样才算‘良好’的Prophet模型？”系列文章的第一篇中，我会分享探讨该如何识别黑箱Prophet模型的方式，以及使用这些模型的风险。

最重要的是，避免黑箱模型

那么，我们该如何判断我们所使用的Prophet模型，是否是一个“黑箱”？与其采用生涩和艰难的技术性词汇来解释，我想建议一个比较简单直接的方法，那就是问自己以下的两个关键问题：

1. 你真的了解你的Prophet模型是如何设计和建立的吗？
2. 你是否有任何文件是可以说明模型的设计原理？

建立一个Prophet模型，不仅仅只是把variables输入到库中。在精算模型中，许多variables是紧密相连的，犹如形成一个硕大的网络。比如，保费收入（premium income）依赖于有效保单的数量，而这个保单数量又受死亡率（mortality rate）的影响。然而，死亡率则会受到已到年龄和性别的影响。天啊，这就像一个骨牌效应——几乎所有的运算都是相互关联的。

如果我们不理解所使用的Prophet模型的核心建模理念和基础结构的话（我称之为模型的“骨架”），进行模型的修改和维护，都会带来一定的风险。哪怕是做一些小的改动，尤其是核心或基础的variables，都是需要额外小心地进行。

更糟糕的是，如果我们拥有的文件无法详细和有效地说明模型的设计和理念，那么每当我们需要比较大幅度的修改时，你就只能靠猜测——这就像将未来完全交付给命运，祈求一切顺利。然而，犹如我所经历过的，小小的错误可能会导致大大的差误，如果我们需要常常猜测的话，风险就会随之提高了。

如果这样的话，会有什么风险呢？

如果我们的Prophet模型是一个“黑箱”的话，它可能会影响我们的精算计算工作的准确性、可靠性和可维护性。好吧，让我们来细分一下其中几种主要的风险：

风险1：难以理解运算脉络

最明显的风险之一，我们可能无法完全理解运算是如何完成的。当模型过于复杂，或者相关文件不完善时，我们就无法梳理运算背后的脉络。我看过一些含有五、六百行程序的extended formula variables，超过了我们可以有效阅读的范围（readability）。

风险2：难以发现隐藏的错误

正如我在前言中提到的，我曾经亲身体验到这个风险。当模型过于复杂时，即使是简单的错误也可能被忽略。在我的案例中，一个基本的除法错误埋藏在成千上万的variables里，导致了大数目的差误。当我饿们对精算模型结构没有清晰的了解时，识别这些错误就更加困难了。

风险3：凭猜测操作，容易引发无意的错误

当我们对Prophet模型的设计没有扎实的理解时，进行大幅度修改会变成大型的“猜谜游戏”。你可能需要做出调整，但如果没有良好的文件或对模型骨架的深入了解，这些修改很可能无意间引发新的错误。这有点像在不理解发动机原理的情况下修理汽车——我们只是只能祈求一切顺利。

在这个情况之下，我们必须进行更严密的模型测试，以便可以挖掘出我们视线之外，隐藏在黑暗中的问题。我们也需要确保所使用的library是可以100%通过基本技术检查（Validate的功能）——我有时候称之为我们至少要确保library所有variables的”语法”都要正确。

对，我严格要求我所处理的Prophet模型，在进行validate的检查时，是零错误的。

风险4：模型越来越复杂，最终变得无法管理

如果我们在不理解模型设计的情况下不断地做出修改，我们的模型只会变得越来越复杂。尤其是当你因新的需求而不得不加入大量的变通代码时，该模型最终就会演变成一个无法修复的混乱的“炸弹”，不晓得什么时候会引爆。我在不少Prophe模型专案中亲眼见过这种情况——Prophet模型由于自定义和修改太多，最终变得无法修复或升级，而最好的解决方式唯有放弃并建立新的Prophet模型。

风险5：难以预测模型行为

当一个模型变成黑箱时，你就失去了预测其运算行为的基础。在我一次Prophet培训课程中，有位参与者问我：“如果我在我的Prophet模型中选择某个产品的XYZIndicator，该产品会发生什么变化呢？”呃，当时我只能无奈地回答：“我不是创建这个library的人，那我怎么可以明确知道会发生什么呢？”

唉，那时候我真的是不想进行“我猜我猜我猜猜猜”的游戏。

理解Prophet模型的重要性

一个好的Prophet模型不应该像一个黑箱运作。正如我们讨论的那样，使用我们不完全理解的精算模型进行工作，是需要承担一定程度的风险——从隐藏的错误到无意的失误，甚至是模型随着时间的推移变得不可管理（beyond repair）。这就是为什么了解你所依赖模型的结构、设计和理念如此重要。

在下一篇文章中，我将深入探讨另一个“良好”的Prophet模型的关键因素——冗余（redundancy）设计。

本文播客：