Page 248 - 《软件学报》2026年第5期

张添翼 等: LLM-Extractor: 基于大语言模型的软件配置间约束提取方法 2127

码 (HDFS release-2.9.2), 本文并未在源代码中找到 dfs.client.read.shortcircuit 直接控制 dfs.block.local-path-
access.user 的程序链路; 2) 配置间约束能够在特定程序位置找到线索, 但是未能被 cDep 预先定义的程序模式匹
配, 例如配置 dfs.namenode.servicerpc-address 在未设置时系统会默认使用另一个配置 dfs.namenode.rpc-address, 我
们通过阅读代码研究了该条配置间约束在代码中的存在形式, 发现了如图 11 的代码形式, 从图 11 中可以看出, 两
个配置经过了两次别名变换, 最后通过 getAddressesForNsIds 函数中的复杂循环逻辑完成默认值处理, 这种依赖形
式未能被 cDep 的预定义模式覆盖, 因此未能被 cDep 提取; 3) 配置间约束提到的配置未出现在源代码中, 例如配
置 dfs.http.client.failover.max.attempts 依赖于功能“WebHDFS client”, 而配置 dfs.webhdfs.enabled 控制功能
“WebHDFS client”的开闭, 但是我们在源代码文件中仅在 hdfs-default.xml 和 WebHDFS.md 文件中找到相关关键
字, 并未在 Java 源文件中找到相关变量引用. 通过对比我们发现, LLM-Extractor 可以综合分析多段文档, 从而找
出部分难以从源代码中获取线索的配置约束关系.

图 11 HDFS 配置约束代码形式示例

从方法泛化能力和适配性来看, 两种方法均有一定的泛化能力. cDep 提出的程序模式挖掘方法理论上适配大
部分编程语言, 所定义的控制约束、行为约束等约束模式在不同软件中也可以找到对应模式实例, 经过对目标软
件源码的阅读分析再通过开发对应软件的程序分析工具, 可以完成迁移应用. 但是此过程面临多种挑战, 首先 Java、
C++等不同语言的语言特性差别巨大, 需要大量前期调研, 并使用 Soot、LLVM 等不同的工具链开发程序分析工
具, 除此之外, 即使是相同语言编写的软件, 编译器版本差异、代码风格不同也会给程序分析工具开发带来困难,
例如适配不同的 LLVM 版本, 又例如需要处理代码中的特殊情况以保证程序分析工具的正常运行. 因此 cDep 在
不同软件之间迁移应用需要消耗较多人力和时间, 且无法分析缺乏源代码的商业软件. 而 LLM-Extractor 作为一
种轻量化的工具, 可以适用于不同的软件, 尤其对于无法获得源代码的商业软件, 可以通过分析配置文档迅速提取
配置约束. 因此本文认为 LLM-Extractor 具有更好的泛化能力.
通过多个方面的对比, 本文认为 LLM-Extractor 与 cDep 各有优劣, 有不同的适用场景和优势. cDep 侧重于尽
可能全面地挖掘配置之间可能存在的依赖关系, 并通过人工确认和测试的方法来获得违反依赖导致的系统行为,
有利于更全面地分析配置约束, 但是需要能够获得和编译源代码, 且部分配置约束在源代码中难以挖掘或者没有
显式的表现形式, 难以通过程序分析方法获取. LLM-Extractor 则侧重轻量化地分析各种软件, 只需获得软件的配
置文档, 泛化能力较强. 虽然受制于配置文档的编写质量, LLM-Extractor 在分析全面性上有一定劣势, 但是可以快
速获得包含确定性条件和条件影响的配置约束, 适用场景更加灵活.
4.5 有效性分析
本节主要分析 LLM-Extractor 以及评估实验可能存在的一些不足.
4.5.1 数据集有效性
由于目前并没有从软件文档中提取配置间约束的公开大规模数据集, 本文所使用的数据集均由参与本文的研
究人员自行构建. 由于研究人员人力有限, 本文重点研究了配置约束集中出现的配置文档, 暂未考虑可能涉及配置
的其他功能文档. 同时, 从文档中提取配置间约束构建标准答案集合需要耗费大量人力, 并且依赖不同软件领域的
专家知识, 因此人工构建数据集的过程中难免会引入主观性, 可能引入部分错误, 对实验评估产生消极影响.
此外, 本文选择 PracExtractor 作为对比方法, 按照 PracExtractor 论文描述复现了该方法并进行测试评估, 由于
涉及关键词认定和约束模板设计, 该复现方法可能与原方法有所差别, 这可能会影响实验评估.