🤖 AI

RAG4Tickets: AI-Powered Ticket Resolution via Retrieval-Augmented Generation on JIRA and GitHub Data

该论文提出了 RAG4Tickets，这是一个通过检索增强生成技术整合 JIRA 和 GitHub 数据，以提供具备上下文感知且基于证据的工单解决建议的 AI 驱动框架，显著提升了软件开发工作流中的准确性和效率。

原作者： Mohammad Baqar

发布于 2026-02-06

📖 1 分钟阅读☕ 轻松阅读

原作者： Mohammad Baqar

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

想象一下你是一名正在处理大型项目的软件开发人员。每当出现一个 Bug 时，它就像是一个新的侦探案件。在过去，解决这些案件就像是在数百万根针组成的草堆中寻找一根针。你必须翻阅旧的 JIRA 工单（错误报告）、阅读成千上万条开发者评论，并扫描 GitHub 的代码变更，以查看是否有人已经解决了类似的问题。通常，即使问题完全相同，由于描述问题的措辞不同，你会错过解决方案，从而白白浪费数小时去重复造轮子。

这篇名为 “RAG4Tickets” 的论文提出了一种智能助手，它就像是一个超级强大的图书管理员和侦探的结合体，旨在解决这个问题。以下是它的工作原理，分为几个简单的步骤：

1. 问题所在：“翻译丢失”的图书馆

把你们公司的 Bug 和修复历史想象成一个巨大且混乱的图书馆。

问题： 一名开发者写道：“点击按钮时应用卡死了。”而两年前的另一名开发者写道：“用户交互期间屏幕锁定了。”尽管它们指的是同一个问题，但简单的关键词搜索可能会错过这种联系。
结果： 开发者把太多的时间花在了搜索上，而不是修复上。

2. 解决方案： “智能图书管理员” (RAG)

作者构建了一个名为 RAG4Tickets 的系统。你可以把这个系统想象成一位训练有素的图书管理员，她不仅能读懂书名，还能理解书背后的含义。

第一步：阅读与理解（嵌入/Embeddings）：
该系统会阅读每一份旧的错误报告、评论和代码变更（Pull Request）。它使用一种名为 Sentence-Transformers 的特殊工具将这些文字转化为“意义地图”（向量）。它不仅仅是寻找“崩溃（crash）”这个词，而是理解“冻结（freeze）”、“锁定（lock up）”和“挂起（hang）”都指向同一个概念。
第二步：超快速搜索（FAISS）：
一旦系统拥有了这些意义地图，它就会将它们存储在一个名为 FAISS 的大规模、超快速索引中。想象一下这是一张神奇的地图，相似的想法在物理位置上紧挨在一起。当新的 Bug 出现时，系统能瞬间找到前 5 或前 10 个最相似的历史案例，即使它们的措辞完全不同。
第三步：侦探报告（LLM 生成）：
系统不仅仅是向你展示旧的工单；它更像是一个总结案件的侦探。它提取找到的旧解决方案，并将它们输入给一个 大语言模型（AI）。随后，AI 会编写一份清晰的、分步骤的指南，指导如何修复新的 Bug，并准确引用是哪些旧的代码变更解决了该问题。这就像是一位资深工程师在你耳边低语：“嘿，我们去年正好修过这个，这是当时用的代码。”

3. 现实生活中的运作方式

论文在一次 Web 应用程序的大型升级（从 React 18 迁移到 React 19）过程中测试了这个系统。

场景： 开发者们正为一个由新软件版本引起的特定类型“UI 冻结”问题而苦恼。
结果： 系统找到了与类似冻结现象相关的旧工单和代码变更。它告诉开发者：“这看起来像是我们之前遇到的问题。这是我们当时使用的修复代码。”
成果：
- 速度： 修复 Bug 所需的时间从 18.5 小时降至 10.2 小时（提升了 45%）。
- 信任度： 大约 68% 的情况下，开发者直接接受了 AI 的建议，或者仅进行了微小的修改。
- 准确性： 该系统寻找正确历史案例的能力非常出色（82% 的情况下，正确答案出现在前 5 个结果中）。

4. 为什么这很重要

论文强调，这不仅仅是为了更快，更是为了避免凭空捏造。

无幻觉： 因为 AI 被迫在编写解决方案之前必须查阅真实的、历史性的证据（旧工单和代码），所以它不太可能编造虚假的修复方案。这就像一个学生在回答测试题之前，必须先引用教科书的内容。
知识复用： 它防止了公司丢失其“机构记忆”。当一名资深开发者离职时，他们的知识不会随之流失；它被锁定在系统中供所有人使用。

5. 局限性（代价）

作者诚实地指出了面临的挑战：

旧的错误： 如果旧的工单包含了错误的建议，系统可能会重复这些错误。
变化的语言： 如果软件技术发生剧变（例如 React 的新版本），旧的“意义地图”可能会变得不再准确，需要对系统进行重新训练。
成本： 运行此系统需要强大的计算机，以便能够即时搜索数百万条记录。

总结

简而言之，RAG4Tickets 是一个连接过去问题与当前解决方案的工具。它将混乱的 Bug 报告堆变成了一个智能、可搜索的知识库，帮助开发者更快地解决问题，减少挫败感，并确信他们是在基于经过验证的、真实的修复方案进行开发。

技术摘要：RAG4Tickets —— 基于检索增强生成的 AI 驱动票据解决系统

1. 问题陈述

