当大多数运营商还在"AI 修一个工单"的阶段反复试验时，加拿大最大的通信公司贝尔（Bell Canada）选择了一条与众不同的路——它没有从单点故障告警入手，而是先用一张"知识图谱"重新理解自己的网络，再让多模态大模型去读懂这张图。结果是：客户报障量直接掉了一块，网络运维从"救火队"变成了"预报员"。
贝尔是加拿大最大的通信公司，1880 年创立于蒙特利尔，提供宽带、无线、电视、媒体和企业通信服务，现归 BCE Inc. 全资持有。这样一个覆盖全国、横跨无线与固网多代技术的"巨无霸"网络，其运维复杂度本身就是最大的敌人。
2025 年 2 月 26 日，贝尔在 MWC 2025 前夕（谷歌云展台 Hall 2，2H40）正式对外宣布：其构建于 Google Cloud 之上的网络 AI Ops（人工智能运维）方案已完成部署并投入实战。贝尔网络高级副总裁 Mark McDonald 在新闻稿中坦言，传统网管方式已经跟不上网络复杂度和流量激增的节奏——遗留系统大多依赖被动响应和人工流程，导致效率低下、服务中断频发、用户体验受损。
核心痛点可以拆成三层：
这三个问题叠加，本质上是同一个：网络早就云化、虚拟化了，但运维还停在"看板 + 工单 + 人脑"的石器时代。贝尔的解法，是用一张图、一个大模型，把三者一次性打通。
贝尔 AI Ops 的技术栈几乎是"谷歌云全家桶"：Google Kubernetes Engine（GKE）做容器化编排，BigQuery 做海量数据仓库，Pub/Sub 做消息流式接入，再叠加贝尔自研的定制 AI/ML 模型。但真正决定这套方案"含金量"的，是两件兵器——Spanner Graph 和 Gemini 多模态大模型。
这是整个方案的灵魂。Spanner Graph 是谷歌云在 Spanner 分布式数据库之上构建的图数据库能力，贝尔用它来动态评估网络拓扑关系与流量变化，从而"完整地理解客户影响（wholly understand the customer impact）"。
通俗讲：传统网管看网络是"一张表"——哪个网元、哪个端口、什么告警。而 Spanner Graph 看网络是"一张网"——节点是网元/端口/链路/小区/客户业务，边是它们之间的依赖、承载、汇聚关系。当某条传输链路中断时，图引擎可以沿着"边"快速向上回溯：这条链路承载了哪些汇聚层、波及哪些基站、最终影响多少在网用户、其中多少是高价值政企客户。
正是这种"图遍历"能力，让贝尔实现了影响感知的智能优先级排序：一个低流量站点的小故障，可能被系统判定为"暂不紧急"；而一个高流量站点哪怕只有轻微抖动，也会被立刻顶到队列最前面。谷歌云电信行业全球负责人 Angelo Libertucci 评价，这是"网络管理方式的一次根本性转变（fundamental shift）"，而非渐进式改良。
如果说 Spanner Graph 负责"算关系"，那 Gemini 多模态大模型就负责"读上下文"。贝尔用 Gemini 实现了三个关键能力：
flowchart TD
A[网络遥测/告警<br/>CE客户体验数据] --> B[Pub/Sub 流式接入]
B --> C[BigQuery 数据湖 + GKE 容器化处理]
C --> D{Spanner Graph<br/>网络关系知识图谱}
D -->|图遍历影响分析| E[影响感知优先级排序]
E --> F[高危故障自动置顶]
D --> G{Gemini 多模态大模型}
G -->|历史案例检索| H1[历史上下文回溯]
G -->|厂商文档检索| H2[排障步骤/配置命令]
G -->|多模态事件分析| H3[事件摘要与研判]
F --> I[自愈/自动化处置]
H1 --> I
H2 --> I
H3 --> I
I --> J[MTTR 下降<br/>客户投诉减少]
I --> K[实时可观测性看板]
K -->|反馈优化模型| C
整个闭环的精髓在于"图算影响 → 模型给方案 → 自动化去执行 → 看板给反馈"。告警不再是孤立的噪点，而是被图谱串成"事件"；事件不再是冰冷的代码，而是被 Gemini 翻译成"人能读、机能办"的排障动作。
贝尔给出的成绩单，是少数能同时拿出"效率、客户、稳定性"三类指标的运营商之一，含金量很高：
| 指标维度 | 传统模式表现 | AI Ops 模式表现 | 提升幅度 / 变化 |
|---|---|---|---|
| 软件交付生产力 | 基线 | — | +75% |
| 客户报障量（customer-reported issues） | 基线 | — | -25% |
| 数据可用性与时效性 SLA 合规率 | — | 99.8% | 持续达标 |
| 平均故障修复时间 MTTR | 较长 | 显著缩短 | 大幅下降（定性） |
| 故障发现方式 | 被动、事后 | 主动、预测 | 范式级转变 |
最值得关注的是"客户报障量下降 25%"。这个数字背后逻辑链很清晰：AI Ops 在客户感知到故障、打电话投诉之前，就已经通过图谱的影响预判和 Gemini 的快速定位，把问题"摁"了下去。换句话说，原本会变成一通投诉电话的隐患，被系统在萌芽阶段消化掉了。对于一个拥有千万级用户基数的大运营商，25% 的投诉降幅意味着客服中心工单洪峰的实质性削减，也直接关联着净推荐值（NPS）与客户留存。
软件交付生产力 +75% 则反映了另一个维度：AI Ops 不只省运维，还反哺了开发流程。借助 GKE 的云原生弹性和谷歌云工具链，贝尔的开发—测试—上线链路被大幅压缩，新功能、新配置更快铺到现网。而 99.8% 的 SLA 合规率说明这套方案本身是稳的——AIOps 不能成为新的故障源。
需要客观指出：贝尔的案例更偏向"AI 增强运维 + 半自动化自愈"，其官方表述强调的是"加速向自治网络（autonomous networks）迈进"，尚未像部分厂商那样宣称"全闭环无人干预"。但 Spanner Graph + Gemini 的组合拳，已经在"理解影响—给出方案—压缩 MTTR—减少投诉"这条主链上跑通了真实价值。
AIOps 在通信行业的落地，远不止贝尔这一条路。把贝尔放回行业坐标系，能更清楚地看到不同技术选型的优劣。这里选取同样有真实部署数据、且与贝尔形成鲜明对照的两家——西班牙电信（Telefónica） 和 意大利电信集团旗下 Sparkle——做横向对比。
2026 年 2 月 18 日，Telefónica 宣布其"自治网络之旅（Autonomous Network Journey, ANJ）"在 2025 年底已累计落地 12 个 Level 4（高度自治）用例，覆盖西班牙、德国（O2）、巴西（Vivo）。其路线与贝尔截然不同：
Telefónica 全球 CTIO Andrea Folgueiras 在 MWC 上阐述了其路线图。与贝尔相比，Telefónica 的特点是范围广、等级高、域全（固定接入/移动接入/传输/IP 核心网/电信云全覆盖），但单点架构的"黑科技"浓度不如贝尔的图谱方案集中。
意大利电信集团旗下的国际批发运营商 Sparkle，2025 年 5 月联合本土集成商 Engineering Group 推出代号 AISNA（AI Sparkle Network Assurance） 的项目，把 AI 注入国际网络的 NOC。它的技术栈是"生成式 AI + 传统 AIOps + 自动化"三件套：IBM watsonx（生成式 AI）+ IBM SevOne/AIOps（性能与故障管理）+ Ansible（配置自动化）。
| 对比维度 | Bell Canada（谷歌云） | Telefónica（TM Forum 分级） | Sparkle/TIM（IBM 系） |
|---|---|---|---|
| 底层云/平台 | Google Cloud（GKE+BigQuery+Pub/Sub） | 多厂商 + TM Forum AN 框架 | IBM watsonx + SevOne |
| 核心智能引擎 | Spanner Graph 知识图谱 + Gemini 多模态 | Fractal AI + 数字孪生 NetOptimizer | watsonx 生成式大模型 |
| 自治成熟度 | 朝 Level 4 演进（半自动自愈） | 12 个用例已达 Level 4 | NOC 流程级自动化 |
| 治理范围 | 全国无线+固网 | 西/德/巴跨多域（接入/传输/核心/云） | 国际传输网 NOC |
| 最亮眼的硬指标 | 客户投诉 -25%、交付 +75% | 多域故障自主检测与解决 | 告警处理 -30%、批量更新 -80% |
| 自愈"含金量" | 影响感知 + 加速修复（强） | 全闭环自主检测与解决（最强） | 告警摘要 + 工单自动更新（中） |
Sparkle 的成绩同样扎实：告警处理时间下降 30%、大规模网络更新活动平均执行时间下降高达 80%、客户报告处理时间每年减少约 3000 小时、停机报告（RFO）时间每年减少约 700 小时。其亮点在于用生成式 AI 处理"邮件内容分析、关键信息摘要、工单自动更新"这类重复性文书工作，把人力从机械劳动中解放出来投入真正的客户服务与问题解决——CIO Lorella Scalcione 与运营负责人 Danilo Decaroli 都强调，这是项目的"首要优先级"。
把三家放在一起，能看清 AIOps 自愈的三种打法：
与传统方案相比，三者共同把网络运维从"被动救火"推向"主动防火"：传统模式下，MTTR 取决于人轮班速度和老师傅经验；AI Ops 模式下，影响预判、根因关联、处置建议、文档检索在秒级完成，人只做"最终决策与高危动作确认"。这正是贝尔 Mark McDonald 所说的——"用 AI 实现更高的准确率与速度，加速迈向自治网络"。
第一，知识图谱是被低估的 AIOps 地基。国内运营商核心网云化、网元数量动辄十万级，纯靠大模型"读告警"容易幻觉、难溯因。贝尔的 Spanner Graph 思路值得借鉴：先用图把网络拓扑与客户业务关系固化下来，大模型在"有图的约束"下做推理，准确率与可解释性都会上一个台阶。中国移动"九天"、中国电信"星辰"等网络大模型，完全可以叠加一层拓扑知识图谱。
第二，多模态不是噱头，是排障刚需。现网排障材料高度异构——拓扑图、抓包、信令 trace、厂商 PDF，纯文本模型处理不了。Gemini 的多模态 + 厂商文档检索，直接命中了"翻手册"这个最耗时环节。国内厂商文档本地化检索（华为、中兴、爱立信中文手册）+ 多模态分析，是可快速复制的提效点。
第三，用"自治等级"做 KPI，比用"准确率"更利于推进。Telefónica 的 TM Forum 分级路线证明，把模糊的"智能化"翻译成 L0–L5 的可考核刻度，能直接进入高管 OKR，推动跨域、跨部门协同。国内三大运营商在自治网络分级标准（如信通院、CCSA 相关工作）上的推进，正是走这条路。
贝尔加拿大用一张 Spanner Graph 和一个 Gemini，把网络投诉砍掉四分之一、把软件交付提速四分之三，更用 99.8% 的 SLA 证明了 AIOps 本身的可靠性。它和 Telefónica 的全域分级自愈、Sparkle 的 NOC 提效，共同勾勒出 2025–2026 通信 AIOps 的三条主流路径。对国内同行而言，重要的不是照搬某一家，而是想清楚：自己的网络，缺的是"一张图"、"一个分级体系"，还是"一个能啃文书的副驾"。答案不同，AIOps 的发力点就截然不同。
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。