[Paper] 从问题到洞察：基于RAG的解释生成来自软件工程制品

Source: arXiv - 2601.05721v1

Overview

现代软件系统变得如此复杂，以至于开发者和用户都难以理解系统为何会表现出某种行为。论文《From Issues to Insights: RAG‑based Explanation Generation from Software Engineering Artifacts》表明，存储在问题追踪系统（例如 GitHub Issues）中的大量信息可以通过检索增强生成（Retrieval‑Augmented Generation，RAG）流水线转化为清晰、上下文特定的解释。作者构建了一个原型，能够自动起草可供人类阅读的解释，并展示其在 90 % 的情况下与手工编写的解释保持一致。

关键贡献

• 首个用于软件工程解释的 RAG 应用 – 利用问题追踪器数据，而不仅仅是源代码。
• 基于公开可用的 LLM 和检索工具的开源概念验证，实现可复现性。
• 与人工解释高度一致（≈ 90 % 匹配），同时保持对原始问题内容的强忠实性。
• 全面的评估指标，涵盖一致性、忠实性和指令遵循，表明该方法既准确又可靠。
• 可扩展解释性的蓝图，将解释能力从机器学习模型延伸到任何在结构化工件中记录开发知识的系统。

方法论

1. 数据收集 – 作者从一个开源项目中收集了具有代表性的 GitHub issue，提取标题、描述、评论、标签以及关联的 pull request。
2. 检索层 – 使用密集向量存储（例如 FAISS）对 issue 文本进行索引。当用户请求解释特定行为时，系统首先根据语义相似度检索出最相关的 issue 条目。
3. 增强生成 – 将检索到的片段与指示语言模型“用通俗语言解释观察到的行为”的提示一起输入生成式大模型（例如 Llama‑2 或 GPT‑3.5）。
4. 后处理与验证 – 对生成的文本进行一致性过滤，检查其与源 issue 的事实依据，最后呈现给用户。
5. 评估 – 人类标注者将系统输出与人工编写的解释进行比较，评分对齐度、事实忠实度以及对指令提示的遵循程度。

该流水线刻意保持模块化，以便可以将每个组件（检索器、向量存储、LLM）替换为更新的或特定领域的替代方案。

结果与发现

这些数字表明，基于 RAG 的系统能够可靠地将原始问题数据转化为对开发者友好的解释，同时不牺牲准确性。

实际影响

• On‑the‑fly documentation – 团队可以直接从问题追踪系统生成针对新功能或 bug 的最新解释，从而降低传统文档的维护负担。
• Improved onboarding – 新员工可以查询系统（例如“为什么组件 X 在条件 Y 下会失败？”），并获得简洁、上下文感知的答案，加快上手速度。
• Support & troubleshooting – 面向客户的支持工具可以展示自动生成的解释，减少手动更新知识库的工作量。
• Compliance & audit trails – 监管机构通常要求系统行为有明确的理由；基于 RAG 的解释引擎可以生成可审计的叙述，并以已记录的问题为依据。
• Extensible to other artifacts – 相同的架构可以接收提交信息、设计文档或测试报告等其他工件，扩大软件生命周期中可解释性的范围。

限制与未来工作

• 依赖问题质量 – 该方法假设 issue（问题）写得很好并包含必要的技术细节；噪声多或信息稀疏的 issue 数据会降低输出质量。
• 领域特定性 – 原型仅在单个开源项目上进行评估；需要在不同语言、框架和企业环境中进行更广泛的验证。
• 检索的可扩展性 – 虽然 FAISS 适用于中等规模的语料库，但大规模工业 issue 跟踪系统可能需要更复杂的索引或分层检索。
• 解释器的可解释性 – 系统本身是一个黑箱 LLM；未来工作可以加入自我解释或置信度评分，以进一步提升可信度。
• 用户交互设计 – 探索 UI/UX 模式（例如查询的交互式细化）可以使工具在真实开发工作流中更易用。

总体而言，本文为将 issue 跟踪器中隐含的隐性知识即时获取开辟了有前景的道路，使“issue”转化为开发者和组织都可操作的洞见。

作者

• Daniel Pöttgen
• Mersedeh Sadeghi
• Max Unterbusch
• Andreas Vogelsang

论文信息

• arXiv ID: 2601.05721v1
• 分类: cs.SE
• 出版日期: 2026年1月9日
• PDF: 下载 PDF