发布于: Oct 14, 2022
如何构造自己的机器学习训练模型呢？今天我们就以 Infoblox 公司与 Amazon SageMaker 的合作为例，为您讲解模型训练的全过程。
为了构建分类器，Infoblox 编写了一部分代码，以类似于 MNIST 的格式构造训练数据。MNIST（美国国家标准技术研究院）发布了一套大型手写数字图像数据库，目前这套数据库已经成为深度学习/计算机视觉从业者群体中“Hello World”般的存在。其中每张图像尺寸为 28 x 28 像素，Infoblox 的代码使用以下素材为每个字符创建对应变体：
- 视觉上容易混淆的各字符的 Unicode 标准列表（最新版本为 13.0.0）及其安全考量因素，用于帮助开发人员避免视觉欺诈攻击并采取适当的应对举措。
- 包含变音标记块中各常见组合字符的 Unicode 标准块。例如，在以下来自维基百科组合变音符词条的图表当中，我们可以看到 U+300 块与 U+300x 行交汇于列 0 处；U+300 似乎代表重音，因为我们能够在法语中看到“è”字符。其中部分组合变音符号不太显眼（例如 U+0363），因此适合被整理起来用于构建训练数据集。关于更多详细信息，请参阅 Unicode 网站上的组合变音符部分。
- 多种字体。攻击者可以通过恶意渲染从根本上改变字符的开关。例如，Infoblox 就使用到本地系统中的多种字体，同时也可以添加第三方字体（例如 Google Fonts）等本应被排除的脚本字体。在此用例中，使用不同字体为各个字符生成多种变体，属于一种强大的图像增强技术。在这一阶段中，Infoblox 选择了65 种字体以生成训练数据集。这一字体数量足以建构建起一致性训练集，由此带来不错的预测准确率。使用更少的字体将无法为各个字符创建充足的表示形式，而字体超过 65 种之后则很难进一步提升模型的准确率。
未来，Infoblox 还计划使用其他数据增强技术（例如翻译、缩放与剪切等操作）进一步提高 ML 模型的健壮性。实际上，每款深度学习框架的 SDK 都提供有丰富的数据增强功能，用户可以根据需求将其湢至数据准备管道当中。
在训练数据集准备就绪之后，Amazon SageMaker 立即跟上，提供一套几乎无需任何学习曲线即可快速上手的模型训练流程。以此为基础，Infoblox 采用以下 CNN 架构构建分类器方案。
这套 CNN 神经网络围绕两个连续的 CONV-POOL 单元构建而成。卷积部分将自动从输入的图像中提取特征，分类部分则使用这些特征将输入图像映射（分类）至 ASCII 字符。最后一层负责将分类网络的输出结果，转换为输入中各个类（例如 ASCII 字符）的概率向量。
Infoblox 已经着手构建新的 TensorFlow 模型，这套模型能够直接导入 Amazon SageMkaer 之内。以此为基础，他们使用多项 Amazon SageMaker 功能以加速并推进模型的开发工作：
- 支持使用 CPU 及 GPU 实例进行分布式训练 – Infoblox 主要使用 ml.c4.xlarge（计算）与 ml.p2.xlarge（GPU）实例。尽管每轮训练周期并不太长（大约 20 分钟），但考虑到可观的参数数量及其细粒度搜索空间，每项超参数调整工作仍然有可能耗费 7 个小时以上。更重要的是，Infoblox 需要在后台的众多实例之上分配工作负载，同时摆脱一切由基础设施管理带来的额外负担。
- 直接在 notebook 环境中训练、部署并测试模型的预测能力 – 就在用于数据整理与准备的同一套环境当中，Infoblox 使用 Amazon SageMaker 以透明方式启动并管理训练集群与推理端点。这些基础设施独立于 Amazon SageMaker notebook 实例之外，并由 SageMaker 服务全权管理。
借助丰富的现有文档与大量示例 notebook，Infoblox 得以轻松使用 Amazon Web Services 发布在 GitHub repo 上以及 Amazon SageMaker notebook 环境中的现成素材，极大降低了机器学习技术的实现难度。
在初始阶段，Infoblox 使用几行代码在 Amazon SageMaker 中对 TensorFlow 训练脚本进行本地测试。以本地模式进行训练具有以下几项优势：
- Infoblox 可以轻松监控各项指标（例如 GPU 资源消耗量），并保证编写的代码能够在训练过程中充分发挥硬件性能优势。
- 在调试过程中，应考虑对训练脚本及推理脚本进行即时更改，提升代码迭代的易行性。
- 无需等待 Amazon SageMaker 置备训练集群，脚本可以立即开始运行。
在 Amazon SageMaker 当中以本地模式工作将带来巨大的灵活性优势，这也是将现有工作负载迁移至云端的关键所在。您还可以在本地实例上部署 Amazon SageMaker TensorFlow 服务容器，在本地对推理代码进行原型设计。如果大家对模型及训练效果感到满意，只需更改几行代码，即可切换至分布式训练与推理模式，由此创建出新的估计器、优化模型甚至将训练好的模型部署至持久端点当中。
使用本地模式完成数据准备与训练过程之后，Infoblox 开始在云端进行模型调优。这部分工作先从一组粗略的参数开始，并通过多个调整工作逐步实现参数完善。在此期间，Infoblox 使用 Amazon SageMaker 超参数调优帮助他们选择最佳超参数值。以下几项超参数值，似乎对模型性能具有最大影响：
- 学习率
- 丢弃(Dropout)率（正则化）
- 卷积层的内核各维度
在优化模型并达到所需的准确率与F1性能得分之后，Infoblox 团队将模型正式部署至 Amazon SageMaker 端点。为了增强安全性，Amazon SageMaker 端点被部署在隔离的专用实例当中，因此需要另行置备并等待几分钟后方可执行新的预测。
要获得良好的准确率，我们自然需要对训练、验证及测试数据集进行甄选或清洗。例如，为了选择并覆盖训练集中的 65 种字体，Infoblox 团队需要输出其工作站上的全部可用字体，并手动检查以选择相关度最高的字体。
Infoblox 使用准确率与F1得分作为评估 CNN 分类器性能的主要指标。
准确率，代表的是模型在正确识别同形异义词方面的得分。其基本定义，是在模型生成的预测总数中，找到预测正确的数量与比例。Infoblox 得出的准确率高于 96.9%（换言之，在该模型做出的 1000 项预测中，至少有 969 项实现了对同形异义词的正确分类）。
此外，分类问题中的精度与召回率也是两项重要的评估指标。
精度，是指正确识别与正确识别加错误识别加和之间的比值：
召回率，则是指正确识别与正确识别加错误忽略加和之间的比值：
Infoblox 使用 F1 得分作为组合指标，其中对精度及召回率进行了谐波平均值计算。如此一来，模型将在这两项指标之间取得良好的平衡。
从业务影响的角度来看，降低错误忽略的重要性往往高于错误识别。错误忽略也可称为漏检，即模型未能正确识别出属于异常状况的因素，大家可以使用分类器缓解这类问题。在另一方面，错误识别也会给最终用户带来负面影响，例如根据检测器中的错误结果在 DNS 解析配置内意外阻止了本应正常执行的响应策略。
下图所示，为在线检测模型的基本架构。
这套在线模型使用以下 Amazon Web Services 组件：
- Amazon Simple Storage Service (Amazon S3)，用于存储训练与测试数据集（1）、Unicode 字形（1）、Passive DNS 数据集、历史数据以及模型（3）。
- Amazon SageMaker，用于训练 CNN 模型（2），并使用同形异义词分类器（4）进行离线推理。输出结果为 ASCII 到 Unicode 的映射（5）。
- Amazon Data Pipeline，运行批量检测管道（6）并管理 Amazon EMR 集群（创建集群，分步提交不同的处理请求，直到集群关闭）。
- Amazon EMR，负责为批处理与流式管道运行 ETL 作业。
-
- 批处理管道从 Amazon S3 中读取输入数据（加载目标列表并读取 Passive DNS 数据（7））、应用 ETL 操作（8），并将结果提供给在线检测系统（10）。
- 示例中使用的在线检测系统为流式管道，虽然与批处理管道采用相同的转换方式（10），但会通过订阅 Apache Kafka 代理（11）以获取额外数据。
- Amazon DynamoDB (一款 NoSQL 数据库)，用于保存来自检测算法（在线系统）的详细检测数据（12）。其以高强度写入访问为主（大型数据集，读取频率较低）。
- Amazon RDS for PostgreSQL，用于存储检测结果的子集，同时随附关于结果的简短说明（13）。Infoblox 在实际应用中发现，Amazon RDS 非常适合存储一部分需要在用例中进行高频读取访问的结果，能够在提升性能表现的同时有效控制成本。
- Amazon Lambda 函数，用于编排及连接架构中的不同组件。
这套整体架构还符合其他 Amazon Web Services 服务的相关最佳实践，包括 Amazon Virtual Private Cloud (Amazon VPC), Elastic Load Balancing 以及 Amazon Elastic Block Store (Amazon EBS)。
Infoblox 团队使用 Amazon SageMaker 训练出一套深度 CNN 模型。此模型能够识别出与 DNS 域名中 ASCII 字符在外观上高度相似的 Unicode 字符。以此为基础，该模型还使用 Unicode 标准识别这些同形异义字符，验证准确率为 0.969，测试 F1 得分为 0.969。接下来，他们又编写一款检测器，使用此模型对 Passive DNS 流量上的 IDN 同形异义词进行检测，整个流程无需进行任何在线图像数字化或预测操作。截至本文撰稿时，这款检测器已经识别出超过 6000 万条同形异义词域名，其中相当一部分与知名在线品牌相关。在检测涵盖的 6 万种不同品牌中，模型发现了 50 多万种独特的同形异义词，并确定针对 100 个行业的实际攻击活动，其中大多数（约49%）指向金融服务领域。
结合实际情况可以看到，IDN 在不经意间给攻击者留下了巨大的可利用空间，且同形异义字的使用范围远超品牌所有方的基本预期。各类组织机构应考虑针对同形异义词进行 DNS 活动监控，单纯依靠预先注册同形异义词域名显然无法达成良好的品牌保护效果。
以下截图展示了同形异义字域名里，网页内容与他们试图模拟的域名对比。左侧为同形异义域的内容，在右侧显示真实域名的内容。
Amazon: xn--amzon-hra.de => amäzon.de vs. amazon.de。请注意同形异义词域名页面上的空白区域。
Google: xn--goog-8va3s.com => googļę.com vs. google.com。同形异义域名的页面上存在一个顶部菜单栏。
Facebook: xn--faebook-35a.com => faċebook.com vs. facebook.com。除非一一对比查看，否则很难发现二者之间的区别。
相关文章