🤖 AI

Automating the Detection of Requirement Dependencies Using Large Language Models

本文提出了名为 LEREDD 的基于大语言模型的方法，通过结合检索增强生成（RAG）和上下文学习（ICL）技术，实现了从自然语言需求中自动化检测多种依赖关系，并在实验证明其显著优于现有基线方法的同时，公开了包含 813 对需求的数据集以支持后续研究。

原作者： Ikram Darif, Feifei Niu, Manel Abdellatif, Lionel C. Briand, Ramesh S., Arun Adiththan

发布于 2026-02-27

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Ikram Darif, Feifei Niu, Manel Abdellatif, Lionel C. Briand, Ramesh S., Arun Adiththan

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

这篇论文介绍了一个名为 LEREDD 的新工具，它的任务是帮软件工程师自动找出“需求”之间的依赖关系。

为了让你更容易理解，我们可以把软件开发想象成建造一座巨大的、复杂的摩天大楼。

1. 背景：混乱的“需求清单”

在盖楼之前，建筑师（软件工程师）会写下一份长长的需求清单（Requirements）。

比如：“大楼必须有一个自动门”、“自动门需要连接到大楼的电力系统”、“如果停电，自动门必须能手动打开”。
问题在于：这些需求之间是互相纠缠的。如果“电力系统”变了，“自动门”和“手动开关”可能都要跟着变。
现状：在大型项目中，需求成千上万，而且是用自然语言（像人话一样）写的，充满了模糊性。工程师们通常只能靠人工去读这些文档，找出哪些需求是互相依赖的。这就像在几千页的说明书里找几根特定的线，既慢又容易出错，甚至经常漏掉。

2. 主角登场：LEREDD（一位超级智能的“建筑监理”）

为了解决这个问题，作者们开发了一个叫 LEREDD 的系统。它基于目前最火的 大语言模型（LLM）（就像现在的 AI 聊天机器人，但更专业）。

你可以把 LEREDD 想象成一位拥有超级记忆力和逻辑推理能力的“建筑监理”。它的工作流程非常巧妙，分两步走：

第一步：查资料（RAG - 检索增强生成）

当监理看到两个需求（比如“自动门”和“电力系统”）时，它不会瞎猜。

它会先去翻阅整个大楼的原始设计图纸（SRS 文档），找出关于“自动门”和“电力系统”的具体描述。
比喻：这就像你问一个专家：“这两个东西有关系吗？”专家不会只凭印象回答，而是会先去查手册，确认“哦，手册里写了自动门确实连着电力系统”。这确保了回答是基于事实的，而不是 AI 的胡编乱造。

第二步：找参考（ICL - 上下文学习）

光查手册还不够，监理还需要知道“什么样的关系算依赖”。

它会从以前的案例库里，找出4 个最相似的例子给 AI 看。
比喻：就像老师教学生做题，不会只给题目，还会给几个“例题”。
- 例题 1：如果 A 坏了 B 就不能用，这叫“依赖”。
- 例题 2：如果 A 和 B 说的是一回事，这叫“重复”。
- 例题 3：如果 A 和 B 互相打架，这叫“冲突”。
通过看这些例子，AI 就能明白：“哦，原来这种关系叫‘依赖’，那种叫‘冲突’。”

3. 它是怎么工作的？

LEREDD 会像这样处理每一对需求：

输入：给你两个需求句子。
思考：
- 去查大楼图纸（RAG），看上下文。
- 看之前的 4 个例子（ICL），学怎么分类。
- 自己反思一下：“我为什么这么判断？我有多大的把握？”
输出：
- 结论：这两个需求有关系吗？如果有，是哪种关系（比如“必须依赖”、“互相冲突”、“只是重复”）？
- 理由：解释为什么这么判断。
- 自信度：打个分（0-5 分），表示它有多确定。

4. 效果如何？（成绩单）

作者们拿 LEREDD 和以前的老方法（比如简单的关键词匹配、传统的机器学习模型）做了一场“考试”，用了三个真实的汽车系统（比如自动泊车、交通拥堵辅助）的数据。

