在未来网络中实现AI/ML的运营化：系统视角的鸟瞰图|算法|运维

Operationalizing AI/ML in Future Networks:

A Bird’s Eye View from the System Perspective

在未来网络中实现AI/ML的运营化：系统视角的鸟瞰图

https://arxiv.org/pdf/2303.04073

摘要

在过去十年中，以机器学习（ML）为代表的现代人工智能（AI）技术获得了前所未有的发展势头。随着这股“AI夏季”的浪潮，网络研究界也逐步引入AI/ML算法来解决与网络运维相关的问题。然而，与其他领域相比，大多数基于机器学习的解决方案尚未实现大规模部署，主要原因是其在生产环境中的成熟度尚显不足。本文聚焦于在实际网络中开发和运营基于ML的解决方案时所面临的实际问题。具体而言，我们列举了阻碍AI/ML在真实网络中集成的关键因素，并回顾现有解决方案以揭示被忽视的重要考量。此外，我们强调了一个有前景的方向——即机器学习运维（MLOps），它有助于弥合当前差距。我们认为本文突出了在实现和维护基于ML的解决方案过程中涉及的系统性考虑，从而推动其在未来网络中的全面采用。

关键词 ：面向网络的AI/ML，网络系统

引言

过去十年见证了现代电信行业在“网络软化”技术（如软件定义网络SDN和网络功能虚拟化NFV）推动下的深刻变革。通过将传统的硬件中心化网络组件转化为基于软件的流程，SDN/NFV带来了前所未有的灵活性、可扩展性和效率 [1]–[3]。尽管如此，随着电信基础设施的迅速扩张，现代网络的规模和动态性持续增长，网络管理仍然是一个艰巨的任务 [4]。

与此同时，人工智能/机器学习取得了显著进展，并在各个商业领域引起了战略性的关注。根据Gartner和MIT Sloan管理学院的报告，AI已带来每年3.9万亿美元的商业价值，并被83%的CEO视为战略优先事项 [5]。受这些成功案例的启发，网络研究人员正广泛探索AI/ML在各类任务中的应用 [2],[6]。这些基于机器学习的解决方案（包括应用程序、功能和服务）在许多方面展现出优于传统固定策略方法的潜力 [4]。

尽管兴趣浓厚，但现代网络的快速发展使得构建和管理用于AI部署的大规模网络数据变得几乎不可能，而这类数据是AI在真实系统中成功落地的关键。根据最近一份报告 [7]，88%的电信行业中AI/ML概念验证项目未能进入实际部署阶段。主要原因在于缺乏足够的“系统思维” [8]。

根据我们的观察，现有的基于AI/ML的解决方案与真实网络部署之间存在两个根本性差异：(i) 单维度设计 ：机器学习解决方案主要目标是在特定性能指标（尤其是准确率）上超越先前方法，而往往忽略其他网络/系统关键需求。例如，随着网络操作日益复杂且相互关联，优化问题变得更加多指标、多维度 [9]；(ii) 系统差异性 ：这些解决方案大多在受控环境中进行演示，在面对真实网络中更高的规模、复杂性和动态性时，难以低成本地适配。例如，鉴于基于ML的解决方案依赖数据驱动特性，在数据稀疏或环境漂移的情况下保障性能表现是一项重大挑战 [10]。这种“现实差距”严重阻碍了AI/ML在真实网络中的整合与部署。

为了使AI/ML真正成为现代网络不可或缺的一部分，需要轻量级的技术手段，能够及时识别并触发模型更新，确保部署的模型无论环境如何演变始终适用于其任务。基于上述前提，本文旨在阐明将AI/ML融入未来网络生态所面临的实际挑战。具体来说，我们首先介绍面向网络的AI/ML研究现状及其与真实网络之间的差距。随后，我们列举在生产级网络中实现AI/ML所需的实际考量。接着，我们展望一个具有前景的方向——MLOps，该方向借鉴敏捷开发理念，融合软件开发（Dev）与IT运维（Ops），旨在缩短系统开发周期，实现高质量的持续交付 [11]。最后，我们介绍了两个在网络软化背景下的示例用例：持续性能预测与异常检测，并展示了其中一些前述技术的应用实例。

