基于证据的802.11数据包捕获集成诊断：具有确定性可靠性评分的多阶段流水线

# 基于证据的802.11数据包捕获集成诊断：一种具有确定可靠性评分的多阶段流水线
来源：https://arxiv.org/html/2606.06871

###### 摘要

从802.11数据包捕获中诊断连接问题需要专家级的协议知识，过程缓慢，工程师之间一致性差，且缺乏可扩展性。近来利用大型语言模型（LLM）的方法所产出的分析听起来合理，但存在三个显著缺陷：它们会捏造捕获中并不存在的协议事件（特别是在截断的追踪中），其自报置信度未校准，并且针对人工标注的黄金参考标准的评估偏向于协助创建该参考标准的模型。我们提出了 **PROBE**（基于证据集成的协议推理），这是一个多阶段诊断流水线，旨在纠正所有三种缺陷模式。该系统整合了：(i) 确定性的PCAP到文本归一化过程，保持帧级别的可验证性；(ii) 多轮、多候选集成，包括可选的跨模型第二意见和渐进式混淆；(iii) 一种判决感知的证据框架，将缺乏失败证据视为贡献性证据；以及 (iv) 完全确定的复合可靠性得分，由证据有效性、轮次间稳定性和跨模型一致性推导得出——不依赖LLM自我评估。在一项涉及87个企业Wi-Fi捕获（104个捕获-审查者配对）的研究中，我们观察到单次LLM分析将加权证据F₁从0.871（人类专家基线）提升至0.912，但在35%的实例中未能识别出诊断关键帧。朴素集成投票导致性能下降至专家基线以下（0.842），因为多数投票倾向于放大保守判决：50%的确认失败被错误分类为“无问题”或“证据不足”。引入一个根据数据包证据评估所有候选方案的协调步骤，将性能提升至0.957，实现了96%的自动接受率，最坏情况下限超过0.70。LLM自报置信度始终聚集在0.95，无论诊断难度如何（71%的案例报告精确值为0.95），表明其信息量不足。我们进一步引入了一种基于逐字段断言匹配的模型无关评估框架，消除了由特定模型共同生成的黄金参考标准中固有的循环偏差。

## 1. 引言

从数据包捕获（PCAP）中诊断企业Wi-Fi问题需要深厚的协议专业知识。一个单一的802.11会话捕获可能包含数十个相关的管理帧、控制帧和数据帧，其解释依赖于微妙的顺序、时序、状态码和跨帧状态机。能够可靠诊断此类捕获的领域专家（SME）稀缺，他们认真仔细，因此诊断速度慢且成本高昂（若以高效方式进行则昂贵），而且不幸的是，有时彼此不一致。

大型语言模型为快速自动PCAP诊断提供了一条路径：给定捕获的文本表示，它们可以生成结构化解释，识别协议阶段，突出异常帧，并提出根本原因。然而，单次LLM分析表现出三种具体且可衡量的失败模式：

1. **虚构完成。** 当捕获被截断时（例如，在四次握手过程中结束），模型通常会推断出一个不存在于现有数据包中的失败。当一次交换中缺少一个数据包时，模型常常会想象出那个数据包，因为下一个数据包存在。

2. **未校准的置信度。** 当被问及对自身诊断的置信度时，模型擅长定量的空谈，通常提出的置信度分数聚集在0.85–0.95之间，无论实际诊断难度如何（见第7.3节（https://arxiv.org/html/2606.06871#S7.SS3））。

3. **黄金参考标准偏差。** 将SME和LLM诊断结合起来产生一个黄金诊断很诱人。然而，这种结构本身更倾向于结合弱点而非产生优势。此外，切换到不同模型会人为地惩罚风格差异而非诊断错误（见第6节（https://arxiv.org/html/2606.06871#S6））。

本文做出了三项贡献：

1. **一个多阶段集成流水线**，生成N×M个候选诊断（跨N轮和每轮M个候选），包括可选的跨模型第二意见、渐进式混淆以及包含“证据不足”判决的正式判决分类法（第4节（https://arxiv.org/html/2606.06871#S4））。我们表明，这种集成提高了诊断的可靠性，但只有在审慎使用时才有效。

2. **一个确定性的复合可靠性得分**，由证据有效性、判决稳定性和跨模型一致性计算得出，不依赖LLM自我评估，从而能够基于原则性的置信度将问题升级至人工审查（第5节（https://arxiv.org/html/2606.06871#S5））。

