MSR 2023 | 用 LLM 生成代码做网络拓扑分析，GPT-4 准确率达 88%

本文来自微软研究院（Microsoft Research），合作者包括波士顿大学和莱斯大学的研究者，作者为 Sathiya Kumaran Mani、Yajie Zhou、Kevin Hsieh、Santiago Segarra、Ranveer Chandra 和 Srikanth Kandula。

研究者提出了一个新思路：让 LLM 不直接回答网络管理问题，而是生成针对特定任务的代码，在本地执行完成图分析与操作。这套方法在可解释性、可扩展性和隐私性三个方面绕过了直接让 LLM 操控网络拓扑的固有缺陷。以 GPT-4 + NetworkX 的组合为例，在流量分析任务上准确率达到 88%，而直接把图数据喂给 LLM 的基线方法只有 29%。

据作者所知，这是首个研究 LLM 在图操作和网络管理中应用的工作。

论文链接：https://arxiv.org/abs/2308.05481

痛点很直接：让 LLM 直接碰网络数据，三个问题无解

网络管理的很多操作本质上都是图分析和图操作——分析拓扑结构、查通信图里的瓶颈、做容量规划、定位设备间的跳数。这些事在底层都绕不开节点和边的操作。

LLM 的语言理解能力很强，用它来统一五花八门的网络管理工具和 DSL，听起来是个好主意。但直接让 LLM 处理网络拓扑数据，会遇到三道硬墙。

第一道墙是可解释性。 LLM 给出的答案，你很难搞清楚它怎么算出来的。即便是最先进的 GPT-4，也存在幻觉和基础算术错误。网络管理不是写诗，算错一个跳数、漏看一条边，可能就是一次故障。

第二道墙是可扩展性。 LLM 的上下文窗口有限。论文写作时的 GPT-4 支持最多 32k token，也就勉强塞下一个包含几十个节点、几百条边的小图。现实中的网络拓扑动辄成千上万个节点——比如论文中使用的 MALT 数据集就有 5493 个节点和 6424 条边。根本塞不进去。

第三道墙是隐私。 网络数据中包含 IP 地址等个人身份信息（PII），传给外部 LLM 服务存在合规风险。尤其对于 GDPR 等数据保护法规，把网络拓扑原封不动地发给云端模型，在很多场景下根本行不通。

换句话说，让 LLM 直接碰数据这条路走不通。那换个思路呢？

核心想法：LLM 不碰数据，只生成代码

研究者的思路很朴素——LLM 负责理解你的自然语言查询，然后生成一段代码。这段代码在本地沙箱里执行，操作的是本地的图数据。LLM 从头到尾都接触不到实际的网络数据。

这样做的好处是三重的：代码是可读的，网络运维人员可以检查逻辑是否正确（解决可解释性）；图数据在本地执行引擎上处理，不受 token 限制（解决可扩展性）；网络数据不需要发送给 LLM（解决隐私性）。同时，计算交给程序执行引擎做，算术错误和幻觉的问题也大幅缓解。

图 1：系统工作流示意。运维人员输入自然语言查询（如「为每个 /16 IP 前缀分配一种唯一颜色」），系统生成 LLM 代码并在本地执行，返回更新后的通信图。

当然，这个方案的核心挑战在于：怎么让 LLM 生成足够高质量的网络管理代码？LLM 在通用代码生成上确实表现不错，但它不了解网络管理领域的特定需求。为此，研究者提出了一个双层架构。

双层架构：领域知识 + 通用程序合成

框架的核心设计思想是把提示词（prompt）的生成分成两层：一层负责注入领域特定的上下文信息，另一层负责通用的代码生成。

图 2：系统框架总览，包含六个核心组件。

具体来说，框架由以下组件协同工作：

应用包装器（Application Wrapper） 是最上游的组件，负责把底层的网络数据转换成图表示，并将实体（如数据包交换机、控制点）和关系（如包含、控制）用自然语言描述出来。这些信息帮助 LLM 理解网络管理应用的数据结构。

应用提示词生成器（Application Prompt Generator） 接收用户的自然语言查询和应用包装器提供的上下文信息，生成针对具体任务的提示词。对于 MALT 这类应用，它可以动态选择与用户查询相关的实体和关系，填入提示词模板。

通用代码生成提示词生成器 负责将应用层的提示词与通用的代码生成指令结合，指导 LLM 使用合适的库和程序合成技术来产出代码。

LLM 负责生成代码。论文测试了 GPT-4、GPT-3、text-davinci-003 和 Google Bard 四个模型。

执行沙箱（Execution Sandbox） 在安全隔离的环境中运行 LLM 生成的代码，限制代码对程序库和系统调用的访问权限，同时可以验证网络不变量和输出格式。

用户界面（UX Interface） 展示生成的代码及其执行结果。如果用户认可结果，更新后的图会被回传给应用包装器，修改网络状态。

这个架构的关键在于：领域特定部分和通用代码生成部分可以独立迭代。你可以在不改动底层 LLM 的情况下，通过优化应用包装器和提示词来提升特定场景的表现。

代码生成三路线：SQL、pandas、NetworkX

研究者实现了三种不同的代码生成路线，分别使用不同的数据表示和操作库：

NetworkX 路线 把网络数据表示为 NetworkX 图对象，利用其灵活的图操作 API。LLM 可以调用 NetworkX 丰富的图分析函数，生成的代码通常更简洁。

pandas 路线 把网络数据拆成节点 DataFrame 和边 DataFrame，利用 pandas 的过滤、排序、分组等操作。这条路线对 LLM 来说比较熟悉，因为 pandas 在公开代码库中出现频率极高。

SQL 路线 把网络数据存入关系数据库（节点表和边表），让 LLM 生成 SQL 查询。之前的研究已经证明 LLM 在 text-to-SQL 任务上可以取得不错的准确率。

