说明

一个项目结束了，趁这两三天在休息，把本次的收获和教训都盘点一下，然后再开始一个更刺激的项目。

短暂的停顿，是为了把过去一段时间辛苦的成果固化一下，把那些很容易消散的宝贵知识和经验可以给未来做决策工具。

内容

1 事实

这是在疫情之后做的第一个项目，算是一个挺好的开门红，不管未来经济如何，至少不要再像疫情期间那样，生活极不方便。

这个项目大概出差了90天左右，总体上还是符合我的专业定义，所以给我的专业时间再贡献了900小时左右。所以说起来，一年增长3600小时左右的时间应该是极限了，每天工作12~13小时的状态其实是很难持久了。我觉得我大概算是3万小时专业时间的选手，这样估算应该是比较合理的，我相信继续累积到4万，5万小时，应该是另一番有趣的光景。

这个项目仍然是使用基础技术完成的，但是流程已经比较完善了。

整个项目基本上是我一人完成，其实本来应该是一个小团队来做。

对于模型的使用、效果以及理解都有了进一步提升。

基本上精确的按照估算时间完成了计划任务。

除了建模工作，还完成了为期2月(8次)的培训工作。

在技术环境极大受限的情况下进行的工作。

2 成果

我尽量以客观的角度来估计这次项目的成果。

有一个前提是，我是以自己的代码为核心构建数据的处理系统的。这个系统最终的目标是所有的数据处理逻辑、信息处理逻辑和决策逻辑所涉及的算法都是100%自己的。

基于这样的目标，那么很多结果的度量会不一样。完全自建的大系统拥有无限的可变性，这是优点；但是这无限可变性又可能存在错误，这是缺点。

成果1：FastModel

其实这不是新的想法，之前也有很多的积累，但是在这次的实践中完成了定型（部分）。整体来说，研发FastModel的过程很像ADBS，其实在定稿之前想法有很多，但最终还是只能取其中一个实现。

定型的好处有很多，简单来说就是应用起来成本低了。

成果2：模型与业务

模型当然是有用的，如果是风险业务（信贷），那么模型的好坏就直接影响着业务的成败。当然，目前很多的信贷是Unfair的游戏。我觉得检验风险模型的合理场景其实是量化交易。风险模型的好坏非常容易衡量。

而营销模型的作用就不太好评估了。所以，关于模型所能带来的提升估计，模型的上线与检测，以及在一些业务场景下的反馈都是比较难以获得的。

在二八理论的指导下，使用模型肯定是可以找到更好的客群，从而使得工作效率提升的。

过去更关注模型是不是能够实现二八理论的假设（看起来是没问题的），而现在则更关心利用模型进行经营会带来多少的业务提升，通过几个月的经营观察，还是得到很多信息的。

成果3：分维度建模流程

过去通常是把所有维度合并建模的，这次因为数据获取非常困难，所以也摸了一条新的流程，不仅帮助我完成这次项目，同时也让我觉得其实应该推广。这明显是一种分治思路下的方法。

成果4：培训

这次的培训其实也是在前次培训的基础上进行修改而来的，因为培训时长、模式以及最终的目标不同，所以其实上还是重新Review了一遍，然后进行Tailor。

教学相长，基于过去整理的一版大而全的内容做了提升，对我的帮助也很大。

还有些成果不太容易描述，可能也不太方便说，总体上来说：

1 加深建模的认知与信念，我觉得推广到量化中是靠谱的。这些自创的函数组件与流程已经在多个项目中应用和验证，非常可靠。
2 工具的定型。FastModel很可能会是下一个ADBS，这会减少大量的简单建模动作。简单的是非判断是大型推理知识模型的基础。
3 业务联系。将建模这种抽象的工作与业务联系起来，估算带来的价值提升。

3 教训

完成任务是首要的目标。

理想与现实差距总是很大，我认为先面对现实，然后再谈理想比较好。从业务的角度来说，这肯定是好的，这就好比两军对垒，获得胜利是最重要的。至于是用导弹还是小米加步枪都是手段而已，当然后者的话，战士会比较辛苦。

在现实中，其实碰到的限制非常大，整个项目做下来，感觉就是小米加步枪，当然，最终也取得了胜利。

一直以来，我觉得资源受限不是坏事，它会让我们去思考一些方法，优化这些方法去达到目的。这个过程会让我们对很多问题有更深刻的认识，也会让我们的技能不断加强。

当然，另一条思路是去创造一个理想的资源环境（事实上我已经搭建了），这样在对比之下，得到的认识会更多。

教训1：无数据库支持的建模工作量大、容易出错

且不论问什么，就假设在建模时没有数据库，然后要求建模出结果，并定期给出名单这样的需求。

在这个过程中，出现的问题包括：