在网络中落地AI

在本节中，我们简要回顾AI/ML的当前状态，并详细阐述阻碍其在网络运营中广泛采用的实际障碍。

当前状态

近年来，AI/ML在运营网络中引发了极大的关注，这得益于以下几点：(i) 理论研究中的创新性突破；(ii) 在计算机视觉和自然语言处理（NLP）等其他领域的成功应用；以及 (iii) 具备硬件加速支持的优化开发工具包的出现。与传统的固定策略方法相比，AI/ML算法在大规模、多维数据上展现出卓越的模式匹配、增量学习和自动化能力 [6]。

标准化组织（如 ETSI、3GPP）预计 AI/ML 技术将在未来网络的自动化中发挥关键作用。2024 年 2 月，ETSI 发布了一项标准（ETSI TR104032 [12]），强调了在整个 AI 模型生命周期中通过模型追踪记录（如 MLOps 框架）记录关键细节的必要性。此外，3GPP 的一项标准（Rel-17 [13]）也强调了管理工具和服务在推动 AI/ML 技术融入 5G 网络方面的重要性。

在工业界，运营商级平台正在积极开发中，以增强 AI/ML 赋能的网络服务：诺基亚的 AVA 生态系统为电信运营商提供云原生的 AI/ML 和分析服务，旨在实现网络运维自动化、提升服务保障和用户使用体验并降低成本 [7]；华为的 ADN 生态系统则通过专门支持 AI 运维的功能实现网络自动化 [4]，其架构分为三个层级，即设备端 AI、在线边缘/云 AI 和离线云 AI，从而支持具备不同时空特性的网络与 AI 运维操作。在学术界，研究人员广泛开发了各类机器学习算法，用于解决范围广泛的“网络”问题，例如流量分类 [10]、资源调度 [6]、异常检测 [1]、负载均衡 [2]、用户体验质量（QoE）管理 [14] 等。随着 AI/ML 领域（例如生成式 AI）的快速拓展，其在电信网络中的应用将持续丰富。

然而，在概念验证与 AI/ML 项目的成功实时部署之间仍存在一定距离。我们将在以下章节中详细讨论这些具体困难。

挑战与障碍

术语“ML系统”（机器学习系统）常常与它所采用的算法联系在一起，例如逻辑回归或各种神经网络。然而，在实际生产环境中，这些算法仅代表完整ML系统的一小部分。如图1所示，现实世界中的ML系统涵盖了最初业务目标、接口设计、整个数据堆栈，以及模型开发、监控和更新的方法论。

生产环境中的机器学习并不等同于研究环境中的机器学习，因为后者通常在测试数据集上达成优化目标后，很少考虑部署与维护问题 [4]。根据我们的研究，将AI落地到网络中面临的主要挑战可总结如下：

数据复杂性：网络数据具有更加多样的格式，例如原始数据包、流级统计信息、配置文件、系统日志和事件告警。这些数据可能包含类别型、时间序列型、空间型，甚至是图结构语义信息。这种高多样性、高速度和大体量的多模态数据在建模和处理上极具挑战性 [14]，更不用说由于数据和系统演进所带来的自然分布漂移问题。

多维需求特性：研究人员往往聚焦于单一目标，最常见的目标是模型性能——即开发出在基准数据集上表现优异的模型。但在实际网络中，关键性能指标（KPI）的优化不能孤立进行。例如，一些预测准确率很高的深度神经网络（DNN）模型，却难以适配资源受限的网络设备 [3]。此外，较高的推理延迟可能使模型无法满足实时性要求，尤其是在服务延迟以微秒为单位衡量的高速网络中 [14]。

本质上，ML系统中的学习复杂度与运行时复杂度都应同等重视：前者涉及训练模型所需的计算与资源成本，而后者则指部署和管理已训练模型的成本。

隐藏的技术债务：这一术语由Sculley等人提出 [8]，指的是非专家在实际部署基于ML的系统时所承担的大量运营成本。在网络系统中也存在类似的问题。由于现有解决方案大多是在模拟或受控环境中开发的，实际部署与维护问题通常被忽视。