此外，论文还设了一个 strawman 基线：直接把图数据以 JSON 格式喂给 LLM，让它直接回答。但因为 token 限制，这条基线只能用合成的小图来测试。

NeMoEval 基准：专门评测 LLM 网络管理能力

为了系统性地评估效果，研究者构建了 NeMoEval 基准。这个基准包含两个可建模为图操作的网络管理应用：

网络流量分析 使用合成的通信图，每条边代表两个节点间的通信活动，包含字节数、连接数、数据包数等随机权重。研究者整理了 24 条查询，涵盖拓扑分析、信息计算和图操作。

网络生命周期管理 使用 Google 的 MALT（Multi-Abstraction-Layer Topology）示例数据集，转化为包含 5493 个节点和 6424 条边的有向图。每个节点代表网络中的一种或多种类型（如数据包交换机、机箱、端口），有向边封装设备间的关系（控制或包含关系）。整理了 9 条管理查询，聚焦运营管理、WAN 容量规划和拓扑设计。

查询按复杂度分为 Easy、Medium、Hard 三个等级。评测流程也很直接：人工专家为每条查询编写「金标准」答案，系统执行 LLM 生成的代码，对比结果是否匹配。

实验结果：NetworkX + GPT-4 是最优组合

先看整体准确率（表 2）。在流量分析任务上，四种 LLM 在 NetworkX 路线下的平均准确率为 68%，其中 GPT-4 达到 88%，一骑绝尘。strawman 基线在相同任务上平均只有 23%，最好的 GPT-4 也只有 29%。代码生成路线将平均准确率提升了 45 个百分点。

模型StrawmanSQLPandasNetworkXSQLPandasNetworkX
流量分析MALT
GPT-40.290.500.380.880.110.560.78
GPT-30.170.130.250.630.110.440.44
text-davinci-0030.210.290.290.630.110.220.56
Google Bard0.250.210.250.590.110.330.44

表 2：两个应用场景下的准确率汇总。

几个观察值得一提。NetworkX 在所有 LLM 和两个应用中都优于 SQL 和 pandas。原因不难理解——NetworkX 提供了专门的图操作 API，LLM 用这些 API 写出来的代码更简洁、更不容易出错。pandas 次之，SQL 在 MALT 上表现最差（GPT-4 用 SQL 做 MALT 只有 11%），可能是因为复杂网络关系用表操作来表达太绕了。

再看复杂度的影响。Easy 任务上，所有 LLM 在 NetworkX 路线下都能达到 88%–100% 的准确率。但到了 Hard 任务，GPT-4 也只有 63%。其他模型更惨，大多在 0%–38% 之间。复杂网络关系（如 MALT 中的多层拓扑）让 LLM 很容易在推理链条上出错。

图 4：成本与可扩展性分析。左图（a）展示小图上的查询成本对比，右图（b）展示随图规模增大的成本变化。

成本方面，以 GPT-4 在 Azure 上的定价计算，该方法的平均查询费用低于 $0.2，而且不随网络规模增大而变化。strawman 方法在 80 个节点的小图上就已经贵了 3 倍，到了 150 个节点时直接超出 LLM 的 token 上限。

代码错了怎么办：Pass@k 和 Self-debug 能补救

在 NetworkX 路线下，流量分析有 35 次失败（共 96 次测试），生命周期管理有 17 次失败（共 36 次测试）。研究者统计了错误类型，发现超过一半是语法错误和「虚构属性」（imaginary attributes）——LLM 编造了图上不存在的属性或调用了不存在的函数。

这些错误有个特点：它们不是逻辑层面的根本错误，而是可以通过多次采样或自我调试来修复的「浅层错误」。研究者用 Bard 模型在 MALT 上做了个案例研究：

方法Bard + Pass@1Bard + Pass@5Bard + Self-debug
NetworkX0.441.00.67

表 6：Bard 在 MALT 上使用不同程序合成技术的改进效果。

Pass@5（让 LLM 生成 5 次代码，有一次正确就算通过）把准确率从 44% 直接拉到了 100%。Self-debug（把错误信息反馈给 LLM 让它自己修正）提升到 67%。这表明，结合互补的程序合成技术，LLM 生成代码的准确率还有相当大的提升空间。

总结

总体来看，这项工作在 LLM 和网络管理的交叉领域迈出了探索性的第一步。核心贡献可以归结为以下几点：

  • 首次提出用 LLM 生成代码（而非直接回答）来完成网络管理中的图分析任务，同时解决了可解释性、可扩展性和隐私三个难题
  • 构建了 NeMoEval 基准，涵盖流量分析和生命周期管理两个应用场景，为后续研究提供了统一的评测标准
  • 在 GPT-4 + NetworkX 的最优组合下，流量分析准确率达 88%，生命周期管理达 78%，显著优于直接输入图数据的基线方法
  • 展示了 pass@k 和 self-debug 等互补技术可进一步提升代码质量，Bard + pass@5 在 MALT 上实现了 100% 的准确率

当然，这项工作的局限也很明显。在 Hard 任务上准确率下降明显，说明 LLM 对复杂网络关系的理解还不够。如何在模型侧引入领域知识（比如微调或更多上下文示例），如何将更多网络管理任务纳入评测范围（如故障诊断、配置验证），都是值得进一步探索的方向。

对于 LLM + 网络管理这个方向感兴趣的读者，可以进一步阅读以下相关研究：NetLLM 用 LoRA 微调 LLM 适配网络任务、NetAssistant 构建面向数据中心网络诊断的对话系统、Confucius 用多智能体 DAG 框架管理超大规模网络——这几项工作分别从不同角度探索了 LLM 赋能网络管理的可能性。