总左往右看，当知识出现行业垂直分化的时候，在工作-娱乐这个维度上，云计算也会出现分化，形态上可以近似理解成“IaaS - PaaS - SaaS - Metaverse”的变形，用下面的表格来说明：

• 在 IaaS 形态中，算力和基础的算法模型都是通用的，因此规模效应明显，是大厂的优势领地。
• 在 PaaS 形态中，由于场景差异化和知识差异化的存在，出现了产业和娱乐的分化，产业方向上，主要是人与场景/物品的交互，面向B端，娱乐方向上，主要是人与人的交互，面向C端。（这里把交易型平台放在产业一侧，也可以独立出来）
• 在 SaaS 形态中，场景更细分，行业知识也因为细节差距巨大，进一步巩固了 SaaS 的分化，带来了更多中小厂商的生存空间

在后续向元宇宙Metaverse的演进中，不可避免出现“开放”和“封闭”两种对立的结构。

在产业方向上，下游行业知识复杂性陡增，各种行业标准层出不穷，下游企业也倾向于避免出现垄断型的上游服务商，因此，产业方向的云宇宙，是松散开放的多边市场。

在娱乐方向上，直面用户，网络效应明显，容易出现垄断型的服务商，因此是封闭的双边市场，一方提供服务，全部用户消费，第三方厂商的生存空间小，赢家通吃。

为了避免 AI 算法产生偏见和歧视，可能要求穿透审查 AI 算法的基础数据，也就是基于样本可解释性，审查那些用于训练算法模型的被采集标注的样本是否带有偏向性。

举个例子，美图秀秀的 AI 修图模型，使用了大量的东方人面部数据，在处理西方人面部时，不可避免会偏向东方人的面部特征，这里产生了一种模型上的“偏见”，所谓穿透审查，就是要求在训练修图模型时，对各地区、各人种、各肤色等等特征，在基础数据上进行公平分配。

在各国纷纷出台涉及 AI 算法规范的前提下，为了避免出现这样的偏见或歧视而产生的市场反应，会是什么样的？在样本可解释性上，很有可能出现一个“合规数据集”市场，有一类专业的基础数据提供厂商，会为算法训练提供能通过“反歧视”审查的标注数据，这些标注数据甚至会形成一个可重复交易的市场。这样的基础数据服务厂商可能有这样一些要求：

• 熟悉欧盟、美国及其他地区的反歧视规则和审查机制
• 具备从分散的数据源获取数据和标注的能力
• 从工具链和管理上，同时具备通过安全性审查和反歧视审查的能力

算法的可解释性是个前沿性话题，各大公司都在做探索，比如谷歌的 X AI 计划与模型卡（Google Model Cards），大致上可以理解成，为算法输出一张“药物说明书”，告知公众算法的基本机制和关键限制要素。

中国人民银行发布了《人工智能算法金融应用评价规范》，并于3月26日起正式实施，是一个成熟度很高的行业规范，可以应用在通用型 AI 算法的评估上，可以参看一图读懂 | 《人工智能算法金融应用评价规范》

结论：出现了运行在不同计算和存储架构中，时序型数据库和图数据库的机会

数据库软件赛道，国内的投资市场还是挺热闹的，出现了如PingCAP、TigerGraph、涛思等企业，大厂的云服务对这样一个市场也很重视，产品矩阵非常完整。结合近期收集的资料，谈谈自己的一点看法。

数据库软件的需求变化

技术进步和新兴产业（如工业互联网、自动驾驶、5G等），对数据库软件的需求环境产生的巨大的影响，从硬件和数据特点两个方面看：

• 硬件

  • 边缘设备：算力弱、存储小、数量大、分散
  • 存储和读取：内存、SSD、HDD、傲腾等设备性能大幅度提升

• 数据特点

  • 数据量大，历史数据多
  • 写入频繁，读取少
  • 数据是顺序写入，update少
  • 数据多维关联

对数据库软件的要求

从硬件特点看，要求新的数据库软件，具备分布式能力，适应不同存储和计算架构，能充分发挥边缘端设备的计算和存储能力，同时有网络和数据安全需求

从数据特点看，是比较典型的时序数据库和图数据库的应用场景，在云计算场景下，内存型数据库又可以大服务提高I/O性能

大厂的布局，腾讯/阿里/百度/华为

分类不精确，部分数据库服务基本多种特性，大厂云服务还提供成熟数据库软件云部署的能力，如Redis等，未写入表单，内存型时序数据库Google Monarch和Facebook Beringei也未列入，国内其他厂商为列入。

数据库软件中小团队的竞争

由于大厂（BATH及运营商等）在数据中心建设上有规模优势，因此存储成本优势和算力优势难以超越，因此留给中小团队的竞争手段不太多。

• 私有化部署，面向政府、央企、大私企等对数据安全有较高要求的客户
• 结合行业认知的增值服务，面向新的数据特点和维度改进数据库
• 海外市场
• 成为大厂云服务的一部分

- 阅读剩余部分 -

结论提要

• 数据标注类项目，走向细分垂直，仍有机会
• 数据集交易是长期趋势，需要培养
• 地方产业基金，会考虑符合本地特色的投资项目

一、定义和模型

1、定义：