而在真实系统中，ML模型必须作为数据处理流水线的一部分进行部署。由于开发工具包和部署目标各异，将其集成到真实网络中可能会既繁琐又容易出错。此外，网络设备可能来自不同厂商，具有定制化的配置、优化和执行流程，因此在其上部署AI/ML可能导致复杂的手动调优、定制化和可行性测试。

更重要的是，ML-based 解决方案并不是一次性完成的过程，它们需要不断升级，以满足业务需求，并在电信行业快速演进的过程中持续创造长期价值。

在生产网络中实现AI/ML的运营化：现状

为了弥合现实差距，实现AI/ML在生产环境中的无缝落地，在整个机器学习生命周期 （包括数据准备、开发和运维阶段）中存在许多关键的系统相关考量，如图2所示。本节总结了这些考量，并探讨了在网络领域中相关的研究工作。所选文献基于两个标准：(i) 涉及一个或多个实际问题；(ii) 提出的方法已在真实网络系统中进行了实现和验证。

数据准备数据质量直接决定了任何基于AI/ML的产品所能达到的上限，这也推动了近年来“以数据为中心的AI”（data-centric AI）的发展趋势 [5]。由于真实网络中的复杂性，高质量的数据集并不总是可用的。确保数据质量通常会占据AI/ML项目平均60%的时间 [7]。

因此，在数据准备过程中需要特别关注以下环节，以向机器学习算法提供高质量的数据支持：数据采集与特征提取 。

数据采集由于监督学习是最常用的一类算法，获取标签是构建训练数据的关键 [9]。现有解决方案中，数据一般来源于三个渠道：(i) 实际运行的网络；(ii) 受控环境；或 (iii) （整理后的）公开数据/数据集。

在情况(i)中，尽管有多种数据采集方法，但该过程可能带来巨大的运维成本，因此必须进行权衡 [2]。例如，在高速网络中，为了减少对数据路径的影响，通常优先采用采样方式而非逐包采集。此外，数据采集还可能引发不可控的情况，如丢包、采样偏差或模式变更，从而导致异常值和离群点的出现。

数据标注仍然是一项劳动密集型任务，因为它需要大量的人工参与，且难以随着数据量的增长而扩展 [10]。尽管已有先进技术（如弱监督、半监督学习、迁移学习和主动学习）用于缓解数据稀缺问题，但这些方法仍依赖于预标注数据集或人工输入，限制了其在处理大规模、复杂数据集时的可扩展性和有效性。

在情况(ii)和(iii)中，由于数据来自目标网络之外，其统计特性可能与部署假设不一致，进而导致意想不到的后果，例如数据漂移。因此，在模型部署之前，有必要通过测试来揭示潜在的偏差或异常。

特征提取 原始网络数据必须被转换为符合后续AI/ML算法要求的特征表示。**特征提取是一项具有挑战性的任务**——不同的特征集意味着不同的系统开销（以及模型性能），因此值得深入研究。

现有的许多基于机器学习的解决方案往往经验性地定义自定义特征，这些特征在实际部署中可能难以获取和扩展。此外，在网络演进过程中，所采用的特征选择方案也可能需要重新设计和调整。

如文献 [15] 中所述，真实系统中的流量模式和网络状况始终处于变化之中，这使得现有特征逐渐失效，从而需要不断进行新的特征工程。

现有解决方案：

在当前的网络研究中，已有几项开创性工作针对数据采集与特征提取的实际挑战提出了应对方案：

Bronzino等人 [14] 提出了 Traffic Refinery，这是一个高效的自动化流水线，用于流级别数据的采集与特征提取。该方案通过整合多种设计选择，以缓解丢包问题，从而更好地契合网络运营商的目标。此外，一个专用的性能分析器可以量化系统级成本，帮助运营商在特征选择与模型准确性之间做出权衡。
在另一项独立研究中，Yao等人 [2] 提出了 Aquarius 框架，旨在为数据中心网络提供灵活的数据采集与特征提取机制。该系统嵌入了一个传输层采集器，用于高效提取TCP流量特征，并将其存储在共享内存中，从而在不干扰数据平面的前提下，实现控制平面上ML算法的无缝交互。
最后，Holland等人 [15] 提出了 nPrint 框架，它将数据包转换为一种一致的二进制格式，同时保留其上下文语义信息。这种机制使机器学习算法能够自动识别关键特征，避免了人工特征提取的繁琐过程。

