人工智能中台化战略

现在不管是大型企业还是中小型企业都会面临外部市场的快速变化，因此企业需要拥有类似创业公司般的快速反应能力。然而随着企业规模的增长，人员和层级关系也逐渐复杂，如何适应市场的快速变化就成为一个难题。

一般企业的职能部门大多采用分治的树状组织架构，层级越多，不管是从上至下还是从下至上推动起来的阻力就越大，这中间如果任何一环节出了问题就难以进行。并且各业务线一般各自拥有KPI，更进一步增加了协作难度。传统企业的树状组织架构如图1所示。

图1 传统企业的树状组织架构

即使获得上层支持，克服重重困难，从各部门抽调和招兵买马，成立了新的业务部门，也将花费相当多的时间，在这期间快速变化的市场很有可能出现方向的转换，之前的努力又将如何处理？

面对这个共同难题各大组织尝试了各种解决方案。例如，阿里巴巴在2016年提出了“大中台小前台”的战略，将业务共同的工具和技术予以沉淀，成立专门的中台部门。因此，新的项目可以重用中台服务而不用完全重新设计，避免重复功能建设和维护带来的浪费。不仅在商界如此，美军同样设计了新的战斗方式，每3人一个小组，战斗需要时可随时调集后方火力、信息和后勤支援，灵活而成本低廉。大中台小前台的组织架构如图2所示。

图2 大中台小前台的组织架构

在编程领域其实也早有类似的概念，中台类比到编程领域，就是形成可复用的函数库，抽象共性，减少重复开发次数，提高迭代效率。中台其实就是将人力、技术和服务重新组织的一种方式。例如，数据中台维护底层数据能力，内容中台将各类资讯汇总整理，为各业务提供丰富的资讯资源；推荐营销中台抽象推荐系统的共性，为各业务提供营销的快速接入能力。这样做的好处就是协调起来更加方便统一，如数据中台可根据业务优先级管理流量和负载分配，在各部门独立时代做到这些是相当困难的。另外中台还有一大好处——分担风险。

当然中台也是有对应的要求的，中台要求公司结构的扁平化管理模式，尽量少的条条框框，制度灵活、基础设施（如数据库和代码库）统一，否则实施起来很困难。

虽然中台相比于传统模式有优势，但是存在实践和理论的隔阂。中台该做什么不该做什么、如何与业务方良好协同、如何评估KPI都成了难题。

我们可以根据中台对业务方的参与度绘制成一张图，如图3所示。

图3 不同企业中台对业务的参与度

• 轴的最左边：仅提供工具库和少量答疑维护，不对最终业务效果负责。绝大多数开源项目、数据库都可以归于这种中台。
• 轴的最右边：All-in参与业务方的大部分流程，从运营业务到数据模型事无巨细。这种中台被称为“高级外包”。

对于中台存在的左右不一致问题，我们形象地称为左倾和右倾问题。

如果越倾向于左边，工具抽象和通用能力越强，赋能业务越多，技术人员能专注于技术本身。但这样就是最优的吗？不一定。越倾向于左边，无法深入业务场景的概率就越大，很有可能无法接受业务反馈滋养，最后导致故步自封，甚至为了技术而技术变得学究派，过于独立的中台变成了纯后台。

在最右边则是另一种极端，其优点也非常明显：此时中台完全融入业务，有完整的业务意识，非常理解并能快速应对需求，与业务方打成一片，被称为“高级外包”。但是缺点也很明显，该模式下的人力一般只能覆盖单一业务，很难对外辐射。因为毕竟人的精力有限，如果技术人员过于关注业务，就会导致中台的技术深度相对较浅。

我们要同时警惕这两种极端，但从整体来看，最容易被忽视的反而是右倾。右倾构建了看似美好的中台合作模式、亲密无间的服务，但是人们很容易忽略其中的问题，过分具象和强耦合会导致中台能力难以沉淀在通用的工具和理论上，当遇到其他相关业务需求时，大概率原有产品并不能支持，导致应对变化的能力不足，一旦业务方向变化就可能前功尽弃。