准确率极高：LEREDD 的准确率达到了 93% 左右。
特别擅长“排除法”：在现实中，绝大多数需求对其实没有依赖关系（比如“门把手”和“空调温度”通常没关系）。LEREDD 能非常精准地识别出这些“没关系”的情况（F1 分数高达 96%）。
- 比喻：这就像在几千个嫌疑人里，它能迅速排除掉 90% 无辜的人，让侦探（工程师）只需要重点调查剩下那 10% 真正可疑的。这大大节省了时间。
碾压旧方法：在识别复杂的依赖关系（比如“必须依赖”）时，它的表现比以前的方法好了一倍多（提升了 94% 到 105%）。
抗干扰能力强：即使把训练它的资料换成另一个完全不同的系统（比如从“汽车 A"换到“汽车 B"），它依然表现很好。而以前的机器学习模型一旦换了环境，表现就会大跌。

5. 总结：为什么这很重要？

以前，工程师要手动检查成千上万条需求，就像大海捞针，既累又容易漏。
现在，有了 LEREDD：

自动化：AI 自动帮你把那些“没关系”的需求先过滤掉。
更聪明：它不仅能找关系，还能解释为什么，甚至告诉你它有多确定。
省成本：工程师只需要花精力去审核 AI 认为“有关系”的那一小部分，效率大大提升。

一句话总结：
LEREDD 就像给软件工程师配了一位不知疲倦、读过所有图纸、还看过无数案例的超级助手，它能迅速从混乱的需求文档中理清头绪，把那些真正重要的“牵一发而动全身”的关系找出来，让软件开发变得更安全、更高效。

这是一份关于论文《Automating the Detection of Requirement Dependencies Using Large Language Models》（利用大语言模型自动化检测需求依赖）的详细技术总结。

1. 研究背景与问题 (Problem)

核心挑战：现代软件系统的需求（Requirements）数量庞大且高度复杂，需求之间存在着各种类型的依赖关系（如“需要”、“实现”、“冲突”等）。识别这些依赖对于影响分析、一致性检查和减少返工至关重要。
现有痛点：
- 人工检测困难：由于自然语言（NL）需求的模糊性、依赖关系的复杂性以及需求数量的增长，人工检测耗时、易错且认知负荷高。
- 现有方法局限：
  - 检索类方法（如 TF-IDF, LSA）：仅基于词汇或固定语义向量，缺乏领域上下文推理能力，无法处理复杂的依赖逻辑。
  - 知识类方法（如本体、图谱）：构建和维护成本极高，依赖专家知识。
  - 机器学习方法（如 Fine-tuned BERT）：需要大量标注数据，且难以解决依赖数据中普遍存在的类别不平衡问题（即“无依赖”的样本远多于“有依赖”的样本）。
研究缺口：虽然大语言模型（LLMs）在自然语言处理方面表现出色，但其在自动化检测需求依赖（特别是细粒度依赖类型）方面的有效性尚未得到充分探索。

2. 方法论：LEREDD 框架 (Methodology)

作者提出了 LEREDD (LLM-Enabled REquirement Dependency Detection)，一种基于大语言模型的自动化需求依赖检测框架。该框架结合了检索增强生成 (RAG) 和 上下文学习 (ICL) 技术。

输入：软件需求规格说明书 (SRS) 文档和标注好的需求对数据集。
核心流程：
1. 知识检索阶段 (Knowledge Retrieval)：
  - 上下文检索 (Contextual Retrieval)：利用 RAG 从 SRS 文档（特别是系统描述部分）中检索与当前需求对相关的领域特定上下文。这有助于模型理解系统架构和组件间的隐含关系。
  - 动态示例检索 (Dynamic Examples Retrieval)：利用 SBERT 模型计算语义相似度，从标注数据集中动态检索与目标需求对最相似的示例。针对每种依赖类型（如 Requires, Implements 等）以及“无依赖”情况，检索 $k$ 个最佳示例作为 Few-shot 提示。