AI基础数据：为AI提供可用于模型训练、校验、应用的数据。数据加工的过程通常是指将非结构化数据转化为结构化数据的过程。

基础数据服务：包括资源和工具链两部分。资源是指多为非结构化的原始数据，也可以是结构化的数据集，以及加工数据所需要的人力资源；工具链是指支持数据采集、清洗、加工的基础技术软件和设施，主要目的是提高效率。

2、基本模型：

数据+算法+算力 -> 应用方案 <-> 应用场景

二、现状和判断

如上图的模型，应用场景增加要求方案群增加，而方案群增加有三个方向：

算法增加，处理过去不能处理的数据类别
算力增强，处理过去不能处理的数据量
基础数据增加，提供过去没有数据类别，或因为准确性不足不能用于处理的数据

基本判断：

创业团队技术上难超越大厂。从当前云服务市场的成熟度看，算法和算力已经成为互联网大厂标配，有品牌和成本优势，且在人才储备和应用场景储备上投资很大。

1、基础数据提供，存在市场机会
算法算力标准化之后，作为原料的基础数据差异（类别、质量、数量），成为竞争的关键
向海外延伸中，小语种和方言应用场景，需要大量基础数据
行业客户的AI改造，因为数据安全需求，存在一个咨询和私有化部署的市场

2、工具链，存在市场机会
工具链对数据标注的效率提升，有很大空间
新的标注领域，需要新的工具软硬件支持，如激光/红外/紫外图像标注、嗅觉标注、触觉标注、非侵入式脑机接口标注等

3、数据供给和交易，需要长期布局
专业标注人员的培养和供给，是长期需求
数据集在安全合规的情况下，交易是降低获取成本的重要手段，涉及到数据资产定价和保护
数据跨境流动，是长期趋势，各地区存在监管落差，时机未成熟

三、地方产业基金的投入

AI市场规模和发展趋势，各类报告都有详尽的阐述，这里举例强调各地区规划的促进作用，会有地方产业基金在发展地方特色的基础上，深入投资。

1、湖北

湖北省新一代人工智能发展总体规划（2020—2030年）

2、云南
“构建开放协同的人工智能科技创新体系。突出了烟草、有色、化工、能源、环保、医药等智能特色应用领域技术创新”
“突出了“3个一批”，即推动一批企业智能化升级、引进一批人工智能领军企业、孵化一批人工智能企业”

四、融资信息（近期发布）

获得大额投资的项目，有较强的下游应用能力；小团队的优势在工具链软件上，效率优先；

数据来自公开报道

五、风险与建议

风险：
1、常见的数据标注公司，走向人力密集型产业，受地方产业政策影响明显，竞争激烈
2、AI技术应用企业未形成稳定盈利，融资情况会影响数据提供商的收入稳定
3、工具链产品扩展新客户成本高，对新竞争者不利
4、数据安全监管加强，合规风险增加
5、算法模型的可解释性要求，对基础数据的影响不明确

建议：
1、掌握细分行业知识和特殊标注人员等的项目，关注对稀缺资源的掌控力，同时考虑市场需求是否过小
2、提供基础数据生产工具链的项目，关注获客成本
3、数据集安全合规的项目，关注政策和相关安全标准是否通用化
4、数据交易类项目，长期布局

参考内容：

各项目的科技媒体及公众号的报道

• 「海天瑞声招股书」
• 「艾瑞咨询-2020年中国AI基础数据服务行业发展报告」
• 「湖北省新一代人工智能发展总体规划（2020—2030年）」
• 「云南省新一代人工智能发展规划-2019年」
• 「金柚网-2020新基建系列专题：人工智能基础数据服务行业观察」

时常能看到一些大数据工程师的自嘲，说着自己是“调参师”，只知道喂数据、调参数、写周报。也能看到一些用户吐槽大厂的个性化推荐是人工智障，还不如创业团队。除去个人偏好的影响，这大概就是拥有数据资源的大厂逃不掉的“资源的诅咒”。

“资源的诅咒”是一个经济学概念，大致上是说拥有丰富资源的国家和地区，存在路径依赖，由于资源成本低，对资源的开发和利用效率不高，反而成为了低收入国家和地区。

理论上，数据是一种越多越好，具有网络效应，边际效用递增的资源，维度越多，覆盖越广，价值会越来越大。
实际上，消费者消费的是数据加工后的产出物，这个加工过程，有一些特点是需要讨论的。

维度增加，特征增加，算法复杂，意味着计算难度成倍增加，还会带来复杂模型侵蚀边界 (Complex Models Erode Boundaries）的问题，改变一个细节就改变了所有（Changing Anything Changes Everything）。

业务的复杂性，以及研发与业务的分离，也造成了一些工程师，也包括产品经理缺少对业务也就是“工艺”的理解，喂更多的数据，调整原有工艺里的参数，是“低成本”的选择。

在内容个性化领域，还有一个不可忽视的因素，就是内容版权的限制，一方面，工艺高超，缺少内容也是巧妇难为无米之炊；另一方面，大量质量不足的内容进入推荐池，反而造成了效果不佳，也是一种程度上的“资源的诅咒”。

最后推荐一篇「Hidden Technical Debt in Machine Learning Systems」，值得一看。