AI时代，数据为王。那么AI数据是如何建设的？本文将以人脸和声纹数据为例，从AI数据的存储说起。
2.1搭建数据库
如果没有数据库，数据就只能存在个人电脑或硬盘里，这种方式非常不安全，容易造成数据泄露且不易查询。这里的数据库是指关系型数据库（Oracle、My SQL），后期可能还会发展成数据仓储（AWS Redshift, Greenplum, Hive）。图片等数据还是存储在如nas盘的地方。
数据入库虽由开发完成，但数据入库前需要产品经理提炼好业务数据模型，即规划好入库需要保留哪些字段，有哪些类型（具体如2.2）这一步是数据库搭建的基石，合理的业务数据模型提炼需要产品经理深刻洞悉业务的本质，如果理解有误或者思考不周全，将会直接影响数据库表结构的设计，导致后期返工。
2.2字段类型：数据入库
产品经理需要在理解业务逻辑的基础上，明确数据需要留存的字段，开发同事才能建设数据库表字段。这一步目的是为了日后提取数据时，能有不同的标签供筛选提取。所以如果这一步一定要考虑周全，适当扩展需求字段或者预测未来的需要，否则后续可能没有办法区分某些细分类型的数据，清洗环节就会花费更多的人力时间。以下以人脸和声纹部分字段为例。
1）人脸：
人员ID：一个人可能有多张照片或音频，需要一个区分人员的唯一标识，如身份证，员工号，客户号，手机号等
来源ID：不同渠道的精准度和数量级不同，所以要区分数据是由哪一种收集渠道来的，如业务、采购、人工采集、公开数据集等。
业务ID：业务的场景特性不同，可用于定位问题和场景特性分析，一般是自定义的英文数字串。
数据类型：用于区分不同数据类型。如人脸的证件照、生活照、身份证照片。声纹的固定文本、文本无关和随机文本。
用途：拿去训练的数据不能用于测试，如测试，训练。
人员信息：表示产生该数据的人的特性，如年龄、性别、国籍、人种、省份
数据质量：如人脸遮挡、光照、模糊度程度，声纹内容完整程度；
数据属性：表示该数据的属性，如人脸有无闭眼，张闭嘴，戴帽子，黑眼圈，背景噪音，音量，表情、情绪。
创建时间：要注意区分是数据生产时间，还是入库时间。
比对分数：算法检测的结果
2）声纹部：
数据简写：简单描述采集人身份的更多信息，如年龄、语言、健康状况等
数据来源：从数据来源信息分析环境噪音，便于定位问题
语音ID号：同一文本类型，可能录制多次，比如数字文本录制8次，按编号1-8进行标记
数据时间：仅用于记录，但也是必要信息
数据录制设备：采集多信道数据时，这是重要的标记信息
数据用途：用于声纹识别或活体检测
数据类型：数据分为固定文本、数字文本和自由文本，简写可快速得知数据类型
其他特性：如声纹采样率，8Khz,16KHz；信道，电话、手机、音箱、麦克风。
2.3字段获取方式
检测手段有以下几种，每种适合的标签字段不一样：
接口回传解析：指业务接口日志就存有的标签字段，比如ID和类型（身份证、手机号、客户号）
算法模型识别：指在数据库中布算法模型跑数据，给一个算法分数的字段，便于提取目标数据时有一个初筛。
映射关系：通过业务场景或特点映射的字段标签
开发工具：有些字段包含在文件中，但不能直接获取，人工一个个打开记录不现实，一般开发人员会开发或寻找一个工具，实现批量获取。比如人脸图片数据的大小，可以从操作系统直接批量获取。人脸的视频，声纹的音频数据需要批量判断文件有多少时长，多大的话，不能直接从操作系统获取，需要开发一个小工具获取。虽然不需要产品经理开发这些工具，但产品经理了解这些对数据入库方案可以做出更准确的周期预判、优先级规划。
人工打标签：人工精细化清洗。人工清洗时赋予数据的标签字段，会更新到数据库表中。
3.3存储量：
数据库构建早期，数据越多越好，可以说是来者不拒。因为此时团队的算法能力还比较弱，对数据的精细化程度要求还不是很高，库里的数据对算法能力的提升多少都会有帮助，另一方面团队初期在应用场景上的积累和经验有限，对未来规划无法做出清晰的远瞻性决策，贸然舍弃一部分数据，在未来拓展了相应落地场景时，就会痛惜缺失了相应的数据。
所以在早期，数据全量入库存储是没有问题的，但随着业务的拓展，数据量会呈指数增长，存储成本将会给团队预算支出带来巨大压力。这个时候产品经理结合算法当前的能力和存量数据以及增量场景数据的特点制定一套恰到好处的数据瘦身回流策略就显得尤为必要。
要知道当前算法测试训练所需的数据是哪些，不需要或者存量已经很充足的数据有哪些。
比如人脸数据，一个思路是从阈值出发，阈值附近可以考虑优先回流（因为算法在阈值附近的误判率比较高，关于附近的定义是什么范围，这个需要结合数据量比例以及算法的要求共识制定）。
另一个思路是根据业务ID的场景特点分析，比如人脸考勤闸机业务来的数据，每月都会产生大量重复人员的数据（因为一个大楼的人员很固定）是否每个人的每日每个时段都要留存，就是个值得商榷的事情。
