[Paper] 利用大型语言模型支持 CI/CD 流水线中故障管理的自动化：SAP HANA 案例研究

Source: arXiv - 2602.06709v1

Overview

本文研究了大型语言模型（LLM）是否能够可靠地在真实的企业级项目——SAP HANA 中自动检测和修复 CI/CD 流水线故障。通过向 LLM 提供各种领域知识，作者展示了它能够精准定位故障组件，并提出具体可操作的修复方案，效果远优于普通的 LLM。

关键贡献

• LLM 驱动的故障管理原型，用于生产级 CI/CD 流水线（SAP HANA）。
• 系统性评估 三种知识来源：流水线元数据、显式故障管理指令以及历史故障案例库。
• 消融研究，量化每种知识来源对定位准确性和解决方案生成准确性的影响。
• 实证结果 表明，错误定位准确率达到 97.4 %（未使用领域知识时为 84.2 %），在包含历史故障数据时精确解决方案率为 92.1 %。
• 实践指南，用于将 LLM 集成到现有 DevOps 工具链中。

方法论

1. 数据收集 – 作者从 SAP HANA 的构建流水线中提取了 1,200 条 CI/CD 失败实例，每条都标注了：

   • 失败步骤（错误位置）。
   • 人工编写的修复指令。
   • 上下文元数据（例如受影响的模块、测试套件）。

2. 知识注入 – 准备了三个“知识包”：

   • 流水线信息 – 关于 CI/CD 阶段和制品依赖的结构化数据。
   • 管理指令 – SAP 工程师使用的经过策划的基于规则的指南集合。
   • 历史失败 – 可搜索的过去失败日志及其已解决方案档案。

3. LLM 提示工程 – 使用最先进的 LLM（GPT‑4‑style），将失败日志与一个或多个知识包一起作为提示输入模型。提示要求模型 (a) 定位错误并 (b) 输出最小化、可执行的修复方案。

4. 消融实验 – 系统在四种配置下运行：

   • 无外部知识（基线）。
   • 仅流水线信息。
   • 仅管理指令。
   • 仅历史失败。
   • 三者全部结合。

5. 评估指标 –

   • 定位准确率 – 正确识别失败的流水线阶段。
   • 解决方案精确度 – 所建议的修复是否与人工验证的解决方案完全匹配且没有多余步骤。

结果与发现

• 历史失败数据占主导：它们提供具体的模式，LLM 可以匹配，从而显著提升定位和解决的准确性。
• 合并所有来源的边际收益 表明，一旦拥有丰富的失败档案，收益递减。
• LLM 始终生成最小化的修复——没有额外步骤，也没有“最佳实践”之类的冗余——使输出可直接用于自动执行。

实际影响

• 自动化分诊机器人：团队可以在 CI/CD 仪表盘中嵌入基于 LLM 的助手，瞬间呈现根本原因并提供可直接运行的修复方案，将平均恢复时间（MTTR）缩短至分钟甚至小时。
• 知识库利用：已经维护可搜索的历史构建失败日志的公司，只需将该档案喂给 LLM，即可实现即时 ROI，无需自行构建规则引擎。
• 可扩展的 DevOps：该方法随故障档案规模的增长而扩展；记录的事件越多，模型的精度越高，形成良性反馈循环。
• 集成简便：由于解决方案以纯文本命令或配置片段的形式生成，可直接管道到现有自动化工具（如 Jenkins、GitHub Actions），无需大量 API 开发。
• 降低值班疲劳：初级工程师或值班人员可以依赖助手进行一线诊断，让高级人员专注于更高价值的工作。

限制与未来工作

• 领域特定性：研究聚焦于 SAP HANA；对于日志结构较少的流水线或历史档案中未涵盖的语言/框架，结果可能有所不同。
• 模型幻觉风险：尽管准确性很高，但偶尔出现的幻觉指令仍可能导致失败；建议加入验证步骤（例如沙箱执行）。
• 知识维护：保持历史失败库的最新需要严格的日志记录和整理——这是一项论文未涉及的运营开销。
• 提示大小的可扩展性：非常大的知识包可能超出当前 LLM API 的 token 限制；未来工作可以探索检索增强生成或基于向量的相似度搜索，以保持提示简洁。
• 更广泛的指标：作者测量了准确率，但未评估下游业务影响（如成本节约、开发者满意度）。将评估扩展到这些维度是自然的下一步。

作者

• Duong Bui
• Stefan Grintz
• Alexander Berndt
• Thomas Bach

论文信息

• arXiv ID: 2602.06709v1
• 分类: cs.SE
• 发布于: 2026年2月6日
• PDF: 下载 PDF