## 概述
5G核心网故障定位，一直是NOC里最依赖老师傅手感的一环：几GB的PCAP、几百页3GPP规范、一句“昨晚开始掉话”的模糊报障。2024年以来，TeleQnA等电信大模型基准论文与国内外运营商的大模型运维实践，把“AI读信令”从概念推向了准生产。本文回答一个问题：大模型到底能不能接下核心网排障这个活？它接得住哪一段、接不住哪一段，落地要避开哪些坑。
## 目录
- 一、故障定位：MTTR里最难啃的那段
- 二、大模型凭什么读懂信令：一笔技术账
- 三、运营商与设备商的真实动作
- 四、一条PDU会话失败工单的AI排障沙盘
- 五、落地暗礁：幻觉、合规与上下文
- 六、经验教训与下一步
## 一、故障定位：MTTR里最难啃的那段
干过NOC的人都知道，一次故障的生命周期大致分三段：**发现、定位、恢复**。发现靠告警系统，恢复靠预案和手速，唯独定位——从“网络不好”到“根因是某网元某接口某参数”——是一段没有自动化兜底的路。
业内流传已久的经验分割是：定位环节平均吃掉MTTR的一半以上。这个数字没有权威统计口径，你在任何厂商PPT里看到的百分比都该打折扣看，但它和一线体感高度一致：告警刷屏只要几秒，倒换恢复只要几分钟，可为了找到“动手的地方”，三个工程师可能对着一台AMF的日志翻两个小时。
定位为什么难？因为它本质上是三件事的交叉验证：
1. **读trace**：从几GB的PCAP里筛出相关UE、相关接口、相关时间窗的信令；
2. **懂协议**：知道注册拒绝原因值、SBI返回码、NGAP cause分别意味着什么，知道去3GPP规范的哪一页找语义；
3. **连历史**：知道这个网、这批设备、这个割接窗口以前犯过什么错。
第一件事是体力活，第二件事是知识活，第三件事是经验活。过去二十年的AIOps努力，大多砸在告警侧的关联收敛上——那是“发现”环节的事。定位环节的三件事，恰好都是大语言模型的舒适区：**trace是半结构化文本，规范是纯文本，历史工单还是文本**。这不是巧合，这是大模型第一次真正摸到了排障的门槛。
## 二、大模型凭什么读懂信令：一笔技术账
### 2.1 它先读懂了规范
大模型能不能“懂信令”，前提是懂规范。2023年10月挂上arXiv的**TeleQnA**论文（编号2310.15051）给出了第一个公开标尺：作者构建了约1万道覆盖3GPP规范、RFC和电信术语的多选题基准，实测通用大模型的电信知识水平。论文的核心结论有两个，都属于可验证的实验事实：一是通用模型在电信专业题上的表现明显低于通用领域，小参数量的开源模型尤其惨；二是在电信语料上做过继续预训练和微调的小模型，可以显著缩小甚至部分反超大参数通用模型。这个结论直接催生了后续一批电信领域模型的工作（如arXiv上可检索到的TelecomGPT等），思路大同小异：**通用底座 + 电信语料续训 + 规范问答微调**。
要分清楚的是：TeleQnA测的是“背规范”的能力，不是“排障”的能力。但背规范是排障的必要条件——老师傅之所以是老师傅，第一步也是把TS 24.501的注册流程和原因值表刻进脑子。
### 2.2 排障Copilot的真实架构
规范知识只是弹药，真正干活的架构是“**大模型当大脑，工具链当手脚**”。一套能在生产环境活下来的排障Copilot，拆开看长这样：
```mermaid
flowchart TD
A[告警风暴触发] --> B[工单预处置
AI生成摘要]
B --> C{置信度够高吗}
C -->|高| D[给出根因假设
附规范条款引用]
C -->|低| E[人工介入
AI辅助检索]
D --> F{工程师复核}
F -->|认可| G[建议处置动作
不自动执行]
F -->|质疑| E
E --> D
G --> H[执行与验证]
H --> I[归档成知识
回填向量库]
```
关键设计有三处：
**第一，RAG管规范，不靠模型背。** 把TS 23.501、TS 24.501、TS 29.500这些核心规范连同企业内部的网络资料，切成500~2000字的段落灌进向量库。模型每给出一个结论，必须附带条款出处。这一步是幻觉的止损阀：模型背错原因值语义是常态，但只要强制它引用检索到的原文，错误就能被工程师肉眼拦截。
**第二，function calling调度Wireshark。** 这是很多演示Demo和真实产品的分水岭。几GB的PCAP塞不进任何模型的上下文窗口，正确姿势是让模型调用tshark做切片——先用 `-q -z io,phs` 看协议分布做体检，再用显示过滤把目标信令抠出来，最后只把几万token的精华喂给模型。**AI不是替代Wireshark，是替代坐在Wireshark前的你。**
**第三，知识回流闭环。** 每次排障结案，把“现象→假设→验证→根因”的四元组结构化入库。半年后，这套系统对“你这张网”的理解，会开始超过任何厂商预训练时见过的公开语料。
### 2.3 一张自建配置账
如果动手自建，下面这份配置清单是我们认为的务实起点（均为经验建议值，非任何厂商官方数据）：
| 配置项 | 建议做法 | 理由 |
|---|---|---|
| 底座模型 | 70B级开源模型内网部署，或商用API专有域实例 | 平衡效果、成本与数据合规 |
| 上下文窗口 | ≥128k，单次实际投喂≤5万token | 超长上下文成本陡增且尾部遗忘明显 |
| 规范库切片 | 3GPP核心规范+企业规范，500~2000字/片 | 保引用精度，避免段落跨流程 |
| 评测集 | ≥200道本地历史故障题 | 没有评测集就不许上线 |
| 脱敏策略 | SUPI/GPSI/IMEI哈希化后入库 | 5G的SUCI天然加密，是现成红利 |
| 动作权限 | 只读+建议，无下发权限 | 割接、复位类操作必须人工 |
## 三、运营商与设备商的真实动作
把镜头拉远，这条赛道上已经站满了人。以下均为公开信息层面的梳理，具体效果数据以各家官方发布为准。
**运营商侧**，国内三大运营商的大模型都把网络运维列为首发场景。中国移动的九天大模型（官网入口见文末）在发布和演示中反复出现工单生成、故障研判等网络场景；中国电信星辰大模型走开源路线（TeleChat系列已开源），中国联通的元景大模型同样把智能运维列为核心板块。运营商做这件事有天然动机：数据不出域是硬约束，集团统建大模型、省市两级落地工具，是逻辑自洽的路线。据公开报道，三家都已在省级NOC试点大模型辅助排障，但**分场景的准确率、MTTR改善幅度等硬指标，公开渠道基本查不到严格口径的数据**——这一点读者要心里有数。
**设备商侧**，爱立信的Intelligent Automate（EIAP是其平台底座）把AI/ML能力打包进网络自动化组合，主打意图驱动和闭环自动化；诺基亚的AVA系列做了多年运营数据分析，近两年也向生成式AI助手方向延伸。设备商方案的天然优势是贴着设备侧数据，天然短板也明摆着：多厂商混跑的网络里，一家设备商的自动化平台很难触达全貌。
**行业组织侧**，TM Forum近两年在生成式AI运营上发了多份报告并推动Catalyst试点项目，GSMA的AI相关研究也持续跟进。一个被反复引用的定性结论是：头部运营商几乎全部在试点生成式AI运维，但多数仍停留在辅助场景，真正进生产闭环的是少数。
各家路线对比如下（基于公开定位的粗粒度比较，不涉及内部实现）：
| 方案 | 形态 | 强项 | 短板 | 适合谁 |
|---|---|---|---|---|
| 运营商自研大模型 | 集团统建+省级落地 | 数据不出域，懂自家网 | 省侧工具链需自补 | 运营商自有NOC |
| 爱立信 Intelligent Automate | 设备商自动化组合 | 贴近设备侧数据 | 多厂商环境适配成本高 | 爱立信存量占高的网 |
| 诺基亚 AVA | AI运维组合 | 运营数据分析积累久 | 同上 | 诺基亚存量网 |
| 自建RAG+开源模型 | 自研工具链 | 完全可控，边际成本低 | 评测集和运维自己扛 | 有软件能力的团队 |
| 通用大模型直连 | API/网页 | 零成本上手 | 数据外发风险 | 学习与脱敏环境 |
## 四、一条PDU会话失败工单的AI排障沙盘
下面这个案例是**本文作者基于真实故障类型做的沙盘推演**——故障模式、信令行为和排查路径完全来自现网常见的真实场景，但具体数值是示例值，请勿对号入座。
**背景**：某市5G PDU会话建立成功率从99.2%跌到96.5%，用户投诉集中在高德地图报“网络异常”。告警侧一片安静——没有任何网元报Critical。
传统打法是三个人分头看：一个盯SMF日志，一个拉核心网信令，一个打电话问传输。而Copilot的打法是一条不同的时间线：
| 时刻 | 事件 | 传统模式 | AI辅助模式 |
|---|---|---|---|
| T+0 | 成功率跌破门限 | 告警触发，值班的先看大盘 | 同左，另自动生成工单摘要 |
| T+10min | 初步定位方向 | 三人分头人工拉数据 | AI从trace统计失败集中的TAC与S-NSSAI |
| T+25min | 关联发现 | 靠记忆想起“昨晚好像有割接” | AI关联变更管理库：昨晚UPF扩容割接 |
| T+40min | 根因假设 | 翻NRF配置逐项核对 | AI给出假设：新SMF未在NRF正确注册 |
| T+55min | 验证与处置 | 人工验证后修正 | 工程师复核假设，人工修正注册数据 |
交互过程是这样的：
```mermaid
sequenceDiagram
participant E as 工程师
participant C as 排障Copilot
participant T as tshark工具链
participant K as 知识库RAG
E->>C: 提问：PDU会话失败率为何抬升
C->>T: 按TAC与切片过滤会话建立流程
T-->>C: 返回失败样本与时间分布
C->>K: 查Nnrf发现与SMF选择规范
K-->>C: TS 29.510与TS 23.501相关条款
C->>T: 核对NRF返回的候选SMF列表
T-->>C: 新SMF不在发现结果中
C-->>E: 假设：NRF注册数据缺失
Note over E,C: 工程师复核后才建议修正动作
```
技术细节值得展开一句：按TS 23.501的SMF选择逻辑，AMF要通过Nnrf_NFDiscovery（TS 29.510）按S-NSSAI和DNN发现候选SMF。沙盘里的故障是扩容SMF的NRF注册数据漏配了其中一个切片——于是只有命中那个切片的会话失败，而且失败的原因值分布散乱，天然不触发任何网元告警。**这类“数据配置错误导致的静默故障”，恰恰是翻日志翻不出来的类型，也是知识+工具型AI最能打的地方。**
但要如实记录AI翻车的一面。同一次沙盘里，模型曾两次出错：一次把SBI某个返回码的语义说反，被强制引用条款的机制当场拦下；一次建议直接重启NRF“刷新缓存”——这个动作在多厂商混跑的现网里是危险操作，被权限边界挡住。两个失败案例都不是模型能力问题，而是**工程机制替模型兜住了能力边界**，这正是我想强调的：落地质量取决于护栏，不取决于模型分数。
## 五、落地暗礁：幻觉、合规与上下文
第一道坎是**幻觉**。大模型编造3GPP IE名、编造TS条款号、把EPS的原因值安到5G头上，都是高频事故。对策只有一条：所有协议类结论必须带检索引用，无引用视为无效。可以再加一层规则校验——把TS 24.501等规范的原因值表做成白名单，模型输出的每个枚举值先过白名单再示人。
第二道坎是**数据合规**。信令trace里全是SUPI、IMEI、位置信息。5G有个现成红利：空口侧SUPI已被加密成SUCI，但核心网内部trace里仍是明文。入库前哈希化是底线，且哈希盐要按次轮换，防止跨工单关联还原。
第三道坎是**上下文经济学**。一次像样的排障要读几十万token的trace切片，商用API按token计费会把一次故障的成本推到令人肉疼的水平，这也是运营商坚持自建小底座的现实原因之一。
第四道坎最隐蔽：**评测集缺失**。很多团队拿着Demo效果惊艳的截图就申请立项，上线后准确率没人说得清。TeleQnA给行业打了个样——仿照它，用自己网络的200道历史故障题做考卷，上线前闭卷考试，才是负责任的做法。
## 六、经验教训与下一步
把这一年的观察压成三句话。
**其一，AI接的是定位段，不是决策段。** 告警收敛、根因假设、验证清单，这些是Copilot的主场；但“要不要切流、要不要回退割接”这类动作决策，未来几年都应该留在人手里。自智网络分级里的现实落点，恰恰是辅助定位的L2到有条件闭环的L3之间，跳级叙事听听就好。
**其二，知识库质量决定上限，模型选型只决定下限。** 同一个底座，喂官方规范和喂内部高价值结案报告，表现差着一个时代。你的结案工单写得越像“现象-假设-验证-根因”，AI就越好用——**治理工单就是治理AI的教材**。
**其三，对工程师个人，这是十年来最好的一次杠杆。** 排障手艺的护城河从来不是“记得住原因值”，而是“知道往哪里查、敢下什么结论”。大模型把记忆和检索这两层外包了，把判断放大了。懂协议的人指挥AI，一小时干完过去一晚的活；不懂协议的人指挥AI，只会更快地得出错误结论。
下一步值得盯的是两件事：多模态排障（拓扑图、trace时序图、语音告警一起喂给模型）和评测基准的行业化——当各家运营商开始互相对齐排障AI的考卷，这个市场才会真正分层。
## 参考来源
1. [TeleQnA: A Benchmark Dataset to Assess the LLMs Knowledge for Telecommunications (arXiv:2310.15051)](https://arxiv.org/abs/2310.15051) — 电信大模型知识基准论文，本文2.1节实验结论的主轴来源
2. [tshark官方手册 - Wireshark Foundation](https://www.wireshark.org/docs/man-pages/tshark.html) — 本文工具链方案中tshark参数的权威出处
3. [3GPP规范门户](https://www.3gpp.org) — TS 23.501/24.501/29.510等规范原文检索入口
4. [TM Forum](https://www.tmforum.org) — 生成式AI与自智网络运营系列研究报告
5. [中国移动九天人工智能平台](https://jiutian.10086.cn) — 运营商大模型及网络运维场景公开信息入口
---
> 本文由「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 等场景全覆盖。
