构建闭环全栈认知 IoT 应用程序时吸取的经验教训-3

look_w

利用 Db2 Warehouse on Cloud 和                Looker 来加强学习令人欣慰的是，IBM 非关系型 JSON 存储库 () 提供了自动复制到 IBM 关系型数据库服务 () 的功能，该服务支持使用现成的分析软件包通过行业标准 SQL                进行数据发现和报告。另外，Looker 还支持对复杂数据进行查询和分析，以便用于展示和分享。（IBM 与 Looker 为技术合作伙伴。）
为实现参数化输入和可使用的输出，最好选择标准方法，尤其是在具有可提供这些功能的工具的情况下。像 SQL                这样的通用查询语言正是输入规范的不二选择。不仅如此，表格形式的输出（如逗号分隔值文件，此类文件始终是首选）或结构化形式（如                JSON，此形式逐渐受人青睐）的输出几乎可供其他任何组件使用。
虽然在源存储库中维护 SQL 查询是管理输入规范时的一种选择，但此流程还需要额外执行编码才能实现自动化。幸好 Looker                提供了一种方法，既可以存储和执行 SQL，又可以为 Db2 Warehouse on Cloud 生成 SQL。此外，SQL                模板（称为“外观”）可作为 URL 进行保存、分享和供外部使用，包括 JSON 和 CSV 文件格式的输出。
通过一天的训练，再加上常驻 Looker 的 Db2 Warehouse on Cloud                    专家给予的一些帮助，随时间推移所检测到实体的分布情况清晰可见（请参阅图 10）。通过用户界面快速消除漏报显示了预期的活动分布，但个别特定时间段不足以充分检测到某个人。
图 10. Looker.com 图表选定的 Watson Visual Recognition                    结果
显而易见，来自视觉识别算法的信号数据中包含了过多的无关信息（即，我没有兴趣了解的实体或者几乎始终存在的实体）。此外，误报和漏报对日常活动的计算产生了不利影响                — 要么是未能看到厨房里有人（漏报，很大程度上依赖于数据），要么就是根本无人却显示有人（误报）。
此应用程序需要减少信号中的噪音，才能提供高质量的通知服务。要判定哪些是噪音，哪些是有用信号，就需要具备某种类型的智库来加以鉴别。在许多方面，这就像是一台收音机同时播放它可在整个频谱中接收到的所有电台一样。无线电操作员（智库）需要对此应用程序进行“调频”，因此有机会按个人喜好对产生的“电台”进行“命名”，                或者调到新电台。
接下来就该采取下一步行动，了解如何利用厨房中所选地点的摄像头的示例对 Watson Visual Recognition 服务进行训练。
2

环境定义成功

着手训练 Watson 带来了大量问题，但最重要的问题促使我们获得了第二个经验教训：环境定义成功。第二个经验教训从一个简单的前提开始，即训练                Watson 需要定义作为家中活动指标的“事物”。例如，住在家里的人和动物。最初的这组                { People, Animals } 定义了 Watson 的学习环境，换言之，可训练 Watson                识别图像中的哪些对象。
Watson                通过使用默认分类模型可以看到许多事物。为了解人类活动，需要对默认事物集合加以精简，表明我着力分析的行为类型，例如，某个人首次进入厨房。若要将摄像头的数字信号转化为表示厨房中人类活动的事件，就需要预先指定某些参数。某些参数表示操作能力，例如，检测到运动和捕获图像之间的时间量。另一些参数则限制了传感器的灵敏度，例如，图像捕获之间的时间间隔。最后一点同样也是最重要的，某些参数定义了与可用图像分类相关的环境（即，Watson                能看到什么？）。
环境发现：通过训练来学习要在不具备完整知识的情况下继续前进，就需要确定一系列可用于对 Watson                进行训练的事物，先从一个简单的集合开始：{ person, dog, cat }。为构建 Watson Visual                Recognition 模型，就必须为漏报示例（空无一人的厨房）和误报示例（厨房中 [只有]                    人、狗或猫）收集训练图像。要收集图像并将其组织为训练集合，认知 IoT                系统的用户需要从捕获的图像中选择范例（即，只有人、没有猫也没有狗的图片）, 并跳过包含多个实体的图片或者存在隐私性质的图片。
图 11. 用于收集示例的初始用户界面这个流程的第一步是通过 Raspberry Pi 收集图像。每个设备都有一张 64 GB 的 micro-SD                卡，但在软件更新期间可擦除图像。由于图像可能存在隐私问题，所以为专用 LAN 配置了仅限本地的检索服务                (FTP)，同时收集了图像，并将其存储在本地分层存储库中，此存储库对应于评分最高的分类类型。
最初，针对厨房的类集合被定义为 { person, dog, cat }。但在用户体验测试期间（请参阅通过构建模型提供环境），显然该类集合需要扩展并进行动态定义。通过添加创建功能，我可以将特定家庭成员添加到标记选项，但这也带来了一些混乱。在花费几个夜晚为训练集合标记图像之后，我最终获得了足够数量的图像（约                800 张图像：一个漏报类和七个误报类），从而能够开始构建定制分类器。（顺便说一句，建议每个类至少有 50 张图像。）
通过构建模型提供环境Watson Visual Recognition 服务要求每个类都有经过压缩的结构化图像有效内容（例如，.zip 文件），每次 API                调用每个类限制为 100 MB，总大小限制为 256                MB。同时还必须遵循其他约束和准则，包括类的命名、整合漏报类，遵循图像处理的数量和质量的最低和最高要求。
既然已了解了 API，并且也确定了限制，我开始通过 Linux                命令行分别执行这些步骤来构建定制分类器。我修改并扩展了分类器，直至生成了合适的输出为止。当一系列步骤成功完成之后，我将它们添加到一个内容不断增加的脚本文件中，并将此文件参数化以自动执行该流程。
每次训练的大小限制 (256 MB) 和每个类的大小限制 (100 MB) 表明需要多次调用训练                API。通过将此流程分为多个不同的阶段（例如，先构建，然后训练对应的测试集合），我在整个流程的某些临时节点处定义了多份快照。
运行的多次训练处理了 50% 的图像，外加一张样本图像，并使用剩余超过 49%                的图像根据已知示例来检验预测结果。通常，来自整个集合的随机选择可用于拆分群体，并采用替代百分比形式                (90/10)；但是，这些方法还尚未实施。
图 12. 用于评估模型质量的混淆矩阵
既然已对一半示例集合完成了训练，就需要对所生成模型的质量进行检验。使用来自已整理集合的剩余示例，重复调用此定制分类器，捕获生成的结果，并将其列在按排名排序的类和评分列表中，评分范围是零                (0) 到一                (1)。如果评分最高的类与经整理的类（例如，“David”）相匹配，那么预测被视为正确。
Age-at-Home                项目的逻辑和分析需要区分人与非人，所有人的并集显然不同于逆反命题。