「明致书院」企业级大数据服务的点滴思考

大数据架构可能是未来支撑企业级IT应用的唯一架构...





大数据架构可能是未来支撑企业级IT应用的唯一架构。

传统的IT部署的表现形式和设计理念与以大数据为基础的认知计算架构有很大的不同。一般IT项目的特点是稳健、精准、防范风险，重点在于新系统的成功部署以及解决计划中的问题。与之相对，专注认知应用和大数据的项目并不十分在意技术部署风险，而是将更多精力放在解决业务问题上，这里的“解决”甚至略带开放性，探索的意味更浓一些。

相比 IT方案，目前阶段的大数据及分析项目更像是科学研究和临床试验，即便是感知问题或发掘潜在机会，都是充满不确定性的预期，很多业务假设以及基础理论都在验证的过程之中，其中大量假设都来自于专家经验和个体直觉。大数据项目的生命周期大致包含整理-分析-反馈-验证等几个步骤，基于存量以及增量数据进行重复多次的迭代性开发和重构。项目周期可能从几天到几年不等，具体取决于业务的复杂程度，外部和内部数据是否容易获得及数据质量，实验性质以及采用的分析技术和工具，相对传统IT项目而言，这种渐进式、循环式的实施方式，使得项目周期和预算经常失控。

总结过去、分析现在、预测未来，这基本上是大数据建设的指导方针。基于这样的思路，大数据建设与传统的IT的项目交付有很大的不同。传统的 IT开发方式在设计时都考虑到了那些被认为重要且可控的数据，以这种方式，从复杂的真实世界中抽象出数据，然后创造一套正式且符合逻辑的数据处理规则，从而简化了系统设计并提供明确的结果。这种方式适合高度结构化的活动，其任务表述精确，比如订单管理系统、财务结算系统等等。这种交付更类似交钥匙工程，就像装修一个房子而已，客户可以拎包入住。

而大数据建设围绕着知识资产进行，存量数据的治理、存量知识的整理仅仅是开始，随着增量数据的不断导入，认知也会发生变化，知识图谱的构建也会同步迭代。第一部分工程的交付只是整个工程的一个先导，一个优质的大数据建设必定依托一个强大的认知计算支撑框架，在框架内不断刷新完善内容和知识体系，这是一个长期迭代、解构并重构的过程，所以用一句比较俗通俗的话讲，大数据建设、认知计算架构的建设，是没有尽头永远在路上的工程。

大数据先天就具有不确定的特质。通常大数据分析出的结果与因素之间的关系都是相关性，不是因果关系，除非是经过非常标准的测试证实了因果联系的存在。这也是为什么很多目前围绕大数据建设的IT项目，经常会遇到一些重复建设、工期拖沓、难出效果的重要原因。

在这种情况下，总结过去的经验，发掘现有的工作成果就是一个必要的先导性工作，但是由于大数据工程缺少有效的样板，可借鉴的经验也不多，往往把总结过去当成一个重要的里程碑，把过去的工作成果用另外一种方式展现出来，大家会认为这种大数据建设是某种作秀。但其实这正是建设的必要阶段，并非是简单的为了汇报，没有对现有工作成果的直观总结就无法有效的进行深度分析，这也正说明大数据建设并非是一个孤立的、泾渭分明的孤岛，大数据建设是大IT建设的一个子集，是连续进程中的一部分，既承袭了传统IT建设的业务流程建设，也在延伸基于当下信息的发掘、研判，预测等等。即使是面向未知性领域的前瞻性研究，针对现有业务的整合总结也是大数据建设必不可少重要阶段。我们经常想象的一个理想场景是先给客户做一个全面体检，从头到脚从内到外的检查，做完之后再制定一个营养食谱，或者是一个治疗方案，全方位的去治疗，按部就班从零开始。但是，实际情况不是这样，更多的是一种头痛医头、脚痛医脚的随机性场景，这对医生的实际上手能力、从业经验提出了非常高的要求。比如说患者告诉你，我现在就是腰疼，你能不能仅仅根据腰疼的几个症状，提出一个非常行之有效对症的解决方法。

传统IT项目中大多是这种场景，大数据建设项目也不能例外。仅仅根据腰疼的种种症状和所获得的数据，其实很难对腰疼进行对症下药。严格意义上，我们需要采集心、肝、脾、肺、肾等等各方面数据，望闻问切也好，验血验尿也罢，都需要一套完整的方法论做支撑，且甲乙双方都要有所共识，这种诊疗方法才能行得通。而用户方或者是患者不能够容忍这样一个复杂的过程，其实道理也很简单，当我们自己去医院的时候，我们也希望仅仅针对显性症状，比如腰疼的一件事儿给一个快速的解决的办法，而不是希望又做CT，又做彩超，甚至核磁共振等等，因为我们长期的生活经历造就的自身认知已经设定了我们可接受的治疗范围，这种范围设定是经过全方位计算的最优选择，你不能说这是讳疾忌医不接受新技术，因为没有人愿意仅仅因为腰上一个疑似囊肿就把自己大卸八块。

