背景：大数据是AI时代的基石。企业与政府大力加强业务智能、决策智能发展，其中，数据相关的基础设施、应用与服务建设一直是焦点所在。人工智能公司创新奇智的数据智能团队依托Orion自动化机器学习平台，在制造、金融、零售等场景中，积累了不少实践经验。本文以问答方式，与创新奇智的数据智能产品总监、技术总监探讨了数据智能领域的产品与技术实践规律及前沿趋势。
问：如何理解“数据智能”？在行业市场上，数据智能是一个常用于产品宣传，却又缺乏清晰定义的一个术语。该如何看待这个概念的本质？
答：企业和政府信息化部门做了多年的大数据建设，这个领域概念繁多，脉络复杂。经常看到不同背景的人在一起谈数据智能，说的却不是一件事。根据我们的理解：
从行业客户的业务视角来看，当然是先有业务需求，再有数据智能产品或解决方案。例如，我需要智能营销，自然就引发有关客户画像的机器学习需求，而机器学习类的算法需求又必然引发对高质量数据样本、数据标签等的依赖。
从产品与解决方案的系统视角看，数据智能需要先打下良好的地基——大数据平台，然后在其基础上建设机器学习算法领衔的人工智能平台，以支撑应用层的业务功能，实现客户的业务规划和产出预期。
整个大数据体系的理论基础早在 2004 年前后就已经建立起来了。过去一二十年，行业先解决的是“有没有数据”的问题，即“数字化”“信息化”等老问题。数据在平台内的表现形式经过几次迭代，从单纯的结构化数据，到结构化与非结构化数据的共生，再到多模态数据以及与特定应用类型相关的数据视图，等等。
接下来，完成了信息化建设的行业客户开始把注意力集中到数据本身的价值问题上，即“数据有没有用”的问题。
很长一段时间里，似乎人人都在谈“大数据”，可大多数时候只是“数据大”，很多数据并不知道该如何发挥价值。
其实，真正的大数据不是单纯说数据量有多大，而是要考察数据本身是否蕴含了足够的聚合价值、信息价值、业务价值。一些企业花费资源建了大数据中心，数据量不可谓不大，但遇到业务问题时，要么找不到数据，要么发现数据不合用，要么发现系统缺乏利用数据的有效接口……光有数据而没有应用，这就很难支撑起数据智能的摩天大厦了。
再进一步，当行业客户拥有了高价值的大数据基础后，必然要追求大数据在智能业务中的使用效率和价值回报。最近几年人工智能热度高，不少客户尝试使用机器学习系统来解决业务问题，但数据基础、机器学习算法和业务应用之间往往难以形成良性循环，数据与算法和业务之间的关联度不高，人工智能技术未能深入到核心业务链条中，很难达到一个最佳的投入产出比。
发挥客户大数据中蕴含的信息价值和业务价值，利用智能算法提高客户业务效率。
问：许多客户反映，他们在数据智能建设上的最大痛点是经常发现数据不可见、不好用、噪音多、难聚合、难提炼、难生效。数据智能产品该如何避免这些痛点？
答：从大数据到人工智能的建设链路周期很长。很多客户也是在建设中边摸索、边改进需求、边升级业务流程的。
如果用割裂的方式，分别考察和采购数据库、大数据平台、机器学习算法、业务应用软件等，就很容易导致上述痛点问题的出现。反之，如果能在一个整体思路下，仔细评估数据智能产品与客户当前工具链、价值链的匹配度，项目的成功概率就大了很多。
在工具链层面bsport体育app，客户要采购的数据智能产品必须和今天客户环境中的相关软硬件工具协同工作。技术上，新产品是否能从已有产品中顺利导入导出数据，能否和现有IT运维人员的能力匹配，是否能和已有的数据存储平台兼容等，都是工具链层面需要考察的重点问题。
在价值链层面，数据智能产品与客户的业务有多好的连接度，能同时支持多少业务的运行，能在业务运行时提供多少效率提升或价值提升，最终的投资回报是多少——这些问题不想清楚，上述痛点必然反复出现。
举个例子，我们在为某家银行做智能风控业务时发现，该银行曾经尝试过一个机器学习算法支撑的风控模型，但实施过程中客户自己发现，无论如何优化，该风控模型的“增益”就是上不去，很难在业务层面体现出可见的价值回报。客户回过头来调研后得到结论：
原始数据噪音较多，最明显的原因是已有的大数据平台是与上层的机器学习模型分别建设的，数据虽多，却难以用机器学习算法期待的方式参与上层的风控模型。
简单说，这家银行采购的大数据平台与风控模型之间缺乏可连接性，丰富的数据资源难以发挥效力。我们为这家银行提供的解决方案，就更像是一条能够将大数据平台与智能风控模型联通的自动供应链——其实就是从业务视角出发，将大数据平台的数据在更高一层的视图上进行再次清洗、对齐和平展化，然后在工具链中，增加一个自动特征工程的层级，利用机器学习算法自动完成特征生成、特征价值评估和特征筛选。经过这样的系统改进，最上层的风控模型拿到的样本特征质量获得大幅提高，业务价值也逐渐凸显出来。
数据智能的整体产品设计经历了三个发展阶段。我们把各阶段的典型产品形态总结成三种“数据智能范式”：
由业务需求带动数据需求的模式——早期的数据类应用以业务需求为单元，单独建设，隔离发展。每个业务模块拥有自己独立的数据支撑和应用支撑。
先有数据汇聚，再共享给不同业务来使用的模式——业务形态的多样化以及客户对投入产出比的高要求必然带来数据层面的整合与业务层面的整合。今天的大多数数据智能系统建设都采用了数据整合、业务整合的思想。例如，数据湖是典型的数据整合层，中间件是典型的业务共享单元层，流行的数据中台则试图将数据与业务的可扩展性容纳到一个统一的体系内。
单纯的数据整合与业务整合可以解决资源共享的基本问题，但不易达到数据使用效率的最大化。我们认为，未来更好的数据智能范式，应该是自上而下围绕业务价值建立的数据按需供给、自动响应、安全流转的新范式。
在未来的数据智能范式中，客户对业务价值的要求体现在整个系统架构的设计思路里。自底向上，系统逐层提供数据支撑和业务灵活度：
未来范式的基础是“数据资产地图”。“数据资产”和传统“数据”这两个概念间的最大不同是前者强调数据的可用性，后者强调数据的技术形态。所有数据都可能形成数据资产。我们可以通过智能技术，将数据的潜在价值挖掘出来，例如，将实体间的关系揭示出来，将隐藏在信息背后的深层知识抽取出来，将数据中蕴含的样本特征提炼出来，将数据在高维空间的分布规律描绘出来，等等。我们还可以在非常细的粒度上，为每一“份”数据标记它的来源、位置bsport体育app、交换方式、“健康”状况等。由此，上层算法或应用不仅可以快速找到所需的数据，还可以随时知晓这份数据该如何用，是否可用等。在数据资产地图中，每份数据都是“有生命的”。
未来范式的中间层级是“数据供应链”。这个概念和此前强调数据聚集与使用关系的“数据仓库”以及强调通用业务单元的“中间件”不同。数据供应链更强调数据与不同业务应用之间的无缝衔接和数据在整个业务流程中的安全、有序流转。简单说，未来的大数据不应是静态的数据聚合与共享，而应该是动态的，可以根据业务流程的变化而变化，“按需匹配”完成数据供应的技术体系。
最后，统一的数据资产地图和高效的数据供应链支撑起顶端的数据决策引擎。引擎可以有针对性地调度、获取和应用数据资源，利用机器学习技术为客户业务提供强有力的支持。
拿图书馆来打比方：传统范式下的数据管理就像是每个图书馆各自管理图书，各扫门前雪；流行范式下大集中的数据管理就像是把全国各地图书馆里的书都调过来，统一存在超大规模的库房里。这两种方式各有各的挑战。而在上面谈到的未来范式下，图书本身是不一定要物理集中的，集中和流转的有可能是图书的摘要，有可能是图书的索引，有可能是图书中提取的知识脉络或内容纲要，也有可能是表明图书目前状态和使用价值的元数据。读者可以在任何时候、任何地点，快速定位需要的信息或知识。读者需要什么样的知识组织形式，图书馆就可以按照什么样的形式来重新组织和包装知识——这是知识的按需供应。
所谓“数据供应链”，本质是一种价值传导。很多大数据工程是先搭好数据平台，然后等着业务过来使用，就像图书馆先把图书摆在书架上，等着读者来借阅。如果用动态的思路来看待这个问题，我们完全可以用更低的成本，更聪明地组织好数据资产中的定位信息和元数据，每当一个新的需求方提出了数据访问要求，就很快通过一个灵活的配置文件，将所需的数据组织好，供给到需求方——这是数据价值的按需供应。
问：数据库，数据仓库，数据湖，数据中台，数据集市，数据治理，大数据操作系统，AI操作系统，智能决策引擎……这些相关但内涵又非常不同的概念之间，是否反映了某种技术和产品演进规律？
答：在行业解决方案这个大背景下，技术和产品概念的演进必然是市场需求与技术迭代两者相互作用、相互助力的结果。早期的概念更偏向对技术价值的展现，中后期，这一类概念逐渐转向业务需求驱动，更偏向对业务价值的展现。
例如，很多年前，数据仓库、数据ETL（抽取、转换、加载）的概念更多是从技术侧演进的，基本上源于技术人员在解决那些简单关系型数据库力不从心的任务时的深入思考与高层设计。单点的业务需求和单点的技术积累一旦拓展到不同的数据维度，不同的数据分析方式，就必然引发更高层次的架构组合与技术抽象。
而晚些出现的数据湖、数据集市、数据中台等概念，则更加深刻地体现了系统对业务价值的支撑。产品和技术人员搭建的平台已经从数据库、数据仓库等要解决的“如何存”“如何查”等基础问题，上升到了“不同模态的业务数据如何聚合”“数据如何被业务使用”“业务如何扩展”等问题。后面这些问题显然与业务价值更近。
当然，也有一些概念是纯粹针对市场的包装。比如很多产品声称自己是“AI操作系统”，可业界对什么是“AI操作系统”的理解并不一致，机器学习所代表的AI算法集合与管理计算资源、输入输出设备的操作系统之间也缺乏技术上的可比性。这样的概念有很大的市场营销空间，但可能很难在产品与技术领域沉淀下来。
举例来说，多模态数据的处理是一个难点，也是今天的技术热点。今天各类行业客户业务相关的大数据环境里，数据本身的形态复杂度急剧增加。文本、语音、图像、视频等数据和传统的结构化数据相比，单条数据的体积更大，信息密度也更低，但是事实性更强。体积更大会导致存储成本更高，进而会导致在实际环境中其存储的时间更短，处理时消耗的计算资源更多，处理的时间更长；信息密度更低，使得我们在使用时一般会基于场景做一些信息抽取的过程，转换成结构化数据使用；事实性更强，所以在做基于多模态数据的综合判断时，这些非结构化数据的结论权重会更高。
深度学习技术的迅猛发展为解决类似问题提供了很好的技术支撑。最近两年非常火的基于Transformer的预训练模型可以跨数据形态，用类似的方式学习到文本、语音、图像、视频中蕴含的信息或知识。比如，2021年3月阿里巴巴与清华大学联合发布的业界最大的中文多模态预训练模型M6，就可以适用于广泛的多模态任务，包括产品描述生成、视觉问答、诗歌生成等，还专门支持文本引导的图像生成任务。
此外，如何用人工智能的前沿技术，自动清洗数据，如何自动将不同来源、不同字段规范的数据相互对齐，如何从数据背后发现隐藏的更有价值的信息或知识，如何从一个领域数据处理快速迁移到另一个领域等，都是未来几年数据智能领域需要投入大量研发资源的地方。
当然，人工智能不是万能的，不是一件拿着锤子就可以到处敲钉子的工作。好的人工智能技术要落地，必须结合具体业务，将算法的应用范围限定在一定的场景内。即，人工智能落地非常依赖于“有限场景”。简单讲，如果不限定领域，从所有文本中评估两个实体间的相关度肯定是非常难的，但如果限定金融领域的文本，这时再评估两个金融术语之间的相关度，问题就会容易不少。
问：数据可视化技术在数据智能中的作用如何？如何设计一个成功的数据可视化产品？
答：数据可视化是借助视觉表达方式，将枯燥专业的，不直观的数据内容，浅显直观的传达给数据使用者的一种手段，是数据智能的重要组成部分。
一个成功的数据可视化产品，最重要的是找准数据可视化产品的定位，即数据可视化产品的受众。数据可视化需要匹配受众的专业背景知识，并能够让受众轻松快速地查看和使用数据，同时还要充分考虑受众对数据呈现基本原理的熟悉程度，以及是否需要经常定期查看图表等因素。受众的不同会影响到数据可视化的数据的层次、数据粒度、数据的类型、图表的使用、示例说明的详细程度以及交互的程度。在一个针对多受众的数据可视化产品中，会基于不同的受众决策采用不同的数据可视化展现方案，并保持可视化的一致性。
例如，将一组无序的离散数值型数据做可视化时，如果受众几乎没有统计学相关的知识，我们可以按照数值区间分组，然后通过饼图或者南丁格尔玫瑰图来显示；如果稍微有一点点统计学的知识，则可以通过箱型图来显示；如果有一定的统计学背景，就可以选择用直方图了；如果统计学知识很深厚，则可以进一步在直方图上拟合出概率质量函数。
当然这些还仅仅只是从数据视角出发考虑的问题，从艺术视角来看，针对统计学知识比较少的受众，在一些报告类的数据可视化产品中可以用一些更个性化、更酷炫的方式展现饼图、南丁格尔玫瑰图或者箱型图中的数据；从设计的视角来看，针对有丰富统计学知识的受众，在直方图和概率质量函数拟合时可以提供丰富的配置方法，让用户可以非常方便的选择和调节背后的算法公式。
问：自动化机器学习（AutoML）可以在 数据智能系统中扮演什么角色？在企业应用中引入自动化机器学习，有哪些需要注意的地方？
AutoML技术最吸引人之处在于它能够实现更便捷、更高质量的AI智能应用搭建，从而实现人工智能这种社会基础动力的普及。识别、预测等各类与机器学习相关的业务需求，都可以通过AutoML来不断降低搭建门槛、提升效率和质量。
建设AutoML系统时，一方面，为了提升便捷性，要考虑整个AI智能应用搭建的全流程。例如，场景化AutoML平台在机器学习建模过程之外，涵盖模型搭建前的业务分解、数据评估以及后续的智能应用部署实施和更新等流程，形成完整的自动化流程，满足客户从业务到任务、从任务到流程、从流程到模型以及从模型到最终应用的全流程需求。另外，采用无代码或低代码的开发方式以及友好的用户界面，加以对自动化环节的可解释性展示，最终达到用户便捷无忧的实际体验。
另一方面，AutoML结果的高质量是依赖先进算法以及高质量模型和知识的丰富积累来实现的。如创新奇智的场景化AutoML平台，在采用业界最先进的自动化特征工程、模型选择、参数优化、模型融合等算法技术的同时，基于元学习和经验概化理论，首创了基于实际场景迁移的AutoML方法，实现了一整套场景化AutoML方法论和算法工具，从而最大化人工智能引擎的最终效果。
问：如何高效管理数据智能平台涉及的各类计算资源，特别是深度学习高度依赖的GPU资源？
该如何高效利用好单张 GPU 的算力资源？GPU 的架构模型与 CPU 有很大不同，很多时候难以沿用 CPU 虚拟化的方案。我们常需要针对 GPU 的特点，构建一种适用的虚拟化方案。除了 Nvidia 的商业方案外，随着云原生的发展和开放，还有很多基于 K8s 的技术方案可供选择。其中有两个主要技术：调度技术解决是否允许将任务分配到某张 GPU 卡上的问题，隔离技术解决同张 GPU 卡上不同任务之间不互相影响的问题。
该如何提升GPU 集群的分布式训练效率？训练任务规模的增长要求分布式的训练方式，而分布式训练必然会涉及到模型参数的同步和分发，技术上既有基于参数服务器的 PS 架构，也有从 HPC领域发展而来的基于 MPI 通信原语的 Ring AllReduce、Binary Blocks 等架构，这些架构除了解决分布式训练过程中模型参数的同步问题外，还在降低参数同步所带来的性能损耗方面做出努力。这样，对于分布式训练任务，用户仅需指定资源需求、Worker节点数量，提供训练代码，就可实现像单机训练任务一般简单的分布式训练。
从客户角度讲，数据智能平台的基础资源管理部分最好能提供一种同时兼容单GPU训练和分布式GPU训练的任务、资源调度方案。在客户业务初期试验阶段，任务规模一般较小，通过虚拟化方案，客户可以实现在一张 GPU 上同时训练多个任务；而在业务应用阶段，单机训练无法承载生产级别的数据量和模型规模，需要借力分布式训练，最大程度的发挥 GPU集群的整体效率。
创新奇智的Orion自动化机器学习平台是一套符合未来数据智能范式的，拥有可灵活选择、配置的三层结构，面向行业客户，以私有化部署为主的系列产品和解决方案。Orion数据智能引擎主要包括三大产品单元：
Orion DAC：智能数据融合管理，支持数据动态融合，实现数据供应链。
从设计初衷上说，Orion自动化机器学习平台主要希望帮客户解决两件事：如何用好数据，如何提高数据决策能力。
首先，要“让数据会说话”。获取、清晰、存储、加工、管理这些数据基础操作都只是手段而不是目的，最终目的是能让客户从数据中获取足够的使用价值。这里面最关键的因素是如何“盘活”数据资产。数据越来越多，但只有“盘活”了数据与业务之间的供需关系，真正建成了“数据供应链”，客户业务才能有提升。
继而，要“让数据会决策”。数据智能引擎必须在数据建设的基础上，用有效的、面向业务目标的机器学习能力，帮助客户提高从信息中获取知识，从知识中预测趋势，从趋势中洞见未来的能力。有了这样的能力，客户的决策才能真正升级到数据驱动的层次上。
Orion自动化机器学习平台的核心使命就是利用前沿技术盘活客户数据，实现数据价值，赋能客户业务。
本文系网易新闻•网易号特色内容激励计划签约账号【量子位】原创内容，未经账号授权，禁止随意转载。
本文为澎湃号作者或机构在澎湃新闻上传并发布，仅代表该作者或机构观点，不代表澎湃新闻的观点或立场，澎湃新闻仅提供信息发布平台。申请澎湃号请用电脑访问。