大数据认知计算框架：带来“中西医结合”解决方案

文/明略数据COO 唐日新

考察一个大数据团队的能力很容易，看他能否既像西医一样，迅速锁定用户的实际问题，又运用中医理论，对自身的能力边界和客户的业务边界有精确和整体的感知，然后从药匣子里找到和用户契合的方剂，量身定制、“中西结合”。

传统IT部署是西医，头痛医头、脚痛医脚。一个资深的大数据团队，则能利用中医方法论，打通企业“任督二脉”、做到“天人合一”。

传统IT部署VS大数据认知计算框架

传统的IT部署的表现形式和设计理念与以大数据为基础的认知计算架构有很大的不同。一般IT项目的特点是稳健、精准、防范风险，重点在于新系统的成功部署以及解决计划中的问题。然而大数据项目并不十分在意技术部署风险，而是将更多精力放在解决业务问题上。

首先，二者所处发展阶段不同。相比 IT方案，目前阶段的大数据及分析项目更像是科学研究和临床试验。即便是在感知问题或发掘潜在机会，也充满不确定性。很多业务假设以及基础理论依然在验证过程中，大量假设都来自于专家经验和个体直觉。

其次，项目周期不同。大数据的项目周期可能从几天到几年不等，具体取决于业务的复杂程度，以及外部和内部数据是否容易获得及数据质量，实验性质以及采用的分析技术和工具等。其生命周期大致包含“整理-分析-反馈-验证”等几个步骤，基于存量以及增量数据进行重复多次的迭代性开发和重构。相对与项目周期固定的传统IT部署而言，大数据项目更渐进式、循环式，这种实施方式经常让项目周期和预算“失控”。

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

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

大数据建设是大IT建设的一个子集

探索前瞻领域，一切从整合总结开始。

先天具有不确定性的大数据，经常会把人带入重复建设、工期拖沓、难出效果的“死胡同”。这是因为，通常大数据分析出的结果与因素之间的关系都是相关性，不是简单的因果关系，除非是经过非常标准的测试证实了因果联系的存在。在这种情况下，总结过去的经验，发掘现有的工作成果就是一个必要的先导性工作。大数据建设并非是一个孤立的、泾渭分明的孤岛，大数据建设是大IT建设的一个子集，是连续进程中的一部分，既承袭了传统IT建设的业务流程建设，也在延伸基于当下信息的发掘、研判，预测等等。即使是面向未知性领域的前瞻性研究，针对现有业务的整合总结也是大数据建设必不可少重要阶段。

运用“整体观”与“系统论”的大数据工程

我们经常想象一个理想场景，先给客户做一个全面体检，从头到脚从内到外的检查，做完之后再制定一个营养食谱，或者是一个全方位治疗方案。然而实际情况并非这样，更多的是一种头痛医头、脚痛医脚的随机性场景。这对医生的实际上手能力、从业经验提出了非常高的要求，比如说患者说腰疼，医生能不能仅仅根据腰疼的几个症状，提出一个对症下药的方子。

传统IT项目中大多是这种场景，大数据建设项目也不能例外。仅仅根据腰疼的种种症状和所获得的数据，其实很难对腰疼进行对症下药。严格意义上，我们需要采集心、肝、脾、肺、肾等等各方面数据，望闻问切也好，验血验尿也罢，都需要一套完整的方法论做支撑，且甲乙双方都要有所共识，这种诊疗方法才能行得通。

但是用户方或者是患者不能够容忍这样一个复杂的过程。当我们自己去医院的时候，我们也希望仅仅针对显性症状，比如腰疼的一件事，给一个快速的解决的办法，并不希望又做CT、又做彩超，甚至核磁共振等等。因为我们长期的生活经历造就的自身认知已经设定了我们可接受的治疗范围，这种范围设定是经过全方位计算的最优选择。不能说这是讳疾忌医不接受新技术，因为没有人愿意仅仅因为腰上一个疑似囊肿就把自己大卸八块。

防范风险和保持业务连续性，决定了我们一定会选择和原有环境相容的应用系统。

信息化是类似于西医的实验医学长期主导，业务系统信息化改造是对证下药、药到病除的过程，患者需要的是立竿见影、妙手回春的实证方案。用户常年生活在西医理论“主导”下的的传统IT环境中，容错率和弹性不高，是风险厌恶型而且还缺少耐心，经常容易因大数据项目的高度不确定性，犹犹豫豫边干边看。

但是，一个高水平的大数据团队，不仅用“西医理论”指导迅速锁定用户实际问题，对症下药，还能娴熟运用中医“整体观”和“系统论”对自身的能力边界和客户的业务边界有精确感知，从药匣子里里找到和用户契合的配方，量身定制、中西结合。

大数据 VS 知识工程 ：从底层知识图谱做起

大数据项目是围绕知识工程进行的工作，从现有系统或数据源中提取信息获取知识这个过程非常混乱和复杂。信息、知识的提炼大量基于自身认知、思维模式和经验来考虑，甚至组织文化也能影响人们对所拥有的数据和信息做出解读、形成闭环。

相对而言，结构化的知识更易于提炼。比如，某种交互语言、经验法则、概念框架等等。非结构知识涉及的是那些深刻、几乎直观的理解，很难清楚表达出来，一般存在于专业极为深厚的知识领域中的就很难提炼。经验丰富的一流工程师，也许能凭直觉解决其他人一筹莫展的技术难题，但他无法将这种直觉清楚阐述出来。身经百战的老探员在掌控谈话、挖掘关系、推测结论等方面拥有超人的经验，却无法将这种行为模式背后的具体原因分享给他的同事。

所以，知识管理本来就不是一件容易的事。

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

大数据路漫漫，为知识增值重构上下而求索

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

同样，一般的行业认知获取起来都不难，真正有价值的知识取决于你能否挖掘出新专长，是否能战略性地利用专有知识，能否找到貌似毫无关联的知识资产或有待开发的知识间的关联，基于现有结构的解构后的增值重构。

显然，这是一个连续的进程。只有一个具有强大支撑能力，具备知识沉淀经验、又严格进行过程管控的团队，才能担当重任。