防范风险和保持业务连续性决定了我们一定会选择和原有环境相容的应用系统，无论你是做大数据还是大保健。业务信息化追求的是高效、快捷，信息化还是从属于业务。而数据业务化就有点凌乱，数据的驱动会对业务现状造成不小的冲击，甚至还有颠覆的效果也说不定。正如上文提到医患矛盾的产生非一日之功那样，数据业务化本身也给大数据工程造成了幸福的烦恼。

信息化是类似于西医的实验医学长期主导，业务系统信息化改造是对证下药、药到病除的过程，患者需要的是立竿见影、妙手回春的实证方案。而你用一种中医的方法论，告诉患者要天人合一、打通任督二脉，重构体内微循环小宇宙，患者会觉得你是江湖郎中卖大力丸的，不把你举报给派出所已属万幸。

而且，真正的实操用户并非是病入膏肓病急乱投医，和我们自己去医院看感冒的心态是一样的，大家对自身的肌体和所处的环境有着长期了解以及深刻领悟，说白了并不是活不下去而是想活的更好，即使有些小病小灾也是可以应付自如的。

用户常年生活在西医实验医学主导下的的传统IT环境中，容错率和弹性并不高，还是风险厌恶型而且还缺少耐心，因此针对高度不确定性的大数据项目，犹犹豫豫边干边看就是最有可能的选择了。所以大数据从业者如果仅仅能够告诉客户一些所谓肾亏脾虚、虚火上升之类江湖术士用语，还是趁早别出来丢人了。

考察一个大数据团队的能力也很容易，看看能否迅速锁定用户实际问题，是否对自身的能力边界和客户的业务边界有精确感知，能否从广谱抗菌的药匣子里里找到和用户契合的偏方，甚至量身定制、中西结合，此间功力深浅高下立见。大数据项目是围绕知识工程进行的工作，从现有系统或数据源中提取信息获取知识这个过程非常混乱和复杂。信息、知识的提炼大量基于自身认知、思维模式和经验来考虑，甚至组织文化也能影响人们对所拥有的数据和信息做出解读、形成闭环。相对而言，结构化的知识更易于提炼：比如，某种交互语言、经验法则、概念框架等等。非结构知识涉及的是那些深刻、几乎直观的理解，很难清楚表达出来，一般存在于专业极为深厚的知识领域中的就很难提炼。经验丰富的一流工程师，也许能凭直觉解决其他人一筹莫展的技术难题，但他无法将这种直觉清楚阐述出来。身经百战的老探员在掌控谈话、挖掘关系、推测结论等方面拥有超人的经验，却无法将这种行为模式背后的具体原因分享给他的同事。

所以，知识管理本来就不是一件容易的事，人们想当然地认为，有了合适的专家和得力的工具，就能从这些数据中发掘出有用的知识和想法，其实远没有那么容易。大数据分析帮忙解决的只是底层图谱的问题，这个“解决”还是需要长期的修修补补，就像是谷歌地图，有了地图还远远不够，知道去哪里才最重要，大数据建设可以帮你推测出从A到B的最佳路线，但是为什么要从A去B的这种机会成本和风险还是要由你自己来承担。

虽然大数据潜力诱人，但是大数据工程建设却很熬人，过度关注工程阶段性成果，可能导致企业忽视了那些更为重要的事情，即对战略知识资产、核心竞争力、的正确积累。如果不对阶段性输出负责，也就无法了解知识积累的实际进程。而且，组织取得成功依靠的是哪些知识，哪些是具有真正价值的资产，未经认真梳理很多企业还真不一定能说的清楚。

同样，一般的行业认知获取起来都不难，真正有价值的知识取决于你能否挖掘出新专长，即你是否能战略性地利用专有知识，或能否找到貌似毫无关联的知识资产，或有待开发的知识间的关联。即，基于现有结构的解构后的增值重构。显然这是一个连续的进程，没有一个具有强大支撑能力，具备知识沉淀经验、又严格进行过程管控的伙伴团队是实现不了这项长期工作的。

· 吴明辉：从大数据创业到商业化，明略数据开创知识经济大时代

· 吴明辉：AI商业化的核心是让用户合理接受机器的错误

· 明略数据首发行业人工智能大脑 “明智系统” 从个体赋能到全局智能

·  堪比福尔摩斯的人工智能，明略数据加码企业级服务

·【新华社瞭望智库与明略联合研究报告】数字经济时代，以人工智能发掘企业数字资产非凡价值（含下载）

· 3W1H 看懂“明智系统”发布会

· “明智系统”发布，刷爆朋友圈的海报都在这啦！

· 格物致知：明略数据产品理念之一 | 知识就是力量！人机同行：明略数据产品理念之二 | 简单好用

· 「略·读」来“明智系统”发布会领书，成为人工智能专家

点击阅读原文，了解更多“明智系统”相关信息。

    关注 明略数据