1 文件多，操作复杂。因为客群的划分，以及文件大小的限制，每次要手工操作50+文件的导出和上传。
2 大文件上传丢失数据。嗯，这个问题我也没想明白，但事实如此。100万条数据可能传到90万条就断了。
3 字段类型不一致。后来尝试用其他方法，减少文件的手工下载、上传，但是又出现了这样的问题。
4 下发数据卡住。耽误流程时间。
5 处理速度慢。
6 模型结果输出也是文件，后续还有一堆手工操作。

因为我的ADBS已经在运行(单机每日吞吐保守8亿+)，所以”假如“使用ADBS的话：

1 不存在文件传递的问题
2 数据可以按天处理
3 吞吐非常大，数据的流转应该是非常快的

教训2：数据复现费时费力

这个问题和上面的问题是相关联的。在好些年前，我已经把SQL Based的数据定义为仅仅做数据表的存储、简单的汇总这些功能，数据的处理全部在Python里实现。

但是实际上，一方面很多系统还是在用SQL实现很多数据处理，另一方面，项目完成后要交接的技术人员可能还是习惯使用SQL类技术。

所以在复现数据处理，包括清洗和特征时，这方面的工作还是比较费时费力的，关键我还觉得这属于没啥意义的额外开销。

但是这是属于技术架构选择的问题，所以我不太可能去做SQL方面的设计，一般情况下，环境本来也应当支持Python程序的处理。所以如果是需要面向SQL实现的话，我可能会考虑进一步简化数据处理和特征的处理。同时，需要对变量做好限定（数值类型、字符类型这些)。

作为对比，在ADBS就可以实现开发即部署。

ADBS会将特征在数据库中生成，这些数据处理程序是嵌入在Worker中的，这保证了建模研发时与上线时采用同样的数据。

这个价值有多大？

本次的项目算是比较标准的实施，假设建模时自由构建特征所耗费的时间/精力是1。在完成工程时，不使用ADBS的方式时，耗费大约是1.8，额外耗费0.8；而使用ADBS时大约是1.2，额外耗费0.2。另外前者是两个明确的阶段：开发、复现，后者则只是开发，只不过要多一些规范化的并入动作。

这些耗费都是宝贵的人力、时间，我觉得这个意义是很大的：假设你好不容易做了一版模型，但是在使用时要再来一次，还是很打击士气的。还不如在做的时候多一些开销，开发完即结束。

教训3：文档

文档一直是比较烦的东西。这涉及到数据来源、衍生逻辑、模型逻辑、模型效果以及应用和部署这些。因为流程本身就已经很长了，所以在整体结束的时候再一次去梳理还是很费神费力的。

我在想，一方面在工程上要更强调结构。本次的结构性比以往还要好一些，但还不够强，应该是一开始整体的工程蓝图就确定了，这样文档的结构和内容也随之确定。

结构确定之后，每一个细节，或者可以想象为列表里的每一个元素，应该也是随着在建模过程中实际的定义而随之确定。例如，我创建了一个变量，它的名称，解释甚至运算规则都需要被加上；后续其他人至少能够看得懂，甚至程序可以根据这个文档进行精确的复现。

教训4：多空间

在不同的情况下，我们需要对模型对应的数据集进行微调和重利用。比较麻烦的一点是我们经常会忘记某个模型或者分析对应的时间和空间信息。

我想这部分应该是可以在准备数据集的时候就进行约定的。命名很重要，每个分析和结果应该都可以用一个命名来表示，更详细一些，应该可以通过一个不超过200字符的字符串来表示。

不这么做的话，要回溯某一个分析还是比较痛苦的。

教训5：结果比较

以测试为导向的思路来看，测试是非常重要，也非常独立的一部分。

这次建模过程中，是分维度建模，然后进行合并的，那么在使用时，自然就需要比较不同模型下的效果：

1 看看在迭代过程中，是否出现了错误
2 比较新模型的结果与老模型的差异，是不是更好

这次还是在数据准备和建模阶段花了太多时间，其实应该更关注在结果的评估上。不管是通过交叉熵，或者是分布偏移，注意力放在结果上是更重要的。

教训5：非黑即白与三值

这是一个具有迷惑性的问题。

如果仅考虑”正“，这种营销类模型的话，那么根据目标率来选择客群就好了。

但如果既有”正“又有”负“，这种风险类模型，或者三值逻辑模型，那么就要注意了。模型可以挑出前20%的好样本，未来均值为正；但是在弱一些的样本中，好样本的比例或者作用可能还没有坏样本大，所以均值可能为负。

假设我们选取的样本基本符合正态分布，也就是均值为0，两边延展的数据分布。当我们挑出相当部分的正时，剩余的基本就是为负了。所以在子问题下，风险模型不能只看”正“。

教训6 : 编制设计

狙击手、观察员以及机枪手