开发模型开发是一个迭代过程。在每一次迭代中，重要的是评估当前模型相较于以往版本的表现，并判断其是否具备部署到实际网络中的准备条件 [9]。

模型开发包含两个基本步骤：(i) 算法设计，以及 (ii) 模型训练与验证，这两个环节对于确定解决方案是否具备面向目标网络的就绪性至关重要。

算法设计

机器学习的目的可以分为三个方面：

1. 有效利用已有知识；

2. 对未知现象形成结构化理解；

3. 通过学习达成特定目标；

这三个目的分别对应机器学习的三大分支：监督学习（Supervised Learning）、无监督学习（Unsupervised Learning）和强化学习（Reinforcement Learning, RL），它们之间也可能存在交叉（例如半监督学习或自监督学习）。

监督学习（Supervised ML）技术，如回归和分类，在开环环境中擅长处理定义明确的问题，有助于提升对网络流量的可见性或从原始数据中提炼洞见。
回归技术适用于预测任务（如流量需求或用户行为），或学习复杂关系，例如将网络服务质量（QoS）指标与用户体验质量（QoE）联系起来。
分类技术是另一个AI技术发挥作用的典型场景：例如，流量优先级划分可能需要粗粒度的流量类别标签用于策略控制，有时还需要细粒度的应用标签。
无监督学习（Unsupervised ML）则通过识别数据中的模式和结构来进行操作，而无需标注数据，依赖于算法自身发现数据集中的内在特征与关系。
例如，在异常检测中，无监督AI使用算法自主学习底层分布，识别数据偏离。这些算法能够识别出显著偏离已知模式的离群值，而无需依赖预标注的正常数据样本。
强化学习（RL）更适合持续且高效的闭环自动化环境。
一个例子是使用RL实现资源管理的自动化，可以通过集中式的云代理或分布式设备代理来实现 [4]。
在此背景下，AI代理致力于改善服务质量（QoS），例如提高传输效率、降低延迟。为了实现这一目标，代理会根据其行为获得奖励，从而在庞大的状态空间中有效平衡“探索”与“利用”，提供自动化的优化方案 [15]。

模型训练与验证

在模型训练与验证的系统语境中，一些因素——如推理效率、泛化能力与安全性——与传统的准确性关注具有同等重要性：

- 泛化能力确保模型能在动态环境中及时适应，如抗灾网络；

- 安全性对于需频繁与真实系统交互的ML算法尤为关键；

- 推理效率则对快速决策至关重要。

模型训练与验证的过程可以借助诸如 MLflow、Weights & Biases 和 DVC 等工具加以增强。这些工具支持机器学习算法的选择和超参数调整，推动模型的自动化与高效优化。

现有解决方案：

以下两项前期工作探讨了如何利用AutoML（自动化机器学习）来自动完成模型选择与超参数调优，从而向网络运营人员隐藏AI/ML相关的复杂性：

- Holland等人 [15] 利用 AutoGluon-Tabular 框架，基于给定的特征与标签，自动寻找并集成具有高预测准确率和低推理延迟的模型。

- Swamy等人 [1] 使用一种优化框架，将算法选择与模型生成建模为一个基于用户意图和网络约束的贝叶斯优化问题，从而实现自动执行。

- Lacoboaiea等人 [6] 针对构建基于深度强化学习的信道管理器所面临的挑战展开研究，重点关注训练的安全性、效率、环境真实性与泛化能力。他们采用数字孪生（digital twins）实现安全训练，调整学习率以提升效率，结合真实数据增强模拟器的真实性，并通过合成噪声与真实数据融合增强模型泛化能力。

运维（Operations）

本部分详细阐述基于AI/ML的解决方案在真实网络中的部署与管理过程中需要关注的问题。