3. **一个模型无关的评估框架**，基于逐字段断言匹配，消除了黄金参考标准中的循环偏差（第6节（https://arxiv.org/html/2606.06871#S6））。

## 2. 背景与动机

### 2.1 PCAP诊断作为结构化推理任务

与许多LLM评估领域不同，在这些领域中地面实况不确定（例如，医学诊断）或本质上是主观的（例如，法律推理），数据包捕获是协议事件的完整、确定性记录。一个帧要么包含EAPOL消息3，要么不包含；RSSI要么是-79 dBm，要么不是。这一特性创造了一个独特的“基于证据的评估”机会，比大多数诊断场景中可能的评估更强。事件的包捕获应包含解释所发生事件的具体帧以及这些帧的具体字段。在现实世界中，导致失败的交换过程的捕获并不总是包含用户支持分析师梦寐以求的证据：

1. 有些捕获包含直接的错误消息，似乎指向确定的根本原因（例如，RADIUS服务器拒绝了关联，因为提供的密码无效）。不幸的是，根本原因往往有不同的深度（密码是在客户端配置错误还是在服务器配置错误？），而且明显的错误消息并不总是能得出可清晰表述的明确根本原因诊断及其相关补救措施。

2. 有些捕获包含问题的间接证据（例如，超时错误：RADIUS服务器没有及时响应）。如果没有从其他位置（路径上的网络节点、服务器日志）收集的额外消息，很难做出类似于1的结论。定量数据或有经验的故障排除者可能将这两类联系起来（例如，罪魁祸首很可能是路由器5，因为过去27次出现该问题时它都有故障）。

3. 有些捕获不包含任何明确的消息或提示（例如，服务器响应不在捕获中，因为捕获被截断，因为捕获设备未记录服务器响应，或其他未知原因），并且没有足够的证据做出任何结论。需要额外的信息才能将问题带回类别2或1。

类型1的捕获是理想的，但有经验的（人类）故障排除者知道，网络捕获是脆弱的事件痕迹。捕获设备看到的视角与数据包的源和目的地的视角不同；时序、缓冲区或驱动程序故障可能导致捕获无法显示目标确实接收到的帧。捕获中可见的错误消息可能不是所调查问题的揭示性线索，而可能只是一个次要事件的附带症状。专家故障排除者驾驭这些不确定性，在可能时填补空白，在需要时质疑捕获。将故障排除任务委托给LLM，意味着模型需要学习相同的导航技能。

### 2.2 为什么单次和多次LLM分析会失败

将数据包捕获分析委托给LLM，即使经过微调，也常常令人失望，因为模型的主要目的是生成概率上可行的令牌，而不是应用分析严谨性。我们数据集中的三个具体例子说明了这一挑战，并激发了本文中流水线的设计。

##### 示例1：虚构的握手失败。
一个自动化脚本捕获了一个客户端关联过程。802.11客户端与接入点交换发现消息（探测帧），然后进行802.11身份验证和关联阶段。AP随后发送了四次握手的第一个消息（M1），客户端以预期的M2响应。捕获在此处中断。人类专家正确地指出捕获是结论不明的，而Sonnet 4.5得出结论（可能也注意到捕获旨在排查网络问题），认为AP未发送M3表明客户端因错误密码而被拒绝。这种误报将触发对可能并不存在的凭证问题的不必要排查。这类问题激发了本文提出的“证据不足”判决和判决感知证据规则。

##### 示例2：模糊的SME注释。
在另一个案例中，四次握手的第三个消息（M3）在捕获中缺失，但第四个消息（M4）存在，表明交换成功完成（捕获设备可能未能捕获M3）。人类专家在旁注中提到了缺失的帧。Sonnet 4.5在第一次迭代中描述了M3帧，声称它存在。在第二次迭代中，同一模型注意到该帧缺失，并得出结论认为四次握手失败。这个问题，以及同一模型对同一捕获的两次迭代之间的差异，强调了捕获的局限性并不能约束模型，反而使模型能够填补任何听起来合理的部分。这类问题激发了本文建议的协调器角色，即将LLM声明与PCAP证据进行比较。

##### 示例3：捏造的问题。
在另一个案例中，客户端尝试DNS解析，首先使用安全DNS（在TLS上使用端口853），然后由于服务器在安全端口上没有响应，使用常规DNS（端口53）。客户端随后成功获取了查询URL的IP地址。然而，Sonnet 4.5得出结论，DNS解析失败，因为安全查询不成功。模型引用了具有真实协议事件的真实帧，但得出了一个不受支持的诊断结论：观察正确但推断错误。这激发了本文提出的“贡献性证据与非贡献性证据”区分，以及集成揭示分歧的能力。