这次我又一个人完成了一个小团队的工作量，从商业模型上是失败的。

在追求专业化能力最优的时候，我经常会错误的估计工作量，然后把自己陷于一个很不利的位置。从建模工作来说，一般主要负责建模的是一个人，负责数据处理的是另一个人，很像狙击手和观察员的关系。而培训工作则很像一个机枪手。

只有在美国大片里才会出现一个孤胆英雄把这些事都干了。

所以在未来的商业活动里，我不会再这么干了。当然，如果把这样的事当成是一个特殊极限训练那还是说的过去的，当我似乎也不再需要通过这样极端的模式去提高自己的能力、潜力了，我的技术路线也已经定稿了。

教训7：大量特征生成

算子化。

一直以来我的特征生成都是用程序直接实现的，现在看到，在更大量的特征工程中，这样是比较局限的。所以要通过符号化的方式，把特征间的操作用”算子“来描述。

这样才可以大量的产生特征，以及用算法自动生成特征。

4 未来

未来1: 商业模式限定

如果再有类似的项目，我肯定按照编制来，我只定位在模型方面。因为数据处理之类的对我来说实在没有意义。

目标：把琐碎的80%事去除掉，专注在20%高价值。

未来2: 算子化

目前已经在实践了，会在我的量化实验里采用算子方式做特征。

这里包含了变量的映射规范化。

将变量进行标准化映射，以适应更长期，更大规模的数据处理与计算。

目标：大规模、自动化、智能化

未来3: FastModel演进

现在只是第一步，后续还有很多演进的地方，例如：

1 自动搜索变量
2 批量LR迭代（这个已经基本实现）
3 自动分维度批次处理

目标：快速、稳定、高效

未来4：测试导向

抛开数据处理与建模过程，纯粹以测试结果来进行评估和判断，类似于量化中的回测。

1 评估变量稳定性
2 评估差异变化
3 评估增益

好吧，这次的项目到这里就画上句号了，接下来把我量化的部分上一个版本。

建模杂谈系列225 小结与反思相关推荐

建模杂谈系列226 流程与对象
说明鲁迅说:我家门前门前有两棵树,一棵是枣树,另一棵也是枣树. 从编程语言的角度,可以分为两大类(面向过程或面向对象),可以参考这篇文章文章的内容其实不多,我贴一下: 对于两者的比较,文章这么说: ...
建模杂谈系列142 关于MVD的思考
说明概念的创建是重要的现实中,数据的获取和处理(ETL)是很麻烦的事,以下是一些关于数据处理的思考. 内容 MVD(MultiVerse Data) 多元宇宙数据借用了<奇异博士>里 ...
建模杂谈系列100 数据工厂
说明我觉得这个概念可以把很多之前讲的概念串起来.概念是非常重要的(<反脆弱>有提到),找到合适的概念来表达思想可以更好的帮助思考和分析. 内容数据工厂包含了两方面的解释: 1 从业务上 ...
建模杂谈系列102 信息安全一二
说明现在考虑信息安全还偏早,并且纯技术的信息安全也并不可靠,本文简单梳理一下如何从大的层面确保信息安全. 内容 1 从数据存储上 1.1 AB类首先,一些数据/算法永远不会存在公网机上.可部署在公 ...
建模杂谈系列61- 行业分类的逻辑
说明假设只从公司的名称上,能不能对行业分类? 理论上应该是可行的,但是就行业分类背后的逻辑来说,我觉得还是不太统一.本篇探讨一下行业分类的内在逻辑. 内容 1 为什么要行业为什么有行业? 因为有社 ...
建模杂谈系列159 数据“板材“模型
说明数据是抽象的,数据处理的工艺也是抽象的,我觉得需要有一些可见的模型进行类比才好记忆和思考.我一直把数据处理和实体制造进行类比,也可能是我过去做过一些制造业的管理咨询有关系,我觉得很自然. 本篇就 ...
建模杂谈系列62- knime模型实例1- 流失预测 Churn Prediction
说明 KNIME是一个开源的机器学习平台,有兴趣可以自己查一下怎么用,这里几篇都是关于其中的示例介绍. 内容 1 获取数据原始程序读取了两个文件并拼接在一起根据节点里的信息找到文件位置,拿出来从 ...
建模杂谈系列81 项目元数据实践3
说明这个实践接着前面的总结,结合可用的时间,进行一定的升级. 内容 1 背景在跑批时,由于目标库的空间不足,导致大约40%的结果没有存入.并且我发现,由于没有做交付的确认(向目标库查询),程序默认 ...
【数学建模绘图系列教程】绘图模板总结
数学建模绘图系列教程合集已更新完成: https://space.bilibili.com/472442675/channel/collectiondetail?sid=562950&ctyp ...

建模杂谈系列225 小结与反思

说明

内容