数据行业中的建模是什么？

数据行业迅猛发展下，“建模”概念脱颖而出，不论是说大数据、云计算，还是机器学习、人工智能，说到后来都会来讲到建模。很多领导讲话，工作意见也是频频使用模型思维在文中。建模到底是什么？大家都想了解下，那今天就来说说建模这件事。

欲知建模是何物，首先需搞清什么叫模型。关于模型的定义，各类百科少说也有几十个义项，其中涉及天文地理，社会自然等各种领域，有兴趣的可以去自行搜索参阅。

我们这里是特指的行业信息化范畴内讨论的模型，说得比较多的大致有两大类:

第一类是归于数据模型范畴，数据模型是数据库中数据的存储方式，是数据库系统的基础。具体包括数据的层次模型、网状模型、关系模型等。这个范畴的东西是纯面向 IT 技术的，感兴趣的童靴可以随便去找本数据库的基础理论书学习下，这并不是在这儿讨论的重点。

第二类，我们可以称之为业务模型。也是下面重点要说的东西。按套路先来个定义，信息化语境里的业务模型是用量描述用户状态、应用对象状态和应用过程的一种技术与业务相融合的有机体。业务模型强调的是以体系化的方式来理解、设计和组织某一领域的信息系统应用架构。

那如何来构建一个业务模型呢？首先，确定你的模型是属于宏观层面还是微观层面，宏观层面的业务模型面向整个应用系统，在某种程度上就是一个应用系统整体架构的核心与灵魂，它立足实现系统整体应用功能的层面，规定和约束了系统各类参与者、系统的数据资源以及不同形式的计算存储能力的调度与管理方式。比如我们构建一个执法监督系统，其宏观业务模型的核心要义就是讲清楚监督者、执法者以及两者形成的各类数据之间的处置关系，大多数情况下，宏观的业务模型可以用一张或者多张拓扑图来表示。

微观的业务模型是面向具体某一项业务的，比如，在执法监督系统中，我们要构建一个违规收取大额取保候审保证金的监督模型，就是属于这个范畴，再比如，我们在刑事侦查分析系统中，可以构建一个分析在逃人员旅馆住宿规律的模型。

我们目前大多数场合下谈论的模型，就是此类微观的业务模型。

经过多年在行业的积累，我现在大致把微观的业务模型分为两个大类:

第一类称之为过程类的应用模型，这种模型主要任务是以一个工作流程作为驱动的，比如以往经常说的“五查一联系”模型，先查 A，再查 B，查出结果 C 后必须去查 D，通过模型设定的流程去驱动和规范工作，就是这类应用模型的主要目的。

第二大类称之为研判类的应用模型，其中又分为两种:

第一种是及时预警型模型。一般是通过两类或者多类的数据进行碰撞比对，得出一个类似于预警的结果来服务实战应用，这种服务一般是以“指令”的形式来呈现给用户；

第二种综合分析型模型，这个其实就是以经典数据仓库理论为根基的应用（不明白数仓的童靴可以自行去补习），通过对不同类数据的综合分析，可能包括各类排序、分组统计等计算，也包括平均数、中间值、极值判断等函数的应用。

这种模型对于实战应用的服务一般是以“指导”的形式出现的。如我以前经常提到的套牌车排查的模型，其实就是很有代表性的研判类应用模型。在实际应用中，可以是单个业务模型独立运行发挥作用，也可以是多个模型进行一个组合，比如甲模型运行的结果可以作为乙模型的源头，或者甲模型中间的一部分封装的比较独立组件可以被乙模型调用等。

关于微观业务模型的产生，一般是遵循这一规律的，首先由有经验的用户个体或群体对某项具体业务进行了规则和逻辑层面的总结和归纳，当然这项工作的总结可能是与信息化手段有关的，也可能是没有关系的，如果说是涉及了信息化手段，特别是能够找到一定的数据作为根基，那在此基础上就可以形成所谓的信息化条件下的技战法或者工作法，如果这些技战法或者工作法能够在更大的范围内得以验证，那就更好了，我们可以说这个东西基本具备了构建微观业务模型的雏形。我在差不多十年前参与了部局组织的全国技战法教程的汇编，主要干的就是这个事。可以说，总结出了明确的或者已经过验证的业务规则逻辑，这些规则和逻辑的背后又有一定的数据资源作为支撑，这就离一个成功的模型不远了。

我们如果更进一步，能够写出这些基于数据支撑的业务关系表达式，然后用一定的机器语言把这些业务关系表达式写出来，一个微观层面的业务模型基本成型了。或者还有一种做法，就是这种表达式是可以用函数的模式或者算法的套路来实现，那么这个应用模型就更高级了。当然，从应用的角度看，这个模型构建之初不一定就很完美，它必须放到业务实战中去不断验证，可能是更大的地域范畴，也可能是更大的数据压力，经过对应用结果的对照评估和持续的修正，最终才能形成一个相对完善的微观业务模型。

最后有这么几点可以供大家在做这项工作中参考，或者说不要走进业务建模的一些误区。

第一，业务建模是不是一定需要图形化工具化的平台来支撑？不一定！特别是一些简单易行的模型，几行代码就搞定，何必还用个工具来多此一举。虽然我盯着这个事已经六七年的，但是扪心自问，越来越觉得这是个伪命题！为什么呢？不是因为技术层面的研发问题，而是重新对平台的应用人群进行了审视，其中涉及我们的用人体制，在这就不多言了。

第二，业务建模是不是一定要用到算法？也不一定！这个问题我在前面应该已经讲清楚了，有算法的模型固然高级，但是在目前情况下大多数业务模型还没有到使用算法的程度，能够使用一些通用的函数来提高效率就已经很成功了，至于能不能封装成插件，那就是更远地考虑了，要清楚的是我们行业还是处于模型应用的初级阶段。

第三，模型是不是一定是个封闭的黑盒？有人把模型形容成一个用户只要关心输入和输出的黑盒，当然这是一个很好的愿景，但是目前对此我还是保留自己的意见，对于微观业务模型而言，不断修正与变化是当前应用的一个常态，因为我们的需求在变，场景在变，机制甚至体制在变，因此很难把此类模型做成一个“傻瓜相机”。

第四，模型应用是不是一定要和大数据捆在一起？当然不是！用一个业内大哥级的人物的话来讲，现在特烦大数据这三个字，啥都扯上大数据，数据的量级跟业务建模没有绝对的因果关系，当然有一点是肯定的，你拥有的数据越多，你的支撑与验证体系也会越强，你的模型也会越健壮。

最后你可能还会问一个问题，到底是业务专家去搞模型好，还是技术大拿去搞模型好？关于这个问题，我能给出的答案是：最好去找个业务技术都精通的复合型人才。如果你说找不到怎么办，我只能说这个问题太复杂，那我们择期再讨论吧。

简要概括下，构建模型是人对事物的一种抽象过程。目前有比较普遍的两种情况，一种情况是人在正式创建事物前，会建立一个简单的模型，目的是更透彻地了解事物本质，切中要解决问题的要害。另一种情况是针对已有的规律或者总结的规则，依托相关数据面向应用对象搭建一个可复制的应用模型，并以此来实现驱动工作或者达到数据增值的目的。我们当前各种场合里讲的建模，大多是后者而已。