部署实际部署涵盖模型的打包、定制化和可行性测试。由于传统的基于机器学习的解决方案主要面向控制平面，这类模型通常可以由标准的模型服务工具处理。

近年来，随着“网络内机器学习”（in-network ML）的兴起，研究人员开始将机器学习的前沿推进到网络数据平面，以利用其中海量的数据 [3]。然而，由于本地实现环境与网络基础设施之间的差异，以及工具链的不统一，模型部署变成了一项西西弗斯式的任务（Sisyphean task），严重阻碍了定制化进程。

此外，网络中充斥着各种架构不同、配置流程各异、资源占用不同的专用硬件设备（例如 SmartNICs、P4 交换机、嵌入式设备），这使得部署过程需要将解决方案重构为一个通用的数据处理流水线，同时对网络服务造成最小干扰 [1]。

管理除了部署之外，对已部署的基于ML的解决方案的管理还涉及模型服务、资源与运维管理、以及漂移监测等任务。

特别地，由于网络系统可能快速演进，内在的概念漂移或数据漂移可能导致模型性能下降和服务质量退化。因此，应持续检查推理结果的质量，以检测性能下降，并在适当时触发模型重建流程。

在实际网络中，正确的质量评估指标和触发机制应被仔细界定，同时还要在监控开销与质量评估准确性之间取得平衡 [10]。

根据具体问题背景，模型重建流程可以从数据准备与标注阶段，或者模型开发阶段重新开始，这些流程必须事先明确指定。

现有解决方案

为应对上述挑战：

- Zheng等人 [3] 提出了 Planter，这是一个模块化架构，支持多种网络内机器学习算法在三大主流硬件平台上的无缝部署。

Planter 支持大量主流机器学习算法。其在训练后自动将模型转换为目标平台定制化的 P4 代码，随后进行编译和集成以完成部署。

- Swamy等人 [1] 设计了一套编译器工具，可自动为流行的数据平面生成目标导向的代码。

他们利用一个周期精确模拟器，提前评估模型的关键性能指标（如吞吐量、延迟和资源利用率）。

- Yang等人 [10] 应对推理监控问题，结合基于梯度的技术与开放集识别（Open Set Recognition）及可解释AI（Explainable AI），深入分析推理质量。

他们进行了对比评估，以验证其方法在推理监控和数据漂移检测方面的有效性。

我们对所有这些开创性工作进行了总结，如表I所示，涵盖了其所针对的机器学习生命周期阶段、支持的机器学习算法类型、目标网络环境以及应用场景。

本质上，每一项工作都覆盖了机器学习生命周期中的部分阶段。

拼图中缺失的部分

基于上述综述，我们识别出实现AI/ML全面落地所缺失的三个关键部分。

首先，尽管在各个领域取得了积极进展，但这些进展尚未被整合转化为整体优势。在真实系统中，各个环节必须无缝衔接，形成一个端到端的数据处理流水线。然而，目前高度依赖人工干预的情况下，基于机器学习的解决方案在未来网络中的管理将变得愈发复杂和沉重。

其次，由于缺乏系统的日志记录与追踪机制，可复现性 （reproducibility）无法得到保障。传统的版本控制工具不足以完整捕捉机器学习工作流中的数据集、参数以及配置依赖关系。为了确保科学研究的严谨性和监管合规性，这些内容必须能够始终如一地被复现。

第三，由于数据科学家与网络工程师在专业知识和优先事项上的差异，容易形成“信息孤岛 ”（silos），这会阻碍工作效率，并延迟价值实现的时间（time-to-value）。

图3展示了两种机器学习生命周期管理的方法。

传统的工作流程是一个一次性过程，包括数据采集、模型开发和部署，侧重于首次快速交付 。然而，随着时间维度的延伸，这种方法效率逐渐下降。特别是当数据或系统发生变更时，模型需要持续重新训练。如果没有适当的管理机制，随着整个流程涉及从数据科学家到网络工程师等多个团队，现有模型的复现和改进将变得十分困难。人工资产的交接效率低下且负担沉重。