## 3. 相关工作

PROBE位于四个活跃研究领域的交叉点：基于LLM的网络分析、自一致性与集成推理、LLM在诊断任务中的评估，以及基于证据的输出评估。我们回顾每个线索，并确定PROBE所解决的具体空白。

### 3.1 基于LLM的网络分析与故障排查

语言模型在网络数据中的利用自2024年以来迅速发展，涵盖了数据包级分析、配置合成和事件诊断。

##### 数据包捕获分析。
LLMcap [1 (https://arxiv.org/html/2606.06871#bib.bib1)] 应用掩码语言建模（使用DistilBERT）于PCAP文件，用于自监督故障检测。通过对数据包头进行分词并训练模型重构掩码字段，LLMcap通过高重构误差识别异常数据包。虽然对于二元异常检测有效，但LLMcap不产生诊断解释：它标记出“哪些”数据包异常，但不说明“为什么”或“指示了什么协议失败”。PROBE解决了一个根本不同的任务，产生结构化的、引用帧的诊断推理，而非二元分类。
Abkenar [2 (https://arxiv.org/html/2606.06871#bib.bib2)] 对仅编码器（DistilBERT）和仅解码器LLM进行微调，用于检测IEEE 802.11网络中的病理状态，包括竞争、帧丢失、隐藏终端效应和干扰。该方法在有监督数据上取得了高分类准确率，但像LLMcap一样，在病理类别级别运行，没有结构化证据或解释性推理。PROBE的不同之处在于产生逐帧证据，附带贡献性/非贡献性标注，以及包含弃权（“证据不足”）的明确判决分类法。
PLUME [3 (https://arxiv.org/html/2606.06871#bib.bib3)] 为无线追踪构建了一个协议原生基础模型，引入了协议感知分词，保留了802.11帧的层次结构。PLUME在比PROBE更低的抽象级别运行：它学习可通过微调用于下游任务（异常检测、流量分类）的数据包序列表示，而PROBE则对文本化的PCAP表示进行操作，专注于诊断推理和可靠性评估。这两种方法是互补的：PLUME的表示可以作为PROBE集成流水线的输入。

##### 网络故障排查与诊断。
NetAssistant [4 (https://arxiv.org/html/2606.06871#bib.bib4)] 是一个基于对话的网络诊断系统，已在字节跳动的数据中心部署超过三年。它接受自然语言查询并执行诊断工作流，显著减少了人工值班负担。然而，NetAssistant通过预定义的诊断工作流运行，而不是对原始数据包数据进行开放式推理，并且它没有解决其诊断输出的可靠性或一致性问题。
BiAn [5 (https://arxiv.org/html/2606.06871#bib.bib5)] 提出了一个基于LLM的框架，用于阿里巴巴云生产网络中的故障定位，处理监控数据以生成带有解释的故障设备排名。BiAn引入了大规模数据的分层推理和通过操作反馈进行的提示优化。虽然BiAn解决了生产规模诊断问题，但它针对的是来自聚合监控日志的设备级故障定位，而不是来自单个数据包捕获的协议级诊断。PROBE专注于互补问题，即在协议层面解释“为什么”特定会话失败。

##### 网络专用LLM。
Mobile-LLaMA [6 (https://arxiv.org/html/2606.06871#bib.bib6)] 对LLaMA 2 13B进行了5G网络分析数据的指令微调，表明领域特定微调改进了网络数据分析任务。
NetLLM [7 (https://arxiv.org/html/2606.06871#bib.bib7)] 将通用LLM适应于网络任务，包括视口预测和自适应码率流。两种方法都侧重于使LLM能力适应网络数据，但没有解决诊断输出的可靠性或一致性问题，这是PROBE的核心关注点。

##### 基准测试。
NIKA [8 (https://arxiv.org/html/2606.06871#bib.bib8)] 提供了最大的LLM驱动网络事件诊断公共基准，包含跨越五种网络场景的数百个精心策划的事件。其评估揭示了一个激发PROBE的关键发现：虽然较大的模型在“检测”网络问题上更成功，但它们仍然难以“定位故障并识别根本原因”。PROBE直接解决了这个问题。