现代软件开发团队在解决重复性问题时面临显著延迟，这是由于知识碎片化地散落在 JIRA 工单、开发者讨论和 GitHub 拉取请求（PR）中造成的。随着项目的规模扩大，工单和代码变更的指数级增长导致了信息过载。开发者往往难以定位语义相似但语言表达不同的历史解决方案（例如，将“UI crash”与“application freeze”进行匹配）。传统的用于错误分类的有监督机器学习方法往往无法捕捉现实世界错误报告中固有的语义变异性，从而导致分拣（triage）和解决效率低下。

2. 方法论

本文提出了 RAG4Tickets，这是一个旨在将异构软件制品统一到上下文感知解决流水线中的检索增强生成（RAG）框架。该系统通过四个主要层级运行：

数据摄取与预处理： 系统摄取来自 JIRA（标题、描述、状态、评论）和 GitHub（PR、提交信息、差异/diff、评审评论）的结构化数据。预处理包括文本归一化、去除冗余信息，并使用抽象语法树（AST）解析器在函数级别对代码差异进行摘要，以减少噪声。
嵌入层（Embedding Layer）： 异构制品被转换为稠密向量表示。框架利用 Sentence-Transformers（具体为 all-MiniLM-L6-v2 和 multi-qa-MPNet-base-dot-v1）处理文本数据（工单、评论）。对于代码特定数据（PR diffs），它采用结合 CodeBERT 和 GraphCodeBERT 的混合策略，以捕捉结构依赖性和编程语义。嵌入按制品类型进行分区，以实现定向搜索。
检索层： 所有嵌入使用 FAISS（Facebook AI Similarity Search）进行索引，以执行近似最近邻（ANN）搜索。系统评估了不同的索引结构（Flat, IVF, HNSW），并选择了 HNSW，因为它在企业级数据集（数百万个向量）中实现了速度与召回率的最佳平衡。在收到新工单时，系统会对该工单进行编码，并检索前 $k$ 个语义最相似的历史工单、评论和 PR。
生成层： 检索到的证据被综合成一个结构化提示词（prompt）传递给大语言模型（LLM）。LLM 生成有据可依的解决建议，包括逐步计划、相关 PR/提交的超链接以及置信度评分。该层旨在通过严格基于检索到的证据来最大限度地减少幻觉。

部署集成： 该框架是模块化的，允许通过 JIRA 插件（用于自动化分拣评论）、GitHub Actions（用于关联 PR 的问题呈现）以及 CI/CD 流水线（用于自动分拣重复的测试失败）进行集成。

3. 核心贡献

论文概述了五项主要贡献：

统一架构： 一个摄取并关联 JIRA 和 GitHub 数据的流水线，建立了工单与代码变更之间的显式连接。
专门的嵌入策略： 一种针对异构制品的定制化方法，结合了语义文本嵌入与具备代码感知能力的嵌入（CodeBERT），以同时捕捉自然语言和结构化代码的相似性。
证据引导的决策流水线： 一种 RAG 工作流，其中检索到的历史证据直接引导 LLM 生成解决建议，确保了可追溯性。
全面的评估： 使用信息检索（IR）指标（Recall@k, Mean Reciprocal Rank）和开发者生产力度量（解决时间、接受率）进行了评估。
实际案例研究： 一个涉及 React 19 微服务迁移的真实部署场景，展示了系统处理与弃用生命周期方法及状态管理相关的重复问题的能力。

4. 实验结果

系统在一个包含约 15,000 个 JIRA 工单和 6,500 个 GitHub PR 的数据集上进行了评估，该数据集来自一个大规模 React 19 迁移项目。

检索性能： 使用 HNSW 索引，系统实现了 82% 的 Recall@5 和 91% 的 Recall@10，平均倒数排名（MRR）为 0.78。这表明相关的历史解决方案通常能在前五个结果中被找到。
生成质量： 在 500 个未见过的议题测试集上，生成的解决方案达到了 0.47 的 BLEU 分数和 0.62 的 ROUGE-L。至关重要的是，事实一致性得分为 84%，证明了 LLM 在很大程度上遵循了检索到的证据，从而减少了幻觉。
业务影响： 在三个敏捷团队的部署中，该系统带来了以下改进：
- 解决时间： 从平均 18.5 小时减少到 10.2 小时（提升了 45%）。
  - 接受率： 开发者直接采用或轻微修改 AI 建议的解决方案的比例为 68%。
- 生产力： 开发者报告了 32% 的自我感知生产力提升，这归功于减少了在重复分拣和手动搜索方面花费的时间。

5. 重要性与局限性

论文指出，RAG4Tickets 展示了 AI 增强的 DevOps 工作流如何减轻认知负荷并增强组织知识的复用。通过弥合非结构化历史数据与自动化解决之间的鸿沟，该框架为构建上下文感知工程环境提供了一条可扩展的路径。

然而，作者对当前的局限性保持了审慎的态度：

幻觉风险： 虽然事实落地性较高（84%），但当 LLM 超出检索到的证据进行推断时，偶尔仍会出现幻觉。
数据偏差与漂移： 系统存在传播来自遗留数据中的次优模式的风险，并且随着框架的演进（例如从 React 18 到 19），可能会出现语义漂移。
运营成本： 对大型仓库进行索引和频繁的 LLM 推理会引入计算和延迟开销。

论文总结道，虽然该系统在自动化软件维护方面显示出强大潜力，但长期成功取决于通过检索验证来减轻幻觉风险、确保模型对不断发展的技术的适应性，以及通过保持透明度来建立开发者信任。未来的工作提议包括引入检索验证层、基于人类反馈的强化学习（RLHF），以及结合稠密与稀疏搜索方法的混合检索架构。