在软件开发的浩瀚星空中，自然语言需求如同闪烁的星光，指引着程序员的航向。然而，这些需求往往模糊、抽象，与最终的代码实现之间仿佛隔着一片语义的星际迷雾。如何在这片迷雾中架起一座坚实的桥梁，将高层次的业务需求精准映射到代码的类和方法上？本文将带你走进一项突破性的研究——通过结合检索增强生成（RAG）和大型语言模型（LLM），实现从自然语言需求到代码的追溯。这不仅是一场技术革新，更是一场关于如何让软件开发更高效、更可靠的冒险。
注解：追溯（Traceability）在软件工程中指从需求到设计、代码、测试等开发阶段的关联能力。它的核心价值在于确保每个代码片段都能与特定的业务需求对应，从而便于维护、验证和变更管理。
🌌 追溯的星空：为何需求与代码的链接如此重要？
想象一下，你是一名宇航员，任务是修复一艘复杂的太空飞船。飞船的设计图（UML类图）可能已经过时，真正的“操作手册”藏在飞船的电路（源代码）中。而你的任务书——用自然语言写成的用户需求——却像一封来自遥远星球的信，充满了模糊的术语和抽象的描述。如何确保你的修理工作精准无误？答案是：你需要一张精确的导航图，将任务书的每一行文字映射到飞船的具体部件。这正是软件工程中需求追溯的意义。
需求追溯不仅关乎验证系统是否按预期构建，还涉及变更影响分析、软件复用以及团队间的沟通。在大型项目中，手动维护这种追溯如同在星际迷雾中徒手绘制星图：费时、易错且难以扩展。传统方法往往依赖文本相似性匹配，但自然语言需求的高层次语义与代码的低层次语法之间存在巨大的“语义鸿沟”。例如，一个需求可能描述“用户需要查看文化遗产列表”，而代码中对应的可能是名为CulturalHeritageManager的类和listHeritage方法。仅靠关键词匹配，很难跨越这道鸿沟。
注解：语义鸿沟（Semantic Gap）指自然语言的高层次、抽象表达与代码的低层次、具体实现之间的含义差异。传统方法如TF-IDF或简单的词嵌入往往只能捕捉表面相似性，忽略深层语义。
🛠️ RAG与LLM的星际引擎：技术如何点亮追溯之路？
为了跨越语义鸿沟，研究者们引入了大型语言模型（LLM）和检索增强生成（RAG）技术，打造了一台“语义导航引擎”。这项名为RARTG（Retrieval Augmented Requirements Traceability Generation）的技术，结合了LLM的语义理解能力与RAG的外部知识检索能力，试图将需求与代码的追溯提升到一个新的高度。
大型语言模型：语义的解码器
LLM，如Llama 3或GPT-4，经过海量文本和代码的训练，能够理解自然语言的细微含义，并将代码的语法逻辑转化为更贴近业务的高层次描述。例如，给定一段Java类代码，LLM可以生成一段总结，描述这个类的功能、方法的作用以及它在系统中的角色。这种能力就像是将飞船的电路图翻译成宇航员能理解的维修指南。
注解：LLM的训练基于预测文本序列，通过学习语言模式生成连贯的回应。它们在代码总结、生成和注释等任务中表现尤为出色，但对特定领域的需求理解仍需外部知识支持。
RAG：知识的星际导航仪
RAG通过检索外部知识源（如代码库中的注释、文档或依赖关系），为LLM提供丰富的上下文。它的核心思想是将查询（需求）与相关文档（代码片段）匹配，然后利用这些文档生成更精准的回答。RAG的工作流程包括两部分：
- 检索器：从代码库中提取与需求相关的文档。它使用关键词索引（KI）、向量索引（VI）和知识图谱索引（KGI）三种方式，分别基于文本相似性、语义嵌入和代码的结构依赖关系。
- 生成器：LLM根据检索到的文档和需求，生成最终的追溯结果，例如列出与需求相关的类名。
RAG的优势在于它不仅依赖LLM的内置知识，还能动态引入代码库中的上下文信息。这种“即插即用”的知识增强方式，使得追溯过程更灵活、更贴合特定项目的需求。
注解：向量索引（VI）使用如BERT的嵌入模型，将文本和代码转化为高维向量，捕捉深层语义。知识图谱索引（KGI）则基于代码的依赖关系（如方法调用），提供结构化上下文。
📊 RARTG的架构：从需求到代码的星际航线
RARTG的架构如同一艘精密的星际飞船，分为索引阶段和查询阶段，通过多个模块协同工作，完成从需求到代码的追溯。以下是其核心流程：
🚀 索引阶段：构建知识星图
在索引阶段，RARTG为代码库生成三种索引，以捕捉代码的语义和结构信息：
代码总结生成
许多代码库的文档（如docstrings）要么缺失，要么过于技术化，难以反映高层次的业务目的。RARTG利用LLM（如Llama 3）为每个类生成总结，描述其功能、属性和方法。例如，对于一个Java类，LLM可能生成：
Class Name: CulturalHeritageManager
Summary: Manages operations related to cultural heritage entities, including creation, deletion, and listing.
Method Name: listHeritage
Summary: Retrieves a list of cultural heritage items based on user query.
这些总结通过精心设计的提示（prompt）生成，确保捕捉类的业务上下文。
关键词索引（KI）
KI将代码视为自然语言文档，应用词干提取（PorterStemmer）和停用词移除等预处理技术，生成基于关键词的索引。它适用于快速匹配需求中的显式术语，但可能忽略深层语义。
向量索引（VI）
VI使用多语言嵌入模型（如M3-embedding）将代码和总结转化为高维向量。这些向量捕捉了代码的语义信息，适用于跨语言（例如英文和意大利文）的追溯任务。
知识图谱索引（KGI）
KGI基于代码的函数依赖图（FDG），以图结构存储类之间的调用关系。每个节点包含类名和文档，边表示方法调用关系。KGI存储在Neo4j数据库中，支持结构化查询。
🌠 查询阶段：导航至代码的星辰
查询阶段接收自然语言需求，并通过以下步骤生成追溯结果：
需求提示生成
系统将需求嵌入一个提示模板，例如：
What are the names of the classes that are related to the following use case requirement?
"View the list of CulturalHeritage as a result of the use case SearchCulturalHeritage"
Provide the answer in a list format: ["Class1", "Class2", ...]
为增强需求的语义，系统通过LLM生成语义相似的需求（查询扩展，QE），但这可能引入噪声。
相关文档检索
检索分为三阶段（RS1-RS3）：
- RS1：使用KI和VI检索与需求语义相似的文档。
- RS2：通过KGI添加与检索文档结构上相关的邻居文档，弥补语义检索的不足。
- RS3：应用语义过滤，剔除相似度低于阈值的文档，确保上下文精炼。
响应生成
LLM接收需求和检索到的文档，生成一个JSON列表，列出与需求相关的类名。上下文的丰富性直接影响结果的准确性。
📈 实验星际日志：RARTG的性能如何？
研究者在四个公开数据集（eTour、iTrust、SMOS、eAnci）上评估了RARTG的性能，涵盖旅游、医疗、教育和治理等多个领域。这些数据集包含自然语言需求和Java代码，语言包括英文和意大利文。评估指标包括精确率（Precision）、召回率（Recall）和F1分数。
研究问题与发现
- RQ1：RARTG与现有方法的比较
RARTG在iTrust和eAnci数据集上的F1分数分别提升了约6%，精确率显著优于基线方法（例如[14]中的方法）。在SMOS和eTour上，F1分数略低于基线，主要因召回率不足，但精确率依然领先。这表明RARTG在生成准确的追溯链接方面更可靠，尤其适用于需要高精确度的场景。
图表展示：追溯性能比较
以下是改编自原文表2的性能对比：
| 数据集 | 方法 | 精确率 | 召回率 | F1分数 |
|--------|--------|--------|--------|--------|
| iTrust | 基线 | 0.176 | 0.353 | 0.235 |
| | RARTG-C1 | 0.289 | 0.292 | 0.290 |
| eAnci | 基线 | 0.294 | 0.220 | 0.252 |
| | RARTG-C1 | 0.779 | 0.199 | 0.317 |
| SMOS | 基线 | 0.443 | 0.297 | 0.356 |
| | RARTG-C1 | 0.608 | 0.126 | 0.209 |
| eTour | 基线 | 0.411 | 0.623 | 0.495 |
| | RARTG-C1 | 0.543 | 0.242 | 0.334 |
- RQ2：参数对性能的影响
- 生成总结（GS）：在iTrust和eAnci上，LLM生成的总结显著提升F1分数，表明高层次的语义总结能有效桥接语义鸿沟。
- 方法调用（MC）：效果因数据集而异，iTrust上呈负影响，eAnci和SMOS上呈正影响，表明方法调用的语义质量至关重要。
- 查询扩展（QE）：意外地，在多个数据集上引入噪声，降低性能，提示需谨慎使用。
- 知识图谱索引（KGI）：通过添加结构化上下文，显著提升iTrust、SMOS和eTour的性能。
- 组合索引（CI）：综合KI、VI和KGI的索引在大多数数据集上表现最佳，凸显多模态索引的优势。
图表展示：参数影响统计
以下是改编自原文表3的参数影响分析：
| 参数 | 数据集 | T统计量 | P值 | 效果 |
|------|--------|---------|------|------|
| GS | iTrust | 2.60 | 0.02 | 显著正向 |
| | eAnci | 5.48 | <0.05| 显著正向 |
| MC | iTrust | -2.36 | 0.03 | 显著负向 |
| | eAnci | 2.24 | 0.04 | 显著正向 |
| QE | iTrust | -4.77 | <0.05| 显著负向 |
| KGI | iTrust | 25.84 | 0.02 | 显著正向 |
| CI | eTour | 7.96 | <0.05| 显著正向 |
🌟 讨论：从星际迷雾到清晰航线
RARTG的成功在于它将LLM的语义理解与RAG的上下文检索相结合，填补了需求与代码之间的语义鸿沟。以下是几点关键洞察：
语义总结的力量
LLM生成的代码总结为代码库注入了高层次的业务上下文，尤其在文档缺失或过于技术化的场景下效果显著。这就像为飞船的每个部件附上一份通俗易懂的说明书。
结构与语义的协同
知识图谱索引通过捕捉代码的依赖关系，弥补了纯语义检索的不足。结构化信息就像星图中的星座线，将看似孤立的代码片段连接成一个有意义的整体。
召回率的瓶颈
RARTG的召回率较低，主要是因为严格的语义阈值限制了文档检索范围。未来的改进方向包括分层检索，先获取更多文档，再通过领域特定规则精炼上下文。
通用性与局限性
RARTG在多语言（英文和意大利文）数据集上的稳健表现，显示了其跨语言适应的潜力。然而，其性能依赖于代码库的质量和需求的清晰度，模糊的需求可能导致追溯偏差。
注解：召回率低意味着某些相关代码可能未被检索到，但高精确率确保了检索到的链接高度可靠。这在追溯任务中尤为重要，因为错误的链接可能误导开发和维护。
🔮 未来星际航程：RARTG的潜力与展望
RARTG不仅是一项技术突破，更为软件工程的未来指明了方向。研究者计划将RARTG扩展为一个工具，支持UML类图的动态更新和需求变更影响分析。这将使开发团队能够实时跟踪需求变化对设计和代码的影响，如同拥有一台实时更新的星际导航仪。
此外，研究者公开了RARTG的源代码（GitHub链接），邀请社区共同完善。这不仅体现了开放科学的理念，也为业界提供了可扩展的追溯解决方案。
注解：公开源代码是软件工程研究的重要趋势，它允许开发者复现实验、定制工具，并推动技术在实际项目中的应用。
📚 参考文献
- Center of Excellence for Software & Systems Traceability (CoEST). (2024). http://sarec.nd.edu/coest/datasets.html
- Hey, T., Chen, F., Weigelt, S., Tichy, W.F. (2021). Improving traceability link recovery using fine-grained requirements-to-code relations. IEEE International Conference on Software Maintenance and Evolution (ICSME), 12–22.
- Hou, X., Zhao, Y., Liu, Y., et al. (2023). Large language models for software engineering: A systematic literature review. CoRR abs/2308.10620.
- Chen, J., Xiao, S., Zhang, P., et al. (2024). M3-embedding: Multi-linguality, multi-functionality, multi-granularity text embeddings through self-knowledge distillation. Findings of ACL 2024, 2318–2335.
- Booch, G., Rumbaugh, J.E., Jacobson, I. (2005). The unified modeling language user guide - covers UML 2.0. Addison-Wesley.