相反，第二种方法采用了更加系统化的策略。最初，相关团队会投入大量时间构建具备完善追踪机制的自动化流水线。与人工方式相比，这种方法带来了显著的长期收益，包括良好的可复现性、模型的持续优化能力，以及各环节之间的无缝沟通。

持续学习（Continual Learning）

持续学习使AI/ML从业者能够高效地更新和部署模型。它能够应对数据分布漂移、基于罕见事件调整模型，并解决因未知数据带来的冷启动问题 [9]。

在网络系统中，我们列举了向持续学习演进的以下阶段：

阶段 1 - 手动、无状态再训练： 最初，研究人员手动重新训练模型，不利用历史数据状态，这种情况常见于没有专门团队来管理机器学习平台的环境中。

阶段 2 - 自动化再训练： 研究人员开始实现模型再训练的自动化。再训练频率通常依赖经验判断，例如每日更新，这种做法缺乏坚实的实证基础，但旨在优化性能。

阶段 3 - 自动化、有状态训练： 为了提高效率，研究人员开始探索最近保存的模型状态和检查点，这对于需要频繁更新模型的应用场景尤为有益。

阶段 4 - 面向网络管理的持续学习： 最先进的阶段是从固定时间表更新过渡到基于触发机制的动态模型更新，其触发条件可以是时间间隔、性能指标、网络流量或通信模式等，从而实现更灵敏和自适应的网络管理。

在现代网络中应用持续学习面临重大挑战。幸运的是，MLOps 提供了缓解这些问题的方法，详见下一节。

MLOps：迈向端到端流水线

MLOps 是一套新兴实践，它将 DevOps 原则应用于基于机器学习系统的开发与运维的统一 [5], [9]。

为何需要 MLOps？

传统上，DevOps 能有效应对软件产品交付的运维成本。它是一套原则的集合，旨在打破软件开发人员与 IT 运维工程师之间的壁垒，推动在整个产品生命周期中实现自动化、持续集成（CI）与持续部署（CD）。这些原则有助于众多企业和组织实现IT目标与业务成果 [10]。网络行业也已采用 DevOps 来推动技术创新和收入增长。

然而，尽管 DevOps 能够降低传统软件项目落地的运维开销，但它在支持机器学习（ML）所具有的独特特性方面仍显不足。

传统软件与 ML 之间存在五个根本性差异：

1. 性能决定因素不同：

在传统软件中，代码质量主要决定了系统表现；而在 AI/ML 中，模型与数据共同影响最终结果 [5]。

2. 工具链复杂度不同：

传统软件通常建立在功能完善的库之上，具有清晰的抽象边界 [8]；而基于 ML 的解决方案往往涉及更广泛的工具和库，带来了额外的集成与维护成本。

3. 行为确定性不同：

传统软件输出是确定性的，而 ML 模型本质上具有随机性，因此需要不同的流程来验证其行为表现。

4. 环境适应性要求不同：

ML 模型容易受到数据漂移与概念漂移的影响，这在网络环境中尤为常见，因此需要具备漂移检测机制以及模型重建能力 [10]。

5. 所需技能集不同：

构建和运营基于 ML 的解决方案需要数据科学相关的技能，而这在传统的软件或网络运维流程中通常是缺失的。

根据最近的一项调查，55% 的电信运营商缺乏相关的数据科学人才 [7]。

在 DevOps 原则的基础上，MLOps 通过以下实践来适应 AI/ML 的独特特性：

持续监控（Continual Monitoring, CM） / 持续训练（Continual Training, CT） ：
MLOps 通过持续监测数据和推理质量，在适当时机重建模型，从而解决模型性能退化的问题。
自动化（Automation） ：
MLOps 将 AI/ML 生命周期整合为一个完全自动化的流水线，以降低运维成本。
版本控制（Versioning） ：
在 DevOps 的基础上，MLOps 扩展了对整个流程中各类产物（包括数据、模型和代码）的版本控制。
实验追踪（Experiment Tracking） ：
对实验过程进行系统化追踪，以确保结果的可复现性与可审计性。
协作机制（Collaboration） ：
MLOps 提倡建立一个统一平台，促进各参与方之间的协同合作，形成合力。