受限于中台的资源投入，过重的服务模式会导致只能覆盖有限的业务。因此中台不得不评估各项目的重要程度，拒绝部分优先度较低的前台业务。因此前台可能会为自己的业绩考虑去自行组团队完成项目，进而导致中台与前台隔阂。如果增加中台资源投入并全面地参与到业务方，则会导致侵入性增强，人的问题会成为最大的问题，中台可能会架空业务方人员，引起猜疑，甚至中台部分业务可能被并入业务方，导致中台骨干流失。

那么什么才是最优的人工智能中台模式呢？

合理的人工智能中台应该能最快、最好地满足企业的人工智能工程化需求，其提供的服务应该像空气一样，不特意感受就察觉不到存在，但它又是必不可少的。

要做到上述目标，中台必须有对应领域过硬的能力积累。例如，算法中台需要有扎实的理论基础，搜索中台在搜索方面的积累更是要达到业务方想不到的程度。打铁还需自身硬，否则被革命掉只是时间问题。

中台一方面提供服务，另一方面则促进人和人之间的交流和沟通，加强换位思考能力。原本不同方向的人为了共同的目标在一起工作，这样就能够迅速地学习对方的能力。在任务告一段落后，我们需要总结并关注：业务方是否能自主维护、改进甚至优化中台的工作和技术；中台是否能通盘理解业务和积累技术沉淀。因此，在合作开展初期，可适当右倾，中台快速全面地熟悉业务，建立共识；随着业务深入，业务方逐渐吸收消化，中台慢慢后撤，最终业务方可自行处理大部分问题。

一般来说，在提供相同服务质量的前提下，对业务问题的抽象能力越高，中台的参与度就越往左。典型的例子就是SQL，它将数据处理的需求抽象得如此淋漓尽致，技术人员能专注于性能优化，业务方能灵活操作数据逻辑，最终一起完成业务目标。

因此，中台应当考虑以下问题：应该如何合理抽象自己的服务和技术，才能将业务和底层解耦？应该如何设计领域特定语言（DSL），才能使业务方方便使用，也易于理解？TensorFlow和Keras等深度学习框架成功的一大部分原因，就是拥有了设计非常良好的深度学习原语。越好的抽象和领域原语，就越能发挥前台人员的业务优势和主观能动性，极大地提高了沟通效率。

同样，业务方也必须能把自己面临的问题予以清晰地定量描述，参数、环境和目标应该能明白、清晰地量化并形成可解释的文档。提出过于模糊的、抽象的（不管用什么方式，以提升KPI为目标），甚至不切实际的目标，就是业务方的不负责任。清晰的分界和明确的问题是大家应做之事，毕竟双方的精力都是有限的，只有做好分内之事才能快速实现目标。

另外在沟通方面，主管之间的密切配合也是不可或缺的，需要建立一套紧密沟通机制，如定期参与前端的业务周会，同时有明确的接口人机制。笔者见过不少例子，多个接口人会导致信息冗杂失真、传播不畅，效率非常低。接口人需要熟悉业务，明确业务问题，拥有较强的沟通能力。业务域和中台域之间的沟通机制如图4所示。

图4 业务域和中台域之间的沟通机制

综上所述，一个好的中台服务不仅强调要给业务方提供强大的技术能力，能解决业务上的各种难题，还需要提供易于使用的一种抽象工具，隔离具体实现和业务之间的强耦合。更强调与业务方的互动反馈，毕竟没有需求，功能再强大也是一种资源投入的浪费，业务需求和中台之间的良性互动不仅能提升企业的战斗力，也能提高自身的技术能力，技术人员也将从中受益。

要想进一步了解关于人工智能中台化战略的内容，包括人工智能中台的数据能力、业务能力、硬件能力、平台能力等核心知识，请关注新书《人工智能工程化：应用落地与中台构建》。本书清晰解答了人工智能工程化的应用场景是什么，并且着重介绍了如何搭建人工智能中台，能够带给相关从业者非常有用的经验。

本文选自博文视点新书《人工智能工程化：应用落地与中台构建》。本书聚焦人工智能工程化应用场景与技术细节，手把手教你搭建企业人工智能中台：技术中台、数据中台、业务中台。侧重于人工智能工程化落地细节的技术资料一直比较罕见，本书因此而受到清华大学计算机系长聘副教授、AIOps专家裴丹的大力推崇。