2. 依赖推理阶段 (Dependency Inference)：
  - 模型选择：实验表明 GPT-4.1 在零样本设置下表现最佳，因此作为核心推理引擎。
  - 提示工程 (Prompting)：构建包含以下内容的增强提示：
    - 角色设定（专家需求工程师）。
    - 待分析的需求对。
    - 依赖类型的形式化定义（如 Requires, Implements, Conflicts, Contradicts, Details, Is similar, Is a variant）。
    - 检索到的领域上下文（RAG 结果）。
    - 检索到的动态示例（ICL 结果）。
    - 自我反思指令：要求模型输出依赖类型、判断理由（Rationale）以及置信度评分（1-5 分），以减少幻觉并提高可解释性。

3. 关键贡献 (Key Contributions)

提出了 LEREDD 框架：首次系统地探索了结合 RAG 和 ICL 的大语言模型方法，用于自动化检测多种类型的自然语言需求依赖。
构建了高质量数据集：创建并公开了一个包含 813 个需求对 的标注数据集，涵盖三个不同的汽车系统（交通拥堵辅助 TJA、自动泊车 APA、自适应远光灯 ADB）。该数据集包含 7 种依赖类型，填补了该领域公开基准数据的空白。
实证评估与对比：在三个系统上进行了广泛的实验，对比了零样本 LLM、Few-shot 策略、RAG 策略以及两种最先进（SOTA）的基线方法（TF-IDF+LSA 和微调 BERT）。
揭示了最佳实践：确定了最优的检索配置（SBERT 嵌入、欧氏距离、最大相似度聚合策略、每类 4 个示例）和 RAG 配置（10 个 500 字符的块），证明了检索质量优于检索数量。

4. 实验结果 (Results)

实验在三个汽车系统数据集上进行，主要发现如下：

零样本 (Zero-shot) 表现：GPT-4.1 在识别“无依赖”（No Dependency）类别时表现良好（F1 约 0.87），但在细粒度依赖（如 Requires, Implements）上表现较差（平均 F1 仅 0.39），表明零样本不足以处理复杂的工业级依赖推理。
提示策略优化 (RQ2)：
- Few-shot + RAG 的组合显著优于单独使用 Few-shot 或 Zero-shot。
- 最优配置下，No Dependency 的 F1 分数达到 0.95，Requires 达到 0.70，Implements 达到 0.70。
- 相比零样本，Requires 依赖的 F1 分数相对提升了 81.82%。
与基线对比 (Intra-dataset & Cross-dataset)：
- 准确率：LEREDD 在所有系统和依赖类型上均优于基线。平均准确率达到 92.66%，平均 F1 分数为 84.33%。
- 细粒度依赖提升：在 Requires 依赖检测上，LEREDD 相比基线（TF-IDF/LSA 和微调 BERT）取得了巨大的相对提升（平均相对增益分别为 94.87% 和 105.41%）。
- 跨数据集鲁棒性 (Cross-dataset)：在训练集和测试集来自不同系统的场景下，LEREDD 依然保持高性能（平均 F1 0.76），而微调 BERT 性能大幅下降。这证明了 LEREDD 对数据分布变化的强鲁棒性，解决了工业场景中目标系统标注数据稀缺的痛点。
- 类别不平衡处理：LEREDD 能有效处理“无依赖”样本占绝大多数的情况，F1 分数高达 0.96，能大幅减少人工筛选工作量。

5. 意义与影响 (Significance)

工程实践价值：LEREDD 能够高效、准确地过滤掉绝大多数“无依赖”的需求对，显著降低了需求分析师进行依赖分析的时间成本和认知负担。
技术突破：证明了通过 RAG 提供领域上下文和通过 ICL 提供任务示例，可以显著提升 LLM 在复杂推理任务（如需求依赖检测）中的表现，使其超越传统的机器学习和检索方法。
解决数据稀缺：通过跨数据集评估证明了该方法在缺乏目标系统标注数据的情况下依然有效，为工业界应用提供了可行的解决方案。
资源开源：发布的标注数据集和代码将促进未来在需求工程领域的研究和基准测试。

总结：该论文提出并验证了一种名为 LEREDD 的创新方法，利用大语言模型结合检索增强和上下文学习，成功解决了软件需求依赖检测中的模糊性、复杂性和数据不平衡问题，在精度、鲁棒性和实用性方面均显著优于现有最先进方法。