从 GitLab Issue 构建 RAG 知识库

一套真正适合企业研发场景的 AI 知识沉淀方案

一、为什么 RAG 是企业 AI 落地的必选项？

在企业内部引入大模型后，很多团队都会很快遇到一个现实问题：

AI 很聪明，但它不了解“我们”。

具体表现为：

不知道公司使用的技术栈
不清楚内部组件库和封装约定
给出的方案和历史决策相冲突
回答看起来“对”，但无法直接落地

于是，RAG（Retrieval-Augmented Generation）成为企业 AI 落地的共识方案。

但新的问题随之而来：

RAG 的知识，从哪里来？

二、为什么选择 GitLab Issue 作为 RAG 知识源？

很多团队第一反应是：

内部 Wiki
技术文档
README
设计文档

这些当然有价值，但它们有一个共同问题：

“文档描述的是‘应该如何’，而 Issue 记录的是‘实际发生了什么’。”

GitLab Issue 的独特价值

GitLab Issue 天然具备以下特性：

✅ 真实问题（不是假想场景）
✅ 完整上下文（问题 → 排查 → 结论）
✅ 包含失败经验
✅ 长期持续增长
✅ 紧贴真实代码与业务

换句话说：

Issue 是企业最真实、最被低估的知识资产。

三、用 Issue 做 RAG，有哪些天然优势？

1️⃣ 问题导向，非常适合问答

开发者问 AI 的问题，往往是：

“为什么会报这个错？”
“之前有没有人遇到过类似问题？”
“这个组件为什么这样设计？”

而 Issue 本身就是以问题为中心组织的，非常适合被检索。

2️⃣ 包含“过程”，而不仅是结论

一条高质量 Issue 通常包含：

问题描述
尝试过的方案
无效方案（非常重要）
最终结论或妥协方案

这些内容，正是通用文档里最缺失的部分。

3️⃣ 自动化程度高

相比 Wiki：

Issue 有 API
有状态（open / closed）
有标签（labels）
有时间维度
有参与人角色

非常适合做自动化采集与更新。

四、整体构建思路概览

从 GitLab Issue 构建 RAG 知识库，我们拆成 5 个阶段：

Issue 数据采集
Issue 清洗与筛选
Issue 结构化与语义重写
向量化与索引
持续更新与演进

五、第一步：Issue 数据采集

1️⃣ 通过 GitLab API 获取 Issue

重点关注字段：

title
description
labels
state
comments / notes
created_at / closed_at

通常建议：

只采集已关闭 Issue
或至少过滤明显无结论的 Issue

2️⃣ Issue 的“最小有效粒度”

不是所有 Issue 都值得进入 RAG：

❌ “这个需求什么时候上线？”
❌ “帮我看下这个 MR”

优先选择：

✅ Bug 修复
✅ 性能问题
✅ 架构讨论
✅ 技术决策类 Issue

六、第二步：Issue 清洗与筛选策略

1️⃣ 标签过滤

例如只保留：

bug
performance
tech-debt
architecture
frontend / backend

2️⃣ 质量过滤

可以通过规则或 AI 判断：

是否包含明确问题描述
是否有最终处理结果
是否有实质性讨论内容

宁愿少，也不要脏

七、第三步：Issue 结构化与语义重写（关键步骤）

这是整个流程中最重要的一步。

1️⃣ 原始 Issue 不适合直接向量化

原因包括：

内容冗长
多人对话穿插
无关寒暄
信息重复

2️⃣ 用 AI 将 Issue 转为“知识单元”

通过 MCP 服务或离线脚本，让 AI 对 Issue 做一次“知识整理”。

目标结构示例：

{
  "problem": "列表在大数据量下渲染卡顿",
  "context": "Vue2 项目，使用自研组件库",
  "attempts": [
    "虚拟列表",
    "节流滚动事件"
  ],
  "resolution": "问题根因在于组件内部 watcher 过多",
  "conclusion": "需要在组件层面优化"
}

这一步的本质是：