概述

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，拆开看长这样：

flowchart TD
    A[告警风暴触发] --> B[工单预处置<br/>AI生成摘要]
    B --> C{置信度够高吗}
    C -->|高| D[给出根因假设<br/>附规范条款引用]
    C -->|低| E[人工介入<br/>AI辅助检索]
    D --> F{工程师复核}
    F -->|认可| G[建议处置动作<br/>不自动执行]
    F -->|质疑| E
    E --> D
    G --> H[执行与验证]
    H --> I[归档成知识<br/>回填向量库]

关键设计有三处：

第一，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 一张自建配置账

如果动手自建，下面这份配置清单是我们认为的务实起点（均为经验建议值，非任何厂商官方数据）：

三、运营商与设备商的真实动作

把镜头拉远，这条赛道上已经站满了人。以下均为公开信息层面的梳理，具体效果数据以各家官方发布为准。

运营商侧，国内三大运营商的大模型都把网络运维列为首发场景。中国移动的九天大模型（官网入口见文末）在发布和演示中反复出现工单生成、故障研判等网络场景；中国电信星辰大模型走开源路线（TeleChat系列已开源），中国联通的元景大模型同样把智能运维列为核心板块。运营商做这件事有天然动机：数据不出域是硬约束，集团统建大模型、省市两级落地工具，是逻辑自洽的路线。据公开报道，三家都已在省级NOC试点大模型辅助排障，但分场景的准确率、MTTR改善幅度等硬指标，公开渠道基本查不到严格口径的数据——这一点读者要心里有数。

设备商侧，爱立信的Intelligent Automate（EIAP是其平台底座）把AI/ML能力打包进网络自动化组合，主打意图驱动和闭环自动化；诺基亚的AVA系列做了多年运营数据分析，近两年也向生成式AI助手方向延伸。设备商方案的天然优势是贴着设备侧数据，天然短板也明摆着：多厂商混跑的网络里，一家设备商的自动化平台很难触达全貌。

行业组织侧，TM Forum近两年在生成式AI运营上发了多份报告并推动Catalyst试点项目，GSMA的AI相关研究也持续跟进。一个被反复引用的定性结论是：头部运营商几乎全部在试点生成式AI运维，但多数仍停留在辅助场景，真正进生产闭环的是少数。

各家路线对比如下（基于公开定位的粗粒度比较，不涉及内部实现）：

四、一条PDU会话失败工单的AI排障沙盘

下面这个案例是本文作者基于真实故障类型做的沙盘推演——故障模式、信令行为和排查路径完全来自现网常见的真实场景，但具体数值是示例值，请勿对号入座。

背景：某市5G PDU会话建立成功率从99.2%跌到96.5%，用户投诉集中在高德地图报“网络异常”。告警侧一片安静——没有任何网元报Critical。

传统打法是三个人分头看：一个盯SMF日志，一个拉核心网信令，一个打电话问传输。而Copilot的打法是一条不同的时间线：

交互过程是这样的：

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) — 电信大模型知识基准论文，本文2.1节实验结论的主轴来源
2. tshark官方手册 - Wireshark Foundation — 本文工具链方案中tshark参数的权威出处
3. 3GPP规范门户 — TS 23.501/24.501/29.510等规范原文检索入口
4. TM Forum — 生成式AI与自智网络运营系列研究报告
5. 中国移动九天人工智能平台 — 运营商大模型及网络运维场景公开信息入口

本文由「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 等场景